What should a shell script wait for after installing Argo CD?
Asked by
VelvetMango42
I'm installing Argo CD from a Kubernetes manifest in a shell script: first creating the namespace, then applying the installation YAML with server-side apply and forced conflict resolution. Before running the next commands, I want to know that the installation is usable.
Using `kubectl wait` against every object is unreliable because resources such as ServiceAccounts, ConfigMaps, Services, and RBAC objects do not expose a Ready condition. Is there a recommended way to wait for the installation to finish, or should I wait for a specific workload or endpoint that indicates the rest of the installation has completed?
Answers
Kubernetes is eventually consistent, so there usually isn’t one universally meaningful “last” object in a manifest. Apply the resources, wait for the components your script actually depends on, and verify the resulting behavior. If the next step uses the Argo CD CLI or API, checking that endpoint is a better completion criterion than checking whether every manifest object exists.
Reply to this answer
If you manage the installation with Helm, its wait options can handle waiting for the relevant workloads and return only after they are ready. For later deployments, Argo CD can also manage its own configuration, although the initial installation still needs to be bootstrapped separately.
Reply to this answer
For resources that are created asynchronously, wait for the specific conditions they support. For example, CRDs can be waited on with `kubectl wait --for=condition=Established crd ...`. Then wait for the Argo CD Deployments or StatefulSets with `kubectl rollout status`, for example:
`kubectl rollout status deployment,statefulset -n argocd -l app.kubernetes.io/part-of=argocd --timeout=300s`
This avoids failures caused by objects that have no Ready condition. Be aware that commands issued immediately after `apply` can also fail if the API server has not registered the resources yet, so use suitable timeouts and retry logic.
Reply to this answer
Don’t wait on every object in the manifest. Wait for the workloads that actually have a rollout, such as Argo CD Deployments and StatefulSets, with an explicit timeout. If those workloads become ready, their required Secrets, ConfigMaps, PVCs, ServiceAccounts, and RBAC resources should already be available. You can then add a small health check against the Argo CD API if you need to verify that it is genuinely responding.
CopperLime19: That’s generally the sweet spot: wait for the core Deployments and StatefulSets, then use a short `curl` loop against the API endpoint. Trying to apply a readiness condition to every object usually creates more race conditions than it solves.
Reply to this answer
Add your answer
Answers are reviewed before publication.
VelvetMango42: That makes sense for my case—the next commands use Argo CD itself, so checking that its API is responding is more useful than trying to assign a readiness state to ServiceAccounts and similar objects.