The open source Kubernetes project has generated a lot of hype and a lot of real world deployments in recent years.
At its’ core, Kubernetes has long been defined as a container orchestration system. That is, it is a platform that provides mechanisms that enables users to deploy, schedule and manage application container deployments. Kubernetes, according to Brian Grant principal engineer at Google and Lead Architect of Kubernetes, is somewhat more than just a container orchestrator, providing a platform on which cloud-native applications can be deployed.
Regardless of how Kubernetes is defined, it’s a platform that is made up of many different components and API abstractions. Getting a handle on all of it can be overwhelming as Kubernetes introduces multiple concepts and ideas that might not be familiar to users of traditional server virtualization technologies.
Attempting to explain the complexity that is Kubernetes is not an easy task, but it’s one that Microsoft engineers Matt Butcher and Karen Chu did during a keynote at the KubeCon + CloudNativeCon NA 18 event. The pair co-authored a children’s picture book that describes a visit to the zoo, in which the animals are various Kubernetes components. While the concept is whimsical the core elements are not and help to provide an understanding of Kubernetes fundamentals. In this ServerWatch guide, we outline six core elements of the Kubernetes platform.
The entire concept of containers is wrapped in the idea that applications, or micro-services run inside isolated compute elements (the container). With Kubernetes, that abstraction is taken one step further with Kubernetes pods. Pods are the basic unit for running containers in Kubernetes.
A Pod can contain one or more containers and it provides a way to define environment variables.
Simply running containers in a Pod only exposes the initial level of power that Kubernetes provides. As an orchestration platform, Kubernetes can run multiple sets of container in a cluster, enabling high-availability.
A ReplicaSet is a Kubernetes component that defines and ensures that a set of of identically configured Pods are running with a user-defined number of replicas. If for some reason one Pod fails and drops off, the ReplicaSet will automatically bring up a new, identical Pod.
A DaemonSet is a another way of making sure that copies of Pods are running on different nodes within a cluster.
According to the Kubernetes documentation on the feature, “a DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them.”
Among the reasons why Kubernetes has become popular is the fact it is extensible. One of the ways that extensibility is enabled is via Custom Resources Definitions or CRDs.
With a CRD a Kubernetes administrator can define resource types that are not part of the platform by default. Once a new CRD has been defined, the core Kubernetes API functionality for managing the resources comes into play.
The concept of ‘secrets’ is not unique to Kubernetes, though it is a core element of the platform. A secret can be defined as a password, access token or security certificate that enables some form of secure access to a given resource.
Rather than hard coding or embedded secrets into Pods, Secrets management within Kubernetes enables Secrets to only be attached to a given pod at runtime.
Orchestration by definition is about deploying application and that is what Kubernetes Deployments enable. A Kubernetes Deployment controller is a higher level abstraction for enabling declarative updates for deploying ReplicaSets and their associated Pods.
Deployments enable updates of running pods as well rollbacks and scaling.
Sean Michael Kerner is a senior editor at ServerWatch and InternetNews.com. Follow him on Twitter @TechJournalist.