From 6e408656af2119775f76b428f95bee11d2cbc5e7 Mon Sep 17 00:00:00 2001 From: fisherxu Date: Wed, 23 Aug 2017 10:51:44 +0800 Subject: [PATCH 01/33] fix incorrect configmap-key in /docs/tasks/configure-pod-container/vim configure-pod-configmap.md --- docs/tasks/configure-pod-container/configure-pod-configmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/configure-pod-configmap.md b/docs/tasks/configure-pod-container/configure-pod-configmap.md index b0c26d8231..6349af7a40 100644 --- a/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -100,7 +100,7 @@ This page provides a series of usage examples demonstrating how to configure Pod valueFrom: configMapKeyRef: name: env-config - key: special.type + key: log_level restartPolicy: Never ``` From 195533d41298cf57ba77187c537258233707b69f Mon Sep 17 00:00:00 2001 From: Murali Reddy Date: Fri, 25 Aug 2017 11:13:23 +0530 Subject: [PATCH 02/33] kubernetes cluster setup with kube-router using kubeadm --- docs/setup/independent/create-cluster-kubeadm.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/docs/setup/independent/create-cluster-kubeadm.md b/docs/setup/independent/create-cluster-kubeadm.md index 5e7a3d0189..6c921df6c5 100644 --- a/docs/setup/independent/create-cluster-kubeadm.md +++ b/docs/setup/independent/create-cluster-kubeadm.md @@ -249,6 +249,16 @@ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documen ``` {% endcapture %} +{% capture kube-router %} + +Kube-router relies on kube-controll-manager to allocate pod CIDR for the nodes. Therefore, use `kubeadm init` with the `--pod-network-cidr` flag. + +Kube-router provides pod networking, network policy, and high-performing IP Virtual Server(IPVS)/Linux Virtual Server(LVS) based service proxy. + +For information on setting up Kubernetes cluster with Kube-router using kubeadm please see official [setup guide](https://github.com/cloudnativelabs/kube-router/blob/master/Documentation/kubeadm.md). + +{% endcapture %} + {% capture romana %} The official Romana set-up guide is [here](https://github.com/romana/romana/tree/master/containerize#using-kubeadm). @@ -272,8 +282,8 @@ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever" ``` {% endcapture %} -{% assign tab_names = "Choose one...,Calico,Canal,Flannel,Romana,Weave Net" | split: ',' | compact %} -{% assign tab_contents = site.emptyArray | push: choose | push: calico | push: canal | push: flannel | push: romana | push: weave_net %} +{% assign tab_names = "Choose one...,Calico,Canal,Flannel,Kube-router,Romana,Weave Net" | split: ',' | compact %} +{% assign tab_contents = site.emptyArray | push: choose | push: calico | push: canal | push: flannel | push: kube-router | push: romana | push: weave_net %} {% include tabs.md %} From 3823bed2a3a1b6fe5a573cfadb79b52bfd2ee07f Mon Sep 17 00:00:00 2001 From: Rob Young Date: Fri, 25 Aug 2017 18:36:38 +0100 Subject: [PATCH 03/33] Link to individual concepts on concept overview (#5202) On the concept overview page there are lists of example concepts. Currently only two are linked to (and one of those to an old location). This change adds links to all of the concepts so that a new user quickly see some exaple concepts. --- docs/concepts/index.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/concepts/index.md b/docs/concepts/index.md index de0a601133..a4cd156b00 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -21,18 +21,18 @@ Kubernetes contains a number of abstractions that represent the state of your sy The basic Kubernetes objects include: -* [Pod](/docs/concepts/abstractions/pod/) -* Service -* Volume -* Namespace +* [Pod](/docs/concepts/workload/pods/pod-overview/) +* [Service](/docs/concepts/services-networking/service/) +* [Volume](/docs/concepts/storage/volumes/) +* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) In addition, Kubernetes contains a number of higher-level abstractions called Controllers. Controllers build upon the basic objects, and provide additional functionality and convenience features. They include: -* ReplicaSet -* Deployment -* [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) -* DaemonSet -* Job +* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) +* [Deployment](/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/docs/concepts/workloads/controllers/statefulsets/) +* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) +* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## Kubernetes Control Plane From 400cdbf068256ec8fa6d64f77ac726707946a614 Mon Sep 17 00:00:00 2001 From: Pablo Guerrero Date: Fri, 25 Aug 2017 19:37:09 +0200 Subject: [PATCH 04/33] typo: duplicate "to" (#5200) --- docs/tasks/configure-pod-container/assign-memory-resource.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/assign-memory-resource.md b/docs/tasks/configure-pod-container/assign-memory-resource.md index 73d0481fa2..d717828345 100644 --- a/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -129,7 +129,7 @@ kubectl delete pod memory-demo --namespace=mem-example A Container can exceed its memory request if the Node has memory available. But a Container is not allowed to use more than its memory limit. If a Container allocates more memory than its limit, the Container becomes a candidate for termination. If the Container continues to -to consume memory beyond its limit, the Container is terminated. If a terminated Container is +consume memory beyond its limit, the Container is terminated. If a terminated Container is restartable, the kubelet will restart it, as with any other type of runtime failure. In this exercise, you create a Pod that attempts to allocate more memory than its limit. From 4c7f17b8dab5fe2f2557aa3ac2b46a2405c67b64 Mon Sep 17 00:00:00 2001 From: Malepati Bala Siva Sai Akhil Date: Fri, 25 Aug 2017 23:19:04 +0530 Subject: [PATCH 05/33] Fix minor typo in buffer case study (#5174) --- case-studies/buffer.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/case-studies/buffer.html b/case-studies/buffer.html index 5c6e9cbcc9..3336e42f96 100755 --- a/case-studies/buffer.html +++ b/case-studies/buffer.html @@ -85,7 +85,7 @@ css: /css/style_buffer.css

Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."

- Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reduce risk." + Another thing they weren’t able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of ‘fingers crossed.’ And this is something that gets run 800,000 times a day, the core of our business. If it doesn’t work, our business doesn’t work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn’t working. This has leveled up our ability to deploy and roll out new changes quickly while reducing risk." From 7d8b9b0b45a56df92274abb8b6055dabbe33c60c Mon Sep 17 00:00:00 2001 From: Malepati Bala Siva Sai Akhil Date: Fri, 25 Aug 2017 23:25:18 +0530 Subject: [PATCH 06/33] Fix minor typo in Deploying WordPress and MySQL with PVs (#5181) Signed-off-by: Malepati Bala Siva Sai Akhil --- .../stateful-application/mysql-wordpress-persistent-volume.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 3dab51db28..07a059dbac 100644 --- a/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -7,7 +7,7 @@ assignees: {% capture overview %} This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data. -A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been provisioned by an administrator, and a [PeristentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a set amout of storage in a PV. PersistentVolumes and PeristentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. +A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been provisioned by an administrator, and a [PeristentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a set amount of storage in a PV. PersistentVolumes and PeristentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. **Warning:** This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production. {: .warning} From 650a370d89ba40fa6ceefb77e3d9f3deeaa8914b Mon Sep 17 00:00:00 2001 From: Matt McNaughton Date: Fri, 25 Aug 2017 13:57:55 -0400 Subject: [PATCH 07/33] Add section on specifying k8s version for minikube (#5172) I struggled to discover information on how to specify a kubernetes version when starting minikube. Ultimately, I found the answer through searching Github issues, and also running `minikube start --help`. Given it seems like a fairly common task, I think it could be useful to include it in the getting started documentation. --- docs/getting-started-guides/minikube.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/getting-started-guides/minikube.md b/docs/getting-started-guides/minikube.md index f9e886e7f6..3def1949f8 100644 --- a/docs/getting-started-guides/minikube.md +++ b/docs/getting-started-guides/minikube.md @@ -143,6 +143,23 @@ Unfortunately just setting the environment variables will not work. Minikube will also create a "minikube" context, and set it to default in kubectl. To switch back to this context later, run this command: `kubectl config use-context minikube`. +#### Specifying the Kubernetes version + +Minikube supports running multiple different versions of Kubernetes. You can +access a list of all available versions via + +``` +minikube get-k8s-versions +``` + +You can specify the specific version of Kubernetes for Minikube to use by +adding the `--kubernetes-version` string to the `minikube start` command. For +example, to run version `v1.7.3`, you would run the following: + +``` +minikube start --kubernetes-version v1.7.3 +``` + ### Configuring Kubernetes Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values. From ec6a0f078a1712c0e54a0197b522129b74e2506b Mon Sep 17 00:00:00 2001 From: Malepati Bala Siva Sai Akhil Date: Fri, 25 Aug 2017 23:30:06 +0530 Subject: [PATCH 08/33] Fix minor typo in Replication Controller (#5173) --- docs/concepts/workloads/controllers/replicationcontroller.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/workloads/controllers/replicationcontroller.md b/docs/concepts/workloads/controllers/replicationcontroller.md index fedd69c3c2..e4b2529c95 100644 --- a/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/docs/concepts/workloads/controllers/replicationcontroller.md @@ -141,7 +141,7 @@ will have to manage the deletion yourself (see [below](#working-with-replication You can specify how many pods should run concurrently by setting `.spec.replicas` to the number of pods you would like to have running concurrently. The number running at any time may be higher -or lower, such as if the replicas was just increased or decreased, or if a pod is gracefully +or lower, such as if the replicas were just increased or decreased, or if a pod is gracefully shutdown, and a replacement starts early. If you do not specify `.spec.replicas`, then it defaults to 1. From d13c10d0ff38c8216b757b287e4b80ccfdd4fa4a Mon Sep 17 00:00:00 2001 From: Quentin Revel Date: Fri, 25 Aug 2017 20:06:59 +0200 Subject: [PATCH 09/33] Update memory-constraint-namespace.md (#5135) --- docs/tasks/administer-cluster/memory-constraint-namespace.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/administer-cluster/memory-constraint-namespace.md b/docs/tasks/administer-cluster/memory-constraint-namespace.md index e28d66911d..88b46f555d 100644 --- a/docs/tasks/administer-cluster/memory-constraint-namespace.md +++ b/docs/tasks/administer-cluster/memory-constraint-namespace.md @@ -162,7 +162,7 @@ Error from server (Forbidden): error when creating "docs/tasks/administer-cluste pods "constraints-mem-demo-3" is forbidden: minimum memory usage per Container is 500Mi, but request is 100Mi. ``` -## Create a Pod that does not specify any CPU request or limit +## Create a Pod that does not specify any memory request or limit From 0a56b9db512effcff6e91fe29fd3d1453758965f Mon Sep 17 00:00:00 2001 From: Matt McNaughton Date: Fri, 25 Aug 2017 14:54:16 -0400 Subject: [PATCH 10/33] Add description of k8s dns to guestbook (#5201) Going through the guestbook tutorial for the first time, the deployment configuration mentioned that whether my configuration included a DNS service would dictate which env value I used for the `GET_HOSTS_FROM` variable. According to https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/, k8s includes DNS by default starting with v1.3. Add this additional info to help the user better understand when DNS may/may not be enabled. --- .../guestbook/frontend-deployment.yaml | 11 +++++++---- .../guestbook/redis-slave-deployment.yaml | 7 +++++-- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/tutorials/stateless-application/guestbook/frontend-deployment.yaml b/docs/tutorials/stateless-application/guestbook/frontend-deployment.yaml index 1888836b3c..340cb04d70 100644 --- a/docs/tutorials/stateless-application/guestbook/frontend-deployment.yaml +++ b/docs/tutorials/stateless-application/guestbook/frontend-deployment.yaml @@ -20,10 +20,13 @@ spec: env: - name: GET_HOSTS_FROM value: dns - # If your cluster config does not include a dns service, then to - # instead access environment variables to find service host - # info, comment out the 'value: dns' line above, and uncomment the - # line below: + # Using `GET_HOSTS_FROM=dns` requires your cluster to + # provide a dns service. As of Kubernetes 1.3, DNS is a built-in + # service launched automatically. However, if the cluster you are using + # does not have a built-in DNS service, you can instead + # instead access an environment variable to find the master + # service's host. To do so, comment out the 'value: dns' line above, and + # uncomment the line below: # value: env ports: - containerPort: 80 diff --git a/docs/tutorials/stateless-application/guestbook/redis-slave-deployment.yaml b/docs/tutorials/stateless-application/guestbook/redis-slave-deployment.yaml index 2bea4a5134..3ff33c998e 100644 --- a/docs/tutorials/stateless-application/guestbook/redis-slave-deployment.yaml +++ b/docs/tutorials/stateless-application/guestbook/redis-slave-deployment.yaml @@ -21,9 +21,12 @@ spec: env: - name: GET_HOSTS_FROM value: dns - # If your cluster config does not include a dns service, then to + # Using `GET_HOSTS_FROM=dns` requires your cluster to + # provide a dns service. As of Kubernetes 1.3, DNS is a built-in + # service launched automatically. However, if the cluster you are using + # does not have a built-in DNS service, you can instead # instead access an environment variable to find the master - # service's host, comment out the 'value: dns' line above, and + # service's host. To do so, comment out the 'value: dns' line above, and # uncomment the line below: # value: env ports: From bb3437058bab4362ce11d01a3b4c969c511946f7 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Sat, 26 Aug 2017 02:58:07 +0800 Subject: [PATCH 11/33] fix typo (#5197) fix typo --- .../imperative-object-management-command.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md index cbf6c44bb2..bbb85d9042 100644 --- a/docs/tutorials/object-management-kubectl/imperative-object-management-command.md +++ b/docs/tutorials/object-management-kubectl/imperative-object-management-command.md @@ -130,8 +130,8 @@ creation. This is done by piping the output of the `create` command to the kubectl create service clusterip -o yaml --dry-run | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f - ``` -1. The `create service -o yaml --dry-run` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server. -1. The `set --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML. +1. The `kubectl create service -o yaml --dry-run` command creates the configuration for the Service, but prints it to stdout as YAML instead of sending it to the Kubernetes API server. +1. The `kubectl set --local -f - -o yaml` command reads the configuration from stdin, and writes the updated configuration to stdout as YAML. 1. The `kubectl create -f -` command creates the object using the configuration provided via stdin. ## Using `--edit` to modify objects before creation @@ -144,8 +144,8 @@ kubectl create service clusterip my-svc -o yaml --dry-run > /tmp/srv.yaml kubectl create --edit -f /tmp/srv.yaml ``` -1. The `create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`. -1. The `create --edit` command opens the configuration file for editing before it creates the object. +1. The `kubectl create service` command creates the configuration for the Service and saves it to `/tmp/srv.yaml`. +1. The `kubectl create --edit` command opens the configuration file for editing before it creates the object. {% endcapture %} From 4ae4607f6c3747f6db5628ea3748f586fbe42e67 Mon Sep 17 00:00:00 2001 From: Chris Stryczynski Date: Fri, 25 Aug 2017 20:56:29 +0100 Subject: [PATCH 12/33] Added additional information about retrieving a secret (#5198) --- docs/concepts/configuration/secret.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/configuration/secret.md b/docs/concepts/configuration/secret.md index 0a673537a4..23a1dc1401 100644 --- a/docs/concepts/configuration/secret.md +++ b/docs/concepts/configuration/secret.md @@ -137,7 +137,7 @@ the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if #### Decoding a Secret -Get back the secret created in the previous section: +Secrets can be retrieved via the `kubectl get secret` command. For example, to retrieve the secret created in the previous section: ```shell $ kubectl get secret mysecret -o yaml From bc9bb3e9296a227a86b8c83c18ea4c364e963aef Mon Sep 17 00:00:00 2001 From: XsWack Date: Sat, 26 Aug 2017 03:57:11 +0800 Subject: [PATCH 13/33] Update clc.md (#5107) Fix leading spaces in kubectl commands and unified format.This is causing bash/zsh shells to not to record the executed command in the history. --- docs/getting-started-guides/clc.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/getting-started-guides/clc.md b/docs/getting-started-guides/clc.md index 1a9beb0090..a83c37d4da 100644 --- a/docs/getting-started-guides/clc.md +++ b/docs/getting-started-guides/clc.md @@ -186,19 +186,19 @@ Kubernetes Cluster. We hope to add a scripted option to do this soon. Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1 ```shell - bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1 +bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1 ``` Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1 ```shell - bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes +bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes ``` Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1: ```shell - bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4 +bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4 ``` From c17803f912e1acdaa21198796345d1a9398f3632 Mon Sep 17 00:00:00 2001 From: Stewart-YU Date: Sat, 26 Aug 2017 03:59:22 +0800 Subject: [PATCH 14/33] Update cluster-management.md (#5130) Missing equal sign. --- docs/tasks/administer-cluster/cluster-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/administer-cluster/cluster-management.md b/docs/tasks/administer-cluster/cluster-management.md index 27c111fd9b..3566ef2c6f 100644 --- a/docs/tasks/administer-cluster/cluster-management.md +++ b/docs/tasks/administer-cluster/cluster-management.md @@ -71,7 +71,7 @@ If your cluster runs short on resources you can easily add more machines to it i If you're using GCE or GKE it's done by resizing Instance Group managing your Nodes. It can be accomplished by modifying number of instances on `Compute > Compute Engine > Instance groups > your group > Edit group` [Google Cloud Console page](https://console.developers.google.com) or using gcloud CLI: ```shell -gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE +gcloud compute instance-groups managed resize kubernetes-minion-group --size=42 --zone=$ZONE ``` Instance Group will take care of putting appropriate image on new machines and start them, while Kubelet will register its Node with API server to make it available for scheduling. If you scale the instance group down, system will randomly choose Nodes to kill. From f4f58b646f2014c131161e212bc06aea20ec83c0 Mon Sep 17 00:00:00 2001 From: Quentin Revel Date: Fri, 25 Aug 2017 22:06:27 +0200 Subject: [PATCH 15/33] Update parallel-processing-expansion.md (#5060) Fix job.yaml.jinja2 job --- docs/tasks/job/parallel-processing-expansion.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/tasks/job/parallel-processing-expansion.md b/docs/tasks/job/parallel-processing-expansion.md index d6e7921062..f8fac8066e 100644 --- a/docs/tasks/job/parallel-processing-expansion.md +++ b/docs/tasks/job/parallel-processing-expansion.md @@ -133,6 +133,7 @@ metadata: jobgroup: jobexample spec: template: + metadata: name: jobexample labels: jobgroup: jobexample From 4376fa34fdcb37b28deb1b1f14b08d63f3e108bc Mon Sep 17 00:00:00 2001 From: lemon-tree Date: Sat, 26 Aug 2017 04:12:18 +0800 Subject: [PATCH 16/33] Update docker-cli-to-kubectl.md (#5040) Added the lost ",". --- docs/user-guide/docker-cli-to-kubectl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/docker-cli-to-kubectl.md b/docs/user-guide/docker-cli-to-kubectl.md index cddbd1eda0..42d124bb50 100644 --- a/docs/user-guide/docker-cli-to-kubectl.md +++ b/docs/user-guide/docker-cli-to-kubectl.md @@ -164,7 +164,7 @@ $ kubectl logs -f nginx-app-zibvs 10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-" ``` -Now's a good time to mention slight difference between pods and containers; by default pods will not terminate if their processes exit. Instead it will restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated but for Kubernetes, each invocation is separate. To see the output from a previous run in Kubernetes, do this: +Now's a good time to mention slight difference between pods and containers; by default pods will not terminate if their processes exit. Instead it will restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated, but for Kubernetes, each invocation is separate. To see the output from a previous run in Kubernetes, do this: ```shell $ kubectl logs --previous nginx-app-zibvs From a17a3b9cb12223d36cbe9f347d9a3073971a9853 Mon Sep 17 00:00:00 2001 From: Stewart-YU Date: Sat, 26 Aug 2017 04:13:20 +0800 Subject: [PATCH 17/33] Update images.md (#5034) Fix the format. The format in orginal web page is confusion. --- docs/concepts/containers/images.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/concepts/containers/images.md b/docs/concepts/containers/images.md index 54df534170..6947df31e8 100644 --- a/docs/concepts/containers/images.md +++ b/docs/concepts/containers/images.md @@ -113,6 +113,7 @@ You first need to create a registry and generate credentials, complete documenta the [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli). Once you have created your container registry, you will use the following credentials to login: + * `DOCKER_USER` : service principal, or admin username * `DOCKER_PASSWORD`: service principal password, or admin user password * `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io` From 02e5ef9a51689f4ed1ea822e98bb386cdddf0471 Mon Sep 17 00:00:00 2001 From: Justin Santa Barbara Date: Sat, 26 Aug 2017 11:38:22 -0400 Subject: [PATCH 18/33] Fix invalid internal links in federation doc Remove double-# links --- docs/concepts/cluster-administration/federation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/concepts/cluster-administration/federation.md b/docs/concepts/cluster-administration/federation.md index 97569451d6..cf1d2aba4d 100644 --- a/docs/concepts/cluster-administration/federation.md +++ b/docs/concepts/cluster-administration/federation.md @@ -38,7 +38,7 @@ why you might want multiple clusters are: * Scalability: There are scalability limits to a single kubernetes cluster (this should not be the case for most users. For more details: [Kubernetes Scaling and Performance Goals](https://git.k8s.io/community/sig-scalability/goals.md)). -* [Hybrid cloud](###hybrid-cloud-capabilities): You can have multiple clusters on different cloud providers or +* [Hybrid cloud](#hybrid-cloud-capabilities): You can have multiple clusters on different cloud providers or on-premises data centers. ### Caveats @@ -70,7 +70,7 @@ register each cluster's API endpoint and credentials with your Federation API Server (See the [federation admin guide](/docs/admin/federation/) for details). -Thereafter, your [API resources](##api-resources) can span different clusters +Thereafter, your [API resources](#api-resources) can span different clusters and cloud providers. ## Setting up federation From 586081ad48e52395ad418a10be95ae6ebfd04c5c Mon Sep 17 00:00:00 2001 From: fgogolli Date: Sun, 27 Aug 2017 11:05:17 +0100 Subject: [PATCH 19/33] Update deployment.md --- docs/concepts/workloads/controllers/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index c0230bb167..da1169df6d 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/docs/concepts/workloads/controllers/deployment.md @@ -262,7 +262,7 @@ removed label still exists in any existing Pods and ReplicaSets. Sometimes you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping. By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want -(you can change that by modifying revision history limit]). +(you can change that by modifying revision history limit). **Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed, From 1d11905cb5020f0675c7886db2bd51997f2ee83e Mon Sep 17 00:00:00 2001 From: fgogolli Date: Sun, 27 Aug 2017 11:26:51 +0100 Subject: [PATCH 20/33] Update deployment.md --- docs/concepts/workloads/controllers/deployment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index da1169df6d..acc21c984e 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/docs/concepts/workloads/controllers/deployment.md @@ -264,7 +264,7 @@ Sometimes you may want to rollback a Deployment; for example, when the Deploymen By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want (you can change that by modifying revision history limit). -**Note:** a Deployment's revision is created when a Deployment's rollout is triggered. This means that the +**Note:** A Deployment's revision is created when a Deployment's rollout is triggered. This means that the new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed, for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment, do not create a Deployment revision, so that we can facilitate simultaneous manual- or auto-scaling. From 82ca38f8dff79f43cfba25a78b070a15e3003e23 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 18 Aug 2017 11:55:08 +0800 Subject: [PATCH 21/33] Improve taint and toleration documentation --- _data/concepts.yml | 1 + docs/api-reference/v1.6/index.html | 2 +- docs/api-reference/v1.7/index.html | 4 +- docs/concepts/architecture/nodes.md | 2 +- .../cluster-administration/sysctl-cluster.md | 3 +- .../concepts/configuration/assign-pod-node.md | 230 +--------------- .../configuration/taint-and-toleration.md | 257 ++++++++++++++++++ .../extensions/v1beta1/definitions.html | 2 +- docs/resources-reference/v1.6/index.html | 2 +- docs/resources-reference/v1.7/index.html | 4 +- .../administer-cluster/securing-a-cluster.md | 1 + 11 files changed, 271 insertions(+), 237 deletions(-) create mode 100644 docs/concepts/configuration/taint-and-toleration.md diff --git a/_data/concepts.yml b/_data/concepts.yml index f1ba8a6661..6f80ff5e1d 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -58,6 +58,7 @@ toc: - docs/concepts/configuration/overview.md - docs/concepts/configuration/manage-compute-resources-container.md - docs/concepts/configuration/assign-pod-node.md + - docs/concepts/configuration/taint-and-toleration.md - docs/concepts/configuration/secret.md - docs/concepts/configuration/organize-cluster-access-kubeconfig.md diff --git a/docs/api-reference/v1.6/index.html b/docs/api-reference/v1.6/index.html index 7e64251ea9..b5f130f619 100644 --- a/docs/api-reference/v1.6/index.html +++ b/docs/api-reference/v1.6/index.html @@ -7868,7 +7868,7 @@ Appears In Pod Pod tolerations
Toleration array -If specified, the pod's tolerations. +If specified, the pod's tolerations. More info: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration volumes
Volume array diff --git a/docs/api-reference/v1.7/index.html b/docs/api-reference/v1.7/index.html index 4f7606ea40..893ed4ea10 100644 --- a/docs/api-reference/v1.7/index.html +++ b/docs/api-reference/v1.7/index.html @@ -7964,7 +7964,7 @@ Appears In: tolerations
Toleration array -If specified, the pod's tolerations. +If specified, the pod's tolerations. More info: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/ volumes
Volume array
patch type: merge
patch merge key: name @@ -72550,4 +72550,4 @@ Appears In: - \ No newline at end of file + diff --git a/docs/concepts/architecture/nodes.md b/docs/concepts/architecture/nodes.md index 7720e46c04..1d361db045 100644 --- a/docs/concepts/architecture/nodes.md +++ b/docs/concepts/architecture/nodes.md @@ -171,7 +171,7 @@ Starting in Kubernetes 1.6, the NodeController is also responsible for evicting pods that are running on nodes with `NoExecute` taints, when the pods do not tolerate the taints. Additionally, as an alpha feature that is disabled by default, the NodeController is responsible for adding taints corresponding to node problems like -node unreachable or not ready. See [this documentation](/docs/concepts/configuration/assign-pod-node/#taints-and-tolerations-beta-feature) +node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration) for details about `NoExecute` taints and the alpha feature. ### Self-Registration of Nodes diff --git a/docs/concepts/cluster-administration/sysctl-cluster.md b/docs/concepts/cluster-administration/sysctl-cluster.md index 434bc68157..3079345d9b 100644 --- a/docs/concepts/cluster-administration/sysctl-cluster.md +++ b/docs/concepts/cluster-administration/sysctl-cluster.md @@ -118,4 +118,5 @@ spec: **Note**: a pod with the _unsafe_ sysctls specified above will fail to launch on any node which has not enabled those two _unsafe_ sysctls explicitly. As with _node-level_ sysctls it is recommended to use [_taints and toleration_ -feature](/docs/user-guide/kubectl/v1.6/#taint) or [labels on nodes](/docs/concepts/configuration/assign-pod-node/) to schedule those pods onto the right nodes. +feature](/docs/user-guide/kubectl/v1.6/#taint) or [taints on nodes](/docs/concepts/configuration/taint-and-toleration/) +to schedule those pods onto the right nodes. diff --git a/docs/concepts/configuration/assign-pod-node.md b/docs/concepts/configuration/assign-pod-node.md index 12331bacfe..b555869ddf 100644 --- a/docs/concepts/configuration/assign-pod-node.md +++ b/docs/concepts/configuration/assign-pod-node.md @@ -298,231 +298,5 @@ Highly Available database statefulset has one master and three replicas, one may For more information on inter-pod affinity/anti-affinity, see the design doc [here](https://git.k8s.io/community/contributors/design-proposals/podaffinity.md). -## Taints and tolerations (beta feature) - -Node affinity, described earlier, is a property of *pods* that *attracts* them to a set -of nodes (either as a preference or a hard requirement). Taints are the opposite -- -they allow a *node* to *repel* a set of pods. - -Taints and tolerations work together to ensure that pods are not scheduled -onto inappropriate nodes. One or more taints are applied to a node; this -marks that the node should not accept any pods that do not tolerate the taints. -Tolerations are applied to pods, and allow (but do not require) the pods to schedule -onto nodes with matching taints. - -You add a taint to a node using [kubectl taint](/docs/user-guide/kubectl/v1.7/#taint). -For example, - -```shell -kubectl taint nodes node1 key=value:NoSchedule -``` - -places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`. -This means that no pod will be able to schedule onto `node1` unless it has a matching toleration. -You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the -taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able -to schedule onto `node1`: - -```yaml -tolerations: -- key: "key" - operator: "Equal" - value: "value" - effect: "NoSchedule" -``` - -```yaml -tolerations: -- key: "key" - operator: "Exists" - effect: "NoSchedule" -``` - -A toleration "matches" a taint if the keys are the same and the effects are the same, and: - -* the `operator` is `Exists` (in which case no `value` should be specified), or -* the `operator` is `Equal` and the `value`s are equal - -`Operator` defaults to `Equal` if not specified. - -**NOTE:** There are two special cases: - -* An empty `key` with operator `Exists` matches all keys, values and effects which means this -will tolerate everything. - -```yaml -tolerations: -- operator: "Exists" -``` - -* An empty `effect` matches all effects with key `key`. - -```yaml -tolerations: -- key: "key" - operator: "Exists" -``` - -The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`. -This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a -pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is -`NoExecute`, described later. - -You can put multiple taints on the same node and multiple tolerations on the same pod. -The way Kubernetes processes multiple taints and tolerations is like a filter: start -with all of a node's taints, then ignore the ones for which the pod has a matching toleration; the -remaining un-ignored taints have the indicated effects on the pod. In particular, - -* if there is at least one un-ignored taint with effect `NoSchedule` then Kubernetes will not schedule -the pod onto that node -* if there is no un-ignored taint with effect `NoSchedule` but there is at least one un-ignored taint with -effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod onto the node -* if there is at least one un-ignored taint with effect `NoExecute` then the pod will be evicted from -the node (if it is already running on the node), and will not be -scheduled onto the node (if it is not yet running on the node). - -For example, imagine you taint a node like this - -```shell -kubectl taint nodes node1 key1=value1:NoSchedule -kubectl taint nodes node1 key1=value1:NoExecute -kubectl taint nodes node1 key2=value2:NoSchedule -``` - -And a pod has two tolerations: - -```yaml -tolerations: -- key: "key1" - operator: "Equal" - value: "value1" - effect: "NoSchedule" -- key: "key1" - operator: "Equal" - value: "value1" - effect: "NoExecute" -``` - -In this case, the pod will not be able to schedule onto the node, because there is no -toleration matching the third taint. But it will be able to continue running if it is -already running on the node when the taint is added, because the third taint is the only -one of the three that is not tolerated by the pod. - -Normally, if a taint with effect `NoExecute` is added to a node, then any pods that do -not tolerate the taint will be evicted immediately, and any pods that do tolerate the -taint will never be evicted. However, a toleration with `NoExecute` effect can specify -an optional `tolerationSeconds` field that dictates how long the pod will stay bound -to the node after the taint is added. For example, - -```yaml -tolerations: -- key: "key1" - operator: "Equal" - value: "value1" - effect: "NoExecute" - tolerationSeconds: 3600 -``` - -means that if this pod is running and a matching taint is added to the node, then -the pod will stay bound to the node for 3600 seconds, and then be evicted. If the -taint is removed before that time, the pod will not be evicted. - -### Example use cases - -Taints and tolerations are a flexible way to steer pods away from nodes or evict -pods that shouldn't be running. A few of the use cases are - -* **dedicated nodes**: If you want to dedicate a set of nodes for exclusive use by -a particular set of users, you can add a taint to those nodes (say, -`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding -toleration to their pods (this would be done most easily by writing a custom -[admission controller](/docs/admin/admission-controllers/)). -The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as -well as any other nodes in the cluster. If you want to dedicate the nodes to them *and* -ensure they *only* use the dedicated nodes, then you should additionally add a label similar -to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admission -controller should additionally add a node affinity to require that the pods can only schedule -onto nodes labeled with `dedicated=groupName`. - -* **nodes with special hardware**: In a cluster where a small subset of nodes have specialized -hardware (for example GPUs), it is desirable to keep pods that don't need the specialized -hardware off of those nodes, thus leaving room for later-arriving pods that do need the -specialized hardware. This can be done by tainting the nodes that have the specialized -hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or -`kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding -toleration to pods that use the special hardware. As in the dedicated nodes use case, -it is probably easiest to apply the tolerations using a custom -[admission controller](/docs/admin/admission-controllers/)). -For example, the admission controller could use -some characteristic(s) of the pod to determine that the pod should be allowed to use -the special nodes and hence the admission controller should add the toleration. -To ensure that the pods that need -the special hardware *only* schedule onto the nodes that have the special hardware, you will need some -additional mechanism, e.g. you could represent the special resource using -[opaque integer resources](/docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature) -and request it as a resource in the PodSpec, or you could label the nodes that have -the special hardware and use node affinity on the pods that need the hardware. - -* **per-pod-configurable eviction behavior when there are node problems (alpha feature)**, -which is described in the next section. - -### Per-pod-configurable eviction behavior when there are node problems (alpha feature) - -Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already -running on the node as follows - - * pods that do not tolerate the taint are evicted immediately - * pods that tolerate the taint without specifying `tolerationSeconds` in - their toleration specification remain bound forever - * pods that tolerate the taint with a specified `tolerationSeconds` remain - bound for the specified amount of time - -The above behavior is a beta feature. In addition, Kubernetes 1.6 has alpha -support for representing node problems (currently only "node unreachable" and -"node not ready", corresponding to the NodeCondition "Ready" being "Unknown" or -"False" respectively) as taints. When the `TaintBasedEvictions` alpha feature -is enabled (you can do this by including `TaintBasedEvictions=true` in `--feature-gates`, such as -`--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically -added by the NodeController and the normal logic for evicting pods from nodes -based on the Ready NodeCondition is disabled. -(Note: To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/) -behavior of pod evictions due to node problems, the system actually adds the taints -in a rate-limited way. This prevents massive pod evictions in scenarios such -as the master becoming partitioned from the nodes.) -This alpha feature, in combination with `tolerationSeconds`, allows a pod -to specify how long it should stay bound to a node that has one or both of these problems. - -For example, an application with a lot of local state might want to stay -bound to node for a long time in the event of network partition, in the hope -that the partition will recover and thus the pod eviction can be avoided. -The toleration the pod would use in that case would look like - -```yaml -tolerations: -- key: "node.alpha.kubernetes.io/unreachable" - operator: "Exists" - effect: "NoExecute" - tolerationSeconds: 6000 -``` - -(For the node not ready case, change the key to `node.alpha.kubernetes.io/notReady`.) - -Note that Kubernetes automatically adds a toleration for -`node.alpha.kubernetes.io/notReady` with `tolerationSeconds=300` -unless the pod configuration provided -by the user already has a toleration for `node.alpha.kubernetes.io/notReady`. -Likewise it adds a toleration for -`node.alpha.kubernetes.io/unreachable` with `tolerationSeconds=300` -unless the pod configuration provided -by the user already has a toleration for `node.alpha.kubernetes.io/unreachable`. - -These automatically-added tolerations ensure that -the default pod behavior of remaining bound for 5 minutes after one of these -problems is detected is maintained. -The two default tolerations are added by the [DefaultTolerationSeconds -admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds). - -[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with -`NoExecute` tolerations for `node.alpha.kubernetes.io/unreachable` and `node.alpha.kubernetes.io/notReady` -with no `tolerationSeconds`. This ensures that DaemonSet pods are never evicted due -to these problems, which matches the behavior when this feature is disabled. +You may want to check [Taints](/docs/concepts/configuration/taint-and-toleration/) +as well, which allow a *node* to *repel* a set of pods. diff --git a/docs/concepts/configuration/taint-and-toleration.md b/docs/concepts/configuration/taint-and-toleration.md new file mode 100644 index 0000000000..f16f69b88f --- /dev/null +++ b/docs/concepts/configuration/taint-and-toleration.md @@ -0,0 +1,257 @@ +--- +approvers: +- davidopp +- kevin-wangzefeng +- bsalamat +title: Taints and Tolerations +--- + +Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), +is a property of *pods* that *attracts* them to a set of nodes (either as a +preference or a hard requirement). Taints are the opposite -- they allow a +*node* to *repel* a set of pods. + +Taints and tolerations work together to ensure that pods are not scheduled +onto inappropriate nodes. One or more taints are applied to a node; this +marks that the node should not accept any pods that do not tolerate the taints. +Tolerations are applied to pods, and allow (but do not require) the pods to schedule +onto nodes with matching taints. + +## Concepts + +You add a taint to a node using [kubectl taint](/docs/user-guide/kubectl/v1.7/#taint). +For example, + +```shell +kubectl taint nodes node1 key=value:NoSchedule +``` + +places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`. +This means that no pod will be able to schedule onto `node1` unless it has a matching toleration. +You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the +taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able +to schedule onto `node1`: + +```yaml +tolerations: +- key: "key" + operator: "Equal" + value: "value" + effect: "NoSchedule" +``` + +```yaml +tolerations: +- key: "key" + operator: "Exists" + effect: "NoSchedule" +``` + +A toleration "matches" a taint if the keys are the same and the effects are the same, and: + +* the `operator` is `Exists` (in which case no `value` should be specified), or +* the `operator` is `Equal` and the `value`s are equal + +`Operator` defaults to `Equal` if not specified. + +**NOTE:** There are two special cases: + +* An empty `key` with operator `Exists` matches all keys, values and effects which means this +will tolerate everything. + +```yaml +tolerations: +- operator: "Exists" +``` + +* An empty `effect` matches all effects with key `key`. + +```yaml +tolerations: +- key: "key" + operator: "Exists" +``` + +The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`. +This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a +pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is +`NoExecute`, described later. + +You can put multiple taints on the same node and multiple tolerations on the same pod. +The way Kubernetes processes multiple taints and tolerations is like a filter: start +with all of a node's taints, then ignore the ones for which the pod has a matching toleration; the +remaining un-ignored taints have the indicated effects on the pod. In particular, + +* if there is at least one un-ignored taint with effect `NoSchedule` then Kubernetes will not schedule +the pod onto that node +* if there is no un-ignored taint with effect `NoSchedule` but there is at least one un-ignored taint with +effect `PreferNoSchedule` then Kubernetes will *try* to not schedule the pod onto the node +* if there is at least one un-ignored taint with effect `NoExecute` then the pod will be evicted from +the node (if it is already running on the node), and will not be +scheduled onto the node (if it is not yet running on the node). + +For example, imagine you taint a node like this + +```shell +kubectl taint nodes node1 key1=value1:NoSchedule +kubectl taint nodes node1 key1=value1:NoExecute +kubectl taint nodes node1 key2=value2:NoSchedule +``` + +And a pod has two tolerations: + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoSchedule" +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" +``` + +In this case, the pod will not be able to schedule onto the node, because there is no +toleration matching the third taint. But it will be able to continue running if it is +already running on the node when the taint is added, because the third taint is the only +one of the three that is not tolerated by the pod. + +Normally, if a taint with effect `NoExecute` is added to a node, then any pods that do +not tolerate the taint will be evicted immediately, and any pods that do tolerate the +taint will never be evicted. However, a toleration with `NoExecute` effect can specify +an optional `tolerationSeconds` field that dictates how long the pod will stay bound +to the node after the taint is added. For example, + +```yaml +tolerations: +- key: "key1" + operator: "Equal" + value: "value1" + effect: "NoExecute" + tolerationSeconds: 3600 +``` + +means that if this pod is running and a matching taint is added to the node, then +the pod will stay bound to the node for 3600 seconds, and then be evicted. If the +taint is removed before that time, the pod will not be evicted. + +## Example Use Cases + +Taints and tolerations are a flexible way to steer pods *away* from nodes or evict +pods that shouldn't be running. A few of the use cases are + +* **Dedicated Nodes**: If you want to dedicate a set of nodes for exclusive use by +a particular set of users, you can add a taint to those nodes (say, +`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) and then add a corresponding +toleration to their pods (this would be done most easily by writing a custom +[admission controller](/docs/admin/admission-controllers/)). +The pods with the tolerations will then be allowed to use the tainted (dedicated) nodes as +well as any other nodes in the cluster. If you want to dedicate the nodes to them *and* +ensure they *only* use the dedicated nodes, then you should additionally add a label similar +to the taint to the same set of nodes (e.g. `dedicated=groupName`), and the admission +controller should additionally add a node affinity to require that the pods can only schedule +onto nodes labeled with `dedicated=groupName`. + +* **Nodes with Special Hardware**: In a cluster where a small subset of nodes have specialized +hardware (for example GPUs), it is desirable to keep pods that don't need the specialized +hardware off of those nodes, thus leaving room for later-arriving pods that do need the +specialized hardware. This can be done by tainting the nodes that have the specialized +hardware (e.g. `kubectl taint nodes nodename special=true:NoSchedule` or +`kubectl taint nodes nodename special=true:PreferNoSchedule`) and adding a corresponding +toleration to pods that use the special hardware. As in the dedicated nodes use case, +it is probably easiest to apply the tolerations using a custom +[admission controller](/docs/admin/admission-controllers/)). +For example, the admission controller could use +some characteristic(s) of the pod to determine that the pod should be allowed to use +the special nodes and hence the admission controller should add the toleration. +To ensure that the pods that need +the special hardware *only* schedule onto the nodes that have the special hardware, you will need some +additional mechanism, e.g. you could represent the special resource using +[opaque integer resources](/docs/concepts/configuration/manage-compute-resources-container/#opaque-integer-resources-alpha-feature) +and request it as a resource in the PodSpec, or you could label the nodes that have +the special hardware and use node affinity on the pods that need the hardware. + +* **Taint based Evictions (alpha feature)**: A per-pod-configurable eviction behavior +when there are node problems, which is described in the next section. + +## Taint based Evictions + +Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already +running on the node as follows + + * pods that do not tolerate the taint are evicted immediately + * pods that tolerate the taint without specifying `tolerationSeconds` in + their toleration specification remain bound forever + * pods that tolerate the taint with a specified `tolerationSeconds` remain + bound for the specified amount of time + +The above behavior is a beta feature. In addition, Kubernetes 1.6 has alpha +support for representing node problems. In other words, the node controller +automatically taints a node when certain condition is true. The builtin taints +currently include: + + * `node.alpha.kubernetes.io/notReady`: Node is not ready. This corresponds to + the NodeCondition `Ready` being "`False`". + * `node.alpha.kubernetes.io/unreachable`: Node is unreachable from the node + controller. This corresponds to the NodeCondition `Ready` being "`Unknown`". + * `node.kubernetes.io/outOfDisk`: Node becomes out of disk. + * `node.kubernetes.io/memoryPressure`: Node has memory pressure. + * `node.kubernetes.io/diskPressure`: Node has disk pressure. + * `node.kubernetes.io/networkUnavailable`: Node's network is unavailable. + * `node.cloudprovider.kubernetes.io/uninitialized`: When kubelet is started + with "external" cloud provider, it sets this taint on a node to mark it + as unusable. When a controller from the cloud-controller-manager initializes + this node, kubelet removes this taint. + +When the `TaintBasedEvictions` alpha feature is enabled (you can do this by +including `TaintBasedEvictions=true` in `--feature-gates`, such as +`--feature-gates=FooBar=true,TaintBasedEvictions=true`), the taints are automatically +added by the NodeController (or kubelet) and the normal logic for evicting pods from nodes +based on the Ready NodeCondition is disabled. +(Note: To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/) +behavior of pod evictions due to node problems, the system actually adds the taints +in a rate-limited way. This prevents massive pod evictions in scenarios such +as the master becoming partitioned from the nodes.) +This alpha feature, in combination with `tolerationSeconds`, allows a pod +to specify how long it should stay bound to a node that has one or both of these problems. + +For example, an application with a lot of local state might want to stay +bound to node for a long time in the event of network partition, in the hope +that the partition will recover and thus the pod eviction can be avoided. +The toleration the pod would use in that case would look like + +```yaml +tolerations: +- key: "node.alpha.kubernetes.io/unreachable" + operator: "Exists" + effect: "NoExecute" + tolerationSeconds: 6000 +``` + +Note that Kubernetes automatically adds a toleration for +`node.alpha.kubernetes.io/notReady` with `tolerationSeconds=300` +unless the pod configuration provided +by the user already has a toleration for `node.alpha.kubernetes.io/notReady`. +Likewise it adds a toleration for +`node.alpha.kubernetes.io/unreachable` with `tolerationSeconds=300` +unless the pod configuration provided +by the user already has a toleration for `node.alpha.kubernetes.io/unreachable`. + +These automatically-added tolerations ensure that +the default pod behavior of remaining bound for 5 minutes after one of these +problems is detected is maintained. +The two default tolerations are added by the [DefaultTolerationSeconds +admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds). + +[DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with +`NoExecute` tolerations for the following taints with no `tolerationSeconds`: + + * `node.alpha.kubernetes.io/unreachable` + * `node.alpha.kubernetes.io/notReady` + * `node.kubernetes.io/memoryPressure` + * `node.kubernetes.io/diskPressure` + * `node.kubernetes.io/outOfDisk` (*only for critical pods*) + +This ensures that DaemonSet pods are never evicted due to these problems, +which matches the behavior when this feature is disabled. diff --git a/docs/reference/federation/extensions/v1beta1/definitions.html b/docs/reference/federation/extensions/v1beta1/definitions.html index 309ff7cab8..1d63515168 100755 --- a/docs/reference/federation/extensions/v1beta1/definitions.html +++ b/docs/reference/federation/extensions/v1beta1/definitions.html @@ -4152,7 +4152,7 @@ When an object is created, the system will populate this list with the current s

tolerations

-

If specified, the pod’s tolerations.

+

If specified, the pod’s tolerations. More info: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/

false

v1.Toleration array

diff --git a/docs/resources-reference/v1.6/index.html b/docs/resources-reference/v1.6/index.html index 0c9dc8932d..0e4f272683 100644 --- a/docs/resources-reference/v1.6/index.html +++ b/docs/resources-reference/v1.6/index.html @@ -1167,7 +1167,7 @@ Appears In Pod Pod tolerations
Toleration array -If specified, the pod's tolerations. +If specified, the pod's tolerations. More info: http://kubernetes.io/docs/concepts/configuration/taint-and-toleration/ volumes
Volume array diff --git a/docs/resources-reference/v1.7/index.html b/docs/resources-reference/v1.7/index.html index 12aaa81e70..89073c6965 100644 --- a/docs/resources-reference/v1.7/index.html +++ b/docs/resources-reference/v1.7/index.html @@ -1261,7 +1261,7 @@ Appears In: tolerations
Toleration array -If specified, the pod's tolerations. +If specified, the pod's tolerations. More info: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/ volumes
Volume array
patch type: merge
patch merge key: name @@ -16577,4 +16577,4 @@ Appears In: - \ No newline at end of file + diff --git a/docs/tasks/administer-cluster/securing-a-cluster.md b/docs/tasks/administer-cluster/securing-a-cluster.md index a0f84ad4d3..2885a27da9 100644 --- a/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/docs/tasks/administer-cluster/securing-a-cluster.md @@ -123,6 +123,7 @@ prevent cross talk, or advanced networking policy. By default, there are no restrictions on which nodes may run a pod. Kubernetes offers a [rich set of policies for controlling placement of pods onto nodes](/docs/concepts/configuration/assign-pod-node/) +and the [taint based pod placement and eviction](/docs/concepts/configuration/taint-and-toleration) that are available to end users. For many clusters use of these policies to separate workloads can be a convention that authors adopt or enforce via tooling. From cd210dc278e07275aacc455f8a38e51e0145c32c Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Mon, 28 Aug 2017 10:42:47 +0800 Subject: [PATCH 22/33] fix the command output fix the command output --- docs/tasks/run-application/configure-pdb.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/tasks/run-application/configure-pdb.md b/docs/tasks/run-application/configure-pdb.md index 9a0c3365aa..cece12a26b 100644 --- a/docs/tasks/run-application/configure-pdb.md +++ b/docs/tasks/run-application/configure-pdb.md @@ -192,6 +192,8 @@ $ kubectl get poddisruptionbudgets zk-pdb -o yaml apiVersion: policy/v1beta1 kind: PodDisruptionBudget metadata: + creationTimestamp: 2017-08-28T02:38:26Z + generation: 1 name: zk-pdb ... status: From b1b57365bb05ed9f6c8397a08c0ff037aa658c9b Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Mon, 28 Aug 2017 11:07:42 +0800 Subject: [PATCH 23/33] fix the command output fix the command output --- .../connecting-frontend-backend.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 76507c6f4b..c1ba86065e 100644 --- a/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -64,11 +64,28 @@ CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700 Labels: app=hello tier=backend track=stable +Annotations: deployment.kubernetes.io/revision=1 Selector: app=hello,tier=backend,track=stable -Replicas: 7 updated | 7 total | 7 available | 0 unavailable +Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 1 max unavailable, 1 max surge +Pod Template: + Labels: app=hello + tier=backend + track=stable + Containers: + hello: + Image: "gcr.io/google-samples/hello-go-gke:1.0" + Port: 80/TCP + Environment: + Mounts: + Volumes: +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable OldReplicaSets: NewReplicaSet: hello-3621623197 (7/7 replicas created) Events: From 2fdca62f971140a4b322ac43a00f4f7a059f4b7c Mon Sep 17 00:00:00 2001 From: Chris Mytton Date: Mon, 28 Aug 2017 13:43:23 +0100 Subject: [PATCH 24/33] Fix link to Pod overview from concepts index There was a typo in the path which was causing the link to the "Pod Overview" page to 404. --- docs/concepts/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/index.md b/docs/concepts/index.md index a4cd156b00..5fce2c4e4f 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -21,7 +21,7 @@ Kubernetes contains a number of abstractions that represent the state of your sy The basic Kubernetes objects include: -* [Pod](/docs/concepts/workload/pods/pod-overview/) +* [Pod](/docs/concepts/workloads/pods/pod-overview/) * [Service](/docs/concepts/services-networking/service/) * [Volume](/docs/concepts/storage/volumes/) * [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) From 127b5f9a9da016840f917c3596586abe633c3a2c Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Mon, 28 Aug 2017 11:25:27 -0700 Subject: [PATCH 25/33] fix resource quota redirect --- _redirects | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/_redirects b/_redirects index 42bebb055b..a9aea70922 100644 --- a/_redirects +++ b/_redirects @@ -33,7 +33,7 @@ /docs/admin/out-of-resource /docs/tasks/administer-cluster/out-of-resource 301 /docs/admin/rescheduler /docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods 301 /docs/admin/resourcequota/limitstorageconsumption /docs/tasks/administer-cluster/limit-storage-consumption 301 -/docs/admin/resourcequota/walkthrough /docs/tasks/administer-cluster/apply-resource-quota-limit 301 +/docs/admin/resourcequota/walkthrough /docs/tasks/administer-cluster/quota-api-object 301 /docs/admin/static-pods /docs/tasks/administer-cluster/static-pod 301 /docs/admin/sysctls /docs/concepts/cluster-administration/sysctl-cluster 301 /docs/admin/upgrade-1-6 /docs/tasks/administer-cluster/upgrade-1-6 301 @@ -86,6 +86,7 @@ /docs/ /docs/home/ 301 /docs/samples /docs/tutorials/ 301 +/docs/tasks/administer-cluster/apply-resource-quota-limit /docs/tasks/administer-cluster/quota-api-object 301 /docs/tasks/administer-cluster/assign-pods-nodes /docs/tasks/configure-pod-container/assign-pods-nodes 301 /docs/tasks/administer-cluster/overview /docs/concepts/cluster-administration/cluster-administration-overview 301 /docs/tasks/administer-cluster/cpu-memory-limit /docs/tasks/administer-cluster/memory-default-namespace 301 From 12722567fe7ef27611762e5bd611068735f7b68d Mon Sep 17 00:00:00 2001 From: Stewart-YU Date: Tue, 29 Aug 2017 03:20:29 +0800 Subject: [PATCH 26/33] Update images.md (#5212) * Update images.md Add signals. * Add capitalization * Add additional capitalization and punctuation. --- docs/concepts/containers/images.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/concepts/containers/images.md b/docs/concepts/containers/images.md index 6947df31e8..1522af2f1f 100644 --- a/docs/concepts/containers/images.md +++ b/docs/concepts/containers/images.md @@ -264,7 +264,7 @@ type: kubernetes.io/dockerconfigjson ``` If you get the error message `error: no objects passed to create`, it may mean the base64 encoded string is invalid. -If you get an error message like `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...` it means +If you get an error message like `Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`, it means the data was successfully un-base64 encoded, but could not be parsed as a `.docker/config.json` file. #### Referring to an imagePullSecrets on a Pod @@ -301,26 +301,26 @@ common use cases and suggested solutions. 1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images. - Use public images on the Docker hub. - - no configuration required - - on GCE/GKE, a local mirror is automatically used for improved speed and availability + - No configuration required. + - On GCE/GKE, a local mirror is automatically used for improved speed and availability. 1. Cluster running some proprietary images which should be hidden to those outside the company, but visible to all cluster users. - - Use a hosted private [Docker registry](https://docs.docker.com/registry/) - - may be hosted on the [Docker Hub](https://hub.docker.com/account/signup/), or elsewhere. - - manually configure .docker/config.json on each node as described above + - Use a hosted private [Docker registry](https://docs.docker.com/registry/). + - It may be hosted on the [Docker Hub](https://hub.docker.com/account/signup/), or elsewhere. + - Manually configure .docker/config.json on each node as described above. - Or, run an internal private registry behind your firewall with open read access. - - no Kubernetes configuration required + - No Kubernetes configuration is required. - Or, when on GCE/GKE, use the project's Google Container Registry. - - will work better with cluster autoscaling than manual node configuration + - It will work better with cluster autoscaling than manual node configuration. - Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`. -1. Cluster with a proprietary images, a few of which require stricter access control - - ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active, otherwise, all Pods potentially have access to all images +1. Cluster with a proprietary images, a few of which require stricter access control. + - Ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods potentially have access to all images. - Move sensitive data into a "Secret" resource, instead of packaging it in an image. -1. A multi-tenant cluster where each tenant needs own private registry - - ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active, otherwise, all Pods of all tenants potentially have access to all images - - run a private registry with authorization required. - - generate registry credential for each tenant, put into secret, and populate secret to each tenant namespace. - - tenant adds that secret to imagePullSecrets of each namespace. +1. A multi-tenant cluster where each tenant needs own private registry. + - Ensure [AlwaysPullImages admission controller](/docs/admin/admission-controllers/#alwayspullimages) is active. Otherwise, all Pods of all tenants potentially have access to all images. + - Run a private registry with authorization required. + - Generate registry credential for each tenant, put into secret, and populate secret to each tenant namespace. + - The tenant adds that secret to imagePullSecrets of each namespace. {% endcapture %} From e7384f280ed732b3c7426122a29f9f2d91b0ffbb Mon Sep 17 00:00:00 2001 From: Stewart-YU Date: Tue, 29 Aug 2017 03:28:11 +0800 Subject: [PATCH 27/33] Update volumes.md (#5214) * Update volumes.md Fix the formats. * Convert important and note into callouts --- docs/concepts/storage/volumes.md | 88 +++++++++++++++++--------------- 1 file changed, 46 insertions(+), 42 deletions(-) diff --git a/docs/concepts/storage/volumes.md b/docs/concepts/storage/volumes.md index b9a9368d83..28cb140e48 100644 --- a/docs/concepts/storage/volumes.md +++ b/docs/concepts/storage/volumes.md @@ -99,9 +99,10 @@ exists as long as that Pod is running on that node. As the name says, it is initially empty. Containers in the pod can all read and write the same files in the `emptyDir` volume, though that volume can be mounted at the same or different paths in each container. When a Pod is removed from a node for -any reason, the data in the `emptyDir` is deleted forever. NOTE: a container -crashing does *NOT* remove a pod from a node, so the data in an `emptyDir` -volume is safe across container crashes. +any reason, the data in the `emptyDir` is deleted forever. + +**Note:** a container crashing does *NOT* remove a pod from a node, so the data in an `emptyDir` volume is safe across container crashes. +{: .note} Some uses for an `emptyDir` are: @@ -189,8 +190,8 @@ Disk](http://cloud.google.com/compute/docs/disks) into your pod. Unlike preserved and the volume is merely unmounted. This means that a PD can be pre-populated with data, and that data can be "handed off" between pods. -__Important: You must create a PD using `gcloud` or the GCE API or UI -before you can use it__ +**Important:** You must create a PD using `gcloud` or the GCE API or UI before you can use it. +{: .caution} There are some restrictions when using a `gcePersistentDisk`: @@ -245,8 +246,8 @@ volume are preserved and the volume is merely unmounted. This means that an EBS volume can be pre-populated with data, and that data can be "handed off" between pods. -__Important: You must create an EBS volume using `aws ec2 create-volume` or -the AWS API before you can use it__ +**Important:** You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it. +{: .caution} There are some restrictions when using an awsElasticBlockStore volume: @@ -259,7 +260,7 @@ There are some restrictions when using an awsElasticBlockStore volume: Before you can use an EBS volume with a pod, you need to create it. ```shell -aws ec2 create-volume --availability-zone eu-west-1a --size 10 --volume-type gp2 +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 ``` Make sure the zone matches the zone you brought up your cluster in. (And also check that the size and EBS volume @@ -296,8 +297,8 @@ unmounted. This means that an NFS volume can be pre-populated with data, and that data can be "handed off" between pods. NFS can be mounted by multiple writers simultaneously. -__Important: You must have your own NFS server running with the share exported -before you can use it__ +**Important:** You must have your own NFS server running with the share exported before you can use it. +{: .caution} See the [NFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/nfs) for more details. @@ -309,8 +310,8 @@ contents of an `iscsi` volume are preserved and the volume is merely unmounted. This means that an iscsi volume can be pre-populated with data, and that data can be "handed off" between pods. -__Important: You must have your own iSCSI server running with the volume -created before you can use it__ +**Important:** You must have your own iSCSI server running with the volume created before you can use it. +{: .caution} A feature of iSCSI is that it can be mounted as read-only by multiple consumers simultaneously. This means that you can pre-populate a volume with your dataset @@ -327,9 +328,8 @@ You can specify single or multiple target World Wide Names using the parameter `targetWWNs` in your volume configuration. If multiple WWNs are specified, targetWWNs expect that those WWNs are from multi-path connections. -__Important: You must configure FC SAN Zoning to allocate and mask those -LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts -can access them__ +**Important:** You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them. +{: .caution} See the [FC example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/fibre_channel) for more details. @@ -344,7 +344,8 @@ CLI or by using the Flocker API. If the dataset already exists it will be reattached by Flocker to the node that the pod is scheduled. This means data can be "handed off" between pods as required. -__Important: You must have your own Flocker installation running before you can use it__ +**Important:** You must have your own Flocker installation running before you can use it. +{: .caution} See the [Flocker example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/flocker) for more details. @@ -358,8 +359,8 @@ means that a glusterfs volume can be pre-populated with data, and that data can be "handed off" between pods. GlusterFS can be mounted by multiple writers simultaneously. -__Important: You must have your own GlusterFS installation running before you -can use it__ +**Important:** You must have your own GlusterFS installation running before you can use it. +{: .caution} See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/glusterfs) for more details. @@ -372,8 +373,8 @@ a `rbd` volume are preserved and the volume is merely unmounted. This means that a RBD volume can be pre-populated with data, and that data can be "handed off" between pods. -__Important: You must have your own Ceph installation running before you -can use RBD__ +**Important:** You must have your own Ceph installation running before you can use RBD. +{: .caution} A feature of RBD is that it can be mounted as read-only by multiple consumers simultaneously. This means that you can pre-populate a volume with your dataset @@ -392,8 +393,8 @@ unmounted. This means that a CephFS volume can be pre-populated with data, and that data can be "handed off" between pods. CephFS can be mounted by multiple writers simultaneously. -__Important: You must have your own Ceph server running with the share exported -before you can use it__ +**Important:** You must have your own Ceph server running with the share exported before you can use it. +{: .caution} See the [CephFS example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/cephfs/) for more details. @@ -433,8 +434,8 @@ use by pods without coupling to Kubernetes directly. `secret` volumes are backed by tmpfs (a RAM-backed filesystem) so they are never written to non-volatile storage. -__Important: You must create a secret in the Kubernetes API before you can use -it__ +**Important:** You must create a secret in the Kubernetes API before you can use it. +{: .caution} Secrets are described in more detail [here](/docs/user-guide/secrets). @@ -467,7 +468,7 @@ Currently, the following types of volume sources can be projected: All sources are required to be in the same namespace as the pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/all-in-one-volume.md). -#### Example pod with a secret, a downward API, and a configmap +#### Example pod with a secret, a downward API, and a configmap. ```yaml apiVersion: v1 @@ -507,7 +508,7 @@ spec: path: my-group/my-config ``` -#### Example pod with multiple secrets with a non-default permission mode set +#### Example pod with multiple secrets with a non-default permission mode set. ```yaml apiVersion: v1 @@ -554,30 +555,31 @@ A `FlexVolume` enables users to mount vendor volumes into a pod. It expects vend drivers are installed in the volume plugin path on each kubelet node. This is an alpha feature and may change in future. -More details are in [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/flexvolume/README.md) +More details are in [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/flexvolume/README.md). ### AzureFileVolume A `AzureFileVolume` is used to mount a Microsoft Azure File Volume (SMB 2.1 and 3.0) into a Pod. -More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_file/README.md) +More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_file/README.md). ### AzureDiskVolume A `AzureDiskVolume` is used to mount a Microsoft Azure [Data Disk](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) into a Pod. -More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_disk/README.md) +More details can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/azure_disk/README.md). ### vsphereVolume -__Prerequisite: Kubernetes with vSphere Cloud Provider configured. -For cloudprovider configuration please refer [vSphere getting started guide](/docs/getting-started-guides/vsphere/).__ +**Prerequisite:** Kubernetes with vSphere Cloud Provider configured. For cloudprovider configuration please refer [vSphere getting started guide](/docs/getting-started-guides/vsphere/). +{: .note} A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The contents of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore. -__Important: You must create VMDK using one of the following method before using with POD.__ +**Important:** You must create VMDK using one of the following method before using with POD. +{: .caution} #### Creating a VMDK volume @@ -631,8 +633,8 @@ More examples can be found [here](https://git.k8s.io/kubernetes/examples/volumes A `Quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume to be mounted into your pod. -__Important: You must have your own Quobyte setup running with the volumes created -before you can use it__ +**Important:** You must have your own Quobyte setup running with the volumes created before you can use it. +{: .caution} See the [Quobyte example](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/quobyte) for more details. @@ -664,9 +666,10 @@ spec: fsType: "" ``` -__Important: Make sure you have an existing PortworxVolume with name `pxvol` before using it in the pod__ +**Important:** Make sure you have an existing PortworxVolume with name `pxvol` before using it in the pod. +{: .caution} -More details and examples can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/portworx/README.md) +More details and examples can be found [here](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/volumes/portworx/README.md). ### ScaleIO ScaleIO is a software-based storage platform that can use existing hardware to create clusters of scalable @@ -674,8 +677,8 @@ shared block networked storage. The ScaleIO volume plugin allows deployed pods volumes (or it can dynamically provision new volumes for persistent volume claims, see [ScaleIO Persistent Volumes](/docs/user-guide/persistent-volumes/#scaleio)). -__Important: You must have an existing ScaleIO cluster already setup and running with the volumes created -before you can use them__ +**Important:** You must have an existing ScaleIO cluster already setup and running with the volumes created before you can use them. +{: .caution} The following is an example pod configuration with ScaleIO: @@ -713,7 +716,8 @@ At its core, StorageOS provides block storage to containers, accessible via a fi The StorageOS container requires 64-bit Linux and has no additional dependencies. A free developer licence is available. -__Important: You must run the StorageOS container on each node that wants to access StorageOS volumes or that will contribute storage capacity to the pool. For installation instructions, consult the [StorageOS documentation](https://docs.storageos.com)__ +**Important:** You must run the StorageOS container on each node that wants to access StorageOS volumes or that will contribute storage capacity to the pool. For installation instructions, consult the [StorageOS documentation](https://docs.storageos.com). +{: .caution} ```yaml apiVersion: v1 @@ -791,11 +795,11 @@ spec: path: /mnt/disks/ssd1 ``` -Note that local PersistentVolume cleanup and deletion requires manual -intervention without the external provisioner. +**Note:** The local PersistentVolume cleanup and deletion requires manual intervention without the external provisioner. +{: .note} For details on the `local` volume type, see the [Local Persistent Storage -user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume) +user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume). ## Using subPath From 0609e2a4fe3c7afe7d74fd5f01f05608dac5d1ad Mon Sep 17 00:00:00 2001 From: Dan Wendlandt Date: Mon, 28 Aug 2017 16:29:06 -0700 Subject: [PATCH 28/33] Cilium network policy, update link: configure-pod-container -> administer-cluster Signed-off-by: Dan Wendlandt --- docs/tasks/administer-cluster/declare-network-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/administer-cluster/declare-network-policy.md b/docs/tasks/administer-cluster/declare-network-policy.md index c473614fe0..a8fa8b2f23 100644 --- a/docs/tasks/administer-cluster/declare-network-policy.md +++ b/docs/tasks/administer-cluster/declare-network-policy.md @@ -12,7 +12,7 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do You'll need to have a Kubernetes cluster in place, with network policy support. There are a number of network providers that support NetworkPolicy, including: * [Calico](/docs/tasks/configure-pod-container/calico-network-policy/) -* [Cilium](/docs/tasks/configure-pod-container/cilium-network-policy/) +* [Cilium](/docs/tasks/administer-cluster/cilium-network-policy/) * [Romana](/docs/tasks/configure-pod-container/romana-network-policy/) * [Weave Net](/docs/tasks/configure-pod-container/weave-network-policy/) From 1a420bacc3d309acc57336602bdf9d498d5efdee Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 29 Aug 2017 10:24:59 -0700 Subject: [PATCH 29/33] update OWNERS file --- OWNERS | 5 ----- 1 file changed, 5 deletions(-) diff --git a/OWNERS b/OWNERS index 195e9fbc8a..fcd3320c9b 100644 --- a/OWNERS +++ b/OWNERS @@ -1,8 +1,3 @@ reviewers: -- a-mccarthy -- abiogenesis-now - bradamant3 - chenopis -- cody-clark -- steveperry-53 -- zacharysarah From 46aa547642339d56d224e74ba1554e88f1635eeb Mon Sep 17 00:00:00 2001 From: vuil Date: Tue, 29 Aug 2017 15:27:33 -0700 Subject: [PATCH 30/33] Update disruptions.md --- docs/concepts/workloads/pods/disruptions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/concepts/workloads/pods/disruptions.md b/docs/concepts/workloads/pods/disruptions.md index 4d2e752626..d0a6fb93b1 100644 --- a/docs/concepts/workloads/pods/disruptions.md +++ b/docs/concepts/workloads/pods/disruptions.md @@ -32,7 +32,7 @@ an application. Examples are: - cluster administrator deletes VM (instance) by mistake - cloud provider or hypervisor failure makes VM disappear - a kernel panic -- if the node to disappears from the cluster due to cluster network partition +- the node disappears from the cluster due to cluster network partition - eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource/). Except for the out-of-resources condition, all these conditions @@ -145,7 +145,7 @@ Initially, the pods are laid out as follows: | pod-a *available* | pod-b *available* | pod-c *available* | | pod-x *available* | | | -All 3 pods are part of an deployment, and they collectively have a PDB which requires +All 3 pods are part of a deployment, and they collectively have a PDB which requires there be at least 2 of the 3 pods to be available at all times. For example, assume the cluster administrator wants to reboot into a new kernel version to fix a bug in the kernel. @@ -174,7 +174,7 @@ Now the cluster is in this state: | pod-a *terminating* | pod-b *available* | pod-c *available* | | pod-x *terminating* | pod-d *starting* | pod-y | -At some point, the pods terminate, and the cluster look like this: +At some point, the pods terminate, and the cluster looks like this: | node-1 *drained* | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| From 69d2091ca6adb2ce0918ca90ffb6e6acc9cb20fe Mon Sep 17 00:00:00 2001 From: divyenpatel Date: Thu, 31 Aug 2017 16:16:24 -0700 Subject: [PATCH 31/33] Updating vSphere Cloud Provider Documentation (#5241) * adding vSphere Cloud Provider Documentation Link, updated introduction and added slack support link * content edits --- docs/getting-started-guides/vsphere.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/getting-started-guides/vsphere.md b/docs/getting-started-guides/vsphere.md index a0048b228c..44f7b1287e 100644 --- a/docs/getting-started-guides/vsphere.md +++ b/docs/getting-started-guides/vsphere.md @@ -12,24 +12,23 @@ This page covers how to get started with deploying Kubernetes on vSphere and det ### Getting started with the vSphere Cloud Provider -Kubernetes comes with a cloud provider for vSphere. A quick and easy way to try out the cloud provider is to deploy Kubernetes using [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere). - -This page also describes how to configure and get started with the cloud provider if deploying using custom install scripts. +Kubernetes comes with *vSphere Cloud Provider*, a cloud provider for vSphere that allows Kubernetes Pods to use enterprise grade vSphere Storage. ### Deploy Kubernetes on vSphere -To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch. +To deploy Kubernetes on vSphere and use the vSphere Cloud Provider, see [Kubernetes-Anywhere](https://github.com/kubernetes/kubernetes-anywhere). Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md) page. ### vSphere Cloud Provider -vSphere Cloud Provider allows using vSphere managed storage within Kubernetes. It supports: +vSphere Cloud Provider allows Kubernetes to use vSphere managed enterprise grade storage. It supports: -1. Volumes -2. Persistent Volumes -3. Storage Classes and provisioning of volumes. -4. vSphere Storage Policy Based Management for Containers orchestrated by Kubernetes. +- Enterprise class services such as de-duplication and encryption with vSAN, QoS, high availability and data reliability. +- Policy based management at granularity of container volumes. +- Volumes, Persistent Volumes, Storage Classes, dynamic provisioning of volumes, and scalable deployment of Stateful Apps with StatefulSets. + +For more detail visit [vSphere Storage for Kubernetes Documentation](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/index.html). Documentation for how to use vSphere managed storage can be found in the [persistent volumes user guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the [volumes user guide](/docs/concepts/storage/volumes/#vspherevolume). @@ -184,7 +183,7 @@ Below is summary of supported parameters in the `vsphere.conf` file --cloud-config= ``` -Manifest files for API server and controller-manager are generally located at `/etc/kubernetes`. +Manifest files for API server and controller-manager are generally located at `/etc/kubernetes/manifests`. **Step-7** Restart Kubelet on all nodes. @@ -194,11 +193,11 @@ Manifest files for API server and controller-manager are generally located at `/ Note: After enabling the vSphere Cloud Provider, Node names will be set to the VM names from the vCenter Inventory. #### Known issues -[vmware#220](https://github.com/vmware/kubernetes/issues/220) : -vSphere Cloud Provider can not be used on the Kubernetes Cluster when vCenter port is configured other than the default port 443. Fix for this issue is already out (Kubernetes PR# [49689](https://github.com/kubernetes/kubernetes/pull/49689)). We will make sure that, PR 49689 is cherry picked to 1.7, 1.6 and 1.5 branches. +Please visit [known issues](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/known-issues.html) for the list of major known issues with Kubernetes vSphere Cloud Provider. ## Support Level +For quick support please join VMware Code Slack ([#kubernetes](https://vmwarecode.slack.com/messages/kubernetes/)) and post your question. IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | --------- | ---------------------------- @@ -206,4 +205,5 @@ Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/ If you identify any issues/problems using the vSphere cloud provider, you can create an issue in our repo - [VMware Kubernetes](https://github.com/vmware/kubernetes). + For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. From 7f828b9ee34da776aae76cd1f145e03983fb5700 Mon Sep 17 00:00:00 2001 From: Ryan McGinnis Date: Fri, 1 Sep 2017 10:55:03 -0700 Subject: [PATCH 32/33] Edits "Creating a Deployment" section (#5195) * Edits "Creating a Deployment" section * Explains the example Deployment * Explains command output * Comprehensive edit for reader comprehension, length, and style * Update deployment.md --- .../workloads/controllers/deployment.md | 93 ++++++++++++------- 1 file changed, 57 insertions(+), 36 deletions(-) diff --git a/docs/concepts/workloads/controllers/deployment.md b/docs/concepts/workloads/controllers/deployment.md index acc21c984e..c0c9587624 100644 --- a/docs/concepts/workloads/controllers/deployment.md +++ b/docs/concepts/workloads/controllers/deployment.md @@ -27,84 +27,106 @@ The following are typical use cases for Deployments: * [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not. * [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment. * [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment. -* [Scale up the Deployment to facilitate more load.](#scaling-a-deployment) +* [Scale up the Deployment to facilitate more load](#scaling-a-deployment). * [Pause the Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout. -* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck -* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore +* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck. +* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore. ## Creating a Deployment -Here is an example Deployment. It creates a ReplicaSet to bring up three nginx Pods. +The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods: {% include code.html language="yaml" file="nginx-deployment.yaml" ghlink="/docs/concepts/workloads/controllers/nginx-deployment.yaml" %} -Run the example by downloading the example file and then running this command: +In this example: + +* A Deployment named `nginx` is created. +* The `nginx` Deployment creates three replicated Pods. +* The Pods are created from the `template` field. + +The `template` field contains the following instructions: + +* Create one container in each Pod. +* Label the container `app: nginx`. +* Run the [Docker Hub](https://hub.docker.com) image `nginx` at version `1.7.9`. +* Open port `80` so that the container can send and accept traffic. + +To create this Deployment, run the following command: ```shell -$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record -deployment "nginx-deployment" created +kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes.github.io/master/docs/concepts/workloads/controllers/nginx-deployment.yaml ``` -Setting the kubectl flag `--record` to `true` allows you to record current command in the annotations of -the resources being created or updated. It is useful for future introspection: for example, to see the -commands executed in each Deployment revision. +Note: You can append `--record` to this command to record the current command in the annotations of +the created or updated resource. This is useful for future review, such as investigating which +commands were executed in each Deployment revision. -Then running `get` immediately will give: +Next, run `kubectl get deployments`. The output is similar to the following: ```shell -$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 0 0 0 1s ``` -This indicates that the Deployment's number of desired replicas is 3 (according to deployment's `.spec.replicas`), -the number of current replicas (`.status.replicas`) is 0, the number of up-to-date replicas (`.status.updatedReplicas`) -is 0, and the number of available replicas (`.status.availableReplicas`) is also 0. +When you inspect the Deployments in your cluster, the following fields are displayed: -To see the Deployment rollout status, run: +* `NAME` lists the names of the Deployments in the cluster. +* `DESIRED` displays the desired number of _replicas_ of the application, which + you define when you create the Deployment. This is the _desired state_. +* `CURRENT` displays how many replicas are currently running. +* `UP-TO-DATE` displays the number of replicas that have been updated to achieve + the desired state. +* `AVAILABLE` displays how many replicas of the application are available to + your users. +* `AGE` displays the amount of time that the application has been running. + +Notice how the values in each field correspond to the values in the Deployment specification: + +* The number of desired replicas is 3 according to `spec: replicas` field. +* The number of current replicas is 0 according to the `.status.replicas` field. +* The number of up-to-date replicas is 0 accoridng to the `.status.updatedReplicas` field. +* The number of available replicas is 0 according to the `.status.availableReplicas` field. + +To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. This command returns the following output: ```shell -$ kubectl rollout status deployment/nginx-deployment Waiting for rollout to finish: 2 out of 3 new replicas have been updated... deployment "nginx-deployment" successfully rolled out ``` -Running the `get` again a few seconds later should give: +Run the `kubectl get deployments` again a few seconds later: ```shell -$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 3 3 3 18s ``` -This indicates that the Deployment has created all three replicas, and all replicas are up-to-date (contains the -latest pod template) and available (pod status is ready for at least Deployment's `.spec.minReadySeconds`). Running -`kubectl get rs` and `kubectl get pods` will show the ReplicaSet (RS) and Pods created. +Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the +latest Pod template) and available (the Pod status is Ready for at least the value of the Deployment's `.spec.minReadySeconds` field). + +To see the ReplicaSet (`rs`) created by the deployment, run `kubectl get rs`: ```shell -$ kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-2035384211 3 3 3 18s ``` -You may notice that the name of the ReplicaSet is always `-`. +Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[POD-TEMPALTE-HASH-VALUE]`. The hash value is automatically generated when the Deployemnt is created. + +To see the labels automatically generated for each pod, run `kubectl get pods --show-labels`. The following output is returned: ```shell -$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-2035384211-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211 nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211 nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211 ``` -The created ReplicaSet ensures that there are three nginx Pods at all times. +The created ReplicaSet ensures that there are three `nginx` Pods running at all times. -**Note:** You must specify an appropriate selector and pod template labels in a Deployment (in this case, -`app = nginx`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets, -StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple -controllers have overlapping selectors, those controllers may fight with each other and won't behave -correctly. +**Note:** You must specify an appropriate selector and Pod template labels in a Deployment (in this case, +`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly. {: .note} ### Pod-template-hash label @@ -112,11 +134,10 @@ correctly. **Note:** Do not change this label. {: .note} -Note the pod-template-hash label in the example output in the pod labels above. This label is added by the -Deployment controller to every ReplicaSet that a Deployment creates or adopts. Its purpose is to make sure that child -ReplicaSets of a Deployment do not overlap. It is computed by hashing the PodTemplate of the ReplicaSet -and using the resulting hash as the label value that will be added in the ReplicaSet selector, pod template labels, -and in any existing Pods that the ReplicaSet may have. +The `pod-template-hash label` is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts. + +This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the `PodTemplate` of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels, +and in any existing Pods that the ReplicaSet might have. ## Updating a Deployment From dd9befb2ca96ad0841fdb755f4195b732872fa18 Mon Sep 17 00:00:00 2001 From: shashidharatd Date: Sat, 2 Sep 2017 03:05:40 +0530 Subject: [PATCH 33/33] Added a prerequisite to using CoreDNS provider in federation (#5159) * Added a prerequisite to using CoreDNS provider in federation * turn prereqs into bullets --- docs/tasks/federation/set-up-coredns-provider-federation.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/tasks/federation/set-up-coredns-provider-federation.md b/docs/tasks/federation/set-up-coredns-provider-federation.md index 8bbde349fe..4268245dba 100644 --- a/docs/tasks/federation/set-up-coredns-provider-federation.md +++ b/docs/tasks/federation/set-up-coredns-provider-federation.md @@ -21,10 +21,12 @@ DNS provider for Cluster Federation. {% capture prerequisites %} -You need to have a running Kubernetes cluster (which is +* You need to have a running Kubernetes cluster (which is referenced as host cluster). Please see one of the [getting started](/docs/getting-started-guides/) guides for installation instructions for your platform. +* Support for `LoadBalancer` services in member clusters of federation is +mandatory to enable `CoreDNS` for service discovery across federated clusters. {% endcapture %}