Argo CD architecture and installation

Argo CD runs as a few controllers in the argocd namespace: the API server, the repo server that renders manifests, and the application controller that compares and syncs.

Argo CD is itself a Kubernetes application. A standard install creates the namespace argocd with these parts:

Component	Job
argocd-server	API server behind the web UI, the CLI and webhooks; handles login, RBAC and SSO.
argocd-repo-server	Clones Git repos (or pulls Helm/OCI charts) and renders manifests: plain YAML, Kustomize, Helm, Jsonnet, plugins. Caches the result.
argocd-application-controller	Compares rendered (desired) and live objects, works out sync and health status, and applies changes. Runs as a StatefulSet and can be sharded across clusters.
argocd-applicationset-controller	Generates many Applications from one template (module 3).
argocd-redis	Cache for rendered manifests and cluster state.
argocd-dex-server	Optional SSO bridge (GitHub, LDAP, SAML…).
argocd-notifications-controller	Sends Slack/e-mail/webhook messages on events (module 4).

flowchart LR
  U["UI / CLI"] --> S["argocd-server"]
  S --> R["repo-server"]
  R -->|"clone + render"| G["Git / Helm repos"]
  C["application-controller"] --> R
  C -->|"watch + apply"| K["Kubernetes API"]
  S --- RD["redis"]
  C --- RD

Argo CD stores its own objects as CRDs: Application, AppProject and ApplicationSet. Settings live in ConfigMaps (argocd-cm, argocd-rbac-cm, argocd-cmd-params-cm) and Secrets (repositories, clusters).

Install

kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl get pods -n argocd

install.yaml is the cluster-wide install. namespace-install.yaml only manages the namespaces you allow; ha/install.yaml runs several replicas for production.
Pin a version in real environments (.../v3.x.y/manifests/install.yaml) or use the official Helm chart argo/argo-cd, so upgrades are deliberate.
Server-side apply avoids the size limit of the large CRD annotations.

First login

kubectl port-forward svc/argocd-server -n argocd 8080:443
argocd admin initial-password -n argocd          # reads secret argocd-initial-admin-secret
argocd login localhost:8080 --username admin --insecure
argocd account update-password

The initial password is random and stored in the Secret argocd-initial-admin-secret. Change it, then delete that Secret — and in a team setup, turn on SSO and disable the local admin user (module 4). --insecure only skips the certificate check of the self-signed port-forward; expose the server through an Ingress with a real certificate instead.

Useful CLI checks

Command	Shows
`argocd version`	Client and server versions
`argocd cluster list`	Clusters Argo CD can deploy to (`https://kubernetes.default.svc` = its own)
`argocd app list`	All Applications with sync and health status
`argocd account get-user-info`	Who you are logged in as

Tip: the UI and the CLI are two views of the same API. Anything you click can be done with argocd or with kubectl on the CRDs — and in GitOps, the Application objects themselves should end up in Git too.