Certified Kubernetes Administrator (CKA) Exam Preparation
5% - Scheduling
- Use label selectors to schedule Pods.
It specifies a map of key-value pairs. For the pod to be eligible to run on a node, the node must have each of the indicated key-value pairs as labels (it can have additional labels as well).
kubectl label nodes <node-name> <label-key>=<label-value>
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd
Interlude: built-in node labels
The key enhancements are
- the language is more expressive (not just “AND of exact match”)
- you can indicate that the rule is “soft”/”preference” rather than a hard requirement, so if the scheduler can’t satisfy it, the pod will still be scheduled
- you can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
Node affinity is conceptually similar to
nodeSelector– it allows you to constrain which nodes your pod is eligible to schedule on, based on labels on the node. There are currently two types of node affinity, called
The “IgnoredDuringExecution” part of the names means that, similar to how
nodeSelectorworks, if labels on a node change at runtime such that the affinity rules on a pod are no longer met, the pod will still continue to run on the node.
spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: another-node-label-key operator: In values: - another-node-label-value
The new node affinity syntax supports the following operators:
If you specify both
nodeAffinity, both must be satisfied for the pod to be scheduled onto a candidate node.
If you specify multiple
nodeAffinitytypes, then the pod can be scheduled onto a node if one of the
If you specify multiple
nodeSelectorTerms, then the pod can be scheduled onto a node only if all
matchExpressionscan be satisfied.
Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods that are already running on the node rather than based on labels on nodes.
You express it using a
topologyKeywhich is the key for the node label that the system uses to denote such a topology domain
spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: failure-domain.beta.kubernetes.io/zone podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: security operator: In values: - S2 topologyKey: kubernetes.io/hostname
The legal operators for pod affinity and anti-affinity are
- Understand the role of DaemonSets.
A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected.
Some typical uses of a DaemonSet are:
- running a cluster storage daemon, such as
ceph, on each node.
- running a logs collection daemon on every node, such as
- running a node monitoring daemon on every node, such as Prometheus Node Exporter,
collectd, Datadog agent, New Relic agent, or Ganglia
- running a cluster storage daemon, such as
apiVersion: apps/v1beta2 # for versions before 1.8.0 use extensions/v1beta1 kind: DaemonSet
A Pod Template in a DaemonSet must have a
Always, or be unspecified, which defaults to
As of Kubernetes 1.8, you must specify a pod selector that matches the labels of the
If you specify a
.spec.template.spec.nodeSelector, then the DaemonSet controller will create Pods on nodes which match that node selector. Likewise if you specify a
.spec.template.spec.affinity, then DaemonSet controller will create Pods on nodes which match that node affinity.
unschedulablefield of a node is not respected by the DaemonSet controller.
- The DaemonSet controller can make Pods even when the scheduler has not been started, which can help cluster bootstrap.
Daemon Pods do respect taints and tolerations, but they are created with
NoExecutetolerations for the following taints with no
If node labels are changed, the DaemonSet will promptly add Pods to newly matching nodes and delete Pods from newly not-matching nodes.
In Kubernetes version 1.6 and later, you can perform a rolling update on a DaemonSet.
- Init Scripts
- Bare Pods
- Static Pods
- Understand how resource limits can affect Pod scheduling.
- Understand how to run multiple schedulers and how to configure Pods to use them.
- Manually schedule a pod without a scheduler.
- Display scheduler events.
- Know how to configure the Kubernetes scheduler.
5% - Logging/Monitoring
- Understand how to monitor all cluster components.
- Understand how to monitor applications.
- Manage cluster component logs.
- Manage application logs.
8% - Application Lifecycle Management
- Understand Deployments and how to perform rolling updates and rollbacks.
- Know various ways to configure applications.
- Know how to scale applications.
- Understand the primitives necessary to create a self-healing application.
11% - Cluster Maintenance
- Understand Kubernetes cluster upgrade process.
- Facilitate operating system upgrades.
- Implement backup and restore methodologies.
12% - Security
- Know how to configure authentication and authorization.
- Understand Kubernetes security primitives.
- Know to configure network policies.
- Create and manage TLS certificates for cluster components.
- Work with images securely.
- Define security contexts.
- Secure persistent key value store.
- Work with role-based access control.
7% - Storage
- Understand persistent volumes and know how to create them.
- Understand access modes for volumes.
- Understand persistent volume claims primitive.
- Understand Kubernetes storage objects.
- Know how to configure applications with persistent storage.
10% - Troubleshooting
- Troubleshoot application failure.
- Troubleshoot control plane failure.
- Troubleshoot worker node failure.
- Troubleshoot networking.
19% - Core Concepts
- Understand the Kubernetes API primitives.
- Understand the Kubernetes cluster architecture.
- Understand Services and other network primitives.
11% - Networking
- Understand the networking configuration on the cluster nodes.
- Understand Pod networking concepts.
- Understand service networking.
- Deploy and configure network load balancer.
- Know how to use Ingress rules.
- Know how to configure and use the cluster DNS.
- Understand CNI.
12% - Installation, Configuration & Validation
- Design a Kubernetes cluster.
- Install Kubernetes masters and nodes, including the use of TLS bootstrapping.
- Configure secure cluster communications.
- Configure a Highly-Available Kubernetes cluster.
- Know where to get the Kubernetes release binaries.
- Provision underlying infrastructure to deploy a Kubernetes cluster.
- Choose a network solution.
- Choose your Kubernetes infrastructure configuration.
- Run end-to-end tests on your cluster.
- Analyse end-to-end tests results.
- Run Node end-to-end tests.