GitOps Application Practice Series-Argo CD from entry to core

Hi everyone, this is Zhang Jintao.

In the last article "GitOps Application Practice Series-Summary (1)" , I introduced the concept of GitOps, how it works, and the model based on Pull and Push. In this article, we focus on the tool ArgoCD used to implement GitOps.

Argo CD overview

On April 7, 2020, the CNCF Technical Oversight Committee (TOC) voted to enter the CNCF incubation through the Argo project.

In fact, Argo was created in 2017 by the Applatix (the company's main products and services are currently deeply integrated with AWS, of course, including some multi-cloud services), and was acquired by Intuit in early 2018. After that, BlackRock contributed to the Argo Events sub-project for the Argo project. Both companies are actively participating in the development and cultivation of projects and communities.

Argo and its sub-projects provide an easy way to manage Workflow, events and applications. All Argo tools are implemented by means of CRD. They can use or integrate other CNCF projects such as gRPC, Prometheus, NATS, Helm and CloudEvents.

The Argo ecosystem currently mainly consists of four sub-projects, including:

• Argo Workflows - The first Argo project, which is Kubernetes' native workflow engine , which supports DAG and step-based workflows;
• Argo Events - Event-based dependency manager on Kubernetes, used to trigger Argo workflow and other operations in Kubernetes.
• Argo CD - is an open source project brought by the Argo community and Intuit, which supports GitOps-based declarative deployment of Kubernetes resources.
• Argo Rollouts - Support declarative progressive delivery strategies, such as canary, blue-green and more.

Argo CD aims to provide a declarative continuous delivery (CD) tool. Argo CD supports multiple configuration management tools, including ksonnet/jsonnet, kustomize and Helm etc. . Argo CD extends the advantages of declarative and Git-based configuration management to accelerate application deployment and lifecycle management without compromising security and compliance with

Applicable scenarios of Argo CD

• The configuration of the application and its deployment environment is declarative and version controllable;
• Application deployment and life cycle management are simple, automatic and auditable (enterprise friendly);
• Application deployment is fast, reliable and idempotent;
• Need to detect and correct any deviations from the version control configuration;
• Simple rollback;

Main features of Argo CD

• It can be used with various configuration management tools (such as ksonnet/jsonnet, Helm and kustomize) to make the application consistent with the definition in Git;
• Automatically deploy the application to the specified target environment;
• Continuously monitor the deployed applications;
• Web and CLI-based operations, and application visualization;
• Deploy or roll back to any state of the application submitted in the Git repository (this is also a major benefit of using Git for version management);
• PreSync, Sync, PostSync hooks to support complex application deployment strategies (for example: blue/green, canary upgrades);
• SSO integration (OIDC, LDAP, SAML 2.0, GitLab, Microsoft, LinkedIn), these are the functions that enterprises need more;
• Webhook integration (GitHub, BitBucket, GitLab).
• It can be used independently or as part of an existing Pipeline, such as with Argo Workflow, Jenkins, and GitLab CI;

Argo CD architecture

On the whole, Argo CD has three main components: API Server, Repository Server, and Application Controller.

API Server

The API Server of Argo CD is a gRPC/REST server, which exposes Web UI, CLI, and some APIs that are needed in other scenarios.

It mainly carries out the following contents:

• Application management and status reporting;
• Invoke application operations (for example: synchronization, rollback, user-defined operations);
• Repository and cluster credential management (store K8s secrets);
• Authentication and authorization are delegated to external authentication components;
• RBAC ( Role-based access control role-based access control);
• The listener/forwarder of Git webhook events;

Repository Server

Repository Server is an internal service that is responsible for storing the local cache of the application Git repository, and is responsible for generating and returning manifests that can be used by Kubernetes. The input information it accepts mainly includes the following:

• Warehouse address (URL)
• revision（commit, tag, branch）
• Application path
• Specific settings of the template: such as helm values.yaml, etc.

Application Controller

Application Controller is a Kubernetes controller that continuously monitors the running application and compares the current real-time state with the desired target state (as specified in the repo). It detects the status of the OutOfSync application and selectively takes corrective actions. It is responsible for calling any user-defined hooks for life cycle events (PreSync, Sync, PostSync).

Main features of Argo CD

v1.0.0 on March 17, 2019, Argo CD has fully entered the v2.x era, and the latest version is v2.1.5.

In 2.0, the Pods View function was introduced, the log visualization was rewritten, the notification banner function was added, there were many background operations and custom operations, and it was committed to creating Argo CD Core (lightweight Argo CD release, only packaged The core GitOps functions rely on Kubernetes API/RBAC to provide support for UI and CLI).

• Pods View: Especially useful for applications with hundreds of Pods. It does not visualize all the Kubernetes resources of the application, but only displays Kubernetes pods and closely related resources.
• New log visualization: supports paging, filtering, the ability to disable/enable log streams, and even provide dark mode for terminal enthusiasts. Supports viewing aggregate logs of multiple deployed Pods, and Argo CD CLI also supports log streaming.
• UI notification banner function: use the ui.bannercontent and ui.bannerurl properties in the ConfigMap to specify the notification message and the optional URL argocd-cm.
• Background operation: Resources deletion / pruning, resources only sync changes, Prune Last, introduced on Sealed- Secrets , Kubernetes-External-Secrets and strimzi CRD health check.

Deploy Argo CD

Argo CD has four installation methods: multi-tenant, core, custom, and Helm.

Multi-tenant

Multi-tenancy is the most used deployment method for Argo CD. Users can use Web UI or argocd CLI to access Argo CD through API Server.

The argocd CLI must first execute the argocd login <server-host> command.

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

Two deployment methods (manifests) are provided by default in the project's GitHub repository:

Non-high availability

This type of installation is usually used for demonstration and testing. (Not recommended for production)

• install.yaml -Standard Argo CD installation with cluster administrator rights. You can use Argo CD to deploy applications in the same cluster where it is running, or you can use the entered credentials to deploy to an external cluster.

• namespace-install.yaml -only requires namespace level permissions (does not require cluster administrator permissions). But with this kind of installation, Argo CD cannot deploy applications in the same cluster it is running on, and will only rely on the external cluster credentials entered.

​ Note: Argo CD CRD is not included in namespace-install.yaml must be installed separately. CRD manifests are located in the manifests/crds directory. Install them using the following command:

kubectl apply -k https://github.com/argoproj/argo-cd/manifests/crds\?ref\=stable

High availability

It is strongly recommended that the production environment use high-availability installation.

The bundle contains the same components, but adjusted for high availability and resiliency.

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

core

The core installation is most suitable for cluster administrators who use Argo CD independently and do not require multi-tenancy.

This installation includes fewer components and is easier to set up. The bundle does not include API Server or UI, and only installs a lightweight (non-HA) version of each component.

Users need Kubernetes access rights to manage Argo CD. The argocd CLI must be configured using the following command:

kubectl config set-context --current --namespace=argocd
argocd login --core 

The Web UI can also be used and can be started with the following command.

argocd admin dashboard

The specific manifests correspond to core-install.yaml in the warehouse.

Custom installation

Argo CD manifests can also use custom installation. It is recommended to include manifests as remote resources and apply other customizations using Kustomize patches.

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

Argo CD can be installed Helm Helm chart is currently maintained by the community, visit https://github.com/argoproj/argo-helm/tree/master/charts/argo-cd get it, no more examples are added here.

Secret management of Argo CD

Argo CD does not explicitly limit the way Secrets can be managed. Here are some GitOps secret management methods, which are also applicable to other scenarios:

• Recommended by Hashicorp Vault . This is a more general solution and has a wide range of application scenarios. ( https://www.vaultproject.io/)
• Bitnami Sealed Secrets the Secret into a SealedSecret that can be stored safely, and can even be stored in a public library; SealedSecret can only be decrypted by the controller running in the target cluster, and no one else (even the original author) can obtain it from SealedSecret The original Secret. ( https://github.com/bitnami-labs/sealed-secrets);
• Banzai Cloud Bank-Vaults provides various tools for Vault to make the use and operation of Hashicorp Vault easier. It is a package of the official Vault client, with automatic token update and built-in Kubernetes support, a dynamic database credential provider based on the Golang client. It has a CLI tool to automatically initialize, unpack and configure Vault. It also provides a Kubernetes operator for configuration, and a mutating webhook for injecting secrets. ( https://github.com/banzaicloud/bank-vaults)
• Helm Secrets and Argo CD is available from helm-secrets v3.9.0;
• argocd-vault-plugin retrieve secrets from various secrets management tools (HashiCorp Vault, IBM Cloud Secrets Manager, AWS Secrets Manager, etc.) and inject them into Kubernetes resources ( https://github.com/IBM/ argocd-vault-plugin);
• Kustomize secret generator plugins Kubernetes ConfigMaps and Secrets are key:value (KV) maps. kustomize has three different methods to generate secrets from local files. You can check the link for details. ( https://github.com/kubernetes-sigs/kustomize/blob/fd7a353df6cece4629b8e8ad56b71e30636f38fc/examples/kvSourceGoPlugin.md#secret-values-from-anywhere)
• aws-secret-operator a Kubernetes operator that can automatically create and update Kubernetes secrets based on the content stored in AWS Secrets Manager. The aws-secret-operator custom resource maps AWS secrets to Kubernetes. ( https://github.com/mumoshu/aws-secret-operator)
• secrets-store-csi-driver is a tool that uses the CSI interface to mount key information into Pod. Support multiple key storage methods, such as Vault, GCP, AWS, Azure, etc.;

Resource health assessment

Argo CD provides built-in health assessments for several standard Kubernetes resources, and then presents these assessments as a whole in the overall application health status.

Check the following types of Kubernetes resources:

• Deployment，ReplicaSet，StatefulSet，DaemonSet
• Service
• Ingress
• PersistentVolumeClaim
• Argocd App

You can also add a custom health check. Argo CD supports Lua , and supports two configuration methods:

1) Define a custom health check in the ConfigMap of argocd-cm

Can argocd-cm of resource.customizations.health.<group_kind> define custom health checks field.

2) Bundled into Argo CD. The custom health check script is located in the https://github.com/argoproj/argo-cd/tree/master/resource_customizations directory.

The above is about the core content of Argo CD. In the next article, we will carry out the practice of Argo CD. Welcome everyone to continue to pay attention and feedback!

---

Welcome to subscribe to my article public account【MoeLove】