Install Argo CD with Helm (and survive the missing-CRD trap)
This exam question looks like three Helm commands: add a repository, render a template, install a release. And it hands you a comforting line: the Argo CD CRDs have already been pre-installed in the cluster. In this lab that line is false, on purpose, and what happens next teaches you exactly what crds.install=false really means. Let's run it.
🎥 Watch the video: https://www.youtube.com/watch?v=kYcHmIh_eHw
This is a CKA Cluster Architecture, Installation & Configuration walkthrough. Every command below is real output from a live cluster, and you can reproduce the whole thing yourself (scripts at the end).
The scenario
Here is the question. Add the official Argo CD Helm repository to the cluster under the name argo; the URL is given in the question, you never have to memorize repository links. The Argo CD CRDs, it says, have already been pre-installed. Generate a Helm template for release argocd, chart version 7.7.3, in the argocd namespace, save it to argo-helm.yaml, and configure the chart to not install the CRDs. Then install the release with the same name, version and namespace, again without CRDs. And one thing you do not have to do: configure access to the Argo CD server UI. Three commands, one premise. Remember the premise.
- Add the official Argo CD Helm repo as 'argo' (URL is given in the question)
- Premise: the Argo CD CRDs 'have already been pre-installed in the cluster'
- helm template: release argocd, chart version 7.7.3, ns argocd -> argo-helm.yaml, NO CRDs
- helm install: same release/version/namespace, NO CRDs; the server UI is out of scope
How the Helm flow works
Three Helm verbs do the work. helm repo add registers where charts come from, under a name you choose. helm template renders the chart into plain YAML on your machine; nothing touches the cluster, which is why the question can ask you to save the output to a file. helm install submits that same render to the cluster as a managed release. The flag that ties them together is set crds.install=false. The argo-cd chart bundles the Argo CD custom resource definitions, and when a question says the CRDs are managed separately, your job is to keep the chart's hands off them, in the template and in the install. Keep the two commands identical apart from the verb; if they drift, the file you saved describes a different system than the one you deployed.
Add the argo repo
Step one. helm repo add argo, then the URL from the question. Helm fetches the repository index immediately, so a mistyped URL fails right here instead of at install time. helm repo list confirms the repository is registered under exactly the name the question asked for: argo.
$ helm repo add argo https://argoproj.github.io/argo-helm
"argo" has been added to your repositories
$ helm repo list
NAME URL
argo https://argoproj.github.io/argo-helm
Render the template
Step two, the template. Release name argocd, chart argo/argo-cd, version 7.7.3 pinned exactly, namespace argocd, crds.install set to false, and the whole thing redirected into argo-helm.yaml. The command prints nothing because the entire render went into the file, and it is substantial: over three thousand lines of YAML. Here is the check that proves the flag worked: grep the file for kind CustomResourceDefinition. Zero. This chart normally ships three CRDs; with the flag set, the render contains none of them.
$ helm template argocd argo/argo-cd --version 7.7.3 --namespace argocd --set crds.install=false > argo-helm.yaml
$ wc -l argo-helm.yaml
3057 argo-helm.yaml
$ grep -c 'kind: CustomResourceDefinition' argo-helm.yaml
0
helm install
Step three is the same command with the verb swapped: helm install, same release name, same chart, same version, same namespace, same crds.install false. Helm prints the release notes, and helm ls in the argocd namespace shows release argocd, revision one, status deployed, chart argo-cd 7.7.3, app version 2.13.0. As far as Helm is concerned, the job is done. The cluster is about to disagree.
$ helm install argocd argo/argo-cd --version 7.7.3 --namespace argocd --set crds.install=false
NAME: argocd
LAST DEPLOYED: Mon Jul 13 09:49:46 2026
NAMESPACE: argocd
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
$ helm ls -n argocd
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
argocd argocd 1 2026-07-13 09:49:46.583903829 -0400 EDT deployed argo-cd-7.7.3 v2.13.0
The crashloop
Give the pods a moment and look again. Redis and dex are up, but the server and the applicationset controller are already in a crash loop, and the application controller never goes ready; everything that watches Argo CD resources is failing. Pull the logs from the server and the last line says exactly why: level fatal, the server could not find the requested resource. That is a component asking the API server for a resource type that does not exist. We told the chart not to install the CRDs because the question said they were pre-installed. They are not. The premise was false, and Helm had no way to know.
$ kubectl get pods -n argocd
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 0/1 Running 0 84s
argocd-applicationset-controller-bcdc99fcf-jdfj9 0/1 CrashLoopBackOff 3 (41s ago) 84s
argocd-dex-server-77f8fcf9d9-plbt8 1/1 Running 0 84s
argocd-notifications-controller-7769fd5fd-rdqzh 1/1 Running 0 84s
argocd-redis-768545f6f-rjsgq 1/1 Running 0 84s
argocd-repo-server-fd74968b8-dr772 1/1 Running 0 84s
argocd-server-74b5fbf858-cn5t4 0/1 CrashLoopBackOff 4 (4s ago) 84s
$ kubectl logs deploy/argocd-server -n argocd --tail=3
time="2026-07-13T13:51:10Z" level=info msg="Starting configmap/secret informers"
time="2026-07-13T13:51:11Z" level=info msg="Configmap/secret informer synced"
time="2026-07-13T13:51:11Z" level=fatal msg="the server could not find the requested resource (post appprojects.argoproj.io)"
The missing CRDs
Confirm the diagnosis in two seconds: kubectl get crd, grep argoproj, nothing. So we install the CRDs ourselves, but pinned to the right version, because CRDs and controllers drift apart across releases. The chart's appVersion tells you which Argo CD this chart deploys: helm show chart says 7.7.3 ships version 2.13.0. Apply the three CRD manifests from the Argo CD repository at exactly that tag: applications, applicationsets, and appprojects. Now the same grep finds all three.
$ kubectl get crd | grep argoproj
No resources found
$ helm show chart argo/argo-cd --version 7.7.3 | grep appVersion
appVersion: v2.13.0
version: 7.7.3
$ kubectl apply -f crds/
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/applicationsets.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io created
$ kubectl get crd | grep argoproj
applications.argoproj.io 2026-07-13T13:51:16Z
applicationsets.argoproj.io 2026-07-13T13:51:16Z
appprojects.argoproj.io 2026-07-13T13:51:16Z
Restart + verify
The crashlooped pods would eventually recover on their own as the backoff retries, but do not sit and wait in an exam. One rollout restart of the workloads in the namespace brings fresh pods up immediately, and this time every informer finds its CRDs. A minute later the whole namespace is Running and Ready. That is the full question: repository added as argo, template saved with zero CRDs in it, release installed at 7.7.3, and a healthy Argo CD. And notice what the fix was not: we never touched the Helm release. The release was correct; the environment broke the promise.
$ kubectl -n argocd rollout restart deployment
deployment.apps/argocd-applicationset-controller restarted
deployment.apps/argocd-dex-server restarted
deployment.apps/argocd-notifications-controller restarted
deployment.apps/argocd-redis restarted
deployment.apps/argocd-repo-server restarted
deployment.apps/argocd-server restarted
$ kubectl get pods -n argocd
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 1/1 Running 0 11s
argocd-applicationset-controller-547b7778c8-psvtd 1/1 Running 0 58s
argocd-dex-server-65cd9bfbb8-ptbnj 1/1 Running 0 58s
argocd-notifications-controller-76fcfb8864-6s7sb 1/1 Running 0 58s
argocd-redis-6d9cb5f875-6z8xw 1/1 Running 0 58s
argocd-repo-server-87cf9c697-dcqzx 1/1 Running 0 58s
argocd-server-6f7b69c655-wgrhn 1/1 Running 0 58s
Exam tips
A few traps. The repository URL and the chart version are printed in the question; copy them, pin --version exactly, and never guess. Template and install must carry identical values: same namespace, same set crds.install=false, only the verb changes. When a question states a premise like CRDs are pre-installed, verify it, it costs two seconds: kubectl get crd, grep argoproj. And learn the signature: a controller crashlooping with the server could not find the requested resource means a missing CRD, and the chart's appVersion tells you exactly which CRD version to apply.
- The repo URL + chart version are IN the question: copy them, pin --version exactly
- template and install take identical values; only the verb changes
- Premises are verifiable: 'CRDs pre-installed' -> kubectl get crd | grep argoproj (2 seconds)
- 'could not find the requested resource' = missing CRD; match it to the chart's appVersion
Recap
- helm repo add argo -> helm template -> helm install, pinned to 7.7.3, crds.install=false on both
- helm ls said 'deployed'; the pods crashlooped: Helm status is not health
- Missing argoproj CRDs -> 'could not find the requested resource'; apply CRDs at appVersion v2.13.0
- rollout restart, all pods Running; subscribe + dev.to writeup
Reproduce this yourself
The entire scenario is scripted on a throwaway kind cluster: https://github.com/The-Cyber-Sidekick/TCS_CKA_2026_Exam_Scenarios
git clone https://github.com/The-Cyber-Sidekick/TCS_CKA_2026_Exam_Scenarios.git
cd TCS_CKA_2026_Exam_Scenarios/learning/scenarios/scenario10-argocd-helm-install
./setup.sh # creates the cluster AND arms the scenario
# solve it by hand, or:
./solution.sh # apply the answer key and verify
If this helped, subscribe to The Cyber SideKick on YouTube for more CKA drills, and grab the newsletter at https://thecybersidekick.beehiiv.com.
Top comments (0)