Kubernetes (K8s): Container Orchestration Project

Kubernetes is described on its home page as production-grade container orchestration: an open source system for automating deployment, scaling and management of containerised applications. It groups containers that make up an application into logical units for easy management and discovery. The project builds upon 15 years of experience of running production workloads at Google, combined with ideas and practices from the community. Kubernetes is a CNCF graduated project.

• Also known as K8s
• Open source container orchestration system
• Builds on 15 years of Google production workload experience
• CNCF graduated project

The Kubernetes home page lists the capabilities the system provides for running containerised workloads. These cover release management, networking, storage, configuration and scaling. The project also states that it is designed for extensibility.

• Automated rollouts and rollbacks
• Service discovery and load balancing
• Storage orchestration
• Secret and configuration management
• Automatic bin packing
• Batch execution
• Self-healing
• Horizontal scaling
• Vertical scaling
• IPv4/IPv6 dual-stack
• Designed for extensibility

Because Kubernetes is open source, it can be used on on-premises, hybrid or public cloud infrastructure, allowing workloads to be moved between them. The project states that it is designed on the same principles that allow Google to run billions of containers a week, and that it can scale without increasing the size of an operations team. It is presented as suitable both for local testing and for global enterprise use. Downloads are available from the download section of the website.

• On-premises, hybrid or public cloud infrastructure
• Suited to local testing through to enterprise scale
• Downloads linked from the site's download section

The Kubernetes website publishes a reference for the objects exposed by the Kubernetes API, each documented with its apiVersion, fields and supported operations. These include workload, storage, security and API extension resources. Examples documented on the site include CronJob for scheduled jobs, ControllerRevision for immutable state snapshots used by DaemonSet and StatefulSet controllers, and CSIDriver for Container Storage Interface volume drivers. Deprecations are noted in the reference; ComponentStatus, for instance, is marked as deprecated in v1.19 and later.

• CronJob (batch/v1) — cron-format scheduled jobs
• ControllerRevision (apps/v1) — immutable state snapshots
• CSIDriver (storage.k8s.io/v1) — CSI volume driver information
• ClusterRole (rbac.authorization.k8s.io/v1) — cluster-level grouping of PolicyRules
• CertificateSigningRequest (certificates.k8s.io/v1) — x509 certificate requests
• APIService (apiregistration.k8s.io/v1) — registration of an API GroupVersion server
• ComponentStatus (v1) — cluster validation info, deprecated in v1.19+

kubectl is the command-line tool used to interact with a Kubernetes cluster, and the site provides a quick reference of commonly used commands and flags. It documents shell autocompletion for Bash, Zsh and Fish, the -A shorthand for --all-namespaces, and commands for viewing and changing kubeconfig settings, contexts and credentials. Further sections cover applying configuration, creating objects, viewing and finding resources, updating and patching resources, and output formats and verbosity levels. The page instructions are for Kubernetes v1.37.

• Autocompletion setup for BASH, ZSH and FISH
• kubectl -A as shorthand for --all-namespaces
• kubectl config commands for clusters, contexts and users
• Output format and verbosity reference tables

Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users managed by a cluster-independent service such as an administrator distributing private keys, a user store, or a file of usernames and passwords. Normal user accounts are not represented by API objects and cannot be added through an API call, but any user presenting a valid certificate signed by the cluster's certificate authority is considered authenticated, with the username taken from the certificate subject's common name. Service accounts are bound to namespaces, created by the API server or through API calls, and tied to credentials stored as Secrets and mounted into pods. Authentication plugins associate a username, UID, groups and extra fields with each request; requests that are not authenticated are treated as anonymous.

• Client certificates, bearer tokens or an authenticating proxy
• Request attributes: username, UID, groups, extra fields
• Authenticated requests join the system:authenticated group
• RBAC determines authorisation after authentication

Feature gates are key=value pairs describing Kubernetes features that an administrator can turn on or off using the --feature-gates command-line flag on each component. Each component supports only the gates relevant to its functions, and available gates can be listed with the component's -h flag. The reference tables record the default value, stage, and the releases in which a gate was introduced or last available, separated into gates for Alpha or Beta features and gates for graduated or deprecated features. The current documented set covers Kubernetes v1.37.

• Set with --feature-gates on kube-apiserver, kubelet and other components
• Alpha features are disabled by default and may change incompatibly
• Beta features are usually enabled by default, though Beta API groups are not
• Graduated and deprecated gates listed in a separate table