GitOps Patterns: CGOA practice questions

GitOps patterns describe how releases, rollouts and the reconciling machinery are arranged once the desired state lives in a versioned store. The CGOA curriculum groups them into four areas: deployment and release patterns, progressive delivery patterns, pull versus event-driven reconciliation, and architecture patterns such as in-cluster versus external reconcilers and how the state store is managed.

Release strategies differ in how old and new versions coexist. The Argo Rollouts concepts page lists four. A rolling update slowly replaces the old version with the new one and is the default for a Kubernetes Deployment. Recreate deletes the old version before bringing up the new one, so two versions never run together but users see downtime. Blue-green has both versions deployed at once while only the old one receives production traffic until the switch; the CNCF glossary describes the switch as moving live traffic to the idle environment, often through a load balancer, once testing on it is finished. A canary exposes a subset of users to the new version while the rest stay on the old one until it is verified.

Progressive delivery is the name for releasing changes in a controlled, gradual way and letting automation and metric analysis decide whether to promote or roll back. Argo Rollouts implements this as a Kubernetes controller with its own custom resources: it can shift traffic gradually through ingress controllers and service meshes, query metric providers such as Prometheus, and promote or abort a rollout based on the results. A plain Deployment has no metric-driven promotion of its own, which is why such a controller is added.

Pull versus event-driven is about what starts a reconciliation. In the OpenGitOps model the agent must be able to pull the desired state from the store at any time, not only when something is pushed, because that is what lets it correct drift nobody announced. Events still have a place: Flux's notification controller accepts webhooks from systems such as GitHub and GitLab and tells the source controllers to fetch early, and Argo CD integrates webhooks from GitHub, GitLab and Bitbucket. The event shortens the wait; the periodic pull remains the safety net.

Architecture patterns ask where the reconciler runs and what it may reach. An in-cluster agent fetches from Git and applies changes inside the runtime it manages, so nothing outside has to push into that cluster. An external reconciler, such as one Argo CD instance deploying to several clusters, centralizes control and visibility in one place but must be able to reach every destination it manages. App of apps, where one Argo CD Application creates further Applications, is a common way to bootstrap many workloads from a single entry point.