This page explains two different approaches to setting up a highly available Kubernetes cluster using kubeadm: With stacked control plane nodes. This approach requires less infrastructure. The etcd members and control plane nodes are co-located. With an external etcd cluster. This approach requires more infrastructure. The control plane nodes and etcd members are separated. Before proceeding, you should carefully consider which approach best meets the needs of your applications and environment.

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. Add-ons extend the functionality of Kubernetes. This page lists some of the available add-ons and links to their respective installation instructions. The list does not try to be exhaustive.

Production-Grade Container Orchestration

This page shows how to configure Pods so that they will be assigned particular Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about evicting Pods when Node resources are exceeded. When Kubernetes creates a Pod it assigns one of these QoS classes to the Pod: Guaranteed Burstable BestEffort Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.

To scale an application and provide a reliable service, you need to understand how the application behaves when it is deployed. You can examine application performance in a Kubernetes cluster by examining the containers, pods, services, and the characteristics of the overall cluster. Kubernetes provides detailed information about an application's resource usage at each of these levels. This information allows you to evaluate your application's performance and where bottlenecks can be removed to improve overall performance.

This page shows you how to configure a Pod to use a PersistentVolumeClaim for storage. Here is a summary of the process: You, as cluster administrator, create a PersistentVolume backed by physical storage. You do not associate the volume with any Pod. You, now taking the role of a developer / cluster user, create a PersistentVolumeClaim that is automatically bound to a suitable PersistentVolume. You create a Pod that uses the above PersistentVolumeClaim for storage.

This page shows how to define dependent environment variables for a container in a Kubernetes Pod. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

This page shows how to enable or disable an API version from your cluster's control plane. Specific API versions can be turned on or off by passing --runtime-config=api/<version> as a command line argument to the API server. The values for this argument are a comma-separated list of API versions. Later values override earlier values. The runtime-config command line argument also supports 2 special keys: api/all, representing all known APIs api/legacy, representing only legacy APIs.

Synopsis Update the user, group, or service account in a role binding or cluster role binding. kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none] Examples # Update a cluster role binding for serviceaccount1 kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1 # Update a role binding for user1, user2, and group1 kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1 # Print the result (in YAML format) of updating rolebinding subjects from a local, without hitting the server kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml Options --all Select all resources, in the namespace of the specified resource types

Synopsis The Kubernetes controller manager is a daemon that embeds the core control loops shipped with Kubernetes. In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.