Cloud Native Architecture: KCNA practice questions

Cloud native architecture starts from a definition the Cloud Native Computing Foundation maintains in its Technical Oversight Committee repository. Version 1.1 says cloud native practices let organizations develop, build and deploy workloads in public, private and hybrid clouds, and that the architectures typically combine some of these technologies: containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless and declarative APIs. The resulting systems are loosely coupled and interoperate in a way that is secure, resilient, manageable, sustainable and observable. Combined with robust automation, the definition says, these practices let engineers make high-impact changes frequently and predictably with minimal toil.

The CNCF itself is part of the nonprofit Linux Foundation, states its mission as making cloud native computing ubiquitous, and hosts open-source projects that implement this architecture, Kubernetes and Prometheus among them. Its projects move through maturity levels. Sandbox projects are experimental and not yet widely tested in production. Incubating projects are used successfully in production by a small number of users and have a healthy pool of contributors. Graduated projects are considered stable, widely adopted and production ready. Projects that have reached the end of their lifecycle are archived.

Kubernetes supports loosely coupled services with declarative objects and with workload types that match different needs. Stateless services usually run as Deployments. An application that needs a stable, unique network identity, stable persistent storage, or ordered deployment and scaling, such as a database or a clustered message broker, runs as a StatefulSet. Its Pods are named after the set with an ordinal, web-0, web-1 and so on; they are created in order from 0 and removed in reverse order, they rely on a headless Service for their network identity, and volumeClaimTemplates give each Pod its own PersistentVolume, which is not deleted when the set is scaled down.

Image handling is a small but concrete part of this topic. The imagePullPolicy field takes three values. Always makes the kubelet ask the container runtime to resolve the tag to a digest on every container start, downloading only layers it does not have. IfNotPresent pulls only when the image is not already on the node, and Never never pulls. If you leave the field out, the cluster fills it in when the Pod is created: Always for an image tagged :latest or with no tag at all, IfNotPresent for any other tag or a digest.

Observable is one of the qualities the definition names, and it is the reason metrics, logs and traces are designed in from the start rather than added after an incident; Prometheus, the CNCF-hosted monitoring system, is the usual answer for the metrics part.