How to install and deploy an application with Argo CD on a Kubernetes cluster?
0 reputation · 30 Jul 2022, 06:25 UTC
0 reputation · 30 Jul 2022, 06:25 UTC
I am setting up Argo CD on a Kubernetes cluster and want to understand the end‑to‑end process: after installing the Argo CD manifests, how should I expose the API server, retrieve the initial admin password, log in via the CLI, register a target cluster (if needed), create an application from a Git repository, and finally sync it to deploy the workloads? Please explain each step, including any required flags, verification commands, and rollback considerations.
26525 reputation · 30 Jul 2022, 13:08 UTC
Deploying an application with Argo CD involves installing the control plane, configuring access to the API server, linking a Git repository, and defining an Application resource that maps the repository state to the cluster state.
The following steps assume a Kubernetes cluster version 1.19+ and that kubectl is configured for the target context. While the stable manifest URL is commonly used, it may point to the latest release; pinning to a specific version is recommended for production stability. Verification of RBAC permissions is required if you are deploying into a restricted environment.
Create a dedicated namespace and apply the official installation manifests:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Verify the installation by checking the server pod status:
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server
For local development, use port-forwarding to access the UI and API. For production, use an Ingress controller with TLS.
kubectl port-forward svc/argocd-server -n argocd 8080:443
Retrieve the auto-generated initial admin password:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d
Log in via the CLI (assuming the argocd binary is installed):
argocd login localhost:8080 --username admin --password <password> --insecure
By default, Argo CD manages the cluster it is installed in (https://kubernetes.default.svc). To manage an external cluster, use:
argocd cluster add <context-name>
If your Git repository is private, navigate to Settings > Repositories in the UI to add your SSH or HTTPS credentials.
Define an Application manifest to link your Git source to the destination namespace. Save this as app.yaml:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/example/my-app.git
targetRevision: HEAD
path: manifests
destination:
server: https://kubernetes.default.svc
namespace: my-app
syncPolicy:
automated:
prune: true
selfHeal: true
Apply the manifest:
kubectl apply -f app.yaml
Synced status and Healthy health state, or run kubectl get pods -n my-app.argocd app rollback my-app <revision>.Diagnostic Note: Are you using a custom CNI or Network Policy? This may require additional configuration for the Argo CD application controller to reach the target cluster API.
Use comments to ask for clarification. Post a solution as an answer.
26,525 reputation · 30 Jul 2022, 06:57 UTC
Solid walkthrough. One clarification worth adding for anyone following it: the argocd-initial-admin-secret is only meant as a bootstrap credential. After logging in, set a new password with argocd account update-password and then delete the secret (kubectl delete secret argocd-initial-admin-secret -n argocd). Leaving it in place means anyone with read access to secrets in that namespace can recover the original admin password.
Two related points: the --insecure flag works because the server uses a self-signed cert by default, but for a shared environment you should terminate TLS properly at an Ingress rather than shipping that flag into scripts. Also, if you plan to manage many applications, look at the App of Apps or ApplicationSet pattern early — retrofitting it later is more painful than starting with it. Verify behavior against your installed version, since secret names and CLI flags have changed across releases.