Kubernetes
Kubernetes (commonly referred to as "k8s") is an open source container cluster manager originally designed by Google and donated to the Cloud Native Computing Foundation. It aims to provide a "platform for automating deployment, scaling, and operations of application containers across clusters of hosts".[1]
History
editKubernetes (from κυβερνήτης: Greek for "helmsman" or "pilot") was founded by Joe Beda, Brendan Burns and Craig McLuckie[2] and first announced by Google in 2014.[3] Its development and design are heavily influenced by Google's Borg system,[4][5] and many of the top contributors to the project previously worked on Borg. Kubernetes v1.0 was released on July 21, 2015.[6] Along with the Kubernetes v1.0 release, Google partnered with the Linux Foundation to form the Cloud Native Computing Foundation (CNCF)[7] and offered Kubernetes as a seed technology.
Design
editKubernetes defines a set of building blocks ("primitives") which collectively provide mechanisms for deploying, maintaining, and scaling applications. The components which make up Kubernetes are designed to be loosely coupled and extensible so that it can meet a wide variety of different workloads. The extensibility is provided in large part by the Kubernetes API, which is used by internal components as well as extensions and containers running on Kubernetes.[8]
Pods
editThe basic scheduling unit in Kubernetes is a "pod". A pod consists of one or more containers that are guaranteed to be colocated on the host machine and can share resources.[8] Each pod in Kubernetes is assigned a unique (within the cluster) IP address, which allows applications to use ports without the risk of conflict.[9] A pod can define a volume, such as a local disk directory or a network disk, and expose it to the containers in the pod.[10] Pods can be manually managed through the Kubernetes API, or their management can be delegated to a controller.[8]
Labels and Selectors
editKubernetes allows clients (users or internal components) to attach key-value pairs called “labels” to any API object in the system, such as pods and nodes. Correspondingly, “label selectors” are queries against labels that resolve to matching objects.[8] Labels and selectors are the primary grouping mechanism in Kubernetes, and are used to determine which components to apply an operation to.[11] For example, if the Pods of an application have labels for “tier” (front-end, back-end, etc.) and “release_track” ( canary, production, etc.), then an operation on all of the back-end canary nodes could use a selector tier=back-end AND release_track=canary.[12]
Controllers
editA controller is a reconciliation loop that drives actual cluster state toward the desired cluster state.[13] It does this by managing a set of pods. One kind of controller is a Replication Controller, which handles replication and scaling by running a specified number of copies of a pod across the cluster. It also handles creating replacement pods when the node a pod is running on fails.[13] Other controllers that are part of the core Kubernetes system include a “DaemonSet controller” for running exactly one pod on every machine (or some subset of machines), and a “Job controller” for running pods that run to completion, e.g. as part of a batch job.[14] The set of pods that a controller manages is determined by label selectors that are part of the controller’s definition.[12]
Services
editA Kubernetes service is a set of pods that work together, such as one tier of a multi-tier application. The set of pods that constitute a service are defined by a label selector.[8] Kubernetes provides service discovery and request routing by assigning a stable IP address and DNS name to the service, and round-robin load balances network connections to that IP address among the pods matching the selector (even as failures cause the pods move from machine to machine).[9] By default a service is exposed inside a cluster (e.g. back end pods might be grouped into a service, with requests from the front-end pods load-balanced among them), but a service can also be exposed outside a cluster (e.g. for clients to reach frontend pods)[15]
Automatic Binpacking
editKubernetes facilitates automatic placement of containers based on resource requirement and constraints.It packs critical and best-effort workloads to make efficient use of resources.
Self-healing
editFailed containers are restarted and only those containers that respond to the health check defined by user are promulgated to clients. Containers are replaced and rescheduled within same pod when corresponding node dies.
Horizontal Scaling
editKubernetes provides simple command or easy interface for auto-scaling of number of pods and also supports automatic scaling based on the threshold of the specified CPU utilization or some other metrics.
Service Discovery and Load Balancing
editApplications are independent of service discovery techniques. Kubernetes uses labels for service discovery of pods generated using the same template? and manages load balancing among replicas.
Automated Rollouts and Rollbacks
editKubernetes roll out of changes to application in batches ensuring it doesn’t kill all instances, by monitoring application health. Changes are rolled back if something goes wrong.
Storage Orchestration
editKubernetes manages storage and allows mounting of storage systems, of our choice, from any source like local, network or cloud.