DevOps Kubernetes Syllabus

What is the sidecar container pattern?

The sidecar pattern places a secondary helper container in the same Pod as the main application container to extend or enhance it, sharing the Pod's network and volumes. Common uses include log shippers, proxies (service mesh), and data synchronizers.

What are init containers?

Init containers are specialized containers in a Pod that run to completion, one at a time and in order, before the main application containers start. They are used for setup tasks such as waiting for a dependency, cloning a repo, or running database migrations.

Why are Pods considered ephemeral, and what is the implication?

Pods are mortal: they are created and destroyed and are never resurrected with the same identity (a new Pod gets a new IP). Because their IPs are unstable, you should not connect directly to Pod IPs; instead use a Service for a stable network endpoint.

What is a ReplicaSet?

A ReplicaSet is a controller that ensures a specified number of identical Pod replicas are running at all times. If a Pod dies or is deleted, the ReplicaSet creates a replacement; if there are too many, it deletes extras. It uses a label selector to identify the Pods it manages.

What is a Deployment and how does it relate to a ReplicaSet?

A Deployment is a higher-level controller that manages ReplicaSets to provide declarative updates, rolling rollouts, and rollbacks for stateless applications. When you update a Deployment, it creates a new ReplicaSet and gradually shifts Pods from the old ReplicaSet to the new one.

What are the two built-in Deployment update strategies, and how do they differ?

RollingUpdate (the default) gradually replaces old Pods with new ones, controlled by maxSurge and maxUnavailable, giving zero-downtime updates. Recreate terminates all old Pods first and then creates new ones, causing downtime but ensuring no two versions run simultaneously.

What do maxSurge and maxUnavailable control in a RollingUpdate?

maxSurge is the maximum number of Pods that can be created above the desired replica count during an update. maxUnavailable is the maximum number of Pods that can be unavailable during the update. Both can be absolute numbers or percentages, tuning rollout speed versus availability.

How do you roll back a Deployment to a previous version?

Use `kubectl rollout undo deployment/<name>` to revert to the previous revision, or add `--to-revision=<n>` to target a specific revision. Deployments keep a revision history (limited by revisionHistoryLimit) that makes rollbacks possible.

What is a Kubernetes Service?

A Service is an abstraction that defines a stable, logical set of Pods (selected by labels) and a policy to access them. It provides a single, durable virtual IP (ClusterIP) and DNS name, load-balancing traffic across the matching Pods even as individual Pods come and go.

Compare the four main Service types: ClusterIP, NodePort, LoadBalancer, and ExternalName.

ClusterIP (default) exposes the Service on an internal cluster-only IP. NodePort exposes it on a static port on every node's IP (range 30000–32767). LoadBalancer provisions an external cloud load balancer pointing to the Service. ExternalName maps the Service to an external DNS name via a CNAME record, with no proxying.

What is the default NodePort range in Kubernetes?

NodePort Services allocate a port in the range $30000$ to $32767$ by default. This range is configurable via the kube-apiserver flag `--service-node-port-range`.

What is a headless Service and when is it used?

A headless Service is created by setting `clusterIP: None`. Instead of providing a single virtual IP and load balancing, DNS returns the individual Pod IPs directly. It is used when clients need to connect to specific Pods, such as with StatefulSets and stateful databases.

How does an Ingress differ from a Service of type LoadBalancer?

A LoadBalancer Service exposes a single Service externally, typically at Layer 4 (TCP/UDP), one load balancer per Service. An Ingress is a Layer 7 (HTTP/HTTPS) router that provides host- and path-based routing, TLS termination, and virtual hosting for many Services behind a single entry point, but requires an Ingress controller (e.g., NGINX) to function.

What is a ConfigMap?

A ConfigMap is an API object that stores non-confidential configuration data as key-value pairs. It decouples configuration from container images, and the data can be consumed by Pods as environment variables, command-line arguments, or files mounted via a volume.

What is a Secret and how does it differ from a ConfigMap?

A Secret stores small amounts of sensitive data such as passwords, tokens, and keys. It is functionally similar to a ConfigMap but intended for confidential data. Secret values are Base64-encoded in the manifest (not encrypted by default), and Kubernetes adds protections like optional encryption-at-rest in etcd and restricted RBAC access.

Is data in a Kubernetes Secret encrypted by default? Explain.

No. By default Secret data is only Base64-encoded, which is encoding, not encryption, and is trivially reversible. To protect Secrets at rest you must enable encryption at rest for etcd (an EncryptionConfiguration) and use RBAC to restrict access; external managers like Vault or sealed-secrets add further protection.

Name common Kubernetes Secret types.

Opaque (default, arbitrary user data), kubernetes.io/dockerconfigjson (registry credentials), kubernetes.io/tls (TLS cert and key), kubernetes.io/service-account-token, and kubernetes.io/basic-auth and kubernetes.io/ssh-auth.

What is a Volume in Kubernetes and how does its lifetime compare to a container's?

A Volume is a directory accessible to the containers in a Pod, used to share data and persist it across container restarts. A Volume's lifetime is tied to the Pod, not to individual containers, so data survives a container crash/restart but (for ephemeral volume types) is lost when the Pod is deleted.

Compare emptyDir and hostPath volume types.

emptyDir creates an initially empty directory tied to the Pod's lifetime; it is deleted when the Pod is removed, and is used for scratch space or sharing files between containers in a Pod. hostPath mounts a file or directory from the host node's filesystem into the Pod, which couples the Pod to a specific node and carries security risks.

Explain the relationship between PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass.

A PersistentVolume (PV) is a piece of cluster storage provisioned by an admin or dynamically. A PersistentVolumeClaim (PVC) is a user's request for storage with a given size and access mode; it binds to a matching PV. A StorageClass defines a provisioner and parameters enabling dynamic provisioning, so a PVC can automatically create a new PV on demand.

What are the PersistentVolume access modes?

ReadWriteOnce (RWO): mounted read-write by a single node. ReadOnlyMany (ROX): mounted read-only by many nodes. ReadWriteMany (RWX): mounted read-write by many nodes. ReadWriteOncePod (RWOP): mounted read-write by a single Pod (added in newer versions).

What are the PersistentVolume reclaim policies?

Retain (keep the PV and its data after the PVC is deleted, for manual reclamation), Delete (delete the PV and the underlying storage asset automatically), and the deprecated Recycle (perform a basic scrub and make the PV available again).

What is a Namespace in Kubernetes?

A Namespace is a virtual cluster that provides a scope for names, partitioning a single physical cluster into multiple logical isolated environments. Resource names must be unique within a namespace but can repeat across namespaces. Namespaces enable multi-tenancy, access control via RBAC, and resource quotas.

Name the default namespaces created by Kubernetes.

default (for objects with no other namespace), kube-system (for Kubernetes system components), kube-public (readable by all, often for cluster info), and kube-node-lease (holds node heartbeat Lease objects for node health detection).

Which Kubernetes resources are namespaced versus cluster-scoped? Give examples.

Namespaced resources exist within a namespace: Pods, Deployments, Services, ConfigMaps, Secrets, PVCs. Cluster-scoped resources are global: Nodes, PersistentVolumes, Namespaces themselves, StorageClasses, ClusterRoles, and ClusterRoleBindings.

What is Helm and what problem does it solve?

Helm is the de facto package manager for Kubernetes. It packages related manifests into a reusable, versioned, parameterized unit called a chart, enabling templated, repeatable installs, upgrades, and rollbacks of applications instead of hand-managing many YAML files.

Define the core Helm terms: chart, release, repository, and values.

A chart is a Helm package containing templates and default configuration. A release is a specific instance of a chart deployed into a cluster (with a tracked revision history). A repository is a collection of distributable charts. values (values.yaml or --set overrides) supply the parameters that fill in chart templates.

What is the major architectural difference between Helm 2 and Helm 3?

Helm 2 used a server-side component called Tiller that ran in the cluster with broad permissions (a security concern). Helm 3 removed Tiller entirely, making Helm a client-only tool that uses the user's own kubeconfig and RBAC permissions and stores release state as Secrets in the cluster.

What is a Kubernetes Operator?

An Operator is a method of packaging, deploying, and managing a Kubernetes application by encoding human operational knowledge into software. It combines Custom Resource Definitions (CRDs) with a custom controller that continuously reconciles the custom resource, automating tasks like backups, upgrades, and failover for complex stateful apps.

What is a Custom Resource Definition (CRD)?

A CRD lets you extend the Kubernetes API by defining your own resource kind (a custom resource). Once registered, you can create and manage objects of that new kind with kubectl just like built-in resources. CRDs are the foundation of the Operator pattern.

What is the control loop / reconciliation pattern that Operators and controllers use?

A controller runs an endless loop that: (1) observes the current state of resources via the API server (watch), (2) compares it to the desired state declared in the spec, and (3) acts to reconcile any difference. This observe-diff-act loop continuously drives actual state toward desired state.

What is a StatefulSet and how does it differ from a Deployment?

A StatefulSet manages stateful applications, giving each Pod a stable, unique, ordinal network identity (e.g., web-0, web-1) and stable persistent storage via per-Pod PVCs. Unlike a Deployment, whose Pods are interchangeable and randomly named, a StatefulSet maintains ordered, predictable Pod identity and ordered deployment, scaling, and updates.

What guarantees does a StatefulSet provide for Pod ordering?

StatefulSet Pods are created sequentially in order (0, 1, 2, ...), with each Pod becoming Ready before the next is created, and are terminated in reverse order. Each Pod keeps a stable hostname and its own dedicated PersistentVolumeClaim that persists across rescheduling.

What is a DaemonSet and when would you use one?

A DaemonSet ensures that a copy of a specific Pod runs on all (or a selected subset of) nodes in the cluster. As nodes are added, Pods are automatically scheduled onto them. It is used for node-level agents such as log collectors (Fluentd), monitoring agents (node-exporter), and networking plugins (CNI, kube-proxy).

What is the difference between a Job and a CronJob?

A Job creates one or more Pods and ensures a specified number of them successfully complete a task, then terminates (used for batch/one-off work). A CronJob creates Jobs on a repeating time-based schedule, defined with standard cron syntax, for recurring tasks like backups or report generation.

What do the completions and parallelism fields control in a Job?

completions specifies how many Pods must successfully finish for the Job to be considered complete. parallelism specifies how many Pods are allowed to run at the same time. Together they define non-parallel jobs, fixed-completion-count parallel jobs, and work-queue style parallel jobs.

What is the cron schedule syntax used by a CronJob?

A CronJob uses standard cron format with five space-separated fields: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), and day-of-week (0–6, where 0 is Sunday). For example, "$0\ 2\ *\ *\ *$" runs daily at 02:00.

What is the difference between Authentication and Authorization in Kubernetes?

Authentication (authn) verifies who is making a request (establishing identity via client certificates, bearer tokens, service account tokens, or OIDC). Authorization (authz) determines whether that authenticated identity is allowed to perform the requested action on the resource. Authentication always precedes authorization.

What are the main authorization modes in Kubernetes?

RBAC (Role-Based Access Control, the most common), ABAC (Attribute-Based Access Control), Node authorization (for kubelets), and Webhook (delegates decisions to an external service). Modes are evaluated in order, and a request is allowed if any enabled module permits it.

Explain the four RBAC objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding.

A Role defines permissions (rules) within a single namespace; a ClusterRole defines permissions cluster-wide or for cluster-scoped resources. A RoleBinding grants a Role's (or ClusterRole's) permissions to subjects within a namespace; a ClusterRoleBinding grants a ClusterRole's permissions across the entire cluster.

What is a ServiceAccount in Kubernetes?

A ServiceAccount provides an identity for processes running inside Pods (as opposed to a UserAccount for humans). Pods use the ServiceAccount's token to authenticate to the API server. Each namespace has a 'default' ServiceAccount, and RBAC bindings control what a ServiceAccount may do.

What is a NetworkPolicy and what is the default behavior without one?

A NetworkPolicy is a specification of how groups of Pods are allowed to communicate (Layer 3/4 rules selected by labels). By default, with no NetworkPolicy, all Pods can communicate freely (the network is non-isolated/allow-all). Once a Pod is selected by any NetworkPolicy, all traffic not explicitly allowed is denied for the directions specified.

What does a NetworkPolicy require to actually take effect?

NetworkPolicies are enforced by the cluster's network plugin (CNI). They have no effect unless you use a CNI that supports them, such as Calico, Cilium, or Weave Net. With a non-enforcing CNI, NetworkPolicy objects are accepted but ignored.

What are ingress and egress in the context of a NetworkPolicy?

Ingress rules control incoming traffic to the selected Pods (who may connect to them). Egress rules control outgoing traffic from the selected Pods (which destinations they may connect to). A policy specifies policyTypes (Ingress, Egress, or both) and lists allowed sources/destinations and ports.

What were PodSecurityPolicies (PSPs) and what is their current status?

PodSecurityPolicies were a cluster-level admission control resource that restricted the security-sensitive aspects of a Pod's spec (e.g., privileged mode, host namespaces, volume types, running as root). PSPs were deprecated in Kubernetes v1.21 and removed in v1.25.

What replaced PodSecurityPolicy after its removal?

Pod Security Admission (PSA), a built-in admission controller that enforces the Pod Security Standards at the namespace level. It is configured via namespace labels and offers three modes: enforce, audit, and warn.

What are the three Pod Security Standards levels?

Privileged (unrestricted, allows known privilege escalations), Baseline (minimally restrictive, prevents known privilege escalations while allowing common Pod specs), and Restricted (heavily restricted, follows current Pod hardening best practices such as non-root users and dropped capabilities).

What is a securityContext in a Pod or container spec?

A securityContext defines privilege and access control settings for a Pod or container, such as runAsUser/runAsNonRoot, fsGroup, readOnlyRootFilesystem, allowPrivilegeEscalation, privileged, and Linux capabilities to add or drop. It is the per-workload mechanism for enforcing least-privilege after PSPs were removed.

How does Kubernetes use liveness, readiness, and startup probes?

A liveness probe detects when a container is unhealthy and restarts it. A readiness probe determines when a container is ready to receive traffic; failing it removes the Pod from Service endpoints without restarting it. A startup probe protects slow-starting containers by delaying liveness/readiness checks until the app has started.

What is the difference between resource requests and limits for a container?

A request is the guaranteed minimum amount of CPU/memory reserved for the container and is used by the scheduler to place the Pod. A limit is the maximum the container may use; exceeding a memory limit causes the container to be OOM-killed, while exceeding a CPU limit causes throttling.

How are CPU and memory resource quantities expressed in Kubernetes?

CPU is measured in cores; $1$ CPU equals $1000$ millicores, written as "1000m", so "500m" means half a core. Memory is measured in bytes with power-of-two suffixes such as Ki, Mi, Gi (e.g., "256Mi") or decimal suffixes K, M, G.

What is the difference between a taint and a toleration?

A taint is applied to a node to repel Pods that do not tolerate it (key=value:effect, where effect is NoSchedule, PreferNoSchedule, or NoExecute). A toleration is applied to a Pod to allow (but not require) it to be scheduled onto nodes with matching taints. Taints and tolerations work together to keep Pods off inappropriate nodes.