Progressive Delivery with ArgoCD - Manage Kubernetes Clusters

Introducing Application Development with GitOps

We end up running and managing several Kubernetes clusters as we incorporate containers and Kubernetes. Some are used for manufacturing, others for QA, and still others for short-term development environments. We need to package and deploy applications to these clusters in a variety of situations. The types of applications we want to deploy can also differ significantly. On the one side, we have third-party apps with their Helm charts, such as Grafana, Elasticsearch, and Kafka. This software will also be distributed after being customized to our use case and pinned to a particular version. On the other side, we have custom apps that are revised and implemented on a weekly basis. In several cases, it's also several times a day.

GitOps uses Git as a single source of truth for infrastructures like declarative infrastructure and applications. Click to explore about, Gitops Tools | Principles | Benefits | Use Cases

Installing, upgrading, and running these applications on several clusters is a challenge in both cases. For a few clusters, say it's about ten, a continuous integration pipeline (like Jenkins) could be set up to deploy to each one using a design rendering method of your choosing (Helm, etc.). On a smaller scale, this method works. What if there were a hundred clusters, each with a dozen or more apps? We'll look at how to install an application in one cluster and keep it updated, as well as how to deploy several applications to different clusters.

How GitOps is best for Application Development?

One of the solutions to this challenge is GitOps. The resources running in the clusters should fit the templates or configs specified in a git repository. It also includes an agent that will download and add all new commits to the git repository to the cluster. A cronjob that clones the git repository, makes the templates and applies them to a target cluster can be the simplest type of an agent. Adopting GitOps has a number of benefits. Here are a few examples:

1. It becomes very simple and straightforward to undo a transition. All you have to do is revert the commit that contains the update with git.
2. Looking through the git repositories gives us a single source of truth about what's going on in the cluster.
3. Pull Requests encourage others to check and point out any issues with any configuration or code updates. It's much easier to audit and monitor improvements. Any update is logged as a commit in git.
4. With GitOps, deployments become declarative, meaning users decide what they want to run, and the code manages resource development and deletion. The process becomes recognizable as well. Any configuration drift can be detected and corrected quickly by the operations team.
5. When we use GitOps, it takes to push an update to a development cluster is significantly reduced.

The real difference between Traditional vs Cloud Native Applications to scale up your business. Click to explore about, Which One to Choose: Cloud Native or Traditional App Development?

What is ArgoCD?

ArgoCD is a declarative Kubernetes GitOps continuous distribution platform. ArgoCD attempts to compare the current state of the cluster's resources to the models created by the git repository at the most recent commit. It makes resource models from a git repository regularly and compares them to the cluster's current state. Manual synchronization through the Graphical User Interface is possible, as is setting up a post-commit webhook. It's even possible that it'll be completed automatically. The templates will be applied to the cluster after sync.

Demo

Let's get started making an ArgoCD application. We'll use a Helm chart to deploy nginx using a Deployment and a Service to keep it straightforward.

Some Prerequisites:

1. Minikube
2. Helm
3. ArgoCD CLI
4. A Kubernetes Cluster (for multi-cluster deployments)

Steps to follow:

Configure the cluster. Minikube will be used to create our cluster.

• Start Minikube

$ minikube start --kubernetes-version="v1.18.10"

• Install Helm from given commands

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

• Now, install ArgoCD through the helm.

$ helm repo add argo https://argoproj.github.io/argo-helm
$ helm repo update
$ helm install --name argocd --namespace argocd argo/argo-cd --wait.

If the pods are up and running, we can connect using the CLI and GUI by port forwarding to the argocd-server service. The argocd-server pod's name serves as the original admin password. To print and copy it, use the commands below. In order to log into ArgoCD, we'll need the information in the next step.

• Check the status of argocd pods.

$ kubectl get pod -n argocd -l app.kubernetes.io/name=argocd-server

• After obtaining the admin password, we will port-forward and log in using the "admin" account and the password we obtained in the previous stage.

$ kubectl port-forward service/argocd-server -n argocd 8080:443

After accepting the self-signed certificate, we can enter the GUI at localhost:8080 using the same credentials. Let's use the GUI to deploy a sample script. We'll see this page after you've signed in.

Stateful and Stateless Applications is the foundation upon which most architectures and designs are based upon — concepts like RESTful design. Click to explore about, Stateful and Stateless Applications Best Practices and Advantages

Application Development in Nginx

Fill in this information by clicking "Create Application." We can also look at the Application Custom Resource (CR) spec created by the GUI by clicking the “Edit as YAML” button. This spec can also be modified to Fill in this information by clicking "Create Application explicitly." We can also look at the Application Custom Resource (CR) spec created by the GUI by clicking the “Edit as YAML'' button. This spec can also be modified explicitly to execute acts that the form's GUI doesn't support.

If the Application is created, this page will be available. Since automated synchronization is disabled, the app's health will be Missing, and its state will be out of sync. When we open the app, we can see a comparison for each resource. To deploy the program to the cluster, select sync from the drop-down menu.

We can verify whether Nginx is running by going to the node port IP once the application is safe and synced. To open the URL in the default window, type the following button. The default Nginx landing page will be shown.

$ minikube service nginx-service --url

By flipping to a different branch, we can simulate a commit. Click "test" and then "App Details" to verify the values to open the application.

Select edit and change the TargetRevision to "nginxV2." This is a git repository branch that has a commit that updates the Nginx landing page. Once we have made our changes, click “Sync.” A new ReplicaSet will be built. If you go to the Nginx URL, we'll notice an additional line that says, "This was deployed using ArgoCD." The following command will open the URL.

$ minikube service nginx-service --url

Cleanup

To remove the apps, use the commands below.

$ argocd app delete <app_name>

Our solutions cater to diverse industries with a focus on serving ever-changing marketing needs. Click to explore our Application Development and Deployment Solutions

Points to remember

Cluster administrators should consider using the following to strengthen tenant isolation:

1. Resource Quotas for capital (limit the compute resources that a team can request)
2. Policies for the network (restrict cross namespace traffic)
3. Security measures for pods (prevent running privileged containers or host network and filesystem usage)
4. Admissions controller for Open Policy Agent (enforce custom policies on Kubernetes objects)

• Click to explore Continuous Delivery Solutions with GitOps
• Discover more about DevOps Assembly Lines and CI Pipelines