Manage Kubernetes pods and nodes with these native features
In Kubernetes, pod management requires familiarity with the platform's native features. From Services and Jobs to taints and tolerations, learn how they help direct deployments.
Kubernetes is a container orchestrator that deploys and sustains software on a pool of resources called a cluster. The orchestration process, however, is much more than just throwing software images into a sea of servers.
Kubernetes has multiple features to align application execution with specific resources -- and to preserve specialized resources for the applications that truly need them. At the most basic level, Kubernetes pods and nodes are the mechanisms by which application components are matched to the resources on which they're supposed to run. Features and tools, such as Kubernetes Services, Jobs, and taints and tolerations, help admins manage pod and node deployment.
Kubernetes Services: Pods exposed
In Kubernetes, containers are assigned to pods, which are abstractions of the containers' required hosting resources. Pods are assigned to nodes, which provide actual hosting resources, such as physical or virtual machines.
Pods by themselves don't do much, even if they're hosted on nodes. Their IP addresses are drawn from an internal namespace, and their addresses change if they scale or redeploy. To expose pods to users consistently, Kubernetes defines Services. A Service is an abstraction of a logical set of pods, and provides instructions on how the pods' functionality is accessed within the deployment.
The ServiceSpec API within a Service definition dictates what kind of exposure is allowed: for example, within a private cluster only or externally on the public internet. An admin can also define the Service to specify an external load balancer that divides work across a set of pods. Because Services define what's seen from the outside, they enable processes such as node failure and redeployment, scaling and load balancing to work without any effect on an application's users. A Service is the window into the pod's capabilities.
Services aren't static properties of pods. They link to pods through labels and selectors, which are tags that attach to pods and Services, respectively, to indicate how they match up. By associating Services with the appropriate pods, changes in IP address and other pod properties don't affect how users see the application the pods represent.
New to Kubernetes? Use this brief video to explore key concepts of the container orchestration technology, including basic cluster functionality, cluster architecture and the difference between a pod and node.
Affinities, taints and tolerations
It doesn't do any good to expose a pod that's not really running. The assignment of Kubernetes pods to nodes also assigns, in effect, the pods' Services to the nodes, and makes the application the pods represent runnable and visible.
In a homogeneous resource pool that supports applications with the same resource requirements, this assignment process would be trivial. But, in most cases, applications will vary in the resources they require from nodes, and nodes will have different capabilities. To match things up appropriately, Kubernetes provides a basic feature that lets admins specify a label set for nodes, and then use nodeSelector feature to specify what labels a pod will require. For more complex situations, there are affinities, taints and tolerations.
Affinities are the most basic -- and easiest -- way to steer pods to specific nodes. The same labeling method used to link Services to pods lets admins assign arbitrary labels to nodes. These labels can then be tested, including with complex AND/OR tests, which specify that a node must or must not have a specific label or labels in order to be assigned a particular pod.
For even more control over Kubernetes pods and nodes, use a feature called taints and tolerations. A taint is a kind of selection antigravity -- something that repels pods from tainted nodes. Pods that have tolerations to that taint, or taints, are the only ones that can be scheduled there. Admins can name taints when there are multiple reasons to repel certain pods from a node.
Use this feature to reserve nodes with special equipment, such as a GPU, for only the applications that require them. It's also possible to evict pods if a running pod doesn't meet a new taint/toleration specification for the node.
Jobs: Batch execution with Kubernetes
Most applications are designed to run continuously to support online activity, but "batch" operations run on demand or at specific times. Kubernetes has a Jobs feature to enable explicit scheduling of execution. A Job will deploy the associated pods, and ensure they run properly. The Job will restart if there's no normal completion. Use Jobs for tasks that have to run in the background, such as monitoring.
Beyond Kubernetes pod management basics
In an edge computing model, each individual resource pool can run as a separate Kubernetes cluster, and then a federation tool can create a unified view across the environment. These federation tools, such as Google's Anthos, Red Hat OpenShift or VMware Tanzu, support multiple clusters that can be controlled independently -- using the techniques described above -- but still present a unified kind of "virtual Kubernetes."
This approach might also be useful if a large enterprise has business units that operate their IT environments independently, but share resources.
