Production-Grade Container Orchestration

In Kubernetes, Services are an abstract way to expose an application running on a set of Pods. Services can have a cluster-scoped virtual IP address (using a Service of type: ClusterIP). Clients can connect using that virtual IP address, and Kubernetes then load-balances traffic to that Service across the different backing Pods. How Service ClusterIPs are allocated? When Kubernetes needs to assign a virtual IP address for a Service, that assignment happens one of two ways:

In a Kubernetes cluster, a node can be shut down in a planned graceful way or unexpectedly because of reasons such as a power outage or something else external. A node shutdown could lead to workload failure if the node is not drained before the shutdown. A node shutdown can be either graceful or non-graceful. Graceful node shutdown FEATURE STATE: Kubernetes v1.21 [beta] (enabled by default: true) The kubelet attempts to detect node system shutdown and terminates pods running on the node.

This page explains the two options for configuring the topology of your highly available (HA) Kubernetes clusters. You can set up an HA cluster: With stacked control plane nodes, where etcd nodes are colocated with control plane nodes With external etcd nodes, where etcd runs on separate nodes from the control plane You should carefully consider the advantages and disadvantages of each topology before setting up an HA cluster.

Kubernetes volumes provide a way for containers in a pod to access and share data via the filesystem. There are different kinds of volume that you can use for different purposes, such as: populating a configuration file based on a ConfigMap or a Secret providing some temporary scratch space for a pod sharing a filesystem between two different containers in the same pod sharing a filesystem between two different pods (even if those Pods run on different nodes) durably storing data so that it stays available even if the Pod restarts or is replaced passing configuration information to an app running in a container, based on details of the Pod the container is in (for example: telling a sidecar container what namespace the Pod is running in) providing read-only access to data in a different container image Data sharing can be between different local processes within a container, or between different containers, or between Pods.

Resources that Kubernetes provides for configuring Pods.

Security architecture information relating to the API server and other components

Kubernetes lets you configure single-stack IPv4 networking, single-stack IPv6 networking, or dual stack networking with both network families active. This page explains how.

This page describes the maximum number of volumes that can be attached to a Node for various cloud providers. Cloud providers like Google, Amazon, and Microsoft typically have a limit on how many volumes can be attached to a Node. It is important for Kubernetes to respect those limits. Otherwise, Pods scheduled on a Node could get stuck waiting for volumes to attach. Kubernetes default limits The Kubernetes scheduler has default limits on the number of volumes that can be attached to a Node:

FEATURE STATE: Kubernetes v1.29 [stable] Controlling the behavior of the Kubernetes API server in an overload situation is a key task for cluster administrators. The kube-apiserver has some controls available (i.e. the --max-requests-inflight and --max-mutating-requests-inflight command-line flags) to limit the amount of outstanding work that will be accepted, preventing a flood of inbound requests from overloading and potentially crashing the API server, but these flags are not enough to ensure that the most important requests get through in a period of high traffic.