LOOKING AT KUBERNETES FROM THE TOP OF A MOUNTAIN
Kubernetes is a software system that allows you to easily deploy and manage containerized applications. It leverages the functionality of Linux containers to run heterogeneous applications without having to know the internal details of those applications and without having to manually deploy those applications to each host.
Because these apps run in containers, they don't affect other apps running on the same server, which is critical when you're running apps for completely different organizations on the same hardware.
This is critically important to cloud providers as they strive to optimize the use of their hardware while having to maintain complete isolation of hosted applications.
Kubernetes allows you to run your software applications on thousands of computer nodes as if all those nodes were one huge computer.
It abstracts the underlying infrastructure and, in doing so, simplifies development, deployment, and management for development and operations teams.
Deploying applications through Kubernetes is always the same whether your cluster contains just a few nodes or thousands of them.
The cluster size makes no difference. The additional cluster nodes simply represent an additional amount of resources available to deployed applications.
The system is composed of a master node and any number of worker nodes. When the developer submits a list of applications to the master, Kubernetes deploys them to the cluster of worker nodes. The node on which a component lands does not (and should not) matter, neither to the developer nor to the system administrator.
The developer can specify that certain applications should run together and Kubernetes will deploy them to the same worker node.
Others will be distributed across the cluster, but they can talk to each other the same regardless of where they are deployed.
UNDERSTANDING THE ARCHITECTURE OF A KUBERNETES CLUSTER
At the hardware level, a Kubernetes cluster is made up of many Nodes, which can be divided into two types:
The master Node: which hosts the Kubernetes control plane which controls and manages the entire Kubernetes system
Worker Nodes: which run the actual applications you deploy
THE CONTROL PLANE
The control plane is what controls the cluster and makes it work. It consists of multiple components that can run on a single master node or be distributed across multiple nodes and replicated to ensure high availability.
The Kubernetes API Server, which you and the other Control Plane components communicate with.
The Scheduler, which schedules your apps (assigns a worker node to each deployable component of your application)
The Controller Manager, which performs cluster-level functions, such as replicating components, keeping track of worker nodes, handling node failures, and so on
etcd, a reliable distributed data store that persistently stores the cluster configuration.
Control plane components maintain and control cluster state, but they do not run your applications. This is done by Worker Nodes.
THE NODES
- Worker Nodes are the machines that run your containerized applications. The task of running, monitoring and providing services to your applications is performed by the following components:
Docker, rkt, or another container runtime, which runs your containers
The Kubelet, which talks to the API server and manages containers on its node
The Kubernetes Service Proxy (kube-proxy), which load-balances network traffic between application components
RUN AN APPLICATION IN KUBERNETES
To run an application in Kubernetes, you must first bundle it into one or more container images, push those images to an image registry, and then publish a description of your application to the Kubernetes API server.
The description includes information such as the container image or images that contain your application's components, how these components relate to each other, and which should be run collocated (together on the same node) and those who are not.
For each component, you can also specify the number of copies (or replicas) you want to run. Additionally, the description also indicates which of these components provide service to internal or external clients and should be exposed through a unique IP address and made discoverable by the other components.
