Synopsis The Kubernetes scheduler is a control plane process which assigns Pods to Nodes. The scheduler determines which Nodes are valid placements for each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. Multiple different schedulers may be used within a cluster; kube-scheduler is the reference implementation. See scheduling for more information about scheduling and the kube-scheduler component.

Synopsis The Kubernetes network proxy runs on each node. This reflects services as defined in the Kubernetes API on each node and can do simple TCP, UDP, and SCTP stream forwarding or round robin TCP, UDP, and SCTP forwarding across a set of backends. Service cluster IPs and ports are currently found through Docker-links-compatible environment variables specifying ports opened by the service proxy. There is an optional addon that provides cluster DNS for these cluster IPs.

Synopsis Configure application resources. These commands help you make changes to existing application resources. kubectl set SUBCOMMAND Options -h, --help help for set --as string Username to impersonate for the operation. User could be a regular user or a service account in a namespace. --as-group strings Group to impersonate for the operation, this flag can be repeated to specify multiple groups. --as-uid string UID to impersonate for the operation.

Component tools Feature Gates Feature Gates (removed) kubelet kube-apiserver kube-controller-manager kube-proxy kube-...

This page shows how to use kubectl exec to get a shell to a running container. 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:

Declarative and imperative paradigms for interacting with the Kubernetes API.

Run and manage both stateless and stateful applications.

This task shows how to create a frontend and a backend microservice. The backend microservice is a hello greeter. The frontend exposes the backend using nginx and a Kubernetes Service object. Objectives Create and run a sample hello backend microservice using a Deployment object. Use a Service object to send traffic to the backend microservice's multiple replicas. Create and run a nginx frontend microservice, also using a Deployment object. Configure the frontend microservice to send traffic to the backend microservice.

FEATURE STATE: Kubernetes v1.10 [stable] kubeadm init and kubeadm join together provide a nice user experience for creating a bare Kubernetes cluster from scratch, that aligns with the best-practices. However, it might not be obvious how kubeadm does that. This document provides additional details on what happens under the hood, with the aim of sharing knowledge on the best practices for a Kubernetes cluster. Core design principles The cluster that kubeadm init and kubeadm join set up should be:

Synopsis Output shell completion code for the specified shell (bash, zsh, fish, or powershell). The shell code must be evaluated to provide interactive completion of kubectl commands. This can be done by sourcing it from the .bash_profile. Detailed instructions on how to do this are available here: for macOS: https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#enable-shell-autocompletion for linux: https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#enable-shell-autocompletion for windows: https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/#enable-shell-autocompletion Note for zsh users: [1] zsh completions are only supported in versions of zsh >= 5.