Kubernetes is designed with self-healing capabilities that help maintain the health and availability of workloads. It automatically replaces failed containers, reschedules workloads when nodes become unavailable, and ensures that the desired state of the system is maintained. Self-Healing capabilities Container-level restarts: If a container inside a Pod fails, Kubernetes restarts it based on the restartPolicy. Replica replacement: If a Pod in a Deployment or StatefulSet fails, Kubernetes creates a replacement Pod to maintain the specified number of replicas.

System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts. Kubernetes components emit metrics in Prometheus format. This format is structured plain text, designed so that people and machines can both read it. Metrics in Kubernetes In most cases metrics are available on /metrics endpoint of the HTTP server. For components that don't expose endpoint by default, it can be enabled using --bind-address flag.

The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. The additional APIs can either be ready-made solutions such as a metrics server, or APIs that you develop yourself. The aggregation layer is different from Custom Resource Definitions, which are a way to make the kube-apiserver recognise new kinds of object. Aggregation layer The aggregation layer runs in-process with the kube-apiserver.

Lower-level detail relevant to creating or administering a Kubernetes cluster.

In this example, you will run a Job in Indexed completion mode configured such that the pods created by the Job can communicate with each other using pod hostnames rather than pod IP addresses. Pods within a Job might need to communicate among themselves. The user workload running in each pod could query the Kubernetes API server to learn the IPs of the other Pods, but it's much simpler to rely on Kubernetes' built-in DNS resolution.

Static Pods are managed directly by the kubelet daemon on a specific node, without the API server observing them. Unlike Pods that are managed by the control plane (for example, a Deployment); instead, the kubelet watches each static Pod (and restarts it if it fails). Static Pods are always bound to one Kubelet on a specific node. The kubelet automatically tries to create a mirror Pod on the Kubernetes API server for each static Pod.

A ServiceAccount provides an identity for processes that run in a Pod. A process inside a Pod can use the identity of its associated service account to authenticate to the cluster's API server. For an introduction to service accounts, read configure service accounts. This task guide explains some of the concepts behind ServiceAccounts. The guide also explains how to obtain or revoke tokens that represent ServiceAccounts, and how to (optionally) bind a ServiceAccount's validity to the lifetime of an API object.

Production-Grade Container Orchestration

Note: This section links to third party projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for these projects, which are listed alphabetically. To add a project to this list, read the content guide before submitting a change. More information. Many features rely on specific kernel functionalities and have minimum kernel version requirements. However, relying solely on kernel version numbers may not be sufficient for certain operating system distributions, as maintainers for distributions such as RHEL, Ubuntu and SUSE often backport selected features to older kernel releases (retaining the older kernel version).

Package v1 is the v1 version of the API. Resource Types WebhookAdmission WebhookAdmission WebhookAdmission provides configuration for the webhook admission controller. FieldDescription apiVersionstringapiserver.config.k8s.io/v1 kindstringWebhookAdmission kubeConfigFile [Required] string KubeConfigFile is the path to the kubeconfig file.