Production-Grade Container Orchestration

Package v1beta1 is the v1beta1 version of the external metrics API. Resource Types ExternalMetricValue ExternalMetricValueList ExternalMetricValue Appears in: ExternalMetricValueList ExternalMetricValue is a metric value for external metric A single metric value is identified by metric name and a set of string labels. For one metric there can be multiple values with different sets of labels. FieldDescription apiVersionstringexternal.metrics.k8s.io/v1beta1 kindstringExternalMetricValue metricName [Required] string the name of the metric metricLabels [Required] map[string]string a set of labels that identify a single time series for the metric

API Priority and Fairness controls the behavior of the Kubernetes API server in an overload situation. You can find more information about it in the API Priority and Fairness documentation. Diagnostics Every HTTP response from an API server with the priority and fairness feature enabled has two extra headers: X-Kubernetes-PF-FlowSchema-UID and X-Kubernetes-PF-PriorityLevel-UID, noting the flow schema that matched the request and the priority level to which it was assigned, respectively.

Resource Types CredentialProviderConfig CredentialProviderConfig CredentialProviderConfig is the configuration containing information about each exec credential provider. Kubelet reads this configuration from disk and enables each provider as specified by the CredentialProvider type. FieldDescription apiVersionstringkubelet.config.k8s.io/v1 kindstringCredentialProviderConfig providers [Required] []CredentialProvider providers is a list of credential provider plugins that will be enabled by the kubelet. Multiple providers may match against a single image, in which case credentials from all providers will be returned to the kubelet.

Overview Package v1beta4 defines the v1beta4 version of the kubeadm configuration file format. This version improves on the v1beta3 format by fixing some minor issues and adding a few new fields. A list of changes since v1beta3: v1.33: Add an EtcdUpgrade field to UpgradeConfiguration.plan that can be used to control whether the etcd upgrade plan should be displayed. v1.31: Support custom environment variables in control plane components under ClusterConfiguration. Use apiServer.

Legacy API for managing workloads that can scale horizontally. Superseded by the Deployment and ReplicaSet APIs.

Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up cluster resources. This allows the clean up of resources like the following: Terminated pods Completed Jobs Objects without owner references Unused containers and container images Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete Stale or expired CertificateSigningRequests (CSRs) Nodes deleted in the following scenarios: On a cloud when the cluster uses a cloud controller manager On-premises when the cluster uses an addon similar to a cloud controller manager Node Lease objects Owners and dependents Many objects in Kubernetes link to each other through owner references.

On Linux, control groups constrain resources that are allocated to processes. The kubelet and the underlying container runtime need to interface with cgroups to enforce resource management for pods and containers which includes cpu/memory requests and limits for containerized workloads. There are two versions of cgroups in Linux: cgroup v1 and cgroup v2. cgroup v2 is the new generation of the cgroup API. What is cgroup v2? FEATURE STATE: Kubernetes v1.

The CRI is a plugin interface which enables the kubelet to use a wide variety of container runtimes, without having a need to recompile the cluster components. You need a working container runtime on each Node in your cluster, so that the kubelet can launch Pods and their containers. The Container Runtime Interface (CRI) is the main protocol for the communication between the kubelet and Container Runtime. The Kubernetes Container Runtime Interface (CRI) defines the main gRPC protocol for the communication between the node components kubelet and container runtime.

By default, kubeadm runs a local etcd instance on each control plane node. It is also possible to treat the etcd cluster as external and provision etcd instances on separate hosts. The differences between the two approaches are covered in the Options for Highly Available topology page. This task walks through the process of creating a high availability external etcd cluster of three members that can be used by kubeadm during cluster creation.