> 原文地址： https://www.digitalocean.com/community/tutorials/how-to-deploy-to-kubernetes-using-argo-cd-and-gitops > 译文地址： <这里是发布在CSDN博客的文章地址> > 译者：[名称](博客的链接) > 译文出自：[CSDN开发云翻译计划](https://gitcode.net/csdn_dev_cloud/translation) # How to Deploy to Kubernetes using Argo CD and GitOps ### Introduction Using Kubernetes to deploy your application can provide significant infrastructural advantages, such as flexible scaling, management of distributed components, and control over different versions of your application. However, with that increased control comes increased complexity. Continuous Integration and Continuous Deployment (_CI/CD_) systems usually work at a high level of abstraction in order to provide version control, change logging, and rollback functionality. A popular approach to this abstraction layer is called _GitOps_. GitOps, as originally proposed by [Weaveworks](https://www.weave.works/) in a [2017 blog post](https://www.weave.works/blog/gitops-operations-by-pull-request), uses [Git](https://git-scm.com/) as a “single source of truth” for CI/CD processes, integrating code changes in a single, shared repository per project and using pull requests to manage infrastructure and deployment. There are several tools that use Git as a focal point for DevOps processes on Kubernetes. In this tutorial, you will learn to use [Argo CD](https://argoproj.github.io/argo-cd), a declarative Continuous Delivery tool. Argo CD provides Continuous Delivery tooling that automatically synchronizes and deploys your application whenever a change is made in your GitHub repository. By managing the deployment and lifecycle of an application, it provides solutions for version control, configurations, and application definitions in Kubernetes environments, organizing complex data with an easy-to-understand user interface. It can handle several types of Kubernetes manifests, including Jsonnet, [Kustomize](https://kustomize.io/) applications, [Helm](https://helm.sh/) charts, and YAML/json files, and supports webhook notifications from GitHub, GitLab, and Bitbucket. In this article, you will use Argo CD to synchronize and deploy an application from a GitHub repository. ## Prerequisites To follow this tutorial, you will need: * An SSH key pair on your local Linux/MacOS/BSD machine. If you haven’t used SSH keys before, you can learn how to set them up by following [this explanation of how to set up SSH keys on your local machine](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#generating-and-working-with-ssh-keys). If you are using Windows, you should be working in the [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/about) environment. * An existing Kubernetes cluster comprising at least one worker node. [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/) should be installed in your work environment and able to connect to your cluster. DigitalOcean’s [Managed Kubernetes](https://www.digitalocean.com/products/kubernetes/) will provide you with a configuration like this by default. If you are using DigitalOcean’s Managed Kubernetes, you should review [How to connect to the Cluster](https://docs.digitalocean.com/products/kubernetes/how-to/connect-to-cluster/). * Familiarity with Kubernetes concepts. Please refer to the article [An Introduction to Kubernetes](https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes) for more details. ## Step 1 — Installing Argo CD on Your Cluster In order to install Argo CD, you should first have a valid Kubernetes configuration set up with `kubectl`, from which you can ping your worker nodes. You can test this by running `kubectl get nodes`: ```bash kubectl get nodes ``` This command should return a list of nodes with the `Ready` status: ``` Output NAME STATUS ROLES AGE VERSION pool-uqv8a47h0-ul5a7 Ready 22m v1.21.5 pool-uqv8a47h0-ul5am Ready 21m v1.21.5 pool-uqv8a47h0-ul5aq Ready 21m v1.21.5 ``` If `kubectl` does not return a set of nodes with the `Ready` status, you should review your cluster configuration and [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/). Next, create the `argocd` namespace in your cluster, which will contain Argo CD and its associated services: ```bash kubectl create namespace argocd ``` After that, you can run the Argo CD install script provided by the project maintainers. ```bash kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml ``` Once the installation completes successfully, you can use the `watch` command to check the status of your Kubernetes pods: ```bash watch kubectl get pods -n argocd ``` By default, there should be five pods that eventually receive the `Running` status as part of a stock Argo CD installation. ``` Output NAME READY STATUS RESTARTS AGE argocd-application-controller-0 1/1 Running 0 2m28s argocd-dex-server-66f865ffb4-chwwg 1/1 Running 0 2m30s argocd-redis-5b6967fdfc-q4klp 1/1 Running 0 2m30s argocd-repo-server-656c76778f-vsn7l 1/1 Running 0 2m29s argocd-server-cd68f46f8-zg7hq 1/1 Running 0 2m28s ``` You can press `Ctrl+C` to exit the `watch` interface. You now have Argo CD running in your Kubernetes cluster! However, because of the way Kubernetes creates abstractions around your network interfaces, you won’t be able to access it directly without forwarding ports from inside your cluster. You’ll learn how to handle that in the next step. ## Step 2 — Forwarding Ports to Access Argo CD Because Kubernetes deploys services to arbitrary network addresses inside your cluster, you’ll need to forward the relevant ports in order to access them from your local machine. Argo CD sets up a service named `argocd-server` on port 443 internally. Because port 443 is the default HTTPS port, and you may be running some other HTTP/HTTPS services, it’s common practice to forward those to arbitrarily chosen other ports, like `8080`, like so: ```bash kubectl port-forward svc/argocd-server -n argocd 8080:443 ``` Port forwarding will block the terminal it’s running in as long as it’s active, so you’ll probably want to run this in a new terminal window while you continue to work. You can press `Ctrl+C` to gracefully quit a blocking process such as this one when you want to stop forwarding the port. In the meantime, you should be able to access Argo CD in a web browser by navigating to `localhost:8080`. However, you’ll be prompted for a login password which you’ll need to use the command line to retrieve in the next step. You’ll probably need to click through a security warning because Argo CD has not yet been configured with a valid SSL certificate. **Note:** Using LetsEncrypt HTTPS certificates with Kubernetes is best accomplished with the use of additional tooling like [Cert-Manager](https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes). ## Step 3 — Working with Argo CD from the Command Line For the next steps, you’ll want to have the `argocd` command installed locally for interfacing with and changing settings in your Argo CD instance. Argo CD’s [official documentation](https://argo-cd.readthedocs.io/en/stable/cli_installation/) recommends that you install it via the [Homebrew](https://brew.sh/) package manager. Homebrew is very popular for managing command line tools on MacOS, and has more recently been ported to Linux to facilitate maintaining tools like this one. If you don’t already have Homebrew installed, you can retrieve and install it with a one-line command: ```bash ​​/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" ``` You may be prompted for your password during the installation process. Afterward, you should have the `brew` command available in your terminal. You can use it to install Argo CD: ```bash brew install argocd ``` This in turn provides the `argocd` command. Before using it, you’ll want to use `kubectl` again to retrieve the admin password which was automatically generated during your installation, so that you can use it to log in. You’ll pass it a path to a particular JSON file that’s stored using Kubernetes secrets, and extract the relevant value: ```bash kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo ``` ``` Output fbP20pvw-o-D5uxH ``` You can then log into your Argo CD dashboard by going back to `localhost:8080` in a browser and logging in as the `admin` user with your own password: ![Argo CD app status](https://dev-docs-image.s3.cn-north-1.jdcloud-oss.com/articles/70fbf915ca_argo.jpg) Once everything is working, you can use the same credentials to log in to Argo CD via the command line, by running `argocd login`. This will be necessary for deploying from the command line later on: ```bash argocd login localhost:8080 ``` You’ll receive the equivalent certificate warning again on the command line here, and should enter `y` to proceed when prompted. If desired, you can then change your password to something more secure or more memorable by running `argocd account update-password`. After that, you’ll have a fully working Argo CD configuration. In the final steps of this tutorial, you’ll learn how to use it to actually deploy some example applications. ## Step 4 — Handling Multiple Clusters (Optional) Before deploying an application, you should review where you actually want to deploy it. By default, Argo CD will deploy applications to the same cluster that Argo CD itself is running in, which is fine for a demo, but is probably not what you’ll want in production. In order to list all of the clusters known to your current machine, you can use `kubectl config`: ```bash kubectl config get-contexts -o name ``` ``` Output test-deploy-cluster test-target-cluster ``` Assuming that you’ve installed Argo CD into `test-deploy-cluster`, and you wanted to use it to deploy applications onto `test-target-cluster`, you could register `test-target-cluster` with Argo CD by running `argocd cluster add`: ```bash argocd cluster add target-k8s ``` This will add the additional cluster’s login details to Argo CD, and enable Argo CD to deploy services on the cluster. ## Step 5 — Deploying an Example Application (Optional) Now that you have Argo CD running and you have an understanding of how to deploy applications to different Kubernetes clusters, it’s time to put it into practice. The Argo CD project maintains a repository of [example applications](https://github.com/argoproj/argocd-example-apps) that have been architected to showcase GitOps fundamentals. Many of these examples are ports of the same `guestbook` demo app to different kinds of Kubernetes manifests, such as [Jsonnet](https://jsonnet.org/). In this case, you’ll be deploying the `helm-guestbook` example, which uses a [Helm chart](https://github.com/argoproj/argocd-example-apps/blob/master/helm-guestbook/Chart.yaml), one of the most durable Kubernetes management solutions. In order to do that, you’ll use the `argocd app create` command, providing the path to the Git repository, the specific `helm-guestbook` example, and passing your default destination and namespace: ```bash argocd app create helm-guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path helm-guestbook --dest-server https://kubernetes.default.svc --dest-namespace default ``` After “creating” the application inside of Argo CD, you can check its status with `argocd app get`: ```bash argocd app get helm-guestbook ``` ``` Output Name: helm-guestbook Project: default Server: https://kubernetes.default.svc Namespace: default URL: https://localhost:8080/applications/helm-guestbook Repo: https://github.com/argoproj/argocd-example-apps.git Target: Path: helm-guestbook SyncWindow: Sync Allowed Sync Policy: Sync Status: OutOfSync from (53e28ff) Health Status: Missing GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE Service default helm-guestbook OutOfSync Missing apps Deployment default helm-guestbook OutOfSync Missing ``` The `OutOfSync` application status is normal. You’ve retrieved the application’s helm chart from Github and created an entry for it in Argo CD, but you haven’t actually spun up any Kubernetes resources for it yet. In order to actually deploy the application you’ll run `argocd app sync`: ```bash argocd app sync helm-guestbook ``` `sync` is synonymous with deployment here in keeping with the principles of GitOps – the goal when using Argo CD is for your application to always track 1:1 with its upstream configuration. ``` Output TIMESTAMP GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE 2022-01-19T11:01:48-08:00 Service default helm-guestbook OutOfSync Missing 2022-01-19T11:01:48-08:00 apps Deployment default helm-guestbook OutOfSync Missing 2022-01-19T11:01:48-08:00 Service default helm-guestbook Synced Healthy 2022-01-19T11:01:48-08:00 Service default helm-guestbook Synced Healthy service/helm-guestbook created 2022-01-19T11:01:48-08:00 apps Deployment default helm-guestbook OutOfSync Missing deployment.apps/helm-guestbook created 2022-01-19T11:01:49-08:00 apps Deployment default helm-guestbook Synced Progressing deployment.apps/helm-guestbook created Name: helm-guestbook Project: default Server: https://kubernetes.default.svc Namespace: default URL: https://localhost:8080/applications/helm-guestbook Repo: https://github.com/argoproj/argocd-example-apps.git Target: Path: helm-guestbook SyncWindow: Sync Allowed Sync Policy: Sync Status: Synced to (53e28ff) Health Status: Progressing Operation: Sync Sync Revision: 53e28ff20cc530b9ada2173fbbd64d48338583ba Phase: Succeeded Start: 2022-01-19 11:01:49 -0800 PST Finished: 2022-01-19 11:01:50 -0800 PST Duration: 1s Message: successfully synced (all tasks run) GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE Service default helm-guestbook Synced Healthy service/helm-guestbook created apps Deployment default helm-guestbook Synced Progressing deployment.apps/helm-guestbook created ``` You have now successfully deployed an application using Argo CD! It is possible to accomplish the same thing from the Argo CD web interface, but it is usually quicker and more reproducible to deploy via the command line. However, it is very helpful to check on your Argo CD web dashboard after deployment in order to verify that your applications are running properly. You can see that by opening `localhost:8080` in a browser: ![Argo CD app status](https://dev-docs-image.s3.cn-north-1.jdcloud-oss.com/articles/71202d91cc_appstatus.jpg) At this point, the last thing to do is to ensure you can access your new deployment in a browser. To do that, you’ll forward another port, the way you did for Argo CD itself. Internally, the `helm-guestbook` app runs on the regular HTTP port `80`, and in order to avoid conflicting with anything that might be running on your own port `80` or on the port `8080` you’re using for Argo CD, you can forward it to port `9090`: ```bash kubectl port-forward svc/helm-guestbook 9090:80 ``` As before, you’ll probably want to do this in another terminal, because it will block that terminal until you press `Ctrl+C` to stop forwarding the port. You can then open `localhost:9090` in a browser window to see your example guestbook app: ![Guestbook app](https://dev-docs-image.s3.cn-north-1.jdcloud-oss.com/articles/bc8dd25644_guestbook.jpg) Any further pushes to this Github repository will automatically be reflected in ArgoCD, which will resync your deployment while providing continuous availability. ## Conclusion You’ve now seen the fundamentals of installing and deploying applications using Argo CD. Because Kubernetes requires so many layers of abstraction, it’s important to ensure that your deployments are as maintainable as possible, and the GitOps philosophy is a good solution. Next, you may want to learn about deploying [TOBS, The Observability Stack](https://www.digitalocean.com/community/tutorials/how-to-set-up-tobs-the-observability-stack-for-kubernetes-monitoring), for monitoring the uptime, health, and logging of your Kubernetes cluster.