Kubernetes Architecture
Kubernetes is a stack of services that work together to manage all the hosts, Kubernetes cluster is what we call them together AKA K8s. All those services or components are shown in the below three diagrams.
POD: A pod is a group of one or more containers (such as Docker Containers), the shared storage for those containers, and options about how to run the containers. Pods are always co-located and co-scheduled and run in a shared context. A pod models an application-specific “logical host” - it contains one or more application containers which are relatively tightly coupled — in a pre-container world, they would have executed on the same physical or virtual machine.
SERVICE: Kubernetes Pods are mortal. They are born and when they die, they are not resurrected. Replication Controllers, in particular, create and destroy Pods dynamically (e.g. when scaling up or down or when doing rolling updates). While each Pod gets its own IP address, even those IP addresses cannot be relied upon to be stable over time. This leads to a problem. Service will be on top of the POD and will have a stable IP, it’s like a load balancer, so no matter what nodes you have under load balancer and what their IP is it can be accessed by the load balancer. Its similar for the Service in Kubernetes.
Master Node Architecture
Etcd: It is an open source key-value store developed by CoreOs team. Kubernetes uses ‘Etcd’ to store the configuration data accessed by all nodes (minions and master) in the cluster.
Example of data stored by Kubernetes in etcd is jobs being scheduled, created and deployed pod/service details and state, namespaces and replication information, etc.
Kube-ApiServer: The Kubernetes API-server generally validates the configuration data store in ‘Etcd’ and the details of the deployed container that are in agreement. It also provides a RESTful interface to make communication easy.
Kube-Schedule Server: The deployment of configured pods and services onto the nodes is done by the scheduler component. It is responsible for assigning a task to minions in the cluster. The schedule has the information regarding resources available on the members of the cluster, as well as the ones required for the configured service to run and hence is able to decide where to deploy a specific service.
Kube-Controller-Manager: It is generally responsible for handling the cluster level function such as a replication controller. Whenever the desired state of the cluster changes it is written to Etcd and then the controller manager tries to bring up the cluster in the desired state. A controller uses the API server to watch the shared state of the cluster and makes corrective changes to the current state to be it to the desired one. One example is Replication Controller which takes care of the PODS in the system if any POD fails it replaces that with a new POD.
Minion Node Architecture
Docker: One of the basic requirement of nodes is Docker. Docker is responsible for pulling down and running container from Docker images.
Kube-Proxy: Every node in the cluster runs a simple network proxy. Using a proxy node in cluster routes request to the correct container in a node.
Kubelet: It is an agent process that runs on each node. It is responsible for managing pods and their containers. It deals with pods specifications which are defined in YAML or JSON format. Kubelet takes the pod specifications and checks whether the pods are running healthy or not.
Flannel: It is an overlay network that works on assigning a range of subnet address. It is used to assign IPs to each pods running in the cluster and to make the pod-to-pod and pod-to-services communications.
For more information about Visualpath, visit www.visualpath.in and follow the company on Facebook and Twitter.
Comments
Post a Comment