Quick Glance at Kubernetes Architectural Building Blocks

This blog represents information on some of the key architectural building blocks of Kubernetes. The greater details on Kubernetes architecture can be found on this page, Kubernetes Architecture.

Following diagram represents technology architecture (with infrastructure) viewpoint of Kubernetes:

Following is another viewpoint of the Kubernetes technology architecture:

Pay attention to some of the following as per above diagrams:

• Kubernetes Master
  • Controller Manager (kube-controller-manager): It is a daemon process that embeds the core control loops, a non-terminating loop, for  regulating the state of the system. A control loop can also be seen as a controller.  Details can be found on this page, kube-controller-manager. Controller manager supports different types of controllers such as some of the following:
    • Replication controller
    • Endpoints controller
    • Namespace controller
    • Service accounts controller

    It is responsible for some of the following:

    • Create one or more copies of pods using Pod templates
    • Autoscale pods up or down as appropriate
    • Can be used for rolling deployments
  • Scheduler (kube-scheduler): Impacts the availability, performance and capacity of the system. It is responsible for some of the following activities:
    • Assigns a node to newly created pods
  • API Manager (kube-apiserver): Acts as a front-end for Kubernetes control panel.
• Kubernetes Nodes
  • Kubelet (kubelet): A daemon process runs on each node. Acts as an agent for managing the node and communicating with Kubernetes master. Makes sure that containers are running and healthy. Kubelet is only responsible for containers whose information is provided as what is termed as PodSpec. The information for containers can be provided to kubelet through API server. Other mechanisms using which kubelet gets pods information are some of the following:
    • File path
    • Http endpoint
    • Http server
  • Kube Proxy (kube-proxy): Exposes the deployed container workloads to the end users/clients.Each node runs a kube-proxy process which programs iptables rules to trap access to service IPs and redirect them to the correct backends.  In the diagram below, multiple pods are grouped together and exposed to the client via kube-proxy. Kubernetes provides service abstraction as a way to group pods under a common access policy (e.g., load-balanced).  The diagram below represents the concepts on how kube-proxy  is used to expose MyApp application to the clients/end users.

    Figure 3. Kube proxy exposing container workloads to clients

  • cAdvisor: Container advisor provides information on resource usage and performance characteristics of the running containers. It can be called as resource monitoring agent. It collects, aggregates, processes, and exports information about running containers. Further details can be found on this page, cAdvisor.
  • Pods: A collection of containers (forming an application and) sharing storage volumes. Following diagram represents the pod:

    Figure 4. Kubernetes Pods (credit: zwischenzugs.wordpress.com)

    A pod shares the volume and has an IP address.