CKA Study Guide – Core Concepts

Understand the Kubernetes API Primitives

The Kubernetes API is the only method for interacting with the Kubernetes system – whether the interaction is occurring on the CLI by a User or by Kubernetes itself. Everything goes through the API.

The various API objects within a Kubernetes cluster have the following responsibilities:

  • Represent the state of the system’s state.
  • Enables the configuration of the state of the system – declarative or imperative.
  • Declaratively describes the implementation of what we want the system to look.
  • Imperatively means we used the command line to make the system look like what we wanted.

There are 5 primary types of API objects within the Kubernetes system.

  • API Server is a RESTful API over HTTP using JSON.
    • All interactions with the system, either by the User or Kubernetes itself occur through the API server.
  • Pods – Containers that are deployed as a single unit
  • Controllers – Things that keep our system in the desired state.
  • Services – Persistent access point to the containers deployed within a Pod.
  • Storage – Objects for persistent storage leveraged by the Pods for the container-based application.

The application kubectl is not technically part of the Kubernetes cluster itself, but it is the primary means for the User to interact with the Kubernetes cluster. kubectl interacts with the API Server and our primary administration tool.


  • Construct that represents one or more containers.
  • It is the container based application and the most basic unit of work inside Kubernetes.
  • Unit of scheduling – up to Kubernetes to schedule the Pod.
  • Ephemeral – no Pod is ever re-deployed – no state is ever shared between iterations of the Pod.
  • Atomicity – they are either there or they are not.
  • A Pod definition is all about keeping the desired state.
    • Kubernetes tracks the state of every Pod.
    • Kubernetes tracks the application health of every Pod.
    • Liveness probes are leveraged to track state and health of the Pods.


The sole part of Kubernetes that is responsible for tracking the state of the Pods deployed within the system.

  • Creates and manages the Pods for us.
  • Job of the controller to take the Pods definition for desired state and act appropriately.
  • Responds to the Pod state and health.
  • ReplicaSet (API Object) – Defines the number of replicas of the pods we want running at any time.
  • Deployment (API Object) – Manages the rollout of the ReplicaSet. Manages the transition between two ReplicaSets.
    • Think of moving from v1 to v2 of a container application where v1 had 2 copies of the Pod, while v2 has 4. The Deployment API Object manages the transition of the Pod state to match the new desired state.

Understand the Kubernetes Cluster Architecture

The Kubernetes architecture includes components that run solely on the Nodes and components that run solely on the Controller/Master represented logically in the diagram below.

Cluster Components

  • Master – Major control functions.
    • Primary access point for cluster administration.
    • Coordinates cluster operations and monitoring and scheduling.
  • Node – Application pods run here.
    • Ensures Pods are up and running.
    • Ensures networking and services are running.
    • Multiple nodes based on scalability requires of the cluster.
  • Scheduled/Add-Ons – Pods that provide services to the cluster.
    • DNS is an example of this.

Master – Control Plane Components

The Master is the communications hub for the Kubernetes cluster.

  • API Server – Stateless
    • Central and core to all operations of the Kubernetes cluster.
    • RESTful API with get put delete post operations.
    • Updates the Cluster Store (etcd ) by validating the operations first.
  • Cluster Store – Tracks the persistence of the state of the Kubernetes objects.
    • Persists state of the Kubernetes objects.
    • Uses key-value store, in the form of etcd.
    • Responsibility to implement watches on the key-value stores to drive change within the environment.
  • Scheduler – Tells Kubernetes which nodes to start Pods on based on the resource requirements and other attributes.
    • Watches the API server for unscheduled Pods and then schedules them.
    • Responsible the availability of resources when it is making Pod placement decisions on Nodes within the Kubernetes cluster.
    • Respects constraints that we’ve defined (affinity or anti-affinity rules).
  • Controller Manager – Responsible for implementing the lifecycle activities of the controllers. It has the responsibility of keeping the Pods and everything else in the desired state across the Kubernetes cluster.
    • Executes the controller loops.
    • Lifecycle functions regarding desired state.
    • Watches and updates the API server to ensure we are heading towards the desired state.
    • ReplicaSet is an example of a controller running inside a Kubernetes cluster.

Note: The Master is tainted by Kubernetes so that it will not run user Pods within itself. It is configured such that it will only ever run system pods, like the API Server, cluster store, controller manager, and scheduler. You can modify the Master so that it will run user Pods, but that is only recommended for test labs and not production systems.

Example of all the Pods running inside the kube-system namespace, including the API Server, Controller Manager, Scheduler, Kube-Proxy, and Cluster Store.


  • Kubelet – Responsible for starting up Pods.
    • Communicates with the API Server running on the Master monitoring for changes to the environment.
    • Asks API Server if there is any new Pods for it to deploy by communicating with the API Server.
    • Responsible for the Pod lifecycle.
    • Reports both Node & Pod state.
    • Executes Pod liveness probes to get the real-time monitoring for the Node and Pod state.

Example of the kubelet service running on an Ubuntu 18.04LTS Kubernetes Node:

  • Kube-Proxy – Responsible for Pod networking and implementing Services abstraction
    • Communicates with the API Server running on the Master monitoring for changes of the networking topology to the environment.
    • Responsible for all networking components for Nodes.
    • A network proxy is implemented through iptables running inside the Linux OS on the nodes.
    • Implements Services
    • Routes all traffic to Pods. Ensures the communication requests get routed to the correct Pod running on the correct Node.
    • Load Balancing. Ensures the communications are distributed across all Nodes running the Pod.

Example of the kube-proxy pod running inside a Kubernetes cluster with the Cilium CNI.

  • Container Runtime – Pulls container images and provides an execution environment for the containers. (Docker)
    • Downloads images and runs the containers.
    • Container Runtime Interface – can swap out whatever runtime we like. Default is Docker.
    • Other Container Runtimes can be used instead of Docker, they must be CRI compliant.

Example of the docker service service running on an Ubuntu 18.04LTS Kubernetes Node:

All three of these pieces run on all nodes in the Kubernetes cluster, even the Master(s). There are special purpose Pods that run on the Master, so they need to exist there as well.

Scheduled/Add-on Pods

These require for the cluster to be online before they can provide their services. They provide special services to the cluster itself.

  • DNS – Primary example. Swapped out for CoreDNS in v1.13.
    • Provides DNS services inside the cluster.
    • IPs and search-suffix for the cluster are inserted into every Pod deployed on the Kubernetes cluster.
    • Commonly used for service discovery.
  • Ingress Controllers – Essentially HTTP content and load balancers.
  • Dashboard – Kubernetes UI for web-based administration of the Kubernetes dashboard.

Understand Services and other Network Primitives


Things inside Kubernetes are constantly changing within the systems and Pods. Kubernetes needs a method for managing consistency across all the iterations of the system — this is the role of Services.

  • Adds persistency to the ephemeral world of Kubernetes.
  • Persistency is based on the state of the system.
  • Network abstraction for Pod access.
  • Allocates an IP and DNS name for the service defined.
  • Acts as the frontend of the Pod, and is dynamically updated when a Pod is modified based on their lifecycle.
  • Can also be scaled by adding/removing Pods.
  • Load balancing for distributing load across the application service.
Scroll Up