Getting Started with Argo CDs

Leave a Comment / / Cloudnative | 云原生实验室

In the previous article “

In ” Introduction to GitOps “, I introduced what GitOps is, including the principles and advantages of GitOps, and the difference between GitOps and DevOps. This article introduces Argo CD, a tool for implementing GitOps.

Argo CD is a continuous delivery (CD) tool that follows the declarative GitOps concept based on Kubernetes infrastructure and supports a variety of configuration management tools, including ksonnet/jsonnet, kustomize, and Helm. It is very simple to configure and use, and comes with an easy-to-use visual interface.

According to the official definition, Argo CD is implemented as a Kubernetes controller that continuously monitors running applications and compares the current actual state with the desired state declared in the Git repository. If the actual state does not meet the desired state, it will Update the actual state of the application to match the desired state.

Before we start to interpret and use Argo CDs, we need to understand why we need Argo CDs? What value can it bring us?

Traditional CD Workflow

From the previous article “

” Introduction to GitOps “, you can know that most CI/CD tools currently use the Push-based deployment mode, such as Jenkins, CircleCI, etc. This mode generally executes a command (such as kubectl) to deploy the application to the target environment after the CI pipeline is completed.

The flaws of this CD mode are obvious:

  • Need to install and configure additional tools (such as kubectl);
  • Requires Kubernetes to authorize it;
  • Cloud platform authorization is required;
  • Unable to sense deployment status. It is impossible to perceive the deviation between the expected state and the actual state, and additional solutions are needed to ensure consistency.

Let’s take Argo CD as an example to see how a CD tool that follows the declarative GitOps concept is implemented.

CD workflow using Argo CD

Like traditional CI/CD tools, the CI part is no different, nothing more than testing, building images, pushing images, modifying deployment manifests, and so on. The focus is on the CD section.

Argo CD will be deployed in the Kubernetes cluster, using the Pull-based deployment mode, it will periodically monitor the actual status of the application, it will also periodically pull the configuration list in the Git repository, and compare the actual status with the expected The state is compared, and if the actual state does not match the desired state, the actual state of the application is updated to match the desired state.

Whether it is triggered by the CI pipeline to update the K8s orchestration file, or the DevOps engineer directly modifies the K8s orchestration file, Argo CD will automatically pull the latest configuration and apply it to the K8s cluster.

You end up with an isolated CI and CD pipeline, the CI pipeline is usually controlled by the R&D staff (or DevOps team), and the CD pipeline is usually controlled by the cluster administrator (or DevOps team).

Advantages of Argo CDs

Let’s take a look at the obvious advantages of Argo CD over traditional CD tools.

Git as the single source of truth for applications

All K8s declarative configurations are stored in Git, and using Git as the only source of truth for the application, we no longer need to manually update the application (such as executing scripts, executing kubectl apply or helm install commands), just through the unified interface ( Git) to update the application.

In addition, Argo CD not only monitors the desired state declared in the Git repository, but also monitors the actual state of the application in the cluster, and compares the two states. As long as the actual state does not meet the desired state, the actual state will be corrected and the desired state Consistent. So even if someone changes the state of the application in the cluster (e.g. changes the number of replicas), Argo CD will restore it to the previous state. This truly ensures that the orchestration files in the Git repository can serve as the single source of truth for the state of the cluster.

Of course, sometimes we need to quickly update the application and debug it. It is still a bit slow to trigger the update through Git. This is not impossible. We can modify the configuration of Argo CD so that it does not overwrite or roll back the manually modified part. Instead, alerts are sent directly to remind administrators not to forget to commit updates to the Git repository.

fast rollback

Argo CD will regularly pull the latest configuration and apply it to the cluster. Once the latest configuration causes the application to fail (for example, the application fails to start), we can quickly restore the application state to the last available state through Git History.

If you have multiple Kubernetes clusters using the same Git repository, this advantage will be more obvious, because you do not need to roll back manually through kubectl delete or helm uninstall in different clusters, just roll back the Git repository to Argo CD will automatically sync with the last available version.

Cluster disaster recovery

if you are

Qingyun in Beijing District 3

If the KubeSphere cluster fails and cannot be recovered in a short period of time, you can directly create a new cluster and then connect Argo CD to the Git repository, which contains all configuration declarations for the entire cluster. In the end, the state of the new cluster will be the same as the previous state of the old cluster, and no manual intervention is required at all.

Access control with Git

Usually in a production environment, everyone is not allowed to access the Kubernetes cluster. If you control access rights directly in the Kubernetes cluster, you must use complex RBAC rules. Controlling permissions in a Git repository is relatively simple. For example, everyone (DevOps team, operations team, R&D team, etc.) can submit Pull Requests to the repository, but only senior engineers can merge Pull Requests.

The benefit of this is that no one but the cluster administrator and a few people need direct access to the Kubernetes cluster, just the Git repository. The same is true for programs, CI tools like Jenkins no longer need access to Kubernetes, because only Argo CD can apply configuration manifests, and Argo CD has been deployed in the Kubernetes cluster, and the necessary access permissions have been configured properly , so that there is no need to provide access certificates to anyone or tools outside the cluster, which can provide stronger security.

Extending Kubernetes

Although Argo CD can be deployed in a Kubernetes cluster and enjoy the benefits of Kubernetes, it is not exclusive to Argo CD! Isn’t Jenkins also deployable in Kubernetes? Is there anything special about Argo CDs?

Of course there is. Without this diamond, I would not dare to take this porcelain job. Argo CD cleverly uses many functions in the Kubernetes cluster to achieve its own purpose. For example, all resources are stored in the Etcd cluster, and the control of Kubernetes is used. monitor the actual state of the application and compare it to the desired state, etc.

The most intuitive benefit of doing this is that the deployment status of the application can be sensed in real time . For example, when you update the image version in the configuration list in the Git repository, Argo CD will update the application in the cluster to the latest version. It runs successfully and is in a healthy state, or the application fails to run and needs to be rolled back).

Argo CD Architecture

From the perspective of functional architecture, Argo CD mainly has three components: API Server, Repository Server and Application Controller. From a GitOps workflow perspective, there are 3 phases in total: Retrieval, Tuning, and Rendering.

Retrieval – Repository Server

The retrieval phase clones the Git repository where the application’s declarative configuration manifest resides and caches it in local storage. Contains Kubernetes native configuration list, Helm Chart and Kustomize configuration list. The component that performs these responsibilities is the Repository Server .

Tuning – Application Controller

The Reconcile phase is the most complicated. In this phase, the configuration list obtained by the Repository Server is compared with the real-time configuration list reflecting the current state of the cluster. Once it is detected that the application is in the OutOfSync state, the Application Controller will take corrective measures to make the cluster The actual state is consistent with the desired state.

Rendering – API Server

The final stage is the presentation stage, which is handled by Argo CD’s API Server , which is essentially a gRPC/REST Server that provides a stateless visual interface for displaying the results of the tuning stage. The following functions are also provided:

  • Application management and status reporting;
  • Invoke application-related operations (such as sync, rollback, and user-defined operations);
  • Git repository and cluster credential management (stored in the form of Kubernetes Secret);
  • Provide authentication and authorization delegation for external authentication components;
  • RBAC enhancements;
  • Listener/forwarder for Git webhook events.

Deploy Argo CD

Argo CD has two different deployment modes:

multi-tenancy

The most common deployment mode for Argo CD is multi-tenancy, which is generally used if the organization contains multiple application development teams. Users can access Argo CD using the visual interface or the argocd CLI. argocd CLI must first obtain Argo CD access authorization through argocd login <server-host> .

 $ argocd login SERVER [ flags ] ## Login to Argo CD using a username and password $ argocd login cd.argoproj.io ## Login to Argo CD using SSO $ argocd login cd.argoproj.io --sso ## Configure direct access using Kubernetes API server $ argocd login cd.argoproj.io --core

Multi-tenant mode provides two different configuration checklists:

Not highly available

Recommended for testing and demo environments, not recommended for production use. There are two deployment manifests to choose from:

  • install.yaml – The standard Argo CD deployment manifest, with cluster administrator privileges. Applications can be deployed within the cluster on which Argo CD is running, or deployed to an external cluster with credentials to access the external cluster.

  • namespace-install.yaml – This deployment manifest only requires namespace level permissions. If you don’t need to deploy the application in the cluster where Argo CD is running, you only need to deploy the application to the external cluster with the credentials to access the external cluster. This deployment checklist is recommended. There is also a fancy way of playing where you can deploy separate Argo CD instances for each team, but each Argo CD instance can use special credentials (eg argocd cluster add <CONTEXT> --in-cluster --namespace <YOUR NAMESPACE> ) to deploy the application into the same cluster (ie kubernetes.svc.default , which is the internal cluster).

⚠️Note: The CRD of Argo CD is not included in the namespace-install.yaml configuration list, you need to deploy it separately in advance: kubectl apply -k https://github.com/argoproj/argo-cd/manifests/crds\?ref\=stable .

High availability

It contains the same components as the non-HA deployment checklist, but enhances high availability and resiliency, and is recommended for use in production environments.

  • ha/install.yaml – Same content as install.yaml mentioned above, but configured with multiple copies of related components.

  • ha/namespace-install.yaml – Same as namespace-install.yaml mentioned above, but configured with multiple copies of related components.

Core

Core mode is also the most streamlined deployment mode. It does not include API Server and visual interface, and only deploys a lightweight (non-highly available) version of each component.

Users need Kubernetes access to manage Argo CD, so the argocd CLI must be configured with the following command:

 $ kubectl config set-context --current --namespace = argocd # change current kube context to argocd namespace $ argocd login --core

The visual interface can also be manually enabled using the command argocd admin dashboard .

The specific configuration list is located in the Git repository at

core-install.yaml .

In addition to deploying directly through native manifests, Argo CD supports additional manifest management tools.

Kustomize

Argo CD manifests can also be deployed using Kustomize, it is recommended to call the manifest via a remote URL and use patch to configure custom options.

 apiVersion : kustomize.config.k8s.io/v1beta1 kind : Kustomization  namespace : argocd resources : - https://raw.githubusercontent.com/argoproj/argo-cd/v2.0.4/manifests/ha/install.yaml

Helm

The Helm Chart for Argo CD is currently maintained by the community at:

https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd .

The deployment process is demonstrated below. If you don’t have an existing Kubernetes environment, you can use

The KubeSphere Cloud managed cluster service can quickly create one, and the free trial time is 2 hours. After the expiration, the cluster will be automatically deleted and can be rebuilt unlimited times.

The process of creating a Kubernetes cluster is very simple, first register and log in

https://kubesphere.cloud console, then click Managed Cluster Service to open the New Kubernetes Cluster page, fill in the cluster name, select the operating environment, and click the New menu to create a cluster.

After a few seconds, it will be created and the basic information of the cluster will be displayed. Download kubeconfig and use kubectl to access the cluster.

Next start deploying Argo CD:

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

View deployment results:

 $ kubectl -n argocd get pod argocd-applicationset-controller-69879c47c-pcbkg 1/1 Running 0 26m argocd-notifications-controller-6b4b74d8d8-s7mrz 1/1 Running 0 26m argocd-redis-65596bf87-2hzcv 1/1 Running 0 26m argocd-dex-server-78c9764884-6lcww 1/1 Running 0 26m argocd-repo-server-657d46f8b-87rzq 1/1 Running 0 26m argocd-application-controller-0 1/1 Running 0 26m argocd-server-6b48df79dd-b7bkw 1/1 Running 0 26m

Visit Argo CD

After the deployment is complete, you can access the visual interface through Service argocd-server .

 $ kubectl -n argocd get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT ( S ) AGE argocd-applicationset-controller ClusterIP 10.105.250.212 <none> 7000/TCP,8080/TCP 5m10s argocd-dex-server ClusterIP 10.108.88.97 <none> 5556/TCP,5557/TCP,5558/TCP 5m10s argocd-metrics ClusterIP 10.103.11.245 <none> 8082/TCP 5m10s argocd-notifications-controller-metrics ClusterIP 10.98.136.200 <none> 9001/TCP 5m9s argocd-redis ClusterIP 10.110.151.108 <none> 6379/TCP 5m9s argocd-repo-server ClusterIP 10.109.131.197 <none> 8081/TCP,8084/TCP 5m9s argocd-server ClusterIP 10.98.23.255 <none> 80/TCP,443/TCP 5m9s argocd-server-metrics ClusterIP 10.103.184.121 <none> 8083/TCP 5m8s

If your client can directly connect to the Service IP, it can be accessed directly through the Cluster IP of the argocd-server. Or it can be accessed directly via local port forwarding:

 $ kubectl port-forward svc/argocd-server -n argocd 8080:443 Forwarding from 127.0.0.1:8080 -> 8080 Forwarding from [ ::1 ] :8080 -> 8080

The initial password is stored in the Secret argocd-initial-admin-secret in clear text and can be obtained with the following command:

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

You can also change the login password with the following command:

 $ argocd account update-password --account admin --current-password xxxx --new-password xxxx

The interface after login:

Argo CD Core Concepts

There are two basic concepts you need to understand before you can actually start using Argo CD.

Argo CD Application

Application in Argo CD defines the source and destination of Kubernetes resources. The source refers to the location in the Git repository where the Kubernetes resource configuration manifest is located, and the target refers to where the resource is deployed in the Kubernetes cluster.

The source can be native Kubernetes configuration manifest, Helm Chart or Kustomize deployment manifest.

The target specifies the URL and associated namespace of the API Server in the Kubernetes cluster, so that Argo CD knows which namespace in which cluster to deploy the application to.

In a nutshell, the Application’s job is to connect the namespace in the target Kubernetes cluster with the desired state declared in the Git repository .

Example configuration manifest for Application:

If you have multiple teams, each maintaining a large number of applications, you need to use another concept of Argo CD: project (Project).

Argo CD Project

Projects in Argo CD can be used to group applications, and different teams use different projects, thus realizing a multi-tenant environment. The project also supports more fine-grained access control:

  • Restrict deployment content (trusted Git repositories);
  • Limit the target deployment environment (target cluster and namespace);
  • Restrict the types of resources deployed (e.g. RBAC, CRD, DaemonSets, NetworkPolicy, etc.);
  • Define project roles and provide RBAC for Application (bound with OIDC group or JWT token).

Demo

Finally, a simple example is used to demonstrate the workflow of Argo CD.

Prepare the Git repository

Create a project on GitHub named

argocd-lab , set the warehouse as a public warehouse for the convenience of experiments. Create a new dev directory in the warehouse, and create two YAML configuration lists in the directory, deployment.yaml and service.yaml .

The content of the configuration list is as follows:

 # deployment.yaml apiVersion : apps/v1 kind : Deployment metadata :   name : myapp spec :   selector :     matchLabels :       app : myapp   replicas : 2   template :     metadata :       labels :         app : myapp     spec :       containers :       - name : myapp         image : nginx:latest         ports :         - containerPort : 80          # service.yaml apiVersion : v1 kind : Service metadata :   name : myapp-service spec :   selector :     app : myapp   ports :   - port : 80     protocol : TCP     targetPort : 80

Next, create an Application configuration manifest in the repository root directory:

 # application.yaml apiVersion : argoproj.io/v1alpha1 kind : Application metadata :   name : myapp-argo-application   namespace : argocd spec :   project : default    source :     repoURL : https://github.com/yangchuansheng/argocd-lab.git     targetRevision : HEAD     path : dev   destination :      server : https://kubernetes.default.svc     namespace : myapp    syncPolicy :     syncOptions :     - CreateNamespace=true      automated :       selfHeal : true       prune : true

Parameter explanation:

  • syncPolicy : Specify the automatic synchronization policy and frequency. If not configured, you need to manually trigger synchronization.

  • syncOptions : Define the synchronization method.

    • CreateNamespace=true : If this namespace does not exist, it will be created automatically.

  • automated : Synchronous actions to take when an inconsistency between the actual state and the desired state is detected.

    • selfHeal : Automatically sync when the cluster century state does not meet the desired state.
    • prune : Remove resources that don’t exist in Git when automatically syncing.

By default, Argo CD will check the Git repository every 3 minutes to determine whether the actual state of the application is consistent with the expected state declared in Git. If it is inconsistent, the state will be converted to OutOfSync . Updates are not triggered by default unless automatic synchronization is configured via syncPolicy .

If periodic synchronization is too slow, you can also set up a webhook to trigger synchronization immediately when the Git repository is updated. The specific usage will be put into the subsequent tutorials, and will not be repeated in this article.

Create Application

Now everything is ready, just create the Application through application.yaml.

 $ kubectl apply -f application.yaml application.argoproj.io/myapp-argo-application created

In the Argo CD visual interface, you can see that the application has been created successfully.

Click to see the synchronization details of the application and the health status of each resource.

If you update the image in deployment.yaml, Argo CD will automatically detect the update in the Git repository and update the Deployment’s image in the cluster to the latest version of the image set in the Git repository.

KubeSphere has also provided a CD solution based on GitOps since 3.3.0 . Argo CD is introduced as the backend of CD, and the visual interface is more cool. Interested partners can try to use KubeSphere to create and manage applications.

Summarize

This article introduces the advantages, architecture, and working principle of Argo CD, and demonstrates its capabilities through a simple example, such as automatically triggering an update after modifying the contents of a Git repository. More automated deployment requirements can also be achieved through Event Source and Trigger.

When deploying Kubernetes resources, Argo CD also supports Kustomize, Helm, Ksonnet and other resource description methods, and other more advanced usage methods will be introduced for you in subsequent tutorials, so stay tuned.

This article is reprinted from https://icloudnative.io/posts/getting-started-with-argocd/
This site is for inclusion only, and the copyright belongs to the original author.

Leave a Comment