Free KCNA flashcards

Which Kubernetes workload object guarantees exactly one copy of a Pod on every eligible node, including nodes that join later?

A DaemonSet. Its controller watches the set of nodes and reconciles one matching Pod per eligible node, adding Pods when nodes join and removing them when nodes leave, which is why it fits cluster-wide agents like log or metrics collectors.

A Deployment can run one Pod on every node because it keeps a fixed number of identical replicas across the cluster.

A Deployment maintains a chosen replica count and lets the scheduler place those Pods anywhere, so it is tempting for any run-this-everywhere need, but it cannot guarantee one Pod per node and will not react to new nodes joining.

A workload only needs a stable internal address and DNS name reachable from within the cluster, never from outside. Which Service type gives this with the least exposure?

ClusterIP, the default Service type. It allocates a virtual IP from the service CIDR plus a cluster DNS name that kube-proxy routes only to backing Pods, so traffic never leaves the cluster boundary.

A NodePort Service is a safe choice for an internal-only cache because it just gives a stable target for other Pods.

NodePort is tempting because it also gives a stable target, but it opens a port on every node's external IP, exposing the cache beyond the cluster, which an internal-only requirement forbids.

What are the two defining pillars of GitOps that distinguish it from other cluster delivery approaches?

A declarative desired state versioned in Git, plus a reconciliation loop running in or against the cluster that continuously drives actual state to match the committed state. This makes Git the single source of truth.

Isn't GitOps just a CI server holding the authoritative config and running kubectl apply whenever a build succeeds?

Tempting because CI pipelines do deploy to clusters, but this describes a push model where an external system imperatively applies changes, rather than a Git repository being the declarative source of truth that the cluster reconciles against.

Under immutable infrastructure, how do you change the configuration of a running service?

You never modify a live instance; you build a new versioned artifact with the change and deploy it as a replacement. This eliminates configuration drift and makes rollbacks predictable.

Can you just open a shell into each running container and edit the config files directly, avoiding a redeploy?

Tempting because it seems faster, but editing files inside a live container mutates the running instance in place, which is the mutable pattern immutable infrastructure exists to avoid.