Why Kubernetes Resources created by new argoexec pod using kubectl? Why not excute kubectl in workflow-controller pod?

[yostao]

Hi, I'm new in argo project.

A few questions make me very confused recently when I'm reading codes near workflowpod:

• Why Kubernetes Resources decribed by manifest are created by a new argoexec pod using kubectl?
• Why not excute kubectl in workflow-controller pod?
• Creating a new argoexec pod need time and resource in the cluster. What do we think about creating effectiveness? What if the resource in this cluster is not sufficient to schedule and create this argoexec pod?

I'm really grateful to your reply! Thank you!

[yostao]

Hi @jessesuen , I'm wondering if you can see this Question and give me some point to understand. Thank you very very much!

[jessesuen]

Why Kubernetes Resources decribed by manifest are created by a new argoexec pod using kubectl? Why not excute kubectl in workflow-controller pod?

It was designed this way because of the current security model. If the workflow controller were to handle resource CRUD operations, then the workflow controller would need to be given god privileges in order to create/delete/update any kubernetes resource, which makes the controller an extremely high value target for attack.

Instead, we felt the ability to manage other resources should be done with the permissions of service accounts in the namespace. Which puts the onus on the user to front the credentials necessary to perform resource mutations.

Creating a new argoexec pod need time and resource in the cluster. What do we think about creating effectiveness? What if the resource in this cluster is not sufficient to schedule and create this argoexec pod?

It is true that by having a pod perform the resource management, it means that an entire Pod needs to be running to do resource management. But this tradeoff is preferred because of the security model and benefit it provides.

However, there is a second reason why the design is to distribute the work into argoexec pods, and that is scalability. Resource templates are often used to watching the resources it manages and complete as soon as it meets some condition (e.g. to wait until a job completes). All this logic/watches are currently distributed to the argoexec pods. If we were to move this logic into the controller, the controller would then have to do all the work, which is not scalable.

[yostao]

Thanks a lot. Your reply is really helpful.
Best regard!

[terrytangyuan]

What if the resource in this cluster is not sufficient to schedule and create this argoexec pod?

@yostao Regarding this specific question, you can configure executor/main container's resources via controller's config map or workflow spec's podSpecPatch to only allocate small amount of resources to those pods.

[yostao]

Thank you, I'll try it later.
:)