Glossary | Kubernetes

This glossary is intended to be a comprehensive, standardized list of Kubernetes terminology. It includes technical terms that are specific to Kubernetes, as well as more general terms that provide useful context.
Filter terms according to their tags
Click on the [+] indicators below to get a longer explanation for any particular term.
Resources that extend the functionality of Kubernetes.
Installing addons explains more about using add-ons with your cluster, and lists some popular add-ons.
A piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object.
Admission controllers are configurable for the Kubernetes API server and may be "validating", "mutating", or both. Any admission controller may reject the request. Mutating controllers may modify the objects they admit; validating controllers may not.
In Kubernetes, affinity is a set of rules that give hints to the scheduler about where to place pods.
There are two kinds of affinity:
The rules are defined using the Kubernetes labels, and selectors specified in pods, and they can be either required or preferred, depending on how strictly you want the scheduler to enforce them.
The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
When you've configured the Kubernetes API Server to support additional APIs, you can add APIService objects to "claim" a URL path in the Kubernetes API.
A key-value pair that is used to attach arbitrary non-identifying metadata to objects.
The metadata in an annotation can be small or large, structured or unstructured, and can include characters not permitted by labels. Clients such as tools and libraries can retrieve this metadata.
A set of related paths in Kubernetes API.
You can enable or disable each API group by changing the configuration of your API server. You can also disable or enable paths to specific resources. An API group makes it easier to extend the Kubernetes API. The API group is specified in a REST path and in the apiVersion field of a serialized object.
An entity in the Kubernetes type system, corresponding to an endpoint on the Kubernetes API. A resource typically represents an object. Some resources represent an operation on other objects, such as a permission check.
Each resource represents an HTTP endpoint (URI) on the Kubernetes API server, defining the schema for the objects or operations on that resource.
The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane.
The main implementation of a Kubernetes API server is kube-apiserver. kube-apiserver is designed to scale horizontally—that is, it scales by deploying more instances. You can run several instances of kube-apiserver and balance traffic between those instances.
API-initiated eviction is the process by which you use the Eviction API to create an Eviction object that triggers graceful pod termination.
You can request eviction either by directly calling the Eviction API using a client of the kube-apiserver, like the kubectl drain command. When an Eviction object is created, the API server terminates the Pod.
API-initiated evictions respect your configured PodDisruptionBudgets and terminationGracePeriodSeconds.
API-initiated eviction is not the same as node-pressure eviction.
Application containers (or app containers) are the containers in a pod that are started after any init containers have completed.
An init container lets you separate initialization details that are important for the overall workload, and that don't need to keep running once the application container has started. If a pod doesn't have any init containers configured, all the containers in that pod are app containers.
A person responsible for the high-level design of an application.
An architect ensures that an app's implementation allows it to interact with its surrounding components in a scalable, maintainable way. Surrounding components include databases, logging infrastructure, and other microservices.
A person who writes an application that runs in a Kubernetes cluster.
An application developer focuses on one part of an application. The scale of their focus may vary significantly in size.
The layer where various containerized applications run.
A person who can review and approve Kubernetes code contributions.
While code review is focused on code quality and correctness, approval is focused on the holistic acceptance of a contribution. Holistic acceptance includes backwards/forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, and others. Approver status is scoped to a part of the codebase. Approvers were previously referred to as maintainers.
cAdvisor (Container Advisor) provides container users an understanding of the resource usage and performance characteristics of their running containers.
It is a running daemon that collects, aggregates, processes, and exports information about running containers. Specifically, for each container it keeps resource isolation parameters, historical resource usage, histograms of complete historical resource usage and network statistics. This data is exported by container and machine-wide.
A cryptographically secure file used to validate access to the Kubernetes cluster.
Certificates enable applications within a Kubernetes cluster to access the Kubernetes API securely. Certificates validate that clients are allowed to access the API.
A group of Linux processes with optional resource isolation, accounting and limits.
cgroup is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network) for a collection of processes.
CIDR (Classless Inter-Domain Routing) is a notation for describing blocks of IP addresses and is used heavily in various networking configurations.