Argo CD’s CLI is more than just a set of commands; it’s a direct conduit to managing your Kubernetes deployments with precision and speed.
Let’s see it in action. Imagine you’ve just deployed a new version of your application, and you want to check its status.
argocd app list
This command will spit out a list of all your Argo CD applications, along with their sync status, health, and repository information. You’ll see something like this:
NAME SYNC STATUS HEALTHY REPOSITORY DESTINATION
my-app Synced Healthy argocd-repo.example.com/my-repo https://kubernetes.default.svc
another-app OutOfSync Degraded argocd-repo.example.com/other-repo https://kubernetes.default.svc
The SYNC STATUS is crucial. Synced means what’s in your Git repository perfectly matches what’s deployed on your Kubernetes cluster. OutOfSync means there are differences, and Argo CD needs to apply them. HEALTHY indicates that the Kubernetes resources managed by the application are healthy. Degraded suggests a problem with one or more of those resources.
To dive deeper into a specific application, you’d use:
argocd app get my-app
This gives you a detailed view of my-app, including its current state, events, resource tree, and sync history. You can see which Git commit is currently deployed and what changes are pending.
When you need to force a synchronization, perhaps after manually changing something in Kubernetes or if Argo CD is stuck:
argocd app sync my-app
This command tells Argo CD to reconcile the state defined in your Git repository with the actual state in your cluster. It will create, update, or delete Kubernetes resources as needed to match the desired state.
What if you want to see the diff before syncing? This is a critical step for safety.
argocd app diff my-app
This command shows you exactly which Kubernetes resources will be changed, added, or removed. It’s like a git diff for your deployments.
--- a/live/my-app/deployment.yaml
+++ b/live/my-app/deployment.yaml
@@ -10,7 +10,7 @@
spec:
containers:
- name: my-app
- image: argocd-repo.example.com/my-repo/my-app:v1.0.0
+ image: argocd-repo.example.com/my-repo/my-app:v1.1.0
ports:
- containerPort: 8080
In this diff, you can clearly see that the image tag is being updated from v1.0.0 to v1.1.0.
Beyond managing applications, you often need to interact with Git repositories directly. Argo CD uses a declarative model, meaning your desired state is defined in Git.
To add a new Git repository that Argo CD should monitor:
argocd repo add argocd-repo.example.com/my-repo --username git --password my-secret-password --enable-oci
This registers the repository, providing credentials if it’s private. The --enable-oci flag is interesting – it allows Argo CD to pull OCI-compatible artifacts (like container images) directly from the repository, not just Git commits.
Sometimes, you’ll encounter situations where Argo CD doesn’t have the necessary permissions to manage resources in your Kubernetes cluster. You can check the RBAC configuration for the service account Argo CD uses. For example, if Argo CD is running in the argocd namespace and its service account is named argocd-application-controller, you might check its cluster role bindings:
kubectl get clusterrolebinding | grep argocd
If you see a binding like argocd-application-controller to cluster-admin, that’s a good start. If not, you’ll need to create or modify roles and role bindings to grant Argo CD the permissions it needs to create, get, list, watch, update, and patch resources like deployments, statefulsets, services, etc., in the target namespaces.
The argocd app rollback command is your best friend when a deployment goes wrong. If my-app suddenly becomes unhealthy after a sync, you can revert to a previous known good state:
argocd app rollback my-app 5
This command rolls back the my-app application to its 5th sync history entry. Argo CD tracks each synchronization event, and this allows you to easily revert to a specific point in time.
When you’re debugging issues within the Argo CD application itself, the argocd-application-controller logs are invaluable. You can access them using:
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-application-controller
These logs will show you the internal workings of Argo CD, including reconciliation loops, API calls, and any errors encountered while trying to manage your applications.
A subtle but powerful aspect of Argo CD is its ability to manage secrets. While you should never commit plain-text secrets to Git, Argo CD can integrate with external secret management systems or use its own internal secrets management. When using the CLI, you might interact with this by ensuring the Argo CD service account has the necessary permissions to get secrets from the Kubernetes API, or by configuring Argo CD’s application controller to use a specific secret management plugin.
The next step in mastering Argo CD often involves understanding its event-driven nature and how to leverage webhooks for automated Git operations.