Cloud Native Application Delivery: KCNA practice questions

Application delivery covers everything between a commit and a running, updated workload: building and testing the change, packaging the manifests, rolling the new version out safely and keeping the cluster in step with what was approved.

GitOps is the model this topic keeps returning to. The OpenGitOps project defines it through four principles. The desired state of the system must be expressed declaratively. That state is stored in a way that enforces immutability and versioning and keeps a complete history, which for most teams means a Git repository. Software agents pull the desired state from that source automatically, rather than a pipeline pushing into the cluster. And those agents continuously observe the actual state and try to apply the desired one. Argo CD is a declarative GitOps continuous delivery tool for Kubernetes built on exactly this loop: it runs as a controller, compares the live state of each application with the target state in Git, marks an application OutOfSync when they differ, for instance after someone edits a resource by hand, and can bring it back either automatically or on demand.

Packaging is handled by two tools with different philosophies. Helm installs charts, packages of Kubernetes resources that can be published to and loaded from chart repositories. Installing a chart creates a release, and every install, upgrade or rollback increments that release's revision number, so helm history lists the revisions and helm rollback returns to an earlier one. Configuration is supplied as values: a chart's defaults can be overridden with a YAML file passed with -f, or on the command line with --set, which takes precedence. Kustomize instead customizes plain YAML through a kustomization file and is built into kubectl as kubectl apply -k. A base is a directory of shared resources, and an overlay is a directory whose kustomization refers to one or more bases and adds changes for an environment such as dev or prod; a base knows nothing about the overlays that use it. Argo CD can deploy Helm charts, Kustomize directories and plain YAML alike, so choosing one tool does not rule out the other.

Rollout strategy decides how a new version replaces the old one. A Deployment's default strategy is RollingUpdate, which scales the new ReplicaSet up and the old one down gradually; maxSurge and maxUnavailable both default to 25% and control how far the rollout may go above or below the desired replica count. The Recreate strategy kills all old Pods before creating new ones, accepting downtime. A canary releases the new version to a subset of users or servers first, which the Kubernetes docs show with one Deployment per release.

Finally, traffic has to reach the application. An Ingress exposes HTTP and HTTPS routes from outside the cluster to Services, but creating one has no effect without an Ingress controller to implement it. The Ingress API is now frozen, and the Kubernetes project recommends Gateway API, which splits the job into role-oriented resources: a GatewayClass describes a kind of gateway managed by a controller, a Gateway is an actual instance of traffic-handling infrastructure, and HTTPRoute or GRPCRoute objects attach to it with routing rules. Header matching and traffic weighting are built in rather than left to controller-specific annotations.