Task 1.1: Kubernetes Core Concepts

• Akube-apiserver

  Incorrect

  The API server exposes the Kubernetes HTTP API and validates requests; it keeps no data of its own.

• Bkube-controller-manager

  Incorrect

  It runs the controllers that act on objects. It reads and writes through the API and keeps no store of its own to back up.

• CThe etcd cluster

  Correct

  etcd is the consistent, highly available key-value store that keeps all API server data. Back it up and you can restore the cluster's objects.

• DThe kubelet

  Incorrect

  The kubelet is the agent on each node that makes sure the Pods assigned to it are running. It holds node-local state only.

Every Kubernetes object is persisted in etcd. The other control plane components and the node agents work through the API, so the etcd data is what a backup of the cluster's state has to capture.

• AA controller saw 2 Pods against the desired 3 and created another

  Correct

  The ReplicaSet behind the Deployment runs a control loop that drives the observed state toward the declared replica count, so it creates a replacement Pod.

• BThe kubelet restarted the deleted Pod on the same node from its local copy

  Incorrect

  The kubelet restarts containers of Pods that still exist. A deleted Pod is gone; the replacement is a new object with a new name.

• Ckube-proxy recreated the Pod so the Service would keep three endpoints

  Incorrect

  kube-proxy maintains network rules for Services on each node. It never creates Pods.

• DThe API server rolled the delete back because the Pod belonged to a Deployment

  Incorrect

  The delete succeeded, which is why the new Pod has a different name. Nothing reverses an accepted request.

Kubernetes works by reconciliation: a controller watches the shared state through the API and makes changes until the current state matches the desired state. Here the ReplicaSet controller noticed one Pod too few.

• ADaemonSet

  Correct

  A DaemonSet makes all (or selected) nodes run a copy of a Pod and adds the Pod to new nodes as they join. Log collectors are a textbook use.

• BDeployment with one replica per node

  Incorrect

  A Deployment keeps a replica count, not one Pod per node. Two replicas can land on the same node, and a new node gets nothing.

• CStatefulSet

  Incorrect

  A StatefulSet runs a counted set of replicas; it does not follow the node list.

• DJob with parallelism equal to the node count

  Incorrect

  A Job runs Pods to completion. An agent that must keep running on every node is not batch work.

Per-node daemons such as log collectors, node monitoring agents and storage daemons are what DaemonSets are for: the controller follows the node list rather than a replica count.

• AThe Service's ClusterIP on port 8080

  Incorrect

  A Service load-balances across every ready Pod it selects, so the request could reach a copy in another Pod.

• BThe application container's own IP on port 8080

  Incorrect

  Containers in a Pod do not get their own addresses; they share the Pod's IP address and port space.

• CThe node's IP address on port 8080

  Incorrect

  That only works with a hostPort or host networking, and it would reach whatever listens on that node, not specifically this Pod.

• Dlocalhost:8080, from inside the Pod

  Correct

  Containers in the same Pod share one network namespace, so the proxy reaches the application on the loopback interface.

A Pod is a group of containers that share network and storage context. Every container in it shares the Pod's IP address and ports and can talk to the others over localhost.

• AIn labels under metadata

  Incorrect

  Labels are meant for identifying and selecting objects, and their values are short and restricted in format. Data nobody selects on belongs elsewhere.

• BIn annotations under metadata

  Correct

  Annotations hold arbitrary, non-identifying metadata for tools and people, and their values may be long or structured.

• CIn a ConfigMap mounted into the Deployment's Pods

  Incorrect

  A ConfigMap carries configuration for the application inside the containers. It does not describe the Deployment object to tools.

• DIn the Deployment's spec.selector

  Incorrect

  The selector decides which Pods the Deployment manages and cannot be changed after creation for apps/v1. It is not a place for notes.

Use labels for attributes you query and select by, and annotations for descriptive metadata such as build information, contacts or tool settings.

• APersistentVolumeClaim

  Incorrect

  A claim is created in a namespace and is the namespaced request for storage.

• BRole

  Incorrect

  A Role grants permissions within one namespace and is itself namespaced; its cluster-wide counterpart is ClusterRole.

• CNetworkPolicy

  Incorrect

  A NetworkPolicy is namespaced and applies to Pods in its own namespace.

• DStorageClass

  Correct

  StorageClass is a cluster-wide object, like Nodes and PersistentVolumes, so namespace permissions do not cover it.

Namespace scoping applies only to namespaced kinds such as Deployments, Services and claims. Cluster-wide kinds such as StorageClass, Node and PersistentVolume need cluster-level permission.

• ADeployment with replicas set to 1

  Incorrect

  A Deployment keeps its Pods running and restarts them after they exit, so a finished migration would run again and again.

• BA CronJob scheduled before each release window

  Incorrect

  A CronJob starts Jobs on a repeating schedule. A migration tied to each release is not time-based.

• CA Job created for each release

  Correct

  A Job creates Pods until the requested number complete successfully, retries failures, and then stops.

• DA DaemonSet with a single-node selector

  Incorrect

  A DaemonSet runs a long-lived Pod per node, which would start the migration once on every node.

Run-to-completion work is a Job. CronJobs add a schedule on top of Jobs; Deployments and DaemonSets are for work that keeps running.

• Akube-scheduler

  Correct

  The scheduler is a control plane component that assigns new Pods to nodes.

• Bkubelet

  Incorrect

  The kubelet is a node component; it runs on every worker node to start and watch that node's Pods.

• Ckube-controller-manager

  Correct

  The controller manager is a control plane component that runs the built-in controllers.

• Dkube-proxy

  Incorrect

  kube-proxy is an optional node component, not part of the control plane.

• EThe container runtime

  Incorrect

  The runtime runs containers on each node and is part of the node components.

The control plane is kube-apiserver, etcd, kube-scheduler, kube-controller-manager and the optional cloud-controller-manager. The kubelet, kube-proxy and the container runtime run on the nodes.

• Ametadata.name

  Incorrect

  The name was reused, so it is the same for both objects.

• Bmetadata.uid

  Correct

  Every object created over the lifetime of a cluster gets a distinct UID, which separates historical occurrences of similar objects.

• Cmetadata.namespace

  Incorrect

  Both objects lived in the same namespace.

• Dmetadata.labels

  Incorrect

  Labels are copied from the same template and can be identical.

Names can be reused after deletion; the UID is unique for the whole life of the cluster.

• Akubernetes.io/cost-center

  Incorrect

  The kubernetes.io/ prefix is reserved for Kubernetes core components.

• Bk8s.io/cost-center

  Incorrect

  The k8s.io/ prefix is reserved as well.

• Cfinance.example.com/cost-center

  Correct

  A prefix based on a DNS subdomain you control keeps the key yours; kubernetes.io/ and k8s.io/ are reserved for core components.

• Dcost center, with a space

  Incorrect

  Spaces are not allowed in label keys.

Label keys can carry a DNS-style prefix; use your own domain and leave the Kubernetes prefixes to Kubernetes.

• ABy writing Job objects straight into etcd

  Incorrect

  Writing to etcd bypasses validation, admission and every controller that reads through the API.

• BBy running kubectl in a subshell from inside the code

  Incorrect

  It works, but kubectl is a tool for people; programs should call the API directly.

• CThrough the Kubernetes API, with a client library

  Correct

  Kubernetes provides client libraries for calling its REST API from programs; kubectl uses the same API.

• DBy sending commands to the kubelet on each of the nodes

  Incorrect

  The kubelet runs Pods bound to its node; it does not accept Job objects.

Everything in Kubernetes goes through its API. Programs use the REST endpoints, usually through a client library.

• AEvery day at 02:00, in the controller manager's time zone

  Correct

  The fields are minute, hour, day of month, month and day of week, so minute 0 of hour 2, each day; without spec.timeZone, kube-controller-manager uses its local time zone.

• BEvery two hours, on the hour, starting at 02:00

  Incorrect

  That would need a step value in the hour field, such as */2.

• CAt 00:02 on the first day of each month

  Incorrect

  The first field is the minute and the second the hour, not the other way round.

• DAt 02:00 on Sundays, once a week

  Incorrect

  A day of week of 0 would have to be in the fifth field.

CronJob schedules use the five-field cron format: minute, hour, day of month, month, day of week.