Kubernetes Architecture - Chapter 4 (Part 2)

• Discuss the Kubernetes architecture.
• Explain the different components for master and worker nodes.
  (part1)
  --------------------------
  (part2)
• Discuss about cluster state management with etcd.
• Review the Kubernetes network setup requirements.
• Discuss what Pods are capable of

Cluster state management with etcd

There are two options of configuring highly available Kubernetes clusters, using kubeadm as bootstrapping tool, where the data store (etcd) runs alongside and shares resources with the other control plane components on the same master node.

This sequence diagram, show the components involved during a simple Pod creation process. It's a great illustration of the API Server and etcd interaction.

Etcd stores keys defining the configuration and status of all resources within the cluster, consisting of

• Nodes
• Namespaces
• ServiceAccounts
• Roles, ClusterRoles and RoleBindings, ClusterRoleBindings
• ConfigMaps
• Secrets
• Workloads (Deployments, DaemonSets, Pods, ...)
• Cluster’s certificates
• The resources within each apiVersion
• The events that bring the cluster in the current state

Networking

The training isn't really explaining what Pods are up until this point, while I have seen it everywhere diving into documentation.

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

This is where you want to have your app deployed. If you want to deploy several apps, which rely heavily on networking in order to mimic the tight-coupling once available in the monolithic era.

Kubernetes addresses a few distinct networking challenges:

Container-to-Container Communication Inside Pods

The host operating system's kernel virtualization features allows a container runtime to create an isolated network space for each container it starts. A network namespace can be shared across containers, or wit the host operating system.

When a Pod is started, a special Pause container is initialized by the Container Runtime for the sole purpose to create a network namespace for the Pod. All additional containers, created through user requests, running inside the Pod will share the Pause container's network namespace so that they can all talk to each other via localhost.

Pod-to-Pod Communication Across Nodes

A fundamental requirement of any networking implementation in Kubernetes is that regardless of their host node, Pods are expected to be able communicate with all other Pods in the cluster, all this without implementation of Network Address Translation (NAT). Kubernetes aims to reduce complexity and treats Pods as VMs on a network, where each VM is equipped with a network interface. Each Pod receives a unique IP address and ensures Pod-to-Pod communication. The container runtime offloads the IP assignment to CNI, which connects to the underlying configured plugin, to get the IP address.

Pod-to-External World Communication

Kubernetes enables external accessibility through Services, complex encapsulations of network routing rule definitions stored in iptables on cluster nodes and implemented by kube-proxy agents. By exposing services to the external world with the aid of kube-proxy, applications become accessible from outside the cluster over a virtual IP address.

To read more about Kubernetes networking visit the following link: https://kubernetes.io/docs/concepts/cluster-administration/networking

To access the Pod's container we will have to configure services which is explained here in more detail.

That's it for now, a lot of knowledge to read about, Kubernetes provides every possibility to create your cluster on your specific needs.

Thanks for reading friends.