In this first of a five-part series, we are going to start simple. If you know this stuff, great, but some of it is unfamiliar then this piece should explain what Kubernetes is, how it operates, and the basic language you need to know to sound like an expert.
Where did Kubernetes come from?
Kubernetes is an open-source project governed by the Cloud Native Computing Foundation (CNCF), which is a subsidiary of the Linux Foundation, and was gifted to the Linux Foundation by Google in 2015. Kubernetes traces its roots directly from the Borg project, which was Google’s internal container-oriented cluster management system. Kubernetes is often referred to in shorthand as K8s simply because there are 8 letters between the “K” at the beginning of the word, and the “S” at the end.
What is Kubernetes?
Kubernetes, in its simplest form is an orchestrator of containerized applications, but such a broad statement requires explanation. A container is the smallest possible entity for delivering an application. It usually consists of a single application and only the environment it needs to run. This allows applications to become truly portable throughout the entire software development lifecycle without running into environment conflicts that are so common when applications share an entire operating system. A software developer can, subsequently, wrap the newly created code into a self-contained structure, a container, consisting only of the application and its particular dependencies. Containers ensure a consistent environment of dependencies as the new code moves from development to quality assurance testing, to integration, to production delivery that are almost always hosted on separate systems. Containers make applications independent of system-level changes enabling things like microservice architectures. In other words, containers do not care about changes to its outside environment because it already has everything it needs within itself. This self-sufficiency throughout the software development lifecycle is what makes Continuous Integration / Continuous Deployment (CI/CD) possible. The purpose of CI/CD is, of course, to accelerate our production pipeline so we get to market faster. Kubernetes solves an additional challenge made possible by containerization, namely scalability and portability. By orchestrating containers we can easily and rapidly create thousands and thousands of copies at virtually any location to address rapidly changing workloads. Let’s look at an example to which most of us can relate. Every time you talk to Alexa, Siri, or Google an orchestrator, such as Kubernetes, fires up a container for the duration of the question. Once your question or conversation terminates so does the container. The system resources the container required are subsequently released and repurposed to be available for another container to use. Containers Orchestration allows instant scalability and elasticity with predictable consistency and quality that was previously impossible. Events like Black Monday online sales would probably crash within minutes without Container Orchestration. Delivery of software and fixes would take months instead of days or weeks.
A Glossary of Kubernetes Terms:
Container: A container is a standardized structure which can store and run applications or services. If your application has been re-architected into micro-services, now each micro-service can be stored in its own container, along with everything it needs to run (settings, libraries, dependencies etc.), creating a closed operating environment so the container can run on any machine.
Docker: Docker is not, as many people believe, a competitor to Kubernetes. Rather it is the leading open-source containerization technology, controlling some 95% of the market. The two technologies are used together. Docker allows you to “create” containers and Kubernetes helps you to “manage” containers.
Pods: A pod is the unit of scheduling in Kubernetes and holds one or more containers. Containers that are part of the same pod are guaranteed to be scheduled together onto the same machine and can share state via local volumes.
Nodes: Nodes are the hardware components and are comprised of either a virtual machine hosted in the cloud, or a physical machine in a data center. Nodes can also be thought of as CPU/RAM resources to be used by a cluster and not just as a virtual machine, since a pod is not constrained to any given machine, but can move freely across all available resources as needed.
Cluster: A cluster is a series of nodes that are aware of each other and connect together to run the containerized applications being orchestrated by Kubernetes. By pooling their resources, the nodes make the cluster more powerful than the individual machines that compose it. Kubernetes moves pods around the cluster as nodes are scaled (added/removed).
Services: A Kubernetes Service is an abstraction which defines a logical set of pods running somewhere in your cluster, that all provide the same functionality. When created, each Service is assigned a unique IP address, which is tied to the lifespan of the Service and will not change while the Service is alive. Pods can be configured to talk to the Service and know that communication to the Service will be automatically load-balanced out to some pod that is a member of the Service.
Labels: A common set of labels allows tools to work together, describing objects in a common manner that all tools can universally understand. In addition to supporting tooling, the recommended labels describe applications in a way that can be queried.
IP-Per-Pod: Kubernetes makes it easy to run off-the-shelf open-source applications because it is able to give every pod and service its own IP address, allowing pods to be treated much like VMs or physical hosts, with access to the entire port space. This is by no means a complete list of the terms surrounding Kubernetes, and we will continue to add to it with each newsletter. Next month we will dive into how to identify and qualify a Kubernetes deal.