This page covers how to customize the components that kubeadm deploys. For control plane components you can use flags in the ClusterConfiguration structure or patches per-node. For the kubelet and kube-proxy you can use KubeletConfiguration and KubeProxyConfiguration, accordingly. All of these options are possible via the kubeadm configuration API. For more details on each field in the configuration you can navigate to our API reference pages. Note:To reconfigure a cluster that has already been created see Reconfiguring a kubeadm cluster.

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.

Production-Grade Container Orchestration

As with any program, you might run into an error installing or running kubeadm. This page lists some common failure scenarios and have provided steps that can help you understand and fix the problem. If your problem is not listed below, please follow the following steps: If you think your problem is a bug with kubeadm: Go to github.com/kubernetes/kubeadm and search for existing issues. If no issue exists, please open one and follow the issue template.

An overview of the key components that make up a Kubernetes cluster.

The kubectl command-line tool supports several different ways to create and manage Kubernetes objects. This document provides an overview of the different approaches. Read the Kubectl book for details of managing objects by Kubectl. Management techniques Warning:A Kubernetes object should be managed using only one technique. Mixing and matching techniques for the same object results in undefined behavior. Management technique Operates on Recommended environment Supported writers Learning curve Imperative commands Live objects Development projects 1+ Lowest Imperative object configuration Individual files Production projects 1 Moderate Declarative object configuration Directories of files Production projects 1+ Highest Imperative commands When using imperative commands, a user operates directly on live objects in a cluster.

If two Pods in your cluster want to communicate, and both Pods are actually running on the same node, use _Service Internal Traffic Policy_ to keep network traffic within that node. Avoiding a round trip via the cluster network can help with reliability, performance (network latency and throughput), or cost.

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.

FEATURE STATE: Kubernetes v1.11 [beta] Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the cloud-controller-manager binary allows cloud vendors to evolve independently from the core Kubernetes code. The cloud-controller-manager can be linked to any cloud provider that satisfies cloudprovider.Interface. For backwards compatibility, the cloud-controller-manager provided in the core Kubernetes project uses the same cloud libraries as kube-controller-manager. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.

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.