How to Install ArgoCD on Kubernetes on RHEL 7

How to Install ArgoCD on Kubernetes on RHEL 7

ArgoCD is a declarative, GitOps-based continuous delivery tool for Kubernetes. The core principle of GitOps is that the desired state of your cluster is stored in a Git repository, and a controller continuously reconciles the live cluster state against that desired state. ArgoCD monitors your Git repos and automatically applies changes — or alerts you when drift is detected — eliminating the need to run kubectl apply manually after every commit. On RHEL 7 environments where compliance, auditability, and reproducible deployments are critical, ArgoCD provides a reliable delivery pipeline backed by a complete Git history of every change ever applied to production infrastructure. This guide walks through installing ArgoCD with kubectl, accessing the web UI, connecting a Git repository, and configuring sync policies for both manual and automated GitOps workflows.

Prerequisites

• RHEL 7 system with a running Kubernetes cluster (v1.19 or later recommended)
• kubectl configured with cluster-admin access
• Outbound internet access from cluster nodes to pull ArgoCD images and reach Git
• A Git repository containing Kubernetes manifests (GitHub, GitLab, Gitea, or self-hosted)
• At least 2 CPU cores and 4 GB RAM available in the cluster for ArgoCD components
• firewalld configured and accessible for external port exposure if needed

Step 1: Create the ArgoCD Namespace

ArgoCD runs entirely within its own Kubernetes namespace. Create it before applying any manifests so all subsequent resources have a home:

kubectl create namespace argocd
kubectl get namespace argocd

All ArgoCD components — the API server, repository server, application controller, and Dex SSO provider — will be deployed into this namespace. Keeping it isolated makes it straightforward to apply RBAC policies, network policies, and resource quotas independently from your workload namespaces.

Step 2: Install ArgoCD with kubectl apply

Apply the official ArgoCD installation manifest. The install.yaml deploys the full non-HA setup, which is appropriate for most single-cluster environments:

kubectl apply -n argocd 
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Monitor the rollout until all pods reach Running status:

kubectl get pods -n argocd -w

You should eventually see these pods all running:

argocd-application-controller-0            1/1     Running
argocd-dex-server-xxxxxxxxxx-xxxxx         1/1     Running
argocd-notifications-controller-xxxxx      1/1     Running
argocd-redis-xxxxxxxxxx-xxxxx              1/1     Running
argocd-repo-server-xxxxxxxxxx-xxxxx        1/1     Running
argocd-server-xxxxxxxxxx-xxxxx             1/1     Running

If image pulls are slow on your RHEL 7 nodes, monitor pull progress with kubectl describe pod -n argocd <pod-name> and check the Events section at the bottom of the output.

Step 3: Access the ArgoCD UI

By default, the ArgoCD API server service is of type ClusterIP and is not exposed externally. Use kubectl port-forward to access it from your RHEL 7 workstation:

kubectl port-forward svc/argocd-server -n argocd 8080:443 &

Open a browser and navigate to https://localhost:8080. Accept the self-signed certificate warning to proceed to the login page.

Expose via NodePort for Remote Access

If you need persistent remote access without port-forwarding, patch the argocd-server service to use NodePort:

kubectl patch svc argocd-server -n argocd 
  -p '{"spec": {"type": "NodePort"}}'

kubectl get svc argocd-server -n argocd

Note the assigned NodePort (for example 30443). Open it in the RHEL 7 firewall:

firewall-cmd --permanent --add-port=30443/tcp
firewall-cmd --reload

Step 4: Retrieve the Initial Admin Password

ArgoCD generates a random initial admin password and stores it in a Kubernetes Secret. The username is always admin:

kubectl get secret argocd-initial-admin-secret 
  -n argocd 
  -o jsonpath="{.data.password}" | base64 -d && echo

Log in using these credentials through either the web UI or the ArgoCD CLI. Install the CLI for efficient management:

curl -sSL -o /usr/local/bin/argocd 
  https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x /usr/local/bin/argocd

argocd login localhost:8080 --insecure
argocd account update-password

After changing the password, delete the initial secret as a security best practice:

kubectl delete secret argocd-initial-admin-secret -n argocd

Step 5: Create an Application from a Git Repository

An ArgoCD Application links a Git repository path to a Kubernetes namespace destination. Save the following to myapp-argocd.yaml, replacing the repoURL with your actual Git repository URL:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/your-k8s-manifests.git
    targetRevision: HEAD
    path: apps/myapp
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    syncOptions:
    - CreateNamespace=true

kubectl apply -f myapp-argocd.yaml

The path field points to the directory inside the repo containing your Kubernetes manifests or Helm chart. The value https://kubernetes.default.svc for destination.server refers to the in-cluster API server — use this when ArgoCD manages the same cluster it is installed on.

Step 6: Configure Automated Sync Policy

By default, ArgoCD runs in manual sync mode and will not apply changes unless you explicitly trigger a sync. To enable automatic synchronization whenever Git changes are detected, update the application’s sync policy:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/your-k8s-manifests.git
    targetRevision: HEAD
    path: apps/myapp
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

prune: true means ArgoCD will delete resources from the cluster that have been removed from Git. selfHeal: true means if someone manually edits a resource with kubectl, ArgoCD will revert it back to the Git state within three minutes. These settings enforce strict GitOps discipline, so ensure your team understands that direct kubectl edits will be overwritten.

Step 7: Check Application Health and Sync Status

ArgoCD reports two key statuses for every managed application:

• Sync Status: Synced means the cluster matches Git exactly; OutOfSync means drift has been detected
• Health Status: Healthy, Progressing, Degraded, or Missing

Check via the ArgoCD CLI:

argocd app get myapp
argocd app list

Trigger a manual sync from the CLI:

argocd app sync myapp --prune

View the diff between the desired Git state and the live cluster state before syncing:

argocd app diff myapp

Step 8: Connect a Private Git Repository

For private repositories, you must add credentials to ArgoCD before creating the Application resource. Credentials are stored as Kubernetes Secrets in the argocd namespace:

# HTTPS with username and personal access token
argocd repo add https://github.com/your-org/your-k8s-manifests.git 
  --username your-git-user 
  --password your-personal-access-token

# SSH key authentication
argocd repo add [email protected]:your-org/your-k8s-manifests.git 
  --ssh-private-key-path ~/.ssh/id_rsa

Verify the repository is accessible:

argocd repo list

A status of Successful confirms ArgoCD can reach and authenticate to the repository. If the status shows Failed, check network connectivity from the argocd-repo-server pod and verify the token or key has read access to the repository.

Conclusion

You have installed ArgoCD on a Kubernetes cluster running on RHEL 7, accessed the web UI via port-forward and NodePort, retrieved and changed the initial admin password, connected both public and private Git repositories, created Application resources pointing to Git paths, and configured automated sync policies with pruning and self-healing enabled. ArgoCD transforms your Git repository into the single source of truth for cluster state, making every deployment fully auditable, reproducible, and rollback-capable simply by reverting a Git commit. As your ArgoCD usage matures, explore Projects for multi-team access control, the App of Apps pattern for managing many applications from a single root application, and ApplicationSets for deploying identical applications across multiple clusters or environments from a single parameterized template.