GitOps - Argo CD - GDSC WoW Punjab

Editor's Notes

• #3: Knowing the audience: How many of you are familiar with Containers, Kubernetes, DevOps etc.? 2 sections: Basic: Where I will be setting up the context Advanced topics.
• #5: Knowing the audience: How many of you are familiar with Containers, Kubernetes, DevOps etc.? Before this, explain audience about how software development is done in real world. Then explain about this slide. Install and setup tools like kubectl. On Jenkins you will install Kubectl is just a client. You need to configure access. If multiple clusters, multiple access needs to be configured Access to GCP Did the app get created, is it healthy? It can only be found out by following the test steps. ArgoCD is built to tackle all these challenges and make the CD process more efficient.
• #7: GitOps vs DevOps Developer centric approach to CD. Git as your source of truth. (Any version control will do)
• #8: Continuous Delivery Tool Rather than using helm, kubectl or any other interface, they use the same interface, which is git commit. And Argo takes care of everything. ArgoCD is part of the K8s cluster. This gives visibility into the cluster. Uses etcd to store the data. ArgoCD agent pulls K8s manifest changes and applied them. ArgoCD supports: Plain K8s YAML Files Helm Charts Kustomize Advantages: Whole K8s configuration defined as code in Git Repository. Git as single source of truth. (no one can manually do some changes) ArgoCD watches the changes in the cluster as well. Controller (Actual State should always be be equal to Desired State) Configure ArgoCD to not sync manual cluster changes automatically. Send alert instead. Version controlled changes. (History of changes and audit trail). Since everything goes through Git and not through rogue kubectl apply commands. Easy Rollback. No need for kubectl delete ot helm remove Easy Cluster Disaster Recovery K8s Access Control with Git. Extends the K8s API with Custom Resource Definition (CRD) Application Logically groups apps - AppProjects. And set restrictions on what git repos maybe deployed and where (clusters and namespaces) apps may be deployed to.
• #9: Continuous Deployment Tool Rather than using helm, kubectl or any other interface, they use the same interface, which is git commit. And Argo takes care of everything. ArgoCD is part of the K8s cluster. This gives visibility into the cluster. Uses etcd to store the data. ArgoCD agent pulls K8s manifest changes and applied them. ArgoCD supports: Plain K8s YAML Files Helm Charts Kustomize Advantages: Whole K8s configuration defined as code in Git Repository. Audit Control Git as single source of truth. (no one can manually do some changes) ArgoCD watches the changes in the cluster as well. Controller (Actual State should always be be equal to Desired State) Configure ArgoCD to not sync manual cluster changes automatically. Send alert instead. Version controlled changes. (History of changes and audit trail). Since everything goes through Git and not through rogue kubectl apply commands. Easy Rollback. No need for kubectl delete ot helm remove Easy Cluster Disaster Recovery K8s Access Control with Git. Extends the K8s API with Custom Resource Definition (CRD) Application Logically groups apps - AppProjects. And set restrictions on what git repos maybe deployed and where (clusters and namespaces) apps may be deployed to.
• #10: Probing: What a controller is in Kubernetes? API Server: Application management and status reporting. Application ops eg: sync, rollback, user-defined actions Credentials management RBAC enforcement Repository Service: Internal service which maintains a local cache of the Git repo Contains the apps manifest. Manifests can be in for Kustomize or Helm templates. GH uses webhook events to notify ArgoCD as to when commit has been made to the repo. Application Controller: K8s controller which continuously monitors running applications. Compares the current, live state of the app against the target state Detects when something is out of sync and automatically syncs it.
• #12: Logically groups apps - AppProjects. And set restrictions on what git repos maybe deployed and where (clusters and namespaces) apps may be deployed to.
• #13: What do I mean by Scale? Multiple apps Multiple K8s clusters
• #14: Have appropriate SA in place. For ArgoCD to do cluster bind And GKE clusters on which the apps run to pull images from GCR Multiple ways: Single ArgoCD Pros Single control plane Cons Single point of failure Security concerns Scalability challenges
• #15: ArgoCD on each cluster Pros Secure Easier to scale Cons No single control plane Management Nightmare
• #17: Suppose you have a new cluster and are looking to install many apps in that cluster. There's no one particular pattern to solve this problem, e.g. you could write a script to create your apps, or you could even manually create them. However, users of Argo CD tend to use the app of apps pattern. How do I bootstrap in a GitOps way? Going to create an application which deploys applications. One manifest and get my entire applications up and running. If someone delete guestbook app then applications app will redeploy it. ApplicationSet: Next iteration. Templating engine to create applications Generators: List Git Cluster
• #18: Argo CD has the ability to automatically sync an application when it detects differences between the desired manifests in Git, and the live state in the cluster. Pruning: By default (and as a safety mechanism), automated sync will not delete resources when Argo CD detects the resource is no longer defined in Git. To prune the resources, a manual sync can always be performed (with pruning checked). Self Heal: By default, changes that are made to the live cluster will not trigger automated sync.
• #19: Github Actions: Checkout Source Code Docker Build Docker Push to GCR Update Image tag in Deploy Repo Best Practice to have 2 repos Why separate Git repo: Not only deployment but also CM, Secret. K8s manifest files can change independent of source code. You don’t want to trigger the full CI pipeline if there’s no change in the source code. CI Pipeline owned by Developers and CD pipelines by Ops.
• #20: Why separate Git repo: Not only deployment but also CM, Secret. K8s manifest files can change independent of source code. You don’t want to trigger the full CI pipeline if there’s no change in the source code. CI Pipeline owned by Developers and CD pipelines by Ops.
• #21: Intuit has 350+ clusters and they are using the third approach but orgs can use any of the above three approaches to setup their ArgoCD to manage multiple clusters.