From 3512bc673ba3e453b8284a6338c3ddbcb9349cb4 Mon Sep 17 00:00:00 2001 From: Zhou Tao Date: Sat, 11 Feb 2017 12:03:38 +0800 Subject: [PATCH 001/213] doc(kubeadm.md) - change base64 decode option to '--decode' `base64 -D` will lead to error on Ubuntu: "base64: invalid option -- 'D'" --- docs/getting-started-guides/kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index a2d4e1b834..5fc815ea9c 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -352,7 +352,7 @@ Please note: `kubeadm` is a work in progress and these limitations will be addre 1. There is no built-in way of fetching the token easily once the cluster is up and running, but here is a `kubectl` command you can copy and paste that will print out the token for you: ```console - # kubectl -n kube-system get secret clusterinfo -o yaml | grep token-map | awk '{print $2}' | base64 -D | sed "s|{||g;s|}||g;s|:|.|g;s/\"//g;" | xargs echo + # kubectl -n kube-system get secret clusterinfo -o yaml | grep token-map | awk '{print $2}' | base64 --decode | sed "s|{||g;s|}||g;s|:|.|g;s/\"//g;" | xargs echo ``` 1. If you are using VirtualBox (directly or via Vagrant), you will need to ensure that `hostname -i` returns a routable IP address (i.e. one on the second network interface, not the first one). From 4fa487f7223991a3596822e08b7e33d48c2db241 Mon Sep 17 00:00:00 2001 From: Bruce Auyeung Date: Mon, 13 Feb 2017 16:39:37 +0800 Subject: [PATCH 002/213] Update index.md --- docs/user-guide/persistent-volumes/index.md | 34 ++++++++++----------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 3ecc8ea99f..8b1178e45d 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -172,23 +172,23 @@ In the CLI, the access modes are abbreviated to: | Volume Plugin | ReadWriteOnce| ReadOnlyMany| ReadWriteMany| | :--- | :---: | :---: | :---: | -| AWSElasticBlockStore | x | - | - | -| AzureFile | x | x | x | -| AzureDisk | x | - | - | -| CephFS | x | x | x | -| Cinder | x | - | - | -| FC | x | x | - | -| FlexVolume | x | x | - | -| Flocker | x | - | - | -| GCEPersistentDisk | x | x | - | -| Glusterfs | x | x | x | -| HostPath | x | - | - | -| iSCSI | x | x | - | -| PhotonPersistentDisk | x | - | - | -| Quobyte | x | x | x | -| NFS | x | x | x | -| RBD | x | x | - | -| VsphereVolume | x | - | - | +| AWSElasticBlockStore | ✓ | - | - | +| AzureFile | ✓ | ✓ | ✓ | +| AzureDisk | ✓ | - | - | +| CephFS | ✓ | ✓ | ✓ | +| Cinder | ✓ | - | - | +| FC | ✓ | ✓ | - | +| FlexVolume | ✓ | ✓ | - | +| Flocker | ✓ | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | +| Glusterfs | ✓ | ✓ | ✓ | +| HostPath | ✓ | - | - | +| iSCSI | ✓ | ✓ | - | +| PhotonPersistentDisk | ✓ | - | - | +| Quobyte | ✓ | ✓ | ✓ | +| NFS | ✓ | ✓ | ✓ | +| RBD | ✓ | ✓ | - | +| VsphereVolume | ✓ | - | - | ### Class From ff088c22568518159778174ecc25c3df5592937e Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 14 Feb 2017 14:25:31 +0800 Subject: [PATCH 003/213] fix typo --- docs/user-guide/kubeconfig-file.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubeconfig-file.md b/docs/user-guide/kubeconfig-file.md index b4d7425127..93877f8a84 100644 --- a/docs/user-guide/kubeconfig-file.md +++ b/docs/user-guide/kubeconfig-file.md @@ -305,7 +305,7 @@ $ kubectl config use-context federal-context ### Final notes for tying it all together -So, tying this all together, a quick start to creating your own kubeconfig file: +So, tying this all together, a quick start to create your own kubeconfig file: - Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication. From 8a865cf1d310d05bed04b910e3560c77f6a04df8 Mon Sep 17 00:00:00 2001 From: yupengzte Date: Tue, 14 Feb 2017 10:36:00 +0800 Subject: [PATCH 004/213] fix typo Signed-off-by: yupengzte --- docs/deprecation-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/deprecation-policy.md b/docs/deprecation-policy.md index c51326bbc5..cdc0bb0102 100644 --- a/docs/deprecation-policy.md +++ b/docs/deprecation-policy.md @@ -233,7 +233,7 @@ after their announced deprecation for no less than:** * **Beta: 3 months or 1 release (whichever is longer)** * **Alpha: 0 releases** -**Rule #6: Deprecated CLI elements must emit warnings (optionally disableable) +**Rule #6: Deprecated CLI elements must emit warnings (optionally disable) when used.** ## Deprecating a feature or behavior From e56a7296ca805029ce4536bc1a2b6e6f5836dc2e Mon Sep 17 00:00:00 2001 From: Pierre Ozoux Date: Tue, 14 Feb 2017 15:18:45 +0000 Subject: [PATCH 005/213] Fix the standard storageClass for GCE As you can see here: https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/gce/gce.go#L117-L121 The default is not ssd --- docs/user-guide/persistent-volumes/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 8b1178e45d..4508a1a25f 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -396,7 +396,7 @@ parameters: zone: us-central1-a ``` -* `type`: `pd-standard` or `pd-ssd`. Default: `pd-ssd` +* `type`: `pd-standard` or `pd-ssd`. Default: `pd-standard` * `zone`: GCE zone. If not specified, a random zone in the same region as controller-manager will be chosen. #### Glusterfs From 7b42b5f9dd0a57fc94664f3b54627b3732216cca Mon Sep 17 00:00:00 2001 From: scjane Date: Tue, 14 Feb 2017 15:03:43 +0800 Subject: [PATCH 006/213] Update multiple-schedulers.md Similar to #2518. But I think an unordered list can be used here :) --- docs/admin/multiple-schedulers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/admin/multiple-schedulers.md b/docs/admin/multiple-schedulers.md index 3e3b4d270b..c20e129b19 100644 --- a/docs/admin/multiple-schedulers.md +++ b/docs/admin/multiple-schedulers.md @@ -95,7 +95,7 @@ Now that our second scheduler is running, let's create some pods, and direct the scheduler in that pod spec. Let's look at three examples. -1. Pod spec without any scheduler name +- Pod spec without any scheduler name {% include code.html language="yaml" file="multiple-schedulers/pod1.yaml" ghlink="/docs/admin/multiple-schedulers/pod1.yaml" %} @@ -108,7 +108,7 @@ scheduler in that pod spec. Let's look at three examples. kubectl create -f pod1.yaml ``` -2. Pod spec with `default-scheduler` +- Pod spec with `default-scheduler` {% include code.html language="yaml" file="multiple-schedulers/pod2.yaml" ghlink="/docs/admin/multiple-schedulers/pod2.yaml" %} @@ -121,7 +121,7 @@ scheduler in that pod spec. Let's look at three examples. kubectl create -f pod2.yaml ``` -3. Pod spec with `my-scheduler` +- Pod spec with `my-scheduler` {% include code.html language="yaml" file="multiple-schedulers/pod3.yaml" ghlink="/docs/admin/multiple-schedulers/pod3.yaml" %} From 7bafe3557f466cd2213adf799084099e5f9daad7 Mon Sep 17 00:00:00 2001 From: Fabrizio Milo Date: Tue, 14 Feb 2017 09:29:08 -0800 Subject: [PATCH 007/213] Update pod.md --- docs/concepts/abstractions/pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/pod.md b/docs/concepts/abstractions/pod.md index 5c364c5376..59a7beaee5 100644 --- a/docs/concepts/abstractions/pod.md +++ b/docs/concepts/abstractions/pod.md @@ -27,7 +27,7 @@ The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information * [The Distributed System Toolkit: Patterns for Composite Containers](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) * [Container Design Patterns](http://blog.kubernetes.io/2016/06/container-design-patterns.html) -Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run muliple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information. +Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information. ### How Pods Manage Multiple Containers From 38033ae6bf377e14947c4844674e174abc4aa5cb Mon Sep 17 00:00:00 2001 From: Fabrizio Milo Date: Tue, 14 Feb 2017 09:20:59 -0800 Subject: [PATCH 008/213] Update overview.md --- docs/concepts/abstractions/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/overview.md b/docs/concepts/abstractions/overview.md index 712ad0f99f..4e832eaffb 100644 --- a/docs/concepts/abstractions/overview.md +++ b/docs/concepts/abstractions/overview.md @@ -9,7 +9,7 @@ This page explains how Kubernetes objects are represented in the Kubernetes API, {% capture body %} ## Understanding Kubernetes Objects -*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubenetes uses these entities to represent the state of your cluster. Specifically, they can describe: +*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe: * What containerized applications are running (and on which nodes) * The resources available to those applications From 2fb161e033f9a4f84b95c1bd04cb87806ebcf57a Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 14 Feb 2017 11:07:33 -0800 Subject: [PATCH 009/213] fix Kubenetes typo Kubenetes -> Kubernetes --- .../configure-liveness-readiness-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index d168ceb211..ff05756350 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -247,7 +247,7 @@ where you would set it. Suppose the Container listens on 127.0.0.1 and the Pod's If your pod relies on virtual hosts, which is probably the more common case, you should not use `host`, but rather set the `Host` header in `httpHeaders`. -In addition to command probes and HTTP probes, Kubenetes supports +In addition to command probes and HTTP probes, Kubernetes supports [TCP probes](/docs/api-reference/v1/definitions/#_v1_tcpsocketaction). {% endcapture %} From 710a17c10d56180677587028c3a1481ceb0eafa6 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Tue, 14 Feb 2017 16:37:49 +0800 Subject: [PATCH 010/213] column READY is missed column READY is missed --- docs/user-guide/deployments.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index 0b4ae0d85a..52d24391c4 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -62,8 +62,8 @@ This indicates that the Deployment has created all three replicas, and all repli ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-2035384211 3 3 18s +NAME DESIRED CURRENT READY AGE +nginx-deployment-2035384211 3 3 0 18s ``` You may notice that the name of the Replica Set is always `-`. @@ -180,9 +180,9 @@ We can run `kubectl get rs` to see that the Deployment updated the Pods by creat ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 3 3 6s -nginx-deployment-2035384211 0 0 36s +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 0 6s +nginx-deployment-2035384211 0 0 0 36s ``` Running `get pods` should now show only the new Pods: @@ -287,10 +287,10 @@ You will also see that both the number of old replicas (nginx-deployment-1564180 ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 2 2 25s -nginx-deployment-2035384211 0 0 36s -nginx-deployment-3066724191 2 2 6s +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 2 2 0 25s +nginx-deployment-2035384211 0 0 0 36s +nginx-deployment-3066724191 2 2 2 6s ``` Looking at the Pods created, you will see that the 2 Pods created by new Replica Set are stuck in an image pull loop. @@ -514,10 +514,10 @@ The Deployment was still in progress when we paused it, so the actions of scalin ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 2 2 1h -nginx-deployment-2035384211 2 2 1h -nginx-deployment-3066724191 0 0 1h +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 2 2 2 1h +nginx-deployment-2035384211 2 2 0 1h +nginx-deployment-3066724191 0 0 0 1h ``` In a separate terminal, watch for rollout status changes and you'll see the rollout won't continue: @@ -546,10 +546,10 @@ deployment nginx-deployment successfully rolled out ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 3 3 1h -nginx-deployment-2035384211 0 0 1h -nginx-deployment-3066724191 0 0 1h +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 1h +nginx-deployment-2035384211 0 0 0 1h +nginx-deployment-3066724191 0 0 0 1h ``` Note: You cannot rollback a paused Deployment until you resume it. From 36ebe59068f338e63c86dbc7d3ceedfb55a936a0 Mon Sep 17 00:00:00 2001 From: Arthur Miranda Date: Tue, 14 Feb 2017 15:41:28 -0300 Subject: [PATCH 011/213] Fix broken/outdated links in the ingress.md file The Ingress controllers have moved to the kubernetes/ingress repository, then some links are broken or outdated. --- docs/user-guide/ingress.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/user-guide/ingress.md b/docs/user-guide/ingress.md index 4628d5050d..0a4f13da2f 100644 --- a/docs/user-guide/ingress.md +++ b/docs/user-guide/ingress.md @@ -44,9 +44,9 @@ It can be configured to give services externally-reachable urls, load balance tr Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect. -GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers) and [here](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc). +GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://github.com/kubernetes/ingress/tree/master/controllers/nginx#running-multiple-ingress-controllers) and [here](https://github.com/kubernetes/ingress/blob/master/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc). -Make sure you review the [beta limitations](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers) as a pod. +Make sure you review the [beta limitations](https://github.com/kubernetes/ingress/blob/master/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://github.com/kubernetes/ingress/tree/master/controllers) as a pod. ## The Ingress Resource @@ -71,7 +71,7 @@ spec: __Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [here](/docs/user-guide/deploying-applications), [here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources). -__Lines 5-7__: Ingress [spec](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules. +__Lines 5-7__: Ingress [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules. __Lines 8-9__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend. From 7c97c392ed7edcd75afd8ccf6a60c671847250ef Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Tue, 14 Feb 2017 10:36:08 +0800 Subject: [PATCH 012/213] add "--show-all" to kubectl get pods add "--show-all" to "kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name}" ,because the pod was ended --- docs/user-guide/jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index d48b856ae3..d64ae9d730 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -66,7 +66,7 @@ To view completed pods of a job, use `kubectl get pods --show-all`. The `--show To list all the pods that belong to a job in a machine readable form, you can use a command like this: ```shell -$ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name}) +$ pods=$(kubectl get pods --show-all --selector=job-name=pi --output=jsonpath={.items..metadata.name}) echo $pods pi-aiw0a ``` From cfaf34835cec826a3452858135477c5b6e82c8ea Mon Sep 17 00:00:00 2001 From: Robert Kubis Date: Sat, 11 Feb 2017 16:05:47 +0000 Subject: [PATCH 013/213] Update cheatsheet for multi-container handling Added how to retrieve logs for containers in multi-container pods --- docs/user-guide/kubectl-cheatsheet.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index c147304a7d..7fc0142f04 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -197,7 +197,9 @@ $ kubectl -n my-ns delete po,svc --all # Delete all pods and servic ```console $ kubectl logs my-pod # dump pod logs (stdout) +$ kubectl logs my-pod -c my-container # dump pod container logs (stdout, multi-container case) $ kubectl logs -f my-pod # stream pod logs (stdout) +$ kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case) $ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell $ kubectl attach my-pod -i # Attach to Running Container $ kubectl port-forward my-pod 5000:6000 # Forward port 6000 of Pod to your to 5000 on your local machine From 04d6793544c18280b934ae9c94d2357bfe9594e2 Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 14 Feb 2017 13:49:14 -0800 Subject: [PATCH 014/213] re: issue #1671; update to direct link Update Docker Volumes link to https://docs.docker.com/engine/tutorials/dockervolumes/ --- docs/user-guide/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/index.md b/docs/user-guide/index.md index 9c69683525..0d4e77a97d 100644 --- a/docs/user-guide/index.md +++ b/docs/user-guide/index.md @@ -54,7 +54,7 @@ Before running examples in the user guides, please ensure you have completed the : A service defines a set of pods and a means by which to access them, such as single stable IP address and corresponding DNS name. [**Volume**](/docs/user-guide/volumes/) -: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/userguide/dockervolumes/), adding provisioning of the volume directory and/or device. +: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/), adding provisioning of the volume directory and/or device. [**Secret**](/docs/user-guide/secrets/) : A secret stores sensitive data, such as authentication tokens, which can be made available to containers upon request. From 566f61f4b939a319eee3400cf2977afe5693605b Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 14 Feb 2017 14:34:13 -0800 Subject: [PATCH 015/213] re: issue #2034; fix docker image link (#2532) * re: issue #2034; fix docker image link change link in line 26 to: https://gcr.io/google_containers/hpa-example * point link to local Dockerfile * specify it as the Dockerfile, not image --- docs/user-guide/horizontal-pod-autoscaling/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md index f0a5cbc64a..616061e930 100644 --- a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md +++ b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md @@ -23,7 +23,7 @@ heapster monitoring will be turned-on by default). ## Step One: Run & expose php-apache server To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image. -The image can be found [here](/docs/user-guide/horizontal-pod-autoscaling/image). +The Dockerfile can be found [here](/docs/user-guide/horizontal-pod-autoscaling/image/Dockerfile). It defines an [index.php](/docs/user-guide/horizontal-pod-autoscaling/image/index.php) page which performs some CPU intensive computations. First, we will start a deployment running the image and expose it as a service: From 255364959892e9818d0f9b84f0df7a15aefd1118 Mon Sep 17 00:00:00 2001 From: foxish Date: Wed, 15 Feb 2017 13:27:00 -0800 Subject: [PATCH 016/213] Fix travis.yml --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 09a28b78cb..d05639d195 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,6 +14,7 @@ install: - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/sample-apiserver +- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/kube-aggregator - cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ - rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* - cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ From 5df783425dc2f01b7be1208becd3eb3e04f125d9 Mon Sep 17 00:00:00 2001 From: sallydeng Date: Tue, 14 Feb 2017 20:03:22 +0800 Subject: [PATCH 017/213] The key-value "optional:true" doesn't work The key-value "optional:true" doesn't work in 1.5.2 yet. So should we add a note here? "The key-value "optional:true" will be work after kubernetes 1.5.2." --- docs/user-guide/configmap/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 3227e416c0..e2de3a7aec 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -590,3 +590,5 @@ Kubelet only supports use of ConfigMap for pods it gets from the API server. Th created using kubectl, or indirectly via a replication controller. It does not include pods created via the Kubelet's `--manifest-url` flag, its `--config` flag, or its REST API (these are not common ways to create pods.) + +The key-value "optional:true" will be work after kubernetes 1.5.2. From 2ab877198bcc16c24f637f1a6e6905cf469db331 Mon Sep 17 00:00:00 2001 From: sallydeng Date: Wed, 15 Feb 2017 13:15:20 +0800 Subject: [PATCH 018/213] Change sentence base on reviewer's comment "NOTE: The key-value optional:true is supported for kubernetes 1.5.3 and above." --- docs/user-guide/configmap/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index e2de3a7aec..5e074e5787 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -591,4 +591,4 @@ created using kubectl, or indirectly via a replication controller. It does not via the Kubelet's `--manifest-url` flag, its `--config` flag, or its REST API (these are not common ways to create pods.) -The key-value "optional:true" will be work after kubernetes 1.5.2. +NOTE: The key-value optional:true is supported for kubernetes 1.5.3 and above. From 0366fcc114d2d21d2b68c863f23afec1048ab1fd Mon Sep 17 00:00:00 2001 From: Michael Mrowetz Date: Wed, 15 Feb 2017 11:58:43 +0900 Subject: [PATCH 019/213] #2534 mark openstack-heat as standalone-salt-conf --- docs/admin/salt.md | 12 ++++++------ docs/getting-started-guides/openstack-heat.md | 9 +++++++-- 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/docs/admin/salt.md b/docs/admin/salt.md index 05d0ae9250..b570dc8473 100644 --- a/docs/admin/salt.md +++ b/docs/admin/salt.md @@ -10,11 +10,11 @@ The Salt scripts are shared across multiple hosting providers and depending on w ## Salt cluster setup -The **salt-master** service runs on the kubernetes-master [(except on the default GCE setup)](#standalone-salt-configuration-on-gce). +The **salt-master** service runs on the kubernetes-master [(except on the default GCE and OpenStack-Heat setup)](#standalone-salt-configuration-on-gce-and-others). The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster. -Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce). +Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE and OpenStack-Heat)](#standalone-salt-configuration-on-gce-and-others). ```shell [root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf @@ -25,15 +25,15 @@ The salt-master is contacted by each salt-minion and depending upon the machine If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master. It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API. -## Standalone Salt Configuration on GCE +## Standalone Salt Configuration on GCE and others -On GCE, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state. +On GCE and OpenStack, using the Openstack-Heat provider, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state. -All remaining sections that refer to master/minion setups should be ignored for GCE. One fallout of the GCE setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes. +All remaining sections that refer to master/minion setups should be ignored for GCE and OpenStack. One fallout of this setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes. ## Salt security -*(Not applicable on default GCE setup.)* +*(Not applicable on default GCE and OpenStack-Heat setup.)* Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.) diff --git a/docs/getting-started-guides/openstack-heat.md b/docs/getting-started-guides/openstack-heat.md index e4fb7c277d..8a2fd52d11 100644 --- a/docs/getting-started-guides/openstack-heat.md +++ b/docs/getting-started-guides/openstack-heat.md @@ -23,7 +23,7 @@ This guide assumes you have access to a working OpenStack cluster with the follo - Heat - DNS resolution of instance names -By default this provider provisions 4 m1.medium instances. If you do not have resources available, please see the [Set additional configuration values](#set-additional-configuration-values) section for information on reducing the footprint of your cluster. +By default this provider provisions 4 `m1.medium` instances. If you do not have resources available, please see the [Set additional configuration values](#set-additional-configuration-values) section for information on reducing the footprint of your cluster. ## Pre-Requisites If you already have the required versions of the OpenStack CLI tools installed and configured, you can move on to the [Starting a cluster](#starting-a-cluster) section. @@ -92,7 +92,7 @@ Please see the contents of these files for documentation regarding each variable ## Starting a cluster -Once Kubernetes version 1.3 is released, and you've installed the OpenStack CLI tools and have set your OpenStack environment variables, issue this command: +Once you've installed the OpenStack CLI tools and have set your OpenStack environment variables, issue this command: ```sh export KUBERNETES_PROVIDER=openstack-heat; curl -sS https://get.k8s.io | bash @@ -194,6 +194,11 @@ nova list --name=$STACK_NAME See the [OpenStack CLI Reference](http://docs.openstack.org/cli-reference/) for more details. +### Salt + +The OpenStack-Heat provider uses a [standalone Salt configuration](/docs/admin/salt/#standalone-salt-configuration-on-gce-and-others). +It only uses Salt for bootstraping the machines and creates no salt-master and does not auto-start the salt-minion service on the nodes. + ## SSHing to your nodes Your public key was added during the cluster turn-up, so you can easily ssh to them for troubleshooting purposes. From 76e1bfc55d40b3c70d25a68eb16379951b16fb48 Mon Sep 17 00:00:00 2001 From: Arthur Miranda Date: Wed, 15 Feb 2017 15:07:08 -0300 Subject: [PATCH 020/213] Update the links of Deployment User Guide The file 'blob/master/docs/devel/api-conventions.md' has moved to 'community/blob/master/contributors/devel/api-conventions.md' Updates the links associated with these file. --- docs/user-guide/deployments.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index 52d24391c4..fb8f2cc0e0 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -615,7 +615,7 @@ the Deployment's `status.conditions`: * Status=False * Reason=ProgressDeadlineExceeded -See the [Kubernetes API conventions](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/devel/api-conventions.md#typical-status-properties) for more information on status conditions. +See the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions. Note that in version 1.5, Kubernetes will take no action on a stalled Deployment other than to report a status condition with `Reason=ProgressDeadlineExceeded`. @@ -725,7 +725,7 @@ As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, a `metadata` fields. For general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications), [configuring containers](/docs/user-guide/configuring-containers), and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents. -A Deployment also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status). +A Deployment also needs a [`.spec` section](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status). ### Pod Template From 9b3f420bd9153fa930d004eb018fbf5a04052c54 Mon Sep 17 00:00:00 2001 From: sallydeng Date: Wed, 15 Feb 2017 16:15:20 +0800 Subject: [PATCH 021/213] kubectl_apply.md-change it for label key When I test this command, if the configmap has a label, it just delete the configmaps which has the same label key and that are not in the file. kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap So I advise change the description like this: "Apply the configuration in manifest.yaml and delete all the other configmaps with the same label key that are not in the file." --- docs/user-guide/kubectl/kubectl_apply.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubectl/kubectl_apply.md b/docs/user-guide/kubectl/kubectl_apply.md index c729263d6c..81c1a12137 100644 --- a/docs/user-guide/kubectl/kubectl_apply.md +++ b/docs/user-guide/kubectl/kubectl_apply.md @@ -32,7 +32,7 @@ kubectl apply -f FILENAME # Apply the configuration in manifest.yaml that matches label app=nginx and delete all the other resources that are not in the file and match label app=nginx. kubectl apply --prune -f manifest.yaml -l app=nginx - # Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file. + # Apply the configuration in manifest.yaml and delete all the other configmaps with the same label key that are not in the file. kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap ``` From 4702554cb68556457811ac9c0ce79c08facd8d0f Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Wed, 15 Feb 2017 14:40:39 -0800 Subject: [PATCH 022/213] rollback PR #2522 Rollingback PR #2522 until we can verify which version optional:true will be available in. --- docs/user-guide/configmap/index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 5e074e5787..40b3fa181b 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -591,4 +591,3 @@ created using kubectl, or indirectly via a replication controller. It does not via the Kubelet's `--manifest-url` flag, its `--config` flag, or its REST API (these are not common ways to create pods.) -NOTE: The key-value optional:true is supported for kubernetes 1.5.3 and above. From c222e9da33df792408351234bd1a9fc92eb36134 Mon Sep 17 00:00:00 2001 From: Michail Kargakis Date: Wed, 25 Jan 2017 10:44:31 +0100 Subject: [PATCH 023/213] Update deployment completeness documentation --- docs/user-guide/deployments.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index fb8f2cc0e0..f2e854690e 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -578,6 +578,7 @@ Kubernetes marks a Deployment as _complete_ when it has the following characteri equals or exceeds the number required by the Deployment strategy. * All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any updates you've requested have been completed. +* No old pods for the Deployment are running. You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code. From a3a2233e6c9dc7c4e56b26762f75ec4456e394e7 Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Wed, 15 Feb 2017 14:56:39 -0800 Subject: [PATCH 024/213] Move Pod Lifecycle to Concepts. (#2420) * Move Pod Lifecycle to Concepts. * Put moved note on old page. * Update pod-lifecycle.md --- _data/concepts.yml | 6 + docs/concepts/workloads/pods/pod-lifecycle.md | 282 ++++++++++++++++++ docs/user-guide/pod-states.md | 166 +---------- 3 files changed, 290 insertions(+), 164 deletions(-) create mode 100644 docs/concepts/workloads/pods/pod-lifecycle.md diff --git a/_data/concepts.yml b/_data/concepts.yml index 4227231cc1..432f4c86e1 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -25,6 +25,12 @@ toc: section: - docs/concepts/object-metadata/annotations.md +- title: Workloads + section: + - title: Pods + section: + - docs/concepts/workloads/pods/pod-lifecycle.md + - title: Configuration section: - docs/concepts/configuration/container-command-args.md diff --git a/docs/concepts/workloads/pods/pod-lifecycle.md b/docs/concepts/workloads/pods/pod-lifecycle.md new file mode 100644 index 0000000000..540ba506fc --- /dev/null +++ b/docs/concepts/workloads/pods/pod-lifecycle.md @@ -0,0 +1,282 @@ +--- +title: Pod Lifecycle +--- + +{% capture overview %} + +{% comment %}Updated: 4/14/2015{% endcomment %} +{% comment %}Edited and moved to Concepts section: 2/2/17{% endcomment %} + +This page describes the lifecycle of a Pod. + +{% endcapture %} + + +{% capture body %} + +## Pod phase + +A Pod's `status` field is a +[PodStatus](/docs/resources-reference/v1.5/#podstatus-v1) +object, which has a `phase` field. + +The phase of a Pod is a simple, high-level summary of where the Pod is in its +lifecycle. The phase is not intended to be a comprehensive rollup of observations +of Container or Pod state, nor is it intended to be a comprehensive state machine. + +The number and meanings of Pod phase values are tightly guarded. +Other than what is documented here, nothing should be assumed about Pods that +have a given `phase` value. + +Here are the possible values for `phase`: + +* Pending: The Pod has been accepted by the Kubernetes system, but one or more of + the Container images has not been created. This includes time before being + scheduled as well as time spent downloading images over the network, + which could take a while. + +* Running: The Pod has been bound to a node, and all of the Containers have been + created. At least one Container is still running, or is in the process of + starting or restarting. + +* Succeeded: All Containers in the Pod have terminated in success, and will not + be restarted. + +* Failed: All Containers in the Pod have terminated, and at least one Container + has terminated in failure. That is, the Container either exited with non-zero + status or was terminated by the system. + +* Unknown: For some reason the state of the Pod could not be obtained, typically + due to an error in communicating with the host of the Pod. + +## Pod conditions + +A Pod has a PodStatus, which has an array of +[PodConditions](docs/resources-reference/v1.5/#podcondition). Each element +of the PodCondition array has a `type` field and a `status` field. The `type` +field is a string, with possible values PodScheduled, Ready, Initialized, and +Unschedulable. The `status` field is a string, with possible values True, False, +and Unknown. + +## Container probes + +A [Probe](/docs/resources-reference/v1.5/#probe-v1) is a diagnostic +performed periodically by the [kubelet](/docs/admin/kubelet/) +on a Container. To perform a diagnostic, +the kublet calls a +[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by +the Container. There are three types of handlers: + +* [ExecAction](/docs/resources-reference/v1.5/#execaction-v1): + Executes a specified command inside the Container. The diagnostic + is considered successful if the command exits with a status code of 0. + +* [TCPSocketAction](/docs/resources-reference/v1.5/#tcpsocketaction-v1): + Performs a TCP check against the Container's IP address on + a specified port. The diagnostic is considered successful if the port is open. + +* [HTTPGetAction](/docs/resources-reference/v1.5/#httpgetaction-v1): + Performs an HTTP Get request against the Container's IP + address on a specified port and path. The diagnostic is considered successful + if the response has a status code greater than or equal to 200 and less than 400. + +Each probe has one of three results: + +* Success: The Container passed the diagnostic. +* Failure: The Container failed the diagnostic. +* Unknown: The diagnostic failed, so no action should be taken. + +The kubelet can optionally perform and react to two kinds of probes on running +Containers: + +* `livenessProbe`: Indicates whether the Container is running. If + the liveness probe fails, the kubelet kills the Container, and the Container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a liveness probe, the default state is `Success`. + +* `readinessProbe`: Indicates whether the Container is ready to service requests. + If the readiness probe fails, the endpoints controller removes the Pod's IP + address from the endpoints of all Services that match the Pod. The default + state of readiness before the initial delay is `Failure`. If a Container does + not provide a readiness probe, the default state is `Success`. + +### When should you use liveness or readiness probes? + +If the process in your Container is able to crash on its own whenever it +encounters an issue or becomes unhealthy, you do not necessarily need a liveness +probe; the kubelet will automatically perform the correct action in accordance +with the Pod's `restartPolicy`. + +If you'd like your Container to be killed and restarted if a probe fails, then +specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure. + +If you'd like to start sending traffic to a Pod only when a probe succeeds, +specify a readiness probe. In this case, the readiness probe might be the same +as the liveness probe, but the existence of the readiness probe in the spec means +that the Pod will start without receiving any traffic and only start receiving +traffic after the probe starts succeeding. + +If you want your Container to be able to take itself down for maintenance, you +can specify a readiness probe that checks an endpoint specific to readiness that +is different from the liveness probe. + +Note that if you just want to be able to drain requests when the Pod is deleted, +you do not necessarily need a readiness probe; on deletion, the Pod automatically +puts itself into an unready state regardless of whether the readiness probe exists. +The Pod remains in the unready state while it waits for the Containers in the Pod +to stop. + +## Pod and Container status + +For detailed information about Pod Container status, see +[PodStatus](/docs/resources-reference/v1.5/#podstatus-v1) +and +[ContainerStatus](/docs/resources-reference/v1.5/#containerstatus-v1). +Note that the information reported as Pod status depends on the current +[ContainerState](/docs/resources-reference/v1.5/#containerstate-v1). + +## Restart policy + +A PodSpec has a `restartPolicy` field with possible values Always, OnFailure, +and Never. The default value is Always. +`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only +refers to restarts of the Containers by the kubelet on the same node. Failed +Containers that are restarted by the kubelet are restarted with an exponential +back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten +minutes of successful execution. As discussed in the +[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), +once bound to a node, a Pod will never be rebound to another node. + + + +## Pod lifetime + +In general, Pods do not disappear until someone destroys them. This might be a +human or a controller. The only exception to +this rule is that Pods with a `phase` of Succeeded or Failed for more than some +duration (determined by the master) will expire and be automatically destroyed. + +Three types of controllers are available: + +- Use a [Job](/docs/user-guide/jobs/) for Pods that are expected to terminate, + for example, batch computations. Jobs are appropriate only for Pods with + `restartPolicy` equal to OnFailure or Never. + +- Use a [ReplicationController](/docs/user-guide/replication-controller/), + [ReplicaSet](/docs/user-guide/replicasets/), or + [Deployment](/docs/user-guide/deployments/) + for Pods that are not expected to terminate, for example, web servers. + ReplicationControllers are appropriate only for Pods with a `restartPolicy` of + Always. + +- Use a [DaemonSet](/docs/admin/daemons/) for Pods that need to run one per + machine, because they provide a machine-specific system service. + +All three types of controllers contain a PodTemplate. It +is recommended to create the appropriate controller and let +it create Pods, rather than directly create Pods yourself. That is because Pods +alone are not resilient to machine failures, but controllers are. + +If a node dies or is disconnected from the rest of the cluster, Kubernetes +applies a policy for setting the `phase` of all Pods on the lost node to Failed. + +## Examples + +### Advanced liveness probe example + +Liveness probes are executed by the kubelet, so all requests are made in the +kubelet network namespace. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + test: liveness + name: liveness-http +spec: + containers: + - args: + - /server + image: gcr.io/google_containers/liveness + livenessProbe: + httpGet: + # when "host" is not defined, "PodIP" will be used + # host: my-host + # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed + # scheme: HTTPS + path: /healthz + port: 8080 + httpHeaders: + - name: X-Custom-Header + value: Awesome + initialDelaySeconds: 15 + timeoutSeconds: 1 + name: liveness +``` + +### Example states + + * Pod is running and has one Container. Container exits with success. + * Log completion event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Pod `phase` becomes Succeeded. + * Never: Pod `phase` becomes Succeeded. + + * Pod is running and has one Container. Container exits with failure. + * Log failure event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Pod `phase` becomes Failed. + + * Pod is running and has two Containers. Container 1 exits with failure. + * Log failure event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Do not restart Container; Pod `phase` stays Running. + * If Container 1 is not running, and Container 2 exits: + * Log failure event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Pod `phase` becomes Failed. + + * Pod is running and has one Container. Container runs out of memory. + * Container terminates in failure. + * Log OOM event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Log failure event; Pod `phase` becomes Failed. + + * Pod is running, and a disk dies. + * Kill all Containers. + * Log appropriate event. + * Pod `phase` becomes Failed. + * If running under a controller, Pod is recreated elsewhere. + + * Pod is running, and its node is segmented out. + * Node controller waits for timeout. + * Node controller sets Pod `phase` to Failed. + * If running under a controller, Pod is recreated elsewhere. + +{% endcapture %} + + +{% capture whatsnext %} + +* Get hands-on experience + [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +* Get hands-on experience + [configuring liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). + +* [Container Lifecycle Hooks](/docs/user-guide/container-environment/) + +{% endcapture %} + +{% include templates/concept.md %} + diff --git a/docs/user-guide/pod-states.md b/docs/user-guide/pod-states.md index 462f8b65bd..a3cea728cc 100644 --- a/docs/user-guide/pod-states.md +++ b/docs/user-guide/pod-states.md @@ -4,168 +4,6 @@ assignees: title: The Lifecycle of a Pod --- -Updated: 4/14/2015 - -This document covers the lifecycle of a pod. It is not an exhaustive document, but an introduction to the topic. - -## Pod Phase - -As consistent with the overall [API convention](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine. - -The number and meanings of `PodPhase` values are tightly guarded. Other than what is documented here, nothing should be assumed about pods with a given `PodPhase`. - -* Pending: The pod has been accepted by the system, but one or more of the container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while. -* Running: The pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. -* Succeeded: All containers in the pod have terminated in success, and will not be restarted. -* Failed: All containers in the pod have terminated, at least one container has terminated in failure (exited with non-zero exit status or was terminated by the system). -* Unknown: For some reason the state of the pod could not be obtained, typically due to an error in communicating with the host of the pod. - -## Pod Conditions - -A pod containing containers that specify readiness probes will also report the Ready condition. Condition status values may be `True`, `False`, or `Unknown`. - -## Container Probes - -A [Probe](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Probe) is a diagnostic performed periodically by the kubelet on a container. Specifically the diagnostic is one of three [Handlers](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler): - -* `ExecAction`: executes a specified command inside the container expecting on success that the command exits with status code 0. -* `TCPSocketAction`: performs a tcp check against the container's IP address on a specified port expecting on success that the port is open. -* `HTTPGetAction`: performs an HTTP Get against the container's IP address on a specified port and path expecting on success that the response has a status code greater than or equal to 200 and less than 400. - -Each probe will have one of three results: - -* `Success`: indicates that the container passed the diagnostic. -* `Failure`: indicates that the container failed the diagnostic. -* `Unknown`: indicates that the diagnostic failed so no action should be taken. - -The kubelet can optionally perform and react to two kinds of probes on running containers: - -* `LivenessProbe`: indicates whether the container is *live*, i.e. running. If the LivenessProbe fails, the kubelet will kill the container and the container will be subjected to its [RestartPolicy](#restartpolicy). The default state of Liveness before the initial delay is `Success`. The state of Liveness for a container when no probe is provided is assumed to be `Success`. -* `ReadinessProbe`: indicates whether the container is *ready* to service requests. If the ReadinessProbe fails, the endpoints controller will remove the pod's IP address from the endpoints of all services that match the pod. The default state of Readiness before the initial delay is `Failure`. The state of Readiness for a container when no probe is provided is assumed to be `Success`. - -### When should I use liveness or readiness probes? - -If the process in your container is able to crash on its own whenever it encounters an issue or becomes unhealthy, you do not necessarily need a liveness probe - the kubelet will automatically perform the correct action in accordance with the RestartPolicy when the process crashes. - -If you'd like your container to be killed and restarted if a probe fails, then specify a LivenessProbe and a RestartPolicy of `Always` or `OnFailure`. - -If you'd like to start sending traffic to a pod only when a probe succeeds, specify a ReadinessProbe. In this case, the ReadinessProbe may be the same as the LivenessProbe, but the existence of the ReadinessProbe in the spec means that the pod will start without receiving any traffic and only start receiving traffic once the probe starts succeeding. - -If a container wants the ability to take itself down for maintenance, you can specify a ReadinessProbe that checks an endpoint specific to readiness which is different than the LivenessProbe. - -Note that if you just want to be able to drain requests when the pod is deleted, you do not necessarily need a ReadinessProbe - on deletion, the pod automatically puts itself into an unready state regardless of whether the ReadinessProbe exists or not while it waits for the containers in the pod to stop. - -## Container Statuses - -More detailed information about the current (and previous) container statuses can be found in [ContainerStatuses](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#PodStatus). The information reported depends on the current [ContainerState](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#ContainerState), which may be Waiting, Running, or Terminated. - -## RestartPolicy - -The possible values for RestartPolicy are `Always`, `OnFailure`, or `Never`. If RestartPolicy is not set, the default value is `Always`. RestartPolicy applies to all containers in the pod. RestartPolicy only refers to restarts of the containers by the Kubelet on the same node. Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x ... capped at 5 minutes and is reset after 10 minutes of successful execution. As discussed in the [pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), once bound to a node, a pod will never be rebound to another node. This means that some kind of controller is necessary in order for a pod to survive node failure, even if just a single pod at a time is desired. - -Three types of controllers are currently available: - -- Use a [`Job`](/docs/user-guide/jobs/) for pods which are expected to terminate (e.g. batch computations). -- Use a [`ReplicationController`](/docs/user-guide/replication-controller/) or [`Deployment`](/docs/user-guide/deployments/) - for pods which are not expected to terminate (e.g. web servers). -- Use a [`DaemonSet`](/docs/admin/daemons/): Use for pods which need to run 1 per machine because they provide a - machine-specific system service. -If you are unsure whether to use ReplicationController or Daemon, then see [Daemon Set versus -Replication Controller](/docs/admin/daemons/#daemon-set-versus-replication-controller). - -`ReplicationController` is *only* appropriate for pods with `RestartPolicy = Always`. -`Job` is *only* appropriate for pods with `RestartPolicy` equal to `OnFailure` or `Never`. - -All 3 types of controllers contain a PodTemplate, which has all the same fields as a Pod. -It is recommended to create the appropriate controller and let it create pods, rather than to -directly create pods yourself. That is because pods alone are not resilient to machine failures, -but Controllers are. - -## Pod lifetime - -In general, pods which are created do not disappear until someone destroys them. This might be a human or a `ReplicationController`, or another controller. The only exception to this rule is that pods with a `PodPhase` of `Succeeded` or `Failed` for more than some duration (determined by the master) will expire and be automatically reaped. - -If a node dies or is disconnected from the rest of the cluster, some entity within the system (call it the NodeController for now) is responsible for applying policy (e.g. a timeout) and marking any pods on the lost node as `Failed`. - -## Examples - -### Advanced livenessProbe example - -Liveness probes are executed by `kubelet`, so all requests will be made within kubelet network namespace. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - test: liveness - name: liveness-http -spec: - containers: - - args: - - /server - image: gcr.io/google_containers/liveness - livenessProbe: - httpGet: - # when "host" is not defined, "PodIP" will be used - # host: my-host - # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness -``` - -### Example states - - * Pod is `Running`, 1 container, container exits success - * Log completion event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: pod becomes `Succeeded` - * Never: pod becomes `Succeeded` - - * Pod is `Running`, 1 container, container exits failure - * Log failure event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: pod becomes `Failed` - - * Pod is `Running`, 2 containers, container 1 exits failure - * Log failure event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: pod stays `Running` - * When container 2 exits... - * Log failure event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: pod becomes `Failed` - - * Pod is `Running`, container becomes OOM - * Container terminates in failure - * Log OOM event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: log failure event, pod becomes `Failed` - - * Pod is `Running`, a disk dies - * All containers are killed - * Log appropriate event - * Pod becomes `Failed` - * If running under a controller, pod will be recreated elsewhere - - * Pod is `Running`, its node is segmented out - * NodeController waits for timeout - * NodeController marks pod `Failed` - * If running under a controller, pod will be recreated elsewhere +{% include user-guide-content-moved.md %} +[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) From f3487280605588e31fa6b69480b5a8f1013aee72 Mon Sep 17 00:00:00 2001 From: foxish Date: Wed, 15 Feb 2017 16:06:49 -0800 Subject: [PATCH 025/213] Fix travis and add comments --- .travis.yml | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index d05639d195..b0a565803c 100644 --- a/.travis.yml +++ b/.travis.yml @@ -7,9 +7,17 @@ install: - export PATH=$GOPATH/bin:$PATH - mkdir -p $HOME/gopath/src/k8s.io - mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/kubernetes.github.io + +# (1) Fetch dependencies for us to run the tests in test/examples_test.go - go get -t -v k8s.io/kubernetes.github.io/test -- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check -- go get -t -v k8s.io/md-check + +# The dependencies are complicated for test/examples_test.go +# k8s.io/kubernetes/pkg is a dependency, which in turn depends on apimachinery +# but we also have apimachinery directly as one of our dependencies, which causes a conflict. +# Additionally, we get symlinks when we clone the directory. The below steps do the following: + +# (a) Replace the symlink with the actual dependencies from kubernetes/staging/src/ +# (b) copy all the vendored files to $GOPATH/src - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apimachinery - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go @@ -18,6 +26,12 @@ install: - cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ - rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* - cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ + +# (2) Fetch md-check along with all its dependencies. +- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check +- go get -t -v k8s.io/md-check + +# (3) Fetch mungedocs - go get -v k8s.io/kubernetes/cmd/mungedocs script: From 2e3758381d7a2dbec084939898366d6879f02c96 Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Mon, 13 Feb 2017 15:03:37 -0800 Subject: [PATCH 026/213] Move Guide toic to Tasks: kubectl exec. --- _data/tasks.yml | 1 + .../kubectl/get-shell-running-container.md | 148 ++++++++++++++++++ docs/tasks/kubectl/shell-demo.yaml | 14 ++ docs/user-guide/getting-into-containers.md | 68 +------- 4 files changed, 165 insertions(+), 66 deletions(-) create mode 100644 docs/tasks/kubectl/get-shell-running-container.md create mode 100644 docs/tasks/kubectl/shell-demo.yaml diff --git a/_data/tasks.yml b/_data/tasks.yml index cb61b1a05a..6d7cdb921e 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -6,6 +6,7 @@ toc: - title: Using the Kubectl Command-Line section: - docs/tasks/kubectl/list-all-running-container-images.md + - docs/tasks/kubectl/get-shell-running-container.md - title: Configuring Pods and Containers section: diff --git a/docs/tasks/kubectl/get-shell-running-container.md b/docs/tasks/kubectl/get-shell-running-container.md new file mode 100644 index 0000000000..a005f3e0fe --- /dev/null +++ b/docs/tasks/kubectl/get-shell-running-container.md @@ -0,0 +1,148 @@ +--- +assignees: +- caesarxuchao +- mikedanese +title: Getting a Shell to a Running Container +--- + +{% capture overview %} + +This page shows how to use `kubectl exec` to get a shell to a +running Container. + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + + +{% capture steps %} + +## Getting a shell to a Container + +In this exercise, you create a Pod that has one Container. The Container +runs the nginx image. Here is the configuration file for the Pod: + +{% include code.html language="yaml" file="shell-demo.yaml" ghlink="/docs/tasks/kubectl/shell-demo.yaml" %} + +Create the Pod: + +```shell +kubectl create -f https://k8s.io/docs/tasks/kubectl/shell-demo.yaml +``` + +Verify that the Container is running: + +```shell +kubectl get pod shell-demo +``` + +Get a shell to the running Container: + +```shell +kubectl exec -it shell-demo -- /bin/bash +``` + +In your shell, list the running processes: + +```shell +root@shell-demo:/# ps aux +``` + +In your shell, list the nginx processes: + +```shell +root@shell-demo:/# ps aux | grep nginx +``` + +In your shell, experiment with other commands. Here are +some examples: + +```shell +root@shell-demo:/# ls / +root@shell-demo:/# cat /proc/mounts +root@shell-demo:/# cat /proc/1/maps +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install tcpdump +root@shell-demo:/# tcpdump +root@shell-demo:/# apt-get install lsof +root@shell-demo:/# lsof +``` + +## Writing the root page for nginx + +Look again at the configuration file for your Pod. The Pod +has an `emptyDir` volume, and the Container mounts the volume +at `/usr/share/nginx/html`. + +In your shell, create an `index.html` file in the `/usr/share/nginx/html` +directory: + +```shell +root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +``` + +In your shell, send a GET request to the nginx server: + +```shell +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install curl +root@shell-demo:/# curl localhost +``` + +The output shows the text that you wrote to the `index.html` file: + +```shell +Hello shell demo +``` + +When you are finished with your shell, enter `exit`. + +## Running individual commands in a Container + +In an ordinary command window, not your shell, list the environment +variables in the running Container: + +```shell +kubectl exec shell-demo env +``` + +Experiment running other commands. Here are some examples: + +```shell +kubectl exec shell-demo ps aux +kubectl exec shell-demo ls / +kubectl exec shell-demo cat /proc/1/mounts +``` + +{% endcapture %} + +{% capture discussion %} + +## Opening a shell when a Pod has more than one Container + +If a Pod has more than one Container, use `--container` or `-c` to +specify a Container in the `kubectl exec` command. For example, +suppose you have a Pod named my-pod, and the Pod has two containers +named main-app and helper-app. The following command would open a +shell to the main-app Container. + +```shell +kubectl exec -it my-pod --container main-app -- /bin/bash +``` + +{% endcapture %} + + +{% capture whatsnext %} + +* [kubectl exec](/docs/user-guide/kubectl/v1.5/#exec) + +{% endcapture %} + + +{% include templates/task.md %} diff --git a/docs/tasks/kubectl/shell-demo.yaml b/docs/tasks/kubectl/shell-demo.yaml new file mode 100644 index 0000000000..2a7d274a64 --- /dev/null +++ b/docs/tasks/kubectl/shell-demo.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: shell-demo +spec: + volumes: + - name: shared-data + emptyDir: {} + containers: + - name: nginx + image: nginx + volumeMounts: + - name: shared-data + mountPath: /usr/share/nginx/html diff --git a/docs/user-guide/getting-into-containers.md b/docs/user-guide/getting-into-containers.md index bf6a5a8a2f..ff89f111f6 100644 --- a/docs/user-guide/getting-into-containers.md +++ b/docs/user-guide/getting-into-containers.md @@ -5,70 +5,6 @@ assignees: title: Running Commands in a Container with kubectl exec --- -Developers can use `kubectl exec` to run commands in a container. This guide demonstrates two use cases. +{% include user-guide-content-moved.md %} -## Using kubectl exec to check the environment variables of a container - -Kubernetes exposes [services](/docs/user-guide/services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`. - -We first create a pod and a service, - -```shell -$ kubectl create -f examples/guestbook/redis-master-controller.yaml -$ kubectl create -f examples/guestbook/redis-master-service.yaml -``` -wait until the pod is Running and Ready, - -```shell -$ kubectl get pod -NAME READY REASON RESTARTS AGE -redis-master-ft9ex 1/1 Running 0 12s -``` - -then we can check the environment variables of the pod, - -```shell -$ kubectl exec redis-master-ft9ex env -... -REDIS_MASTER_SERVICE_PORT=6379 -REDIS_MASTER_SERVICE_HOST=10.0.0.219 -... -``` - -We can use these environment variables in applications to find the service. - - -## Using kubectl exec to check the mounted volumes - -It is convenient to use `kubectl exec` to check if the volumes are mounted as expected. -We first create a Pod with a volume mounted at /data/redis, - -```shell -kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml -``` - -wait until the pod is Running and Ready, - -```shell -$ kubectl get pods -NAME READY REASON RESTARTS AGE -storage 1/1 Running 0 1m -``` - -we then use `kubectl exec` to verify that the volume is mounted at /data/redis, - -```shell -$ kubectl exec storage ls /data -redis -``` - -## Using kubectl exec to open a bash terminal in a pod - -After all, open a terminal in a pod is the most direct way to introspect the pod. Assuming the pod/storage is still running, run - -```shell -$ kubectl exec -ti storage -- bash -root@storage:/data# -``` - -This gets you a terminal. \ No newline at end of file +[Getting a Shell to a Running Container](/docs/tasks/kubectl/get-shell-running-container/) From ed63f9a8ce3f40c088cde8b172d4119e6a5c5134 Mon Sep 17 00:00:00 2001 From: "Jorge O. Castro" Date: Thu, 16 Feb 2017 07:44:49 -0500 Subject: [PATCH 027/213] Let's put kubectl in ~/bin. --- docs/getting-started-guides/ubuntu/installation.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/getting-started-guides/ubuntu/installation.md b/docs/getting-started-guides/ubuntu/installation.md index cc93995144..9e3bdd8b2b 100644 --- a/docs/getting-started-guides/ubuntu/installation.md +++ b/docs/getting-started-guides/ubuntu/installation.md @@ -159,15 +159,17 @@ juju scp kubernetes-master/0:config ~/.kube/config Fetch a binary for the architecture you have deployed. If your client is a different architecture you will need to get the appropriate `kubectl` binary -through other means. +through other means. In this example we copy kubectl to `~/bin` for convenience, +by default this should be in your $PATH. ``` -juju scp kubernetes-master/0:kubectl ./kubectl +mkdir -p ~/bin +juju scp kubernetes-master/0:kubectl ~/bin/kubectl ``` Query the cluster: - ./kubectl cluster-info + kubectl cluster-info Output: From 0d9e568d1bd2be06655c857e963abfea9d3236e0 Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Thu, 16 Feb 2017 16:20:08 +0800 Subject: [PATCH 028/213] remove its name from file content --- docs/admin/service-accounts-admin.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/admin/service-accounts-admin.md b/docs/admin/service-accounts-admin.md index 4a31fbeced..0c7b495a10 100644 --- a/docs/admin/service-accounts-admin.md +++ b/docs/admin/service-accounts-admin.md @@ -71,8 +71,9 @@ account. To create additional API tokens for a service account, create a secret of type `ServiceAccountToken` with an annotation referencing the service account, and the controller will update it with a generated token: -```json secret.json: + +```json { "kind": "Secret", "apiVersion": "v1", @@ -100,4 +101,4 @@ kubectl delete secret mysecretname ### Service Account Controller Service Account Controller manages ServiceAccount inside namespaces, and ensures -a ServiceAccount named "default" exists in every active namespace. \ No newline at end of file +a ServiceAccount named "default" exists in every active namespace. From ac44956a7595561f0768b5cf6130d9e183f78496 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Thu, 16 Feb 2017 17:17:54 +0800 Subject: [PATCH 029/213] replace kubernetes.d with kubelet.d replace kubernetes.d with kubelet.d --- docs/admin/static-pods.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/admin/static-pods.md b/docs/admin/static-pods.md index 8c9e482d0d..cacf6e2010 100644 --- a/docs/admin/static-pods.md +++ b/docs/admin/static-pods.md @@ -26,11 +26,11 @@ For example, this is how to start a simple web server as a static pod: [joe@host ~] $ ssh my-node1 ``` -2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubernetes.d/static-web.yaml`: +2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`: ```shell -[root@my-node1 ~] $ mkdir /etc/kubernetes.d/ -[root@my-node1 ~] $ cat </etc/kubernetes.d/static-web.yaml +[root@my-node1 ~] $ mkdir /etc/kubelet.d/ +[root@my-node1 ~] $ cat </etc/kubelet.d/static-web.yaml apiVersion: v1 kind: Pod metadata: @@ -114,11 +114,11 @@ CONTAINER ID IMAGE COMMAND CREATED ... Running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes pods as files appear/disappear in this directory. ```shell -[joe@my-node1 ~] $ mv /etc/kubernetes.d/static-web.yaml /tmp +[joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp [joe@my-node1 ~] $ sleep 20 [joe@my-node1 ~] $ docker ps // no nginx container is running -[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubernetes.d/ +[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubelet.d/ [joe@my-node1 ~] $ sleep 20 [joe@my-node1 ~] $ docker ps CONTAINER ID IMAGE COMMAND CREATED ... From 37a51088f7ba4230c27bbb7c4a2fb1f6a044ae09 Mon Sep 17 00:00:00 2001 From: liangxiaoping Date: Thu, 16 Feb 2017 18:37:34 +0800 Subject: [PATCH 030/213] fix etcd disaster-recovery hyperlink --- docs/admin/etcd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/etcd.md b/docs/admin/etcd.md index 41a3e35ddb..06b0eda07c 100644 --- a/docs/admin/etcd.md +++ b/docs/admin/etcd.md @@ -20,7 +20,7 @@ Data Reliability: for reasonable safety, either etcd needs to be run as a etcd) or etcd's data directory should be located on durable storage (e.g., GCE's persistent disk). In either case, if high availability is required--as it might be in a production cluster--the data directory ought to be [backed up -periodically](https://coreos.com/etcd/docs/2.2.1/admin_guide.html#disaster-recovery), +periodically](https://coreos.com/etcd/docs/latest/op-guide/recovery.html), to reduce downtime in case of corruption. ## Default configuration From 2638f4f0879584c8712dca004374119d13780a16 Mon Sep 17 00:00:00 2001 From: "architect.bian" Date: Thu, 16 Feb 2017 18:43:21 +0800 Subject: [PATCH 031/213] modify typora modify namespace-kube-system to namespace=kube-system --- docs/tasks/administer-cluster/dns-horizontal-autoscaling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md index 069409058a..3d80cc77b2 100644 --- a/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md +++ b/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md @@ -156,7 +156,7 @@ The output is: Verify that the replica count is zero: - kubectl get deployment --namespace-kube-system + kubectl get deployment --namespace=kube-system The output displays 0 in the DESIRED and CURRENT columns: From 0da9c85fd44a643aa39fbbbfb7c01f0977866d03 Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Thu, 16 Feb 2017 12:59:54 -0800 Subject: [PATCH 032/213] Move Guide topic to Tasks: Downward API (#2439) --- _data/tasks.yml | 1 + .../dapi-volume-resources.yaml | 54 ++++ .../configure-pod-container/dapi-volume.yaml | 39 +++ ...nward-api-volume-expose-pod-information.md | 242 ++++++++++++++++++ ...ronment-variable-expose-pod-information.md | 12 + docs/tasks/index.md | 3 + 6 files changed, 351 insertions(+) create mode 100644 docs/tasks/configure-pod-container/dapi-volume-resources.yaml create mode 100644 docs/tasks/configure-pod-container/dapi-volume.yaml create mode 100644 docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md diff --git a/_data/tasks.yml b/_data/tasks.yml index 6d7cdb921e..5dae817f8e 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -16,6 +16,7 @@ toc: - docs/tasks/configure-pod-container/configure-volume-storage.md - docs/tasks/configure-pod-container/configure-persistent-volume-storage.md - docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md + - docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md - docs/tasks/configure-pod-container/distribute-credentials-secure.md - docs/tasks/configure-pod-container/pull-image-private-registry.md - docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md diff --git a/docs/tasks/configure-pod-container/dapi-volume-resources.yaml b/docs/tasks/configure-pod-container/dapi-volume-resources.yaml new file mode 100644 index 0000000000..65770f283f --- /dev/null +++ b/docs/tasks/configure-pod-container/dapi-volume-resources.yaml @@ -0,0 +1,54 @@ +apiVersion: v1 +kind: Pod +metadata: + name: kubernetes-downwardapi-volume-example-2 +spec: + containers: + - name: client-container + image: gcr.io/google_containers/busybox:1.24 + command: ["sh", "-c"] + args: + - while true; do + echo -en '\n'; + if [[ -e /etc/cpu_limit ]]; then + echo -en '\n'; cat /etc/cpu_limit; fi; + if [[ -e /etc/cpu_request ]]; then + echo -en '\n'; cat /etc/cpu_request; fi; + if [[ -e /etc/mem_limit ]]; then + echo -en '\n'; cat /etc/mem_limit; fi; + if [[ -e /etc/mem_request ]]; then + echo -en '\n'; cat /etc/mem_request; fi; + sleep 5; + done; + resources: + requests: + memory: "32Mi" + cpu: "125m" + limits: + memory: "64Mi" + cpu: "250m" + volumeMounts: + - name: podinfo + mountPath: /etc + readOnly: false + volumes: + - name: podinfo + downwardAPI: + items: + - path: "cpu_limit" + resourceFieldRef: + containerName: client-container + resource: limits.cpu + - path: "cpu_request" + resourceFieldRef: + containerName: client-container + resource: requests.cpu + - path: "mem_limit" + resourceFieldRef: + containerName: client-container + resource: limits.memory + - path: "mem_request" + resourceFieldRef: + containerName: client-container + resource: requests.memory + diff --git a/docs/tasks/configure-pod-container/dapi-volume.yaml b/docs/tasks/configure-pod-container/dapi-volume.yaml new file mode 100644 index 0000000000..7126cefae5 --- /dev/null +++ b/docs/tasks/configure-pod-container/dapi-volume.yaml @@ -0,0 +1,39 @@ +apiVersion: v1 +kind: Pod +metadata: + name: kubernetes-downwardapi-volume-example + labels: + zone: us-est-coast + cluster: test-cluster1 + rack: rack-22 + annotations: + build: two + builder: john-doe +spec: + containers: + - name: client-container + image: gcr.io/google_containers/busybox + command: ["sh", "-c"] + args: + - while true; do + if [[ -e /etc/labels ]]; then + echo -en '\n\n'; cat /etc/labels; fi; + if [[ -e /etc/annotations ]]; then + echo -en '\n\n'; cat /etc/annotations; fi; + sleep 5; + done; + volumeMounts: + - name: podinfo + mountPath: /etc + readOnly: false + volumes: + - name: podinfo + downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "annotations" + fieldRef: + fieldPath: metadata.annotations + diff --git a/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md b/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md new file mode 100644 index 0000000000..a55d22f387 --- /dev/null +++ b/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md @@ -0,0 +1,242 @@ +--- +title: Exposing Pod Information to Containers Using a DownwardApiVolumeFile +--- + +{% capture overview %} + +This page shows how a Pod can use a DownwardAPIVolumeFile to expose information +about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose +Pod fields and Container fields. + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + +{% capture steps %} + +## The Downward API + +There are two ways to expose Pod and Container fields to a running Container: + +* [Environment variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/) +* DownwardAPIVolumeFiles + +Together, these two ways of exposing Pod and Container fields are called the +*Downward API*. + +## Storing Pod fields + +In this exercise, you create a Pod that has one Container. +Here is the configuration file for the Pod: + +{% include code.html language="yaml" file="dapi-volume.yaml" ghlink="/docs/tasks/configure-pod-container/dapi-volume.yaml" %} + +In the configuration file, you can see that the Pod has a `downwardAPI` Volume, +and the Container mounts the Volume at `/etc`. + +Look at the `items` array under `downwardAPI`. Each element of the array is a +[DownwardAPIVolumeFile](/docs/resources-reference/v1.5/#downwardapivolumefile-v1). +The first element specifies that the value of the Pod's +`metadata.labels` field should be stored in a file named `labels`. +The second element specifies that the value of the Pod's `annotations` +field should be stored in a file named `annotations`. + +**Note**: The fields in this example are Pod fields. They are not +fields of the Container in the Pod. + +Create the Pod: + +```shell +kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/dapi-volume.yaml +``` + +Verify that Container in the Pod is running: + +```shell +kubectl get pods +``` + +View the Container's logs: + +```shell +kubectl logs kubernetes-downwardapi-volume-example +``` + +The output shows the contents of the `labels` file and the `annotations` file: + +```shell +cluster="test-cluster1" +rack="rack-22" +zone="us-est-coast" + +build="two" +builder="john-doe" +``` + +Get a shell into the Container that is running in your Pod: + +``` +kubectl exec -it kubernetes-downwardapi-volume-example -- sh +``` + +In your shell, view the `labels` file: + +```shell +/# cat /etc/labels +``` + +The output shows that all of the Pod's labels have been written +to the `labels` file: + +```shell +cluster="test-cluster1" +rack="rack-22" +zone="us-est-coast" +``` + +Similarly, view the `annotations` file: + +```shell +/# cat /etc/annotations +``` + +View the files in the `/etc` directory: + +```shell +/# ls -laR /etc +``` + +In the output, you can see that the `labels` and `annotations` files +are in a temporary subdirectory: in this example, +`..2982_06_02_21_47_53.299460680`. In the `/etc` directory, `..data` is +a symbolic link to the temporary subdirectory. Also in the `/etc` directory, +`labels` and `annotations` are symbolic links. + +``` +drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680 +lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680 +lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations +lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels + +/etc/..2982_06_02_21_47_53.299460680: +total 8 +-rw-r--r-- ... Feb 6 21:47 annotations +-rw-r--r-- ... Feb 6 21:47 labels +``` + +Using symbolic links enables dynamic atomic refresh of the metadata; updates are +written to a new temporary directory, and the `..data` symlink is updated +atomically using +[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html). + +Exit the shell: + +```shell +/# exit +``` + +## Storing Container fields + +The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile. +In this next exercise, you store Container fields. Here is the configuration +file for a Pod that has one Container: + +{% include code.html language="yaml" file="dapi-volume-resources.yaml" ghlink="/docs/tasks/configure-pod-container/dapi-volume-resources.yaml" %} + +In the configuration file, you can see that the Pod has a `downwardAPI` Volume, +and the Container mounts the Volume at `/etc`. + +Look at the `items` array under `downwardAPI`. Each element of the array is a +DownwardAPIVolumeFile. + +The first element specifies that in the Container named `client-container`, +the value of the `limits.cpu` field +`metadata.labels` field should be stored in a file named `cpu_limit`. + +Create the Pod: + +```shell +kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/dapi-volume-resources.yaml +``` + +Get a shell into the Container that is running in your Pod: + +``` +kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh +``` + +In your shell, view the `cpu_limit` file: + +```shell +/# cat /etc/cpu_limit +``` +You can use similar commands to view the `cpu_request`, `mem_limit` and +`mem_request` files. + +{% endcapture %} + +{% capture discussion %} + +## Capabilities of the Downward API + +The following information is available to Containers through environment +variables and DownwardAPIVolumeFiles: + +* The node’s name +* The Pod’s name +* The Pod’s namespace +* The Pod’s IP address +* The Pod’s service account name +* A Container’s CPU limit +* A container’s CPU request +* A Container’s memory limit +* A Container’s memory request + +In addition, the following information is available through +DownwardAPIVolumeFiles. + +* The Pod's labels +* The Pod's annotations + +**Note**: If CPU and memory limits are not specified for a Container, the +Downward API defaults to the node allocatable value for CPU and memory. + +## Projecting keys to specific paths and file permissions + +You can project keys to specific paths and specific permissions on a per-file +basis. For more information, see +[Secrets](/docs/user-guide/secrets/). + +## Motivation for the Downward API + +It is sometimes useful for a Container to have information about itself, without +being overly coupled to Kubernetes. The Downward API allows containers to consume +information about themselves or the cluster without using the Kubernetes client +or API server. + +An example is an existing application that assumes a particular well-known +environment variable holds a unique identifier. One possibility is to wrap the +application, but that is tedious and error prone, and it violates the goal of low +coupling. A better option would be to use the Pod's name as an identifier, and +inject the Pod's name into the well-known environment variable. + +{% endcapture %} + + +{% capture whatsnext %} + +* [PodSpec](/docs/resources-reference/v1.5/#podspec-v1) +* [Volume](/docs/resources-reference/v1.5/#volume-v1) +* [DownwardAPIVolumeSource](/docs/resources-reference/v1.5/#downwardapivolumesource-v1) +* [DownwardAPIVolumeFile](/docs/resources-reference/v1.5/#downwardapivolumefile-v1) +* [ResourceFieldSelector](/docs/resources-reference/v1.5/#resourcefieldselector-v1) + +{% endcapture %} + +{% include templates/task.md %} + diff --git a/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md b/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md index 1390727000..10ac238c5e 100644 --- a/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md +++ b/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md @@ -26,6 +26,17 @@ Together, these two ways of exposing Pod and Container fields are called the {% capture steps %} +## The Downward API + +There are two ways to expose Pod and Container fields to a running Container: + +* Environment variables +* [DownwardAPIVolumeFiles](/docs/resources-reference/v1.5/#downwardapivolumefile-v1) + +Together, these two ways of exposing Pod and Container fields are called the +*Downward API*. + + ## Using Pod fields as values for environment variables In this exercise, you create a Pod that has one Container. Here is the @@ -161,3 +172,4 @@ The output shows the values of selected environment variables: {% include templates/task.md %} + diff --git a/docs/tasks/index.md b/docs/tasks/index.md index 39f81c6751..d490fe5532 100644 --- a/docs/tasks/index.md +++ b/docs/tasks/index.md @@ -12,6 +12,8 @@ single thing, typically by giving a short sequence of steps. * [Defining a Command and Arguments for a Container](/docs/tasks/configure-pod-container/define-command-argument-container/) * [Assigning CPU and RAM Resources to a Container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) * [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/) +* [Exposing Pod Information to Containers Through Environment Variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/) +* [Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) * [Distributing Credentials Securely](/docs/tasks/configure-pod-container/distribute-credentials-secure/) * [Pulling an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry/) * [Configuring Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) @@ -55,3 +57,4 @@ single thing, typically by giving a short sequence of steps. If you would like to write a task page, see [Creating a Documentation Pull Request](/docs/contribute/create-pull-request/). + From 05c1dfe76c4b182d706954eba6ef8846d3018bc7 Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Thu, 16 Feb 2017 13:20:48 -0800 Subject: [PATCH 033/213] Add note about moved content. (#2563) --- docs/user-guide/downward-api/index.md | 135 +------------------ docs/user-guide/downward-api/volume/index.md | 116 +--------------- 2 files changed, 4 insertions(+), 247 deletions(-) diff --git a/docs/user-guide/downward-api/index.md b/docs/user-guide/downward-api/index.md index 33b2b06c49..beb1cddd9b 100644 --- a/docs/user-guide/downward-api/index.md +++ b/docs/user-guide/downward-api/index.md @@ -5,137 +5,6 @@ assignees: title: Using the Downward API to Convey Pod Properties --- -It is sometimes useful for a container to have information about itself, but we -want to be careful not to over-couple containers to Kubernetes. The downward -API allows containers to consume information about themselves or the system and -expose that information how they want it, without necessarily coupling to the -Kubernetes client or REST API. +{% include user-guide-content-moved.md %} -An example of this is a "legacy" app that is already written assuming -that a particular environment variable will hold a unique identifier. While it -is often possible to "wrap" such applications, this is tedious and error prone, -and violates the goal of low coupling. Instead, the user should be able to use -the Pod's name, for example, and inject it into this well-known variable. - - -## Capabilities - -The following information is available to a `Pod` through the downward API: - -* The node's name -*   The pod's name -* The pod's namespace -* The pod's IP -* The pod's service account name -* A container's cpu limit -* A container's cpu request -* A container's memory limit -* A container's memory request - -More information will be exposed through this same API over time. - - -## Exposing pod information into a container - -Containers consume information from the downward API using environment -variables or using a volume plugin. - - -## Environment variables - -Most environment variables in the Kubernetes API use the `value` field to carry -simple values. However, the alternate `valueFrom` field allows you to specify -a `fieldRef` to select fields from the pod's definition, and a `resourceFieldRef` -to select fields from one of its container's definition. - -The `fieldRef` field is a structure that has an `apiVersion` field and a `fieldPath` -field. The `fieldPath` field is an expression designating a field of the pod. The -`apiVersion` field is the version of the API schema that the `fieldPath` is -written in terms of. If the `apiVersion` field is not specified it is -defaulted to the API version of the enclosing object. - -The `fieldRef` is evaluated and the resulting value is used as the value for -the environment variable. This allows users to publish their pod's name in any -environment variable they want. - -The `resourceFieldRef` is a structure that has a `containerName` field, a `resource` -field, and a `divisor` field. The `containerName` is the name of a container, -whose resource (cpu or memory) information is to be exposed. The `containerName` is -optional for environment variables and defaults to the current container. The -`resource` field is an expression designating a resource in a container, and the `divisor` -field specifies an output format of the resource being exposed. If the `divisor` -is not specified, it defaults to "1" for cpu and memory. The table shows possible -values for cpu and memory resources for `resource` and `divisor` settings: - - -| Setting | Cpu | Memory | -| ------------- |-------------| -----| -| resource | limits.cpu, requests.cpu| limits.memory, requests.memory| -| divisor | 1(cores), 1m(millicores) | 1(bytes), 1k(kilobytes), 1M(megabytes), 1G(gigabytes), 1T(terabytes), 1P(petabytes), 1E(exabytes), 1Ki(kibibyte), 1Mi(mebibyte), 1Gi(gibibyte), 1Ti(tebibyte), 1Pi(pebibyte), 1Ei(exbibyte)| - - -### Example - -This is an example of a pod that consumes its name and namespace via the -downward API: - -{% include code.html language="yaml" file="dapi-pod.yaml" ghlink="/docs/user-guide/downward-api/dapi-pod.yaml" %} - -This is an example of a pod that consumes its container's resources via the downward API: - -{% include code.html language="yaml" file="dapi-container-resources.yaml" ghlink="/docs/user-guide/downward-api/dapi-container-resources.yaml" %} - -## Downward API volume - -Using a similar syntax it's possible to expose pod information to containers using plain text files. -Downward API are dumped to a mounted volume. This is achieved using a `downwardAPI` -volume type and the different items represent the files to be created. `fieldPath` references the field to be exposed. -For exposing a container's resources limits and requests, `containerName` must be specified with `resourceFieldRef`. - -Downward API volume permits to store more complex data like [`metadata.labels`](/docs/user-guide/labels) and [`metadata.annotations`](/docs/user-guide/annotations). Currently key/value pair set fields are saved using `key="value"` format: - -```conf -key1="value1" -key2="value2" -``` - -In future, it will be possible to specify an output format option. - -Downward API volumes can expose: - -* The node's name -* The pod's name -* The pod's namespace -* The pod's labels -* The pod's annotations -* The pod's service account name -* A container's cpu limit -* A container's cpu request -* A container's memory limit -* A container's memory request - -The downward API volume refreshes its data in step with the kubelet refresh loop. When labels will be modifiable on the fly without respawning the pod containers will be able to detect changes through mechanisms such as [inotify](https://en.wikipedia.org/wiki/Inotify). - -In future, it will be possible to specify a specific annotation or label. - -#### Projecting keys to specific paths and file permissions - -You can project keys to specific paths and specific permissions on a per-file -basis. The [Secrets](/docs/user-guide/secrets/) user guide explains the syntax. - -### Example - -This is an example of a pod that consumes its labels and annotations via the downward API volume, labels and annotations are dumped in `/etc/labels` and in `/etc/annotations`, respectively: - -{% include code.html language="yaml" file="volume/dapi-volume.yaml" ghlink="/docs/user-guide/downward-api/volume/dapi-volume.yaml" %} - -This is an example of a pod that consumes its container's resources via the downward API volume. - -{% include code.html language="yaml" file="volume/dapi-volume-resources.yaml" ghlink="/docs/user-guide/downward-api/volume/dapi-volume-resources.yaml" %} - -For a more thorough example, see -[environment variables](/docs/user-guide/environment-guide/). - -## Default values for container resource limits - -If cpu and memory limits are not specified for a container, the downward API will default to the node allocatable value for cpu and memory. +[Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) diff --git a/docs/user-guide/downward-api/volume/index.md b/docs/user-guide/downward-api/volume/index.md index 882b2da1e9..6f359cc797 100644 --- a/docs/user-guide/downward-api/volume/index.md +++ b/docs/user-guide/downward-api/volume/index.md @@ -2,118 +2,6 @@ title: Downward API Volumes --- -Following this example, you will create a pod with a downward API volume. -A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be for example some [metadata](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#metadata) or a container's [resources](/docs/user-guide/compute-resources). +{% include user-guide-content-moved.md %} -Supported metadata fields: - -1. `metadata.annotations` -2. `metadata.namespace` -3. `metadata.name` -4. `metadata.labels` - -Supported container's resources: - -1. `limits.cpu` -2. `limits.memory` -3. `requests.cpu` -4. `requests.memory` - -### Step Zero: Prerequisites - -This example assumes you have a Kubernetes cluster installed and running, and the `kubectl` command line tool somewhere in your path. Please see the [gettingstarted](/docs/getting-started-guides/) for installation instructions for your platform. - -### Step One: Create the pod - -Use the [dapi-volume.yaml](/docs/user-guide/downward-api/volume/dapi-volume.yaml) file to create a Pod with a downward API volume which stores pod labels and pod annotations to `/etc/labels` and `/etc/annotations` respectively. - -```shell -$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume.yaml -``` - -### Step Two: Examine pod/container output - -The pod displays (every 5 seconds) the content of the dump files which can be executed via the usual `kubectl log` command - -```shell -$ kubectl logs kubernetes-downwardapi-volume-example -cluster="test-cluster1" -rack="rack-22" -zone="us-est-coast" -build="two" -builder="john-doe" -kubernetes.io/config.seen="2015-08-24T13:47:23.432459138Z" -kubernetes.io/config.source="api" -``` - -### Internals - -In pod's `/etc` directory one may find the file created by the plugin (system files elided): - -```shell -$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh -/ # ls -laR /etc -/etc: -total 4 -drwxrwxrwt 3 0 0 120 Jun 1 19:55 . -drwxr-xr-x 17 0 0 4096 Jun 1 19:55 .. -drwxr-xr-x 2 0 0 80 Jun 1 19:55 ..6986_01_06_15_55_10.473583074 -lrwxrwxrwx 1 0 0 31 Jun 1 19:55 ..data -> ..6986_01_06_15_55_10.473583074 -lrwxrwxrwx 1 0 0 18 Jun 1 19:55 annotations -> ..data/annotations -lrwxrwxrwx 1 0 0 13 Jun 1 19:55 labels -> ..data/labels - -/etc/..6986_01_06_15_55_10.473583074: -total 8 -drwxr-xr-x 2 0 0 80 Jun 1 19:55 . -drwxrwxrwt 3 0 0 120 Jun 1 19:55 .. --rw-r--r-- 1 0 0 129 Jun 1 19:55 annotations --rw-r--r-- 1 0 0 59 Jun 1 19:55 labels -/ # -``` - -The file `labels` is stored in a temporary directory (`..6986_01_06_15_55_10.473583074` in the example above) which is symlinked to by `..data`. Symlinks for annotations and labels in `/etc` point to files containing the actual metadata through the `..data` indirection.  This structure allows for dynamic atomic refresh of the metadata: updates are written to a new temporary directory, and the `..data` symlink is updated atomically using `rename(2)`. - -## Example of downward API volume with container resources - -Use the `docs/user-guide/downward-api/volume/dapi-volume-resources.yaml` file to create a Pod with a downward API volume which stores its container's limits and requests in /etc. - -```shell -$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume-resources.yaml -``` - -### Examine pod/container output - -In pod's `/etc` directory one may find the files created by the plugin: - -```shell -$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh -/ # ls -alR /etc -/etc: -total 4 -drwxrwxrwt 3 0 0 160 Jun 1 19:47 . -drwxr-xr-x 17 0 0 4096 Jun 1 19:48 .. -drwxr-xr-x 2 0 0 120 Jun 1 19:47 ..6986_01_06_15_47_23.076909525 -lrwxrwxrwx 1 0 0 31 Jun 1 19:47 ..data -> ..6986_01_06_15_47_23.076909525 -lrwxrwxrwx 1 0 0 16 Jun 1 19:47 cpu_limit -> ..data/cpu_limit -lrwxrwxrwx 1 0 0 18 Jun 1 19:47 cpu_request -> ..data/cpu_request -lrwxrwxrwx 1 0 0 16 Jun 1 19:47 mem_limit -> ..data/mem_limit -lrwxrwxrwx 1 0 0 18 Jun 1 19:47 mem_request -> ..data/mem_request - -/etc/..6986_01_06_15_47_23.076909525: -total 16 -drwxr-xr-x 2 0 0 120 Jun 1 19:47 . -drwxrwxrwt 3 0 0 160 Jun 1 19:47 .. --rw-r--r-- 1 0 0 1 Jun 1 19:47 cpu_limit --rw-r--r-- 1 0 0 1 Jun 1 19:47 cpu_request --rw-r--r-- 1 0 0 8 Jun 1 19:47 mem_limit --rw-r--r-- 1 0 0 8 Jun 1 19:47 mem_request - -/ # cat /etc/cpu_limit -1 -/ # cat /etc/mem_limit -67108864 -/ # cat /etc/cpu_request -1 -/ # cat /etc/mem_request -33554432 -``` +[Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) From d0bdf37c1f84245e8e8e997cfecce84dba2a5f82 Mon Sep 17 00:00:00 2001 From: Guillaume Breton Date: Thu, 16 Feb 2017 18:07:10 +0000 Subject: [PATCH 034/213] Fix typos in running zookeeper article --- docs/tutorials/stateful-application/zookeeper.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md index ba2bb219d6..e31d8e280b 100644 --- a/docs/tutorials/stateful-application/zookeeper.md +++ b/docs/tutorials/stateful-application/zookeeper.md @@ -580,7 +580,7 @@ env: key: purge.interval ``` -The entry point of the container invokes a bash script, `zkConfig.sh`, prior to +The entry point of the container invokes a bash script, `zkGenConfig.sh`, prior to launching the ZooKeeper server process. This bash script generates the ZooKeeper configuration files from the supplied environment variables. @@ -653,7 +653,7 @@ ZK_LOG_DIR=/var/log/zookeeper ### Configuring Logging -One of the files generated by the `zkConfigGen.sh` script controls ZooKeeper's logging. +One of the files generated by the `zkGenConfig.sh` script controls ZooKeeper's logging. ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default, it uses a time and size based rolling file appender for its logging configuration. Get the logging configuration from one of Pods in the `zk` StatefulSet. From 041100bd2a82fc83e496d75beed881b859779e79 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Fri, 17 Feb 2017 16:54:23 +0800 Subject: [PATCH 035/213] fix typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1、column PORTS is missed 2、fix command `kubectl get pods`output --- docs/admin/static-pods.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/admin/static-pods.md b/docs/admin/static-pods.md index cacf6e2010..610da03da7 100644 --- a/docs/admin/static-pods.md +++ b/docs/admin/static-pods.md @@ -72,8 +72,8 @@ When kubelet starts, it automatically starts all pods defined in directory speci ```shell [joe@my-node1 ~] $ docker ps -CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES -f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c ``` If we look at our Kubernetes API server (running on host `my-master`), we see that a new mirror-pod was created there too: @@ -81,9 +81,9 @@ If we look at our Kubernetes API server (running on host `my-master`), we see th ```shell [joe@host ~] $ ssh my-master [joe@my-master ~] $ kubectl get pods -POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE -static-web-my-node1 172.17.0.3 my-node1/192.168.100.71 role=myrole Running 11 minutes - web nginx Running 11 minutes +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 2m + ``` Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering. @@ -94,8 +94,9 @@ Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/ [joe@my-master ~] $ kubectl delete pod static-web-my-node1 pods/static-web-my-node1 [joe@my-master ~] $ kubectl get pods -POD IP CONTAINER(S) IMAGE(S) HOST ... -static-web-my-node1 172.17.0.3 my-node1/192.168.100.71 ... +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 12s + ``` Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while: From 77b4ffa69649769c4a15eb06fc736c6740c71d97 Mon Sep 17 00:00:00 2001 From: jianglingxia Date: Wed, 15 Feb 2017 16:33:38 +0800 Subject: [PATCH 036/213] modify one word examples to example --- docs/user-guide/walkthrough/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/walkthrough/index.md b/docs/user-guide/walkthrough/index.md index d7872b2260..e0400ec7ed 100644 --- a/docs/user-guide/walkthrough/index.md +++ b/docs/user-guide/walkthrough/index.md @@ -9,7 +9,7 @@ title: Kubernetes 101 For Kubernetes 101, we will cover kubectl, pods, volumes, and multiple containers -In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes). +In order for the kubectl usage examples to work, make sure you have an example directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes). * TOC {:toc} From 265a2fc996d3ba79015bd570863a2e6f4ba99722 Mon Sep 17 00:00:00 2001 From: Michael Fraenkel Date: Fri, 17 Feb 2017 08:34:06 -0500 Subject: [PATCH 037/213] Revert "mend" This reverts commit 324451c3378b4ba01d27e3db6117f86d0517a598. --- docs/user-guide/configmap/index.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 40b3fa181b..36d3e89394 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -317,7 +317,10 @@ spec: restartPolicy: Never ``` -When this pod is run, the output will be empty. +When this pod is run, its output will include the lines: + +```shell +``` ### Use-Case: Set command-line arguments with ConfigMap From 4635787521f89c4396c6a82d08d8a92ac89f7a77 Mon Sep 17 00:00:00 2001 From: Michael Fraenkel Date: Fri, 17 Feb 2017 08:34:15 -0500 Subject: [PATCH 038/213] Revert "Document new optional support for ConfigMap and Secret" This reverts commit 7abcc6c8540a7b0a4f6712e77e0f5cb134271bed. --- docs/user-guide/configmap/index.md | 70 ++-------------------------- docs/user-guide/secrets/index.md | 74 +++--------------------------- 2 files changed, 10 insertions(+), 134 deletions(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 36d3e89394..1355e599f2 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -291,37 +291,6 @@ SPECIAL_LEVEL_KEY=very SPECIAL_TYPE_KEY=charm ``` -#### Optional ConfigMap in environment variables - -There might be situations where environment variables are not -always required. These environment variables can be marked as optional in a -pod like so: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: dapi-test-pod -spec: - containers: - - name: test-container - image: gcr.io/google_containers/busybox - command: [ "/bin/sh", "-c", "env" ] - env: - - name: SPECIAL_LEVEL_KEY - valueFrom: - configMapKeyRef: - name: a-config - key: akey - optional: true - restartPolicy: Never -``` - -When this pod is run, its output will include the lines: - -```shell -``` - ### Use-Case: Set command-line arguments with ConfigMap ConfigMaps can also be used to set the value of the command or arguments in a container. This is @@ -453,38 +422,6 @@ very You can project keys to specific paths and specific permissions on a per-file basis. The [Secrets](/docs/user-guide/secrets/) user guide explains the syntax. -#### Optional ConfigMap via volume plugin - -Volumes and files provided by a ConfigMap can be also be marked as optional. -The ConfigMap or the key specified does not have to exist. The mount path for -such items will always be created. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: dapi-test-pod -spec: - containers: - - name: test-container - image: gcr.io/google_containers/busybox - command: [ "/bin/sh", "-c", "ls /etc/config" ] - volumeMounts: - - name: config-volume - mountPath: /etc/config - volumes: - - name: config-volume - configMap: - name: no-config - optional: true - restartPolicy: Never -``` - -When this pod is run, the output will be: - -```shell -``` - ## Real World Example: Configuring Redis Let's take a look at a real-world example: configuring redis using ConfigMap. Say we want to inject @@ -580,10 +517,9 @@ $ kubectl exec -it redis redis-cli ## Restrictions -ConfigMaps must be created before they are consumed in pods unless they are -marked as optional. Controllers may be written to tolerate missing -configuration data; consult individual components configured via ConfigMap on -a case-by-case basis. +ConfigMaps must be created before they are consumed in pods. Controllers may be written to tolerate +missing configuration data; consult individual components configured via ConfigMap on a case-by-case +basis. ConfigMaps reside in a namespace. They can only be referenced by pods in the same namespace. diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md index 9723e00aee..29e9044fde 100644 --- a/docs/user-guide/secrets/index.md +++ b/docs/user-guide/secrets/index.md @@ -375,41 +375,6 @@ However, it is using its local ttl-based cache for getting the current value of As a result, the total delay from the moment when the secret is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of secrets cache in kubelet. -#### Optional Secrets as Files from a Pod - -Volumes and files provided by a Secret can be also be marked as optional. -The Secret or the key within a Secret does not have to exist. The mount path for -such items will always be created. - -```json -{ - "apiVersion": "v1", - "kind": "Pod", - "metadata": { - "name": "mypod", - "namespace": "myns" - }, - "spec": { - "containers": [{ - "name": "mypod", - "image": "redis", - "volumeMounts": [{ - "name": "foo", - "mountPath": "/etc/foo" - }] - }], - "volumes": [{ - "name": "foo", - "secret": { - "secretName": "mysecret", - "defaultMode": 256, - "optional": true - } - }] - } -} -``` - #### Using Secrets as Environment Variables To use a secret in an environment variable in a pod: @@ -456,30 +421,6 @@ $ echo $SECRET_PASSWORD 1f2d1e2e67df ``` -#### Optional Secrets from Environment Variables - -You may not want to require all your secrets to exist. They can be marked as -optional as shown in the pod: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: optional-secret-env-pod -spec: - containers: - - name: mycontainer - image: redis - env: - - name: OPTIONAL_SECRET - valueFrom: - secretKeyRef: - name: mysecret - key: username - optional: true - restartPolicy: Never -``` - #### Using imagePullSecrets An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry @@ -511,8 +452,7 @@ can be automatically attached to pods based on their service account. Secret volume sources are validated to ensure that the specified object reference actually points to an object of type `Secret`. Therefore, a secret -needs to be created before any pods that depend on it, unless it is marked as -optional. +needs to be created before any pods that depend on it. Secret API objects reside in a namespace. They can only be referenced by pods in that same namespace. @@ -532,12 +472,12 @@ not common ways to create pods.) When a pod is created via the API, there is no check whether a referenced secret exists. Once a pod is scheduled, the kubelet will try to fetch the -secret value. If a required secret cannot be fetched because it does not -exist or because of a temporary lack of connection to the API server, the -kubelet will periodically retry. It will report an event about the pod -explaining the reason it is not started yet. Once the secret is fetched, the -kubelet will create and mount a volume containing it. None of the pod's -containers will start until all the pod's volumes are mounted. +secret value. If the secret cannot be fetched because it does not exist or +because of a temporary lack of connection to the API server, kubelet will +periodically retry. It will report an event about the pod explaining the +reason it is not started yet. Once the secret is fetched, the kubelet will +create and mount a volume containing it. None of the pod's containers will +start until all the pod's volumes are mounted. ## Use cases From b01dd765a9c1ea8169c264dc70ed3fee0f9dc73f Mon Sep 17 00:00:00 2001 From: Harry Zhang Date: Sat, 18 Feb 2017 03:06:01 +0800 Subject: [PATCH 039/213] Add kubelet eviction in GC doc (#2484) --- docs/admin/garbage-collection.md | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index a960172426..9717a41dd8 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -42,15 +42,34 @@ to free. Default is 80%. We also allow users to customize garbage collection policy through the following kubelet flags: 1. `minimum-container-ttl-duration`, minimum age for a finished container before it is -garbage collected. Default is 1 minute. +garbage collected. Default is 0 minute, which means any finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to retain -per container. Default is 2. +per container. Default is 1. 3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. -Default is 100. +Default is -1, which means there is no global limit. Containers can potentially be garbage collected before their usefulness has expired. These containers can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for -`maximum-dead-containers-per-container` is highly recommended to allow at least 2 dead containers to be +`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be retained per expected container. A higher value for `maximum-dead-containers` is also recommended for a similar reason. See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. + + +### Deprecation + +Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future. + +Including: + +| Existing Flag | New Flag | Rationale | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` | existing eviction signals can trigger image garbage collection | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | +| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | +| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | +| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources | + +See [kubelet eviction design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/kubelet-eviction.md) for more details. From 180091299beb46a23234e9745a41e857f1e1af54 Mon Sep 17 00:00:00 2001 From: Bruce Auyeung Date: Mon, 20 Feb 2017 10:24:13 +0800 Subject: [PATCH 040/213] dedent yaml code blocks otherwise extra redundant ````yaml` characters will be displayed because github code fencing doesn't need any indentation --- docs/admin/kubeadm.md | 80 +++++++++++++++++++++---------------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index edf9c87a7d..a43beec497 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -180,49 +180,49 @@ available as configuration file options. ### Sample Master Configuration - ```yaml - apiVersion: kubeadm.k8s.io/v1alpha1 - kind: MasterConfiguration - api: - advertiseAddresses: - - - - - bindPort: - externalDNSNames: - - - - - authorizationMode: - cloudProvider: - discovery: - bindPort: - etcd: - endpoints: - - - - - caFile: - certFile: - keyFile: - kubernetesVersion: - networking: - dnsDomain: - serviceSubnet: - podSubnet: - secrets: - givenToken: - ``` +```yaml +apiVersion: kubeadm.k8s.io/v1alpha1 +kind: MasterConfiguration +api: + advertiseAddresses: + - + - + bindPort: + externalDNSNames: + - + - +authorizationMode: +cloudProvider: +discovery: + bindPort: +etcd: + endpoints: + - + - + caFile: + certFile: + keyFile: +kubernetesVersion: +networking: + dnsDomain: + serviceSubnet: + podSubnet: +secrets: + givenToken: +``` ### Sample Node Configuration - ```yaml - apiVersion: kubeadm.k8s.io/v1alpha1 - kind: NodeConfiguration - apiPort: - discoveryPort: - masterAddresses: - - - secrets: - givenToken: - ``` +```yaml +apiVersion: kubeadm.k8s.io/v1alpha1 +kind: NodeConfiguration +apiPort: +discoveryPort: +masterAddresses: +- +secrets: + givenToken: +``` ## Automating kubeadm From abf9560874889fe2b953cf2bda01b833e1280238 Mon Sep 17 00:00:00 2001 From: xuxinkun Date: Fri, 17 Feb 2017 18:19:33 +0800 Subject: [PATCH 041/213] Add more options for self-registration. --- docs/admin/node.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/admin/node.md b/docs/admin/node.md index 0923169256..f91f155919 100644 --- a/docs/admin/node.md +++ b/docs/admin/node.md @@ -176,6 +176,9 @@ For self-registration, the kubelet is started with the following options: - `--kubeconfig=` - Path to credentials to authenticate itself to the apiserver. - `--cloud-provider=` - How to talk to a cloud provider to read metadata about itself. - `--register-node` - Automatically register with the API server. + - `--node-ip` IP address of the node. + - `--node-labels` - Labels to add when registering the node in the cluster. + - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master. Currently, any kubelet is authorized to create/modify any node resource, but in practice it only creates/modifies its own. (In the future, we plan to only allow a kubelet to modify its own node resource.) From 8dd5d7b8adb0494d24a16307853ccefac97122d6 Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Thu, 16 Feb 2017 16:44:45 +0800 Subject: [PATCH 042/213] Parallel Jobs with a *work queue*: do not specify `.spec.completions`, default to `.spec.Parallelism`, not default to 1 --- docs/user-guide/jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index d64ae9d730..438b63dff7 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -120,7 +120,7 @@ There are three main types of jobs: - the job is complete when there is one successful pod for each value in the range 1 to `.spec.completions`. - **not implemented yet:** each pod passed a different index in the range 1 to `.spec.completions`. 1. Parallel Jobs with a *work queue*: - - do not specify `.spec.completions` + - do not specify `.spec.completions`, default to `.spec.Parallelism` - the pods must coordinate with themselves or an external service to determine what each should work on - each pod is independently capable of determining whether or not all its peers are done, thus the entire Job is done. - when _any_ pod terminates with success, no new pods are created. From ab7d2c1b3c703066865192cdf0a4ca06a9119b74 Mon Sep 17 00:00:00 2001 From: Olegs Jeremejevs Date: Tue, 21 Feb 2017 17:48:51 +0200 Subject: [PATCH 043/213] Fix typo in concepts --- 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 93e4533caf..8e738e809e 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -17,7 +17,7 @@ Once you've set your desired state, the *Kubernetes Control Plane* works to make ## Kubernetes Objects -Kubernetes contains a number of abstractions that represent your the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. +Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. The basic Kubernetes objects include: From 03b53f2aa90cd2f7a574f304a39a9e823b0998a4 Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 21 Feb 2017 15:23:24 +0800 Subject: [PATCH 044/213] fix typo --- .../configure-pod-container/pull-image-private-registry.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/pull-image-private-registry.md b/docs/tasks/configure-pod-container/pull-image-private-registry.md index e9b640873a..f54d881178 100644 --- a/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -80,7 +80,7 @@ Copy the base64 representation of the secret data into a file named `secret64`. **Important**: Make sure there are no line breaks in your `secret64` file. -To understand what is in the `dockercfg` field, convert the secret data to a +To understand what is in the `.dockercfg` field, convert the secret data to a readable format: base64 -d secret64 From 27039ac3b6859fe1786b12cf00cf8b3746ee3907 Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 21 Feb 2017 11:52:18 +0800 Subject: [PATCH 045/213] add an example --- docs/concepts/configuration/container-command-args.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/concepts/configuration/container-command-args.md b/docs/concepts/configuration/container-command-args.md index 25d555f702..3f39baff57 100644 --- a/docs/concepts/configuration/container-command-args.md +++ b/docs/concepts/configuration/container-command-args.md @@ -66,6 +66,7 @@ Here are some examples: | `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` | | `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` | | `[/ep-1]` | `[foo bar]` | <not set> | `[zoo boo]` | `[ep-1 zoo boo]` | +| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` | {% endcapture %} From d4c2da211e8b3aa9cd477f5b03813cc6b55a0a94 Mon Sep 17 00:00:00 2001 From: Ben Mathews Date: Fri, 17 Feb 2017 14:39:48 -0700 Subject: [PATCH 046/213] Remove reference to port-forward to services port forwarding to services isn't supported. --- docs/user-guide/kubectl-cheatsheet.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index 7fc0142f04..6b67cba4a0 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -203,7 +203,6 @@ $ kubectl logs -f my-pod -c my-container # stream pod container log $ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell $ kubectl attach my-pod -i # Attach to Running Container $ kubectl port-forward my-pod 5000:6000 # Forward port 6000 of Pod to your to 5000 on your local machine -$ kubectl port-forward my-svc 6000 # Forward port to service $ kubectl exec my-pod -- ls / # Run command in existing pod (1 container case) $ kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case) $ kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers From 58f20b10fa575145f8c10b5e8bbf1656719db8ce Mon Sep 17 00:00:00 2001 From: Guangya Liu Date: Mon, 20 Feb 2017 22:37:54 +0800 Subject: [PATCH 047/213] Fixed typos in persistent volume index.md --- docs/user-guide/persistent-volumes/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 4508a1a25f..e2d2661d13 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -421,7 +421,7 @@ parameters: * `restauthenabled` : Gluster REST service authentication boolean that enables authentication to the REST server. If this value is 'true', `restuser` and `restuserkey` or `secretNamespace` + `secretName` have to be filled. This option is deprecated, authentication is enabled when any of `restuser`, `restuserkey`, `secretName` or `secretNamespace` is specified. * `restuser` : Gluster REST service/Heketi user who has access to create volumes in the Gluster Trusted Pool. * `restuserkey` : Gluster REST service/Heketi user's password which will be used for authentication to the REST server. This parameter is deprecated in favor of `secretNamespace` + `secretName`. -* `secretNamespace` + `secretName` : Identification of Secret instance that containes user password to use when talking to Gluster REST service. These parameters are optional, empty password will be used when both `secretNamespace` and `secretName` are omitted. The provided secret must have type "kubernetes.io/glusterfs", e.g. created in this way: +* `secretNamespace` + `secretName` : Identification of Secret instance that contains user password to use when talking to Gluster REST service. These parameters are optional, empty password will be used when both `secretNamespace` and `secretName` are omitted. The provided secret must have type "kubernetes.io/glusterfs", e.g. created in this way: ``` $ kubectl create secret generic heketi-secret --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' --namespace=default ``` @@ -507,7 +507,7 @@ parameters: * `quobyteAPIServer`: API Server of Quobyte in the format `http(s)://api-server:7860` * `registry`: Quobyte registry to use to mount the volume. You can specify the registry as ``:`` pair or if you want to specify multiple registries you just have to put a comma between them e.q. ``:,:,:``. The host can be an IP address or if you have a working DNS you can also provide the DNS names. * `adminSecretNamespace`: The namespace for `adminSecretName`. Default is "default". -* `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate agains the API server. The provided secret must have type "kubernetes.io/quobyte", e.g. created in this way: +* `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate against the API server. The provided secret must have type "kubernetes.io/quobyte", e.g. created in this way: ``` $ kubectl create secret generic quobyte-admin-secret --type="kubernetes.io/quobyte" --from-literal=key='opensesame' --namespace=kube-system ``` From 74d8327f6dfbef515b1e2246e7c48fdf6d0538cb Mon Sep 17 00:00:00 2001 From: Guangya Liu Date: Mon, 20 Feb 2017 21:29:07 +0800 Subject: [PATCH 048/213] Highlight some keyworks in garbage-collection.md. --- docs/admin/garbage-collection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index 9717a41dd8..8164fbb7d9 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -24,9 +24,9 @@ threshold has been met. ### Container Collection The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers any single -pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting 'MinAge' to zero and setting 'MaxPerPodContainer' and 'MaxContainers' respectively to less than zero. +pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero. -Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. 'MaxPerPodContainer' and 'MaxContainer' may potentially conflict with each other in situations where retaining the maximum number of containers per pod ('MaxPerPodContainer') would go outside the allowable range of global dead containers ('MaxContainers'). 'MaxPerPodContainer' would be adjusted in this situation: A worst case scenario would be to downgrade 'MaxPerPodContainer' to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. +Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`). `MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. Containers that are not managed by kubelet are not subject to container garbage collection. From 960bb03b30b98ee47718950840e45f126f836285 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Sat, 18 Feb 2017 15:14:37 +0800 Subject: [PATCH 049/213] replace argumment with argument replace argumment with argument --- docs/admin/network-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/network-plugins.md b/docs/admin/network-plugins.md index d5e05ac7b1..f06d22fb87 100644 --- a/docs/admin/network-plugins.md +++ b/docs/admin/network-plugins.md @@ -49,7 +49,7 @@ The plugin requires a few things: * The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect. * Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin -* Kubelet should also be run with the `--non-masquerade-cidr=` argumment to ensure traffic to IPs outside this range will use IP masquerade. +* Kubelet should also be run with the `--non-masquerade-cidr=` argument to ensure traffic to IPs outside this range will use IP masquerade. * The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=` controller-manager command-line options. ### Customizing the MTU (with kubenet) From 72c93f9b52e612ec75163e4896ddb4dc9f68de17 Mon Sep 17 00:00:00 2001 From: "Ricardo M. Augusto" Date: Tue, 21 Feb 2017 13:16:27 -0300 Subject: [PATCH 050/213] Updated result of command Actually according to the command in example: kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub The keys will be available with names ssh-publickey and ssh-privatekey. --- docs/user-guide/secrets/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md index 29e9044fde..8b7c7ae2fb 100644 --- a/docs/user-guide/secrets/index.md +++ b/docs/user-guide/secrets/index.md @@ -534,8 +534,8 @@ consumes it in a volume: When the container's command runs, the pieces of the key will be available in: ```shell -/etc/secret-volume/id-rsa.pub -/etc/secret-volume/id-rsa +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey ``` The container is then free to use the secret data to establish an ssh connection. From 60b50187389ab0d9a31075e5e4805e69ae4b6302 Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 21 Feb 2017 16:08:27 +0800 Subject: [PATCH 051/213] replace petset with statefulsets --- docs/user-guide/kubectl-cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index 6b67cba4a0..56f6d71de4 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -243,7 +243,7 @@ Resource type | Abbreviated alias `namespaces` |`ns` `networkpolicies` | `nodes` |`no` -`petset` | +`statefulsets` | `persistentvolumeclaims` |`pvc` `persistentvolumes` |`pv` `pods` |`po` From e82a2e2a58575302ee757d3df81db52316031f0f Mon Sep 17 00:00:00 2001 From: Cao Shufeng Date: Mon, 20 Feb 2017 23:45:50 -0500 Subject: [PATCH 052/213] Remove details about where authenticator is implemented It not necessary to mention where the functions are implemented in document. Further more, the directories recorded here is out of date. Now they are in: staging/src/k8s.io/apiserver/plugin/pkg/authenticator/... --- docs/admin/authentication.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 7c59c955ac..7a7d8f1bc3 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -85,9 +85,9 @@ See [APPENDIX](#appendix) for how to generate a client cert. The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line. Currently, tokens last indefinitely, and the token list cannot be changed without restarting API server. -The token file format is implemented in `plugin/pkg/auth/authenticator/token/tokenfile/...` -and is a csv file with a minimum of 3 columns: token, user name, user uid, followed by -optional group names. Note, if you have more than one group the column must be double quoted e.g. +The token file is a csv file with a minimum of 3 columns: token, user name, user uid, +followed by optional group names. Note, if you have more than one group the column must be +double quoted e.g. ```conf token,user,uid,"group1,group2,group3" @@ -115,9 +115,9 @@ and the password cannot be changed without restarting API server. Note that basi authentication is currently supported for convenience while we finish making the more secure modes described above easier to use. -The basic auth file format is implemented in `plugin/pkg/auth/authenticator/password/passwordfile/...` -and is a csv file with a minimum of 3 columns: password, user name, user id, followed by -optional group names. Note, if you have more than one group the column must be double quoted e.g. +The basic auth file is a csv file with a minimum of 3 columns: password, +user name, user id, followed by optional group names. Note, if you have more than +one group the column must be double quoted e.g. ```conf password,user,uid,"group1,group2,group3" From 91356cfbd23f70faf65094dd203f524e258cac11 Mon Sep 17 00:00:00 2001 From: Alexander Kanevskiy Date: Tue, 21 Feb 2017 20:41:52 +0200 Subject: [PATCH 053/213] Updated description for kubeadm init --kubernetes-version --- docs/admin/kubeadm.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index a43beec497..32bd70812f 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -143,10 +143,11 @@ By default, `kubeadm init` automatically generates the token used to initialise each new node. If you would like to manually specify this token, you can use the `--token` flag. The token must be of the format `<6 character string>.<16 character string>`. -- `--use-kubernetes-version` (default 'v1.5.1') the kubernetes version to initialise +- `--kubernetes-version` (default 'latest') the kubernetes version to initialise `kubeadm` was originally built for Kubernetes version **v1.4.0**, older versions are not -supported. With this flag you can try any future version, e.g. **v1.6.0-beta.1** +supported. The current version of `kubeadm` requires at least **v1.6.0-alpha.3** due to RBAC being enabled by default. +With this flag you can try any future version, e.g. **v1.6.0-beta.1** whenever it comes out (check [releases page](https://github.com/kubernetes/kubernetes/releases) for a full list of available versions). From bd7607a066b2472eb70021f9fbf1d6a1e522fd77 Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 21 Feb 2017 12:35:15 -0800 Subject: [PATCH 054/213] Revert "Updated description for kubeadm init --kubernetes-version" --- docs/admin/kubeadm.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 32bd70812f..a43beec497 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -143,11 +143,10 @@ By default, `kubeadm init` automatically generates the token used to initialise each new node. If you would like to manually specify this token, you can use the `--token` flag. The token must be of the format `<6 character string>.<16 character string>`. -- `--kubernetes-version` (default 'latest') the kubernetes version to initialise +- `--use-kubernetes-version` (default 'v1.5.1') the kubernetes version to initialise `kubeadm` was originally built for Kubernetes version **v1.4.0**, older versions are not -supported. The current version of `kubeadm` requires at least **v1.6.0-alpha.3** due to RBAC being enabled by default. -With this flag you can try any future version, e.g. **v1.6.0-beta.1** +supported. With this flag you can try any future version, e.g. **v1.6.0-beta.1** whenever it comes out (check [releases page](https://github.com/kubernetes/kubernetes/releases) for a full list of available versions). From f1ecafcdb1b251e7416f176d763ee38c95a6b36b Mon Sep 17 00:00:00 2001 From: divyenpatel Date: Fri, 17 Feb 2017 14:58:30 -0800 Subject: [PATCH 055/213] updated vsphere getting started guide addressed review comments addressed chenopis's review comments --- docs/getting-started-guides/vsphere.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/getting-started-guides/vsphere.md b/docs/getting-started-guides/vsphere.md index 61ea733bf3..a22d38609f 100644 --- a/docs/getting-started-guides/vsphere.md +++ b/docs/getting-started-guides/vsphere.md @@ -79,8 +79,7 @@ Sample Config: #### Known issues -* [Volumes are not removed from a VM configuration if the VM is down](https://github.com/kubernetes/kubernetes/issues/33061). The workaround is to manually remove the disk from VM settings before powering it up. -* [FS groups are not supported in 1.4.7](https://github.com/kubernetes/kubernetes/issues/34039) - This issue is fixed in 1.4.8 +* [Unable to execute command on pod container using kubectl exec](https://github.com/kubernetes/kubernetes-anywhere/issues/337) ### Kube-up (Deprecated) @@ -216,7 +215,7 @@ going on (find yourself authorized with your SSH key, or use the password IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu))([@luomiao](https://github.com/luomiao)) +Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu)), ([@luomiao](https://github.com/luomiao)), ([@divyenpatel](https://github.com/divyenpatel)) For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. From a7b66a78a38619f8962bbf3c425141a5919188e3 Mon Sep 17 00:00:00 2001 From: "Elijah C. Voigt" Date: Fri, 17 Feb 2017 17:12:13 -0800 Subject: [PATCH 056/213] concepts/abstractions: init containers example. --- docs/concepts/abstractions/init-containers.md | 94 ++++++++++++++++++- 1 file changed, 93 insertions(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/init-containers.md b/docs/concepts/abstractions/init-containers.md index 1bea00b3a2..89738eef56 100644 --- a/docs/concepts/abstractions/init-containers.md +++ b/docs/concepts/abstractions/init-containers.md @@ -95,6 +95,98 @@ Here are some ideas for how to use Init Containers: More detailed usage examples can be found in the [StatefulSets documentation](/docs/concepts/abstractions/controllers/statefulsets/) and the [Production Pods guide](/docs/user-guide/production-pods.md#handling-initialization). +### Init Containers in use + +The following yaml file outlines a simple Pod which has two Init Containers. +The first waits for `myservice` and the second waits for `mydb`. Once both +containers complete the Pod will begin. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp + annotations: + pod.beta.kubernetes.io/init-containers: '[ + { + "name": "init-myservice", + "image": "busybox", + "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] + }, + { + "name": "init-mydb", + "image": "busybox", + "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] + } + ]' +spec: + containers: + - name: myapp-container + image: busybox + command: ['sh', '-c', 'echo The app is running! && sleep 3600'] +``` + +This Pod can be started and debugged with the following commands: + +``` +$ kubectl create -f myapp.yaml +pod "myapp-pod" created +$ kubectl get -f myapp.yaml +NAME READY STATUS RESTARTS AGE +myapp-pod 0/1 Init:0/2 0 6m +$ kubectl describe -f myapp.yaml +i11:32 $ kubectl describe -f examples/init-container.yaml +Name: myapp-pod +Namespace: default +[...] +Labels: app=myapp +Status: Pending +[...] +Init Containers: + init-myservice: +[...] + State: Running +[...] + init-mydb: +[...] + State: Running +[...] +Containers: + myapp-container: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201 + 16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 +$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container +$ kubectl logs myapp-pod -c init-mydd # Inspect the second init container +``` + +Once we start the `mydb` and `myservice` Services we can see the Init Containers +complete and the `myapp-pod` is created: + +``` +$ kubectl create -f services.yaml +service "myservice" created +service "mydb" created +$ kubectl get -f myapp.yaml +NAME READY STATUS RESTARTS AGE +myapp-pod 1/1 Running 0 9m +``` + +This example is very simple but should provide some inspiration for you to +create your own Init Containers. + ## Detailed behavior During the startup of a Pod, the Init Containers are started in order, after the @@ -181,4 +273,4 @@ Kubelet and Apiserver versions; see the [release notes](https://github.com/kuber {% endcapture %} -{% include templates/concept.md %} \ No newline at end of file +{% include templates/concept.md %} From 13b7c5eb5cfe9c8408db641158a06cf0f5cc06e1 Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Tue, 21 Feb 2017 09:15:27 +0800 Subject: [PATCH 057/213] Update source-ip.md --- docs/tutorials/services/source-ip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md index e1eac87c4e..6366690e88 100644 --- a/docs/tutorials/services/source-ip.md +++ b/docs/tutorials/services/source-ip.md @@ -132,7 +132,7 @@ client_address=10.240.0.5 client_address=10.240.0.3 ``` -Note that these are not your IPs, they're cluster internal IPs. This is what happens: +Note that these are not right client IPs, they're cluster internal IPs. This is what happens: * Client sends packet to `node2:nodePort` * `node2` replaces the source IP address (SNAT) in the packet with its own IP address From 93c5edce64b3a4ac79f9e9da6113bfa7c0a2486a Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Wed, 22 Feb 2017 08:40:09 +0800 Subject: [PATCH 058/213] Update source-ip.md --- docs/tutorials/services/source-ip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md index 6366690e88..4f5f7d884a 100644 --- a/docs/tutorials/services/source-ip.md +++ b/docs/tutorials/services/source-ip.md @@ -132,7 +132,7 @@ client_address=10.240.0.5 client_address=10.240.0.3 ``` -Note that these are not right client IPs, they're cluster internal IPs. This is what happens: +Note that these are not the correct client IPs, they're cluster internal IPs. This is what happens: * Client sends packet to `node2:nodePort` * `node2` replaces the source IP address (SNAT) in the packet with its own IP address From 5095cf60df3381caa356c02a3fa12821163274a6 Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Tue, 21 Feb 2017 19:12:47 -0800 Subject: [PATCH 059/213] Move Guide topic: Garbage Collection. (#2488) --- _data/concepts.yml | 1 + .../controllers/garbage-collection.md | 110 ++++++++++++++++++ .../abstractions/controllers/my-repset.yaml | 17 +++ docs/user-guide/garbage-collection.md | 33 +----- 4 files changed, 130 insertions(+), 31 deletions(-) create mode 100644 docs/concepts/abstractions/controllers/garbage-collection.md create mode 100644 docs/concepts/abstractions/controllers/my-repset.yaml diff --git a/_data/concepts.yml b/_data/concepts.yml index 432f4c86e1..56a556a801 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -20,6 +20,7 @@ toc: - title: Controllers section: - docs/concepts/abstractions/controllers/statefulsets.md + - docs/concepts/abstractions/controllers/garbage-collection.md - title: Object Metadata section: diff --git a/docs/concepts/abstractions/controllers/garbage-collection.md b/docs/concepts/abstractions/controllers/garbage-collection.md new file mode 100644 index 0000000000..889049c1ba --- /dev/null +++ b/docs/concepts/abstractions/controllers/garbage-collection.md @@ -0,0 +1,110 @@ +--- +title: Garbage Collection +--- + +{% capture overview %} + +The role of the Kubernetes garbage collector is to delete certain objects +that once had an owner, but no longer have an owner. + +**Note**: Garbage collection is a beta feature and is enabled by default in +Kubernetes version 1.4 and later. + +{% endcapture %} + + +{% capture body %} + +## Owners and dependents + +Some Kubernetes objects are owners of other objects. For example, a ReplicaSet +is the owner of a set of Pods. The owned objects are called *dependents* of the +owner object. Every dependent object has a `metadata.ownerReferences` field that +points to the owning object. + +Sometimes, Kubernetes sets the value of `ownerReference` automatically. For +example, when you create a ReplicaSet, Kubernetes automatically sets the +`ownerReference` field of each Pod in the ReplicaSet. You can also specify +relationships between owners and dependents by manually setting the +`ownerReference` field. + +Here's a configuration file for a ReplicaSet that has three Pods: + +{% include code.html language="yaml" file="my-repset.yaml" ghlink="/docs/concepts/abstractions/controllers/my-repset.yaml" %} + +If you create the ReplicaSet and then view the Pod metadata, you can see +OwnerReferences field: + +```shell +kubectl create -f http://k8s.io/docs/concepts/abstractions/controllers/my-repset.yaml +kubectl get pods --output=yaml +``` + +The output shows that the Pod owner is a ReplicaSet named my-repset: + +```shell +apiVersion: v1 +kind: Pod +metadata: + ... + ownerReferences: + - apiVersion: extensions/v1beta1 + controller: true + kind: ReplicaSet + name: my-repset + uid: d9607e19-f88f-11e6-a518-42010a800195 + ... +``` + +## Controlling whether the garbage collector deletes dependents + +When you delete object, you can specify whether the object's dependents +are deleted automatically. Deleting dependents automatically is called +*cascading deletion*. If you delete an object without deleting its +dependents automatically, the dependents are said to be *orphaned*. + +To delete dependent objects automatically, set the `orphanDependents` query +parameter to false in your request to delete the owner object. + +To orphan the dependents of an owner object, set the `orphanDependents` query +parameter to true in your request to delete the owner object. + +The default value for `orphanDependents` is true. So unless you specify +otherwise, dependent objects are orphaned. + +Here's an example that deletes dependents automatically: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset?orphanDependents=false +``` + +To delete dependents automatically using kubectl, set `--cascade` to true. +To orphan dependents, set `--cascade` to false. The default value for +`--cascade` is true. + +Here's an example that orphans the dependents of a ReplicaSet: + +```shell +kubectl delete replicaset my-repset --cascade=false +``` + +## Ongoing development + +In Kubernetes version 1.5, synchronous garbage collection is under active +development. See the tracking +[issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details. + +{% endcapture %} + + +{% capture whatsnext %} + +[Design Doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/garbage-collection.md) + +[Known issues](https://github.com/kubernetes/kubernetes/issues/26120) + +{% endcapture %} + + +{% include templates/concept.md %} diff --git a/docs/concepts/abstractions/controllers/my-repset.yaml b/docs/concepts/abstractions/controllers/my-repset.yaml new file mode 100644 index 0000000000..54befd8f9d --- /dev/null +++ b/docs/concepts/abstractions/controllers/my-repset.yaml @@ -0,0 +1,17 @@ +apiVersion: extensions/v1beta1 +kind: ReplicaSet +metadata: + name: my-repset +spec: + replicas: 3 + selector: + matchLabels: + pod-is-for: garbage-collection-example + template: + metadata: + labels: + pod-is-for: garbage-collection-example + spec: + containers: + - name: nginx + image: nginx diff --git a/docs/user-guide/garbage-collection.md b/docs/user-guide/garbage-collection.md index af90b4dd1a..16f9380866 100644 --- a/docs/user-guide/garbage-collection.md +++ b/docs/user-guide/garbage-collection.md @@ -4,35 +4,6 @@ assignees: title: Garbage Collection (Beta) --- -* TOC -{:toc} +{% include user-guide-content-moved.md %} -## Garbage Collection - -Note: the Garbage Collection is a beta feature and is enabled by default in Kubernetes version 1.4. - -### What does Garbage Collector do - -When you delete, for example, a ReplicaSet, it is often desirable for the server to automatically garbage collect all the Pods that the ReplicaSet creates. The Garbage Collector (GC) implements this. In general, when you delete an owner object, GC deletes that owner's dependent objects. - -### How to establish an owner-dependent relationship between objects - -Kubernetes 1.3 added a metadata.ownerReferences field to every Kubernetes API object. If an API object is a dependent of another object, ownerReference should point to the owning API object. - -When you create a ReplicationController or a ReplicaSet in Kubernetes 1.4, the Kubernetes control plane automatically sets the ownerReference field in each created pod to point to the owning ReplicationController or ReplicaSet. - -You can set up owner-dependent relationships among other objects by manually setting the ownerReference field on dependent objects. - -### Controlling whether Garbage Collector deletes dependents - -When deleting an object, you can request the GC to ***asynchronously*** delete its dependents by ***explicitly*** specifying `deleteOptions.orphanDependents=false` in the deletion request that you send to the API server. A 200 OK response from the API server indicates the owner is deleted. - -In Kubernetes version 1.5, synchronous garbage collection is under active development. See the tracking [issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details. - -If you specify `deleteOptions.orphanDependents=true`, or leave it blank, then the GC will first reset the `ownerReferences` in the dependents, then delete the owner. Note that the deletion of the owner object is asynchronous, that is, a 200 OK response will be sent by the API server before the owner object gets deleted. - -### Other references - -[Design Doc](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/garbage-collection.md) - -[Known issues](https://github.com/kubernetes/kubernetes/issues/26120) +[Garbage Collection](/docs/concepts/abstractions/controllers/garbage-collection/) From c5ca45729707f04617cb5fa211d80f2bd042207d Mon Sep 17 00:00:00 2001 From: Jared Date: Wed, 22 Feb 2017 10:54:28 -0800 Subject: [PATCH 060/213] Update review-issues.md --- docs/contribute/review-issues.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/contribute/review-issues.md b/docs/contribute/review-issues.md index f5430d0b11..1353620e81 100644 --- a/docs/contribute/review-issues.md +++ b/docs/contribute/review-issues.md @@ -12,6 +12,8 @@ This page explains how documentation issues are reviewed and prioritized for the ## Categorizing issues Issues should be sorted into different buckets of work using the following labels and definitions. If an issue doesn't have enough information to identify a problem that can be researched, reviewed, or worked on (i.e. the issue doesn't fit into any of the categories below) you should close the issue with a comment explaining why it is being closed. +### Needs Clarification +* Issues that need more information from the original submitter to make them actionable. Issues with this label that aren't followed up within a week may be closed. ### Actionable * Issues that can be worked on with current information (or may need a comment to explain what needs to be done to make it more clear) @@ -26,8 +28,9 @@ Issues should be sorted into different buckets of work using the following label * Issues that are suggestions for better processes or site improvements that require community agreement to be implemented * Topics can be brought to SIG meetings as agenda items -#### Needs UX Review -* Issues that are suggestions for improving the user interface of the site or fixing a broken UX. +### Needs UX Review +* Issues that are suggestions for improving the user interface of the site. +* Fixing broken site elements. ## Prioritizing Issues From 8904a7f8626bb2ff00169003114628668d241da2 Mon Sep 17 00:00:00 2001 From: Guangya Liu Date: Wed, 22 Feb 2017 10:11:42 +0800 Subject: [PATCH 061/213] Fixed flag for eviction-soft. --- docs/admin/garbage-collection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index 8164fbb7d9..ad55b773a5 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -64,7 +64,7 @@ Including: | Existing Flag | New Flag | Rationale | | ------------- | -------- | --------- | -| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` | existing eviction signals can trigger image garbage collection | +| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | | `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | | `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | | `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | From 7b69821e5eac5ba69d4dce36780dd3565fed5cd2 Mon Sep 17 00:00:00 2001 From: Xiuyu Li Date: Tue, 21 Feb 2017 16:18:52 +0800 Subject: [PATCH 062/213] show kubectl_rollingupdate svg --- docs/user-guide/kubectl/kubectl_rolling-update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubectl/kubectl_rolling-update.md b/docs/user-guide/kubectl/kubectl_rolling-update.md index 382e630c78..f20483e125 100644 --- a/docs/user-guide/kubectl/kubectl_rolling-update.md +++ b/docs/user-guide/kubectl/kubectl_rolling-update.md @@ -13,7 +13,7 @@ Perform a rolling update of the given ReplicationController. Replaces the specified replication controller with a new replication controller by updating one pod at a time to use the new PodTemplate. The new-controller.json must specify the same namespace as the existing replication controller and overwrite at least one (common) label in its replicaSelector. -! http://kubernetes.io/images/docs/kubectl_rollingupdate.svg +![kubectl_rollingupdate](http://kubernetes.io/images/docs/kubectl_rollingupdate.svg) ``` kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) From 9dc31d63022c7d4c47411bb958d5e442823e30aa Mon Sep 17 00:00:00 2001 From: Andres Villarroel Date: Tue, 7 Feb 2017 09:30:13 -0800 Subject: [PATCH 063/213] Update hello-minikube.md - Proposing a different way to run curl without proxy, without touching current environment - There's a formatting problem and the whole thing is being displayed in a single line ![screenshot](http://imgur.com/download/nfk02hd) --- docs/tutorials/stateless-application/hello-minikube.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/tutorials/stateless-application/hello-minikube.md b/docs/tutorials/stateless-application/hello-minikube.md index 6f2a47b897..70fed7db16 100644 --- a/docs/tutorials/stateless-application/hello-minikube.md +++ b/docs/tutorials/stateless-application/hello-minikube.md @@ -74,10 +74,9 @@ chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl ``` Determine whether you can access sites like [https://cloud.google.com/container-registry/](https://cloud.google.com/container-registry/) directly without a proxy, by opening a new terminal and using + ```shell -export http_proxy="" -export https_proxy="" -curl https://cloud.google.com/container-registry/ +curl --proxy "" https://cloud.google.com/container-registry/ ``` If NO proxy is required, start the Minikube cluster: From aa0424825195d83a2a0c1d2eed295b0a85de6249 Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Fri, 3 Feb 2017 11:55:13 -0800 Subject: [PATCH 064/213] Add object fields to style guide. --- docs/contribute/style-guide.md | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/docs/contribute/style-guide.md b/docs/contribute/style-guide.md index 6bb1aa5837..d44cab2ea4 100644 --- a/docs/contribute/style-guide.md +++ b/docs/contribute/style-guide.md @@ -17,7 +17,7 @@ docs, follow the instructions on ## Documentation formatting standards -### Use Camel Case for API objects +### Use camel case for API objects When you refer to an API object, use the same uppercase and lowercase letters that are used in the actual object name. Typically, the names of API @@ -75,7 +75,7 @@ represents. Open the /_data/concepts.yaml file.Open the /_data/concepts.yaml file. -## Code snippet formatting +## Inline code formatting ### Use code style for inline code and commands @@ -84,10 +84,31 @@ document, use the backtick (`). - +
DoDon't
Set the value of the replicas field in the configuration file.Set the value of the "replicas" field in the configuration file.
The kubectl run command creates a Deployment.The "kubectl run" command creates a Deployment.
For declarative management, use kubectl apply.For declarative management, use "kubectl apply".
+### Use code style for object field names + + + + + +
DoDon't
Set the value of the replicas field in the configuration file.Set the value of the "replicas" field in the configuration file.
The value of the exec field is an ExecAction object.The value of the "exec" field is an ExecAction object.
+ +### Use normal style for string and integer field values + +For field values of type string or integer, use normal style without quotation marks. + + + + + + +
DoDon't
Set the value of imagePullPolicy to Always.Set the value of imagePullPolicy to "Always".
Set the value of image to nginx:1.8.Set the value of image to nginx:1.8.
Set the value of the replicas field to 2.Set the value of the replicas field to 2.
+ +## Code snippet formatting + ### Don't include the command prompt From d2266ed0eb804aa3e9f319324e3c6ffc8274aa00 Mon Sep 17 00:00:00 2001 From: David Calavera Date: Sat, 4 Feb 2017 20:25:31 +0100 Subject: [PATCH 065/213] Add documentation to the redirects.rb script. Signed-off-by: David Calavera --- redirects.rb | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/redirects.rb b/redirects.rb index 3aeabbd326..4cb238a811 100644 --- a/redirects.rb +++ b/redirects.rb @@ -1,3 +1,53 @@ +# This script generates a redirects file that Netlify's CDN +# can use to forward visitor to the right content. +# +# You can read more details about this file in Netlify documentation: +# +# https://www.netlify.com/docs/redirects/ +# +# USAGE: +# +# Run this script with Ruby to generate the _redirects file in this repository. +# It works with any Ruby version higher than 1.8. +# +# ruby redirects.rb +# +# If you want to test a change without modifying the content of the current file, +# you can print the output of the script setting the DEBUG environment variable +# when you run the script: +# +# DEBUG=1 ruby redirects.rb +# +# You can test if the content generated is correct in this playground: +# +# https://play.netlify.com/redirects +# +# HOW TO ADD NEW RULES: +# +# This script is divided in two sections. +# +# The first section handles static redirects, +# those that you know the old path and the new path and never change. +# +# If you want to add one of these redirects, add the rule to the `fixed_redirects` variable, +# in a new line before the closing """. The format for basic 301 redirects is the following one, +# check Netlify's documentation linked above for other rules: +# +# /OLD_PATH /NEW_PATH_OR_URL +# +# The second section handles redirects that change depending on the branch that's deployed +# in the site. For instance, when you want to redirect a path to content in +# the kubernetes main repository but the content is specific to a branch that +# matches the deployed branch. +# +# If you want to add one of there redirects, add the old path to the `branch_redirects` list. For instance, +# when you deploy the branch release-1.5 on Netlify, this script will generate the following redirects: +# +# /examples/* https://github.com/kubernetes/kubernetes/tree/release-1.5/examples/:splat +# /cluster/* https://github.com/kubernetes/kubernetes/tree/release-1.5/cluster/:splat +# /docs/devel/* https://github.com/kubernetes/kubernetes/tree/release-1.5/docs/devel/:splat +# /docs/design/* https://github.com/kubernetes/kubernetes/tree/release-1.5/docs/design/:splat +# REPO_TMPL = "https://github.com/kubernetes/kubernetes/tree/%s/%s/:splat" fixed_redirects = """# 301 redirects (301 is the default status when no other one is provided for each line) From 5cf0e08b5bde9be8bf2860c21df3331eb9db1fa6 Mon Sep 17 00:00:00 2001 From: Shiyang Wang Date: Sat, 4 Feb 2017 13:40:26 +0800 Subject: [PATCH 066/213] fix typo --- .../tools/kubectl/object-management-using-declarative-config.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/tools/kubectl/object-management-using-declarative-config.md b/docs/concepts/tools/kubectl/object-management-using-declarative-config.md index 5033bbac8c..6c8dfbd250 100644 --- a/docs/concepts/tools/kubectl/object-management-using-declarative-config.md +++ b/docs/concepts/tools/kubectl/object-management-using-declarative-config.md @@ -382,7 +382,7 @@ is used to identify fields that have been removed from the configuration file and need to be cleared from the live configuration. Here are the steps used to caluculate which fields should be deleted or set: -1. Calculate the fields to delete. Thes are the fields present in `last-applied-configuration` and missing from the configuration file. +1. Calculate the fields to delete. These are the fields present in `last-applied-configuration` and missing from the configuration file. 2. Calculate the fields to add or set. These are the fields present in the configuration file whose values don't match the live configuration. Here's an example. Suppose this is the configuration file for a Deployment object: From a21e061dcbfd4edc3f6dfbb6df19c3452709f698 Mon Sep 17 00:00:00 2001 From: Pan Luo Date: Fri, 3 Feb 2017 16:13:58 -0800 Subject: [PATCH 067/213] Add generic to create secret command The generic is missing from the command and will cause error: `Error: unknown flag: --type` when running the command. --- docs/user-guide/persistent-volumes/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index ae34668c9e..3ecc8ea99f 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -423,7 +423,7 @@ parameters: * `restuserkey` : Gluster REST service/Heketi user's password which will be used for authentication to the REST server. This parameter is deprecated in favor of `secretNamespace` + `secretName`. * `secretNamespace` + `secretName` : Identification of Secret instance that containes user password to use when talking to Gluster REST service. These parameters are optional, empty password will be used when both `secretNamespace` and `secretName` are omitted. The provided secret must have type "kubernetes.io/glusterfs", e.g. created in this way: ``` - $ kubectl create secret heketi-secret --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' --namespace=default + $ kubectl create secret generic heketi-secret --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' --namespace=default ``` #### OpenStack Cinder @@ -482,7 +482,7 @@ parameters: * `userId`: Ceph client ID that is used to map the RBD image. Default is the same as `adminId`. * `userSecretName`: The name of Ceph Secret for `userId` to map RBD image. It must exist in the same namespace as PVCs. This parameter is required. The provided secret must have type "kubernetes.io/rbd", e.g. created in this way: ``` - $ kubectl create secret ceph-secret --type="kubernetes.io/rbd" --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' --namespace=kube-system + $ kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' --namespace=kube-system ``` #### Quobyte @@ -509,7 +509,7 @@ parameters: * `adminSecretNamespace`: The namespace for `adminSecretName`. Default is "default". * `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate agains the API server. The provided secret must have type "kubernetes.io/quobyte", e.g. created in this way: ``` - $ kubectl create secret quobyte-admin-secret --type="kubernetes.io/quobyte" --from-literal=key='opensesame' --namespace=kube-system + $ kubectl create secret generic quobyte-admin-secret --type="kubernetes.io/quobyte" --from-literal=key='opensesame' --namespace=kube-system ``` * `user`: maps all access to this user. Default is "root". * `group`: maps all access to this group. Default is "nfsnobody". From 24fc013242d033b86e54b28b85a1ca7652784aab Mon Sep 17 00:00:00 2001 From: Philipp T Date: Sat, 4 Feb 2017 19:38:07 +0100 Subject: [PATCH 068/213] Update kubeadm.md grammar ocd --- docs/getting-started-guides/kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index a005ed0c56..a4e5679ffb 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -357,6 +357,6 @@ Please note: `kubeadm` is a work in progress and these limitations will be addre 1. If you are using VirtualBox (directly or via Vagrant), you will need to ensure that `hostname -i` returns a routable IP address (i.e. one on the second network interface, not the first one). By default, it doesn't do this and kubelet ends-up using first non-loopback network interface, which is usually NATed. - Workaround: Modify `/etc/hosts`, take a look at this [`Vagrantfile`][ubuntu-vagrantfile] for how you this can be achieved. + Workaround: Modify `/etc/hosts`, take a look at this [`Vagrantfile`][ubuntu-vagrantfile] for how this can be achieved. [ubuntu-vagrantfile]: https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11), From 29e432d41987ed8deb51d627b10142124afa51a6 Mon Sep 17 00:00:00 2001 From: Vasily Upornikov Date: Sun, 5 Feb 2017 13:38:13 +0300 Subject: [PATCH 069/213] Update container-command-args.md --- docs/concepts/configuration/container-command-args.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/configuration/container-command-args.md b/docs/concepts/configuration/container-command-args.md index 54fe3afcb9..25d555f702 100644 --- a/docs/concepts/configuration/container-command-args.md +++ b/docs/concepts/configuration/container-command-args.md @@ -13,7 +13,7 @@ fields to override the default Entrypoint and Cmd of the the Container's image. ## Container entry points and arguments -The configuration file for a Container has an `image` field that specifies the +The configuration file for a Container has an `image` field that specifies the Docker image to be run in the Container. A Docker image has metadata that includes a default Entrypoint and a default Cmd. From 456a3ddcd6283a00155f71036bd6969fbd253c88 Mon Sep 17 00:00:00 2001 From: scjane Date: Mon, 6 Feb 2017 11:08:46 +0800 Subject: [PATCH 070/213] Update kubefed.md --- docs/admin/federation/kubefed.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/federation/kubefed.md b/docs/admin/federation/kubefed.md index 9685271b85..695edf7bee 100644 --- a/docs/admin/federation/kubefed.md +++ b/docs/admin/federation/kubefed.md @@ -36,7 +36,7 @@ in your `$PATH` and set the executable permission on those binaries. Note: The URL in the curl command below downloads the binaries for Linux amd64. If you are on a different platform, please use the URL for the binaries appropriate for your platform. You can find the list -of available binaries on the [release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-3) +of available binaries on the [release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-3). ```shell From af059b3b3c95758daf11d3275df5abdb527d8db6 Mon Sep 17 00:00:00 2001 From: caiyixiang Date: Mon, 6 Feb 2017 11:35:24 +0800 Subject: [PATCH 071/213] Update minikube.md --- docs/getting-started-guides/minikube.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/getting-started-guides/minikube.md b/docs/getting-started-guides/minikube.md index 4f4a432185..e0e79364cf 100644 --- a/docs/getting-started-guides/minikube.md +++ b/docs/getting-started-guides/minikube.md @@ -40,7 +40,7 @@ See the installation instructions for the [latest release](https://github.com/ku ## Quickstart Here's a brief demo of minikube usage. -If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube Supports +If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports the following drivers: * virtualbox @@ -106,7 +106,7 @@ plugins, if required. When using a single VM of Kubernetes, it's really handy to reuse the minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet. -To be able to work with the docker daemon on your mac/linux host use the [docker-env command](./docs/minikube_docker-env.md) in your shell: +To be able to work with the docker daemon on your mac/linux host use the [docker-env command](https://github.com/kubernetes/minikube/blob/master/docs/minikube_docker-env.md) in your shell: ``` eval $(minikube docker-env) From a045b3987d0e4291913e8bb6fea77e18b2b2964b Mon Sep 17 00:00:00 2001 From: yupengzte Date: Sat, 4 Feb 2017 10:46:04 +0800 Subject: [PATCH 072/213] Fix the url error Signed-off-by: yupengzte --- docs/admin/limitrange/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/limitrange/index.md b/docs/admin/limitrange/index.md index 3a31b9e732..82bed781f1 100644 --- a/docs/admin/limitrange/index.md +++ b/docs/admin/limitrange/index.md @@ -30,7 +30,7 @@ This example demonstrates how limits can be applied to a Kubernetes [namespace]( min/max resource limits per pod. In addition, this example demonstrates how you can apply default resource limits to pods in the absence of an end-user specified value. -See [LimitRange design doc](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/docs/user-guide/compute-resources/) +See [LimitRange design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/admission_control_limit_range.md) for more information. For a detailed description of the Kubernetes resource model, see [Resources](/docs/user-guide/compute-resources/) ## Step 0: Prerequisites From f2184920afab181399b7a7f8ce648959ee94aa8d Mon Sep 17 00:00:00 2001 From: sallydeng Date: Mon, 6 Feb 2017 15:06:55 +0800 Subject: [PATCH 073/213] Update namspace and service part of ui.md 1. Namespace can not contain capital letter. 2. For service, internal endpoints for cluster connections and external endpoints for external users. Here, it lost "external". --- docs/user-guide/ui.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/ui.md b/docs/user-guide/ui.md index da2b2e611c..b2acc5e8ed 100644 --- a/docs/user-guide/ui.md +++ b/docs/user-guide/ui.md @@ -97,7 +97,7 @@ track=stable - **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/admin/namespaces/). They let you partition resources into logically named groups. - Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-). + Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-), can not contain capital letters. In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected. @@ -147,7 +147,7 @@ Detail views for workloads show status and specification information and surface ![Deployment detail view](/images/docs/ui-dashboard-deployment-detail.png) #### Services and discovery -Services and discovery view shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and endpoints for external users. +Services and discovery view shows Kubernetes resources that allow for exposing services to external world and discovering them within a cluster. For that reason, Service and Ingress views show Pods targeted by them, internal endpoints for cluster connections and external endpoints for external users. ![Service list partial view](/images/docs/ui-dashboard-service-list.png) From 83d5b27667f6dc34cd6169092ca81344862d8106 Mon Sep 17 00:00:00 2001 From: sallydeng Date: Tue, 7 Feb 2017 08:35:21 +0800 Subject: [PATCH 074/213] Update ui.md base on comments Former: The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) , can not contain capital letters. Now: The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters. --- docs/user-guide/ui.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/ui.md b/docs/user-guide/ui.md index b2acc5e8ed..5d6567a62c 100644 --- a/docs/user-guide/ui.md +++ b/docs/user-guide/ui.md @@ -97,7 +97,7 @@ track=stable - **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/admin/namespaces/). They let you partition resources into logically named groups. - Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-), can not contain capital letters. + Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters. In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected. From 34f61c10e89fa8ae92b3e283212a027482a0819e Mon Sep 17 00:00:00 2001 From: Ben Spoon Date: Tue, 7 Feb 2017 13:38:47 -0800 Subject: [PATCH 075/213] Fix overflow scroll on code blocks Fixes https://github.com/kubernetes/kubernetes.github.io/issues/633 --- _sass/_base.sass | 1 + 1 file changed, 1 insertion(+) diff --git a/_sass/_base.sass b/_sass/_base.sass index 3ad4f81dc5..72557bb983 100644 --- a/_sass/_base.sass +++ b/_sass/_base.sass @@ -856,6 +856,7 @@ dd display: block margin: 20px 0 padding: 15px + position: relative overflow-x: auto h1 code, h2 code, h3 code, h4 code, h5 code, h6 code From c999e614f25ccf38fc2a0c88b4629c787753de87 Mon Sep 17 00:00:00 2001 From: tailnode Date: Tue, 7 Feb 2017 19:40:15 +0800 Subject: [PATCH 076/213] fix link --- _includes/v1.5/v1-definitions.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_includes/v1.5/v1-definitions.html b/_includes/v1.5/v1-definitions.html index faaa0e847d..16858392bc 100755 --- a/_includes/v1.5/v1-definitions.html +++ b/_includes/v1.5/v1-definitions.html @@ -8146,7 +8146,7 @@ The resulting set of endpoints can be viewed as:
 - + @@ -8263,4 +8263,4 @@ Last updated 2016-11-17 06:26:10 UTC - \ No newline at end of file + From ee10fefec806ad0273847f7f16e5fa4d89cc626a Mon Sep 17 00:00:00 2001 From: Bruce Auyeung Date: Tue, 7 Feb 2017 10:59:04 +0800 Subject: [PATCH 077/213] fix unreachable links and typos 1. fix unreachable federated resources links 2. federation proposal doc has been relocated, so i fix this link 3. make federation resources supporting cascading deletion clickable 4. make link to `Kubernetes Scaling and Performance Goals` clickable 5. other typo fixes --- docs/user-guide/federation/index.md | 36 ++++++++++++++--------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/user-guide/federation/index.md b/docs/user-guide/federation/index.md index 7ba0ca9c60..10cea0ad6e 100644 --- a/docs/user-guide/federation/index.md +++ b/docs/user-guide/federation/index.md @@ -43,7 +43,7 @@ why you might want multiple clusters are: [Multi cluster guide](/docs/admin/multi-cluster) has more details on this. * Scalability: There are scalability limits to a single kubernetes cluster (this should not be the case for most users. For more details: - https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md). + [Kubernetes Scaling and Performance Goals](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md)). * Hybrid cloud: You can have multiple clusters on different cloud providers or on-premises data centers. @@ -53,7 +53,7 @@ why you might want multiple clusters are: While there are a lot of attractive use cases for federation, there are also some caveats. -* Increased network bandwidth and cost: The dederation control plane watches all +* Increased network bandwidth and cost: The federation control plane watches all clusters to ensure that the current state is as expected. This can lead to significant network cost if the clusters are running in different regions on a cloud provider or on different cloud providers. @@ -93,15 +93,15 @@ Once we have the control plane setup, we can start creating federation API resources. The following guides explain some of the resources in detail: -* [ConfigMap](/docs/user-guide/federation/configmap/) -* [DaemonSets](/docs/user-guide/federation/daemonsets/) -* [Deployment](/docs/user-guide/federation/deployment/) -* [Events](/docs/user-guide/federation/events/) -* [Ingress](/docs/user-guide/federation/federated-ingress/) -* [Namespaces](/docs/user-guide/federation/namespaces/) -* [ReplicaSets](/docs/user-guide/federation/replicasets/) -* [Secrets](/docs/user-guide/federation/secrets/) -* [Services](/docs/user-guide/federation/federated-services/) +* [ConfigMap](https://kubernetes.io/docs/user-guide/federation/configmap/) +* [DaemonSets](https://kubernetes.io/docs/user-guide/federation/daemonsets/) +* [Deployment](https://kubernetes.io/docs/user-guide/federation/deployment/) +* [Events](https://kubernetes.io/docs/user-guide/federation/events/) +* [Ingress](https://kubernetes.io/docs/user-guide/federation/federated-ingress/) +* [Namespaces](https://kubernetes.io/docs/user-guide/federation/namespaces/) +* [ReplicaSets](https://kubernetes.io/docs/user-guide/federation/replicasets/) +* [Secrets](https://kubernetes.io/docs/user-guide/federation/secrets/) +* [Services](https://kubernetes.io/docs/user-guide/federation/federated-services/) [API reference docs](/docs/federation/api-reference/) lists all the resources supported by federation apiserver. @@ -119,12 +119,12 @@ federation control plane. The following Federated resources are affected by cascading deletion: -* Ingress -* Namespace -* ReplicaSet -* Secret -* Deployment -* DaemonSet +* [Ingress](https://kubernetes.io/docs/user-guide/federation/federated-ingress/) +* [Namespaces](https://kubernetes.io/docs/user-guide/federation/namespaces/) +* [ReplicaSets](https://kubernetes.io/docs/user-guide/federation/replicasets/) +* [Secrets](https://kubernetes.io/docs/user-guide/federation/secrets/) +* [Deployment](https://kubernetes.io/docs/user-guide/federation/deployment/) +* [DaemonSets](https://kubernetes.io/docs/user-guide/federation/daemonsets/) Note: By default, deleting a resource from federation control plane does not delete the corresponding resources from underlying clusters. @@ -133,5 +133,5 @@ delete the corresponding resources from underlying clusters. ## For more information * [Federation - proposal](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/proposals/federation.md) + proposal](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/federation.md) * [Kubecon2016 talk on federation](https://www.youtube.com/watch?v=pq9lbkmxpS8) From 8c1b7a6f5c0777bf3f7d4e133ec52a3a29153b3b Mon Sep 17 00:00:00 2001 From: scjane Date: Wed, 8 Feb 2017 09:48:41 +0800 Subject: [PATCH 078/213] Update assign-cpu-ram-container.md --- docs/tasks/configure-pod-container/assign-cpu-ram-container.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md index 24cca3eca5..fc62af79d9 100644 --- a/docs/tasks/configure-pod-container/assign-cpu-ram-container.md +++ b/docs/tasks/configure-pod-container/assign-cpu-ram-container.md @@ -4,7 +4,7 @@ title: Assigning CPU and RAM Resources to a Container {% capture overview %} -This page shows how assign CPU and RAM resources to containers running +This page shows how to assign CPU and RAM resources to containers running in a Kubernetes Pod. {% endcapture %} From aa1c435df38f4bdad8d6be9e747a47cee5e1b21e Mon Sep 17 00:00:00 2001 From: sallydeng Date: Wed, 8 Feb 2017 16:38:00 +0800 Subject: [PATCH 079/213] Update ui.md: namespace name can't be number only When the namespace name only contains number, such as "10", the pod can't be created in this kind of namespace, the pod will be put in default namespace. --- docs/user-guide/ui.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/user-guide/ui.md b/docs/user-guide/ui.md index 5d6567a62c..3456a7e98a 100644 --- a/docs/user-guide/ui.md +++ b/docs/user-guide/ui.md @@ -98,6 +98,7 @@ track=stable - **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/admin/namespaces/). They let you partition resources into logically named groups. Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters. + When the namespace name only contains number, such as "10", the pod can't be created in this kind of namespace, the pod will be put in default namespace. In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected. From 30b425b99128afd0d25846d7d9295b9678fd09c7 Mon Sep 17 00:00:00 2001 From: Andrew Martin Date: Wed, 8 Feb 2017 14:55:50 +0000 Subject: [PATCH 080/213] Fix typo `pages` -> `page` --- docs/getting-started-guides/ubuntu/backups.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started-guides/ubuntu/backups.md b/docs/getting-started-guides/ubuntu/backups.md index 9c0c741d9b..b839cafee4 100644 --- a/docs/getting-started-guides/ubuntu/backups.md +++ b/docs/getting-started-guides/ubuntu/backups.md @@ -3,7 +3,7 @@ title: Backups --- {% capture overview %} -This pages shows you how to backup and restore data from the different deployed services in a given cluster. +This page shows you how to backup and restore data from the different deployed services in a given cluster. {% endcapture %} {% capture prerequisites %} From 0b192ad9ec3219e7fe8ba83c85a460629a278bbf Mon Sep 17 00:00:00 2001 From: Ghe Rivero Date: Wed, 8 Feb 2017 11:19:11 +0100 Subject: [PATCH 081/213] Fix examples display --- docs/admin/authorization.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/admin/authorization.md b/docs/admin/authorization.md index ce75c189f0..e5c091b772 100644 --- a/docs/admin/authorization.md +++ b/docs/admin/authorization.md @@ -445,6 +445,7 @@ subjects: ``` For all authenticated users: + ```yaml subjects: - kind: Group @@ -452,6 +453,7 @@ subjects: ``` For all unauthenticated users: + ```yaml subjects: - kind: Group @@ -459,6 +461,7 @@ subjects: ``` For all users: + ```yaml subjects: - kind: Group From e93aaf7028a80ddbceb5542502fcf6c159a7bf9a Mon Sep 17 00:00:00 2001 From: Eamon Taaffe Date: Wed, 8 Feb 2017 15:43:16 +1100 Subject: [PATCH 082/213] Missing export statement in example --- docs/user-guide/jobs/work-queue-1/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/jobs/work-queue-1/index.md b/docs/user-guide/jobs/work-queue-1/index.md index b2b68cff23..4ce1ffb667 100644 --- a/docs/user-guide/jobs/work-queue-1/index.md +++ b/docs/user-guide/jobs/work-queue-1/index.md @@ -101,7 +101,7 @@ Next we will verify we can create a queue, and publish and consume messages. # In the next line, rabbitmq-service is the hostname where the rabbitmq-service # can be reached. 5672 is the standard port for rabbitmq. -root@temp-loe07:/# BROKER_URL=amqp://guest:guest@rabbitmq-service:5672 +root@temp-loe07:/# export BROKER_URL=amqp://guest:guest@rabbitmq-service:5672 # If you could not resolve "rabbitmq-service" in the previous step, # then use this command instead: # root@temp-loe07:/# BROKER_URL=amqp://guest:guest@$RABBITMQ_SERVICE_SERVICE_HOST:5672 From c4e19401707e265d36a10827311cd5efb9092e7c Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Wed, 8 Feb 2017 10:39:32 -0800 Subject: [PATCH 083/213] Remove User Guide topic: Launching, Exposing, --- docs/user-guide/quick-start.md | 67 +--------------------------------- 1 file changed, 2 insertions(+), 65 deletions(-) diff --git a/docs/user-guide/quick-start.md b/docs/user-guide/quick-start.md index 6cef04810d..67dfb1dc77 100644 --- a/docs/user-guide/quick-start.md +++ b/docs/user-guide/quick-start.md @@ -5,69 +5,6 @@ assignees: title: Launching, Exposing, and Killing Applications --- -This guide will help you get oriented to Kubernetes and running your first containers on the cluster. If you are already familiar with the docker-cli, you can also checkout the docker-cli to kubectl migration guide [here](/docs/user-guide/docker-cli-to-kubectl). +{% include user-guide-content-moved.md %} -* TOC -{:toc} - -## Launching a simple application, and exposing it to the Internet - -Once your application is packaged into a container and pushed to an image registry, you're ready to deploy it to Kubernetes. -Through integration with some cloud providers (for example Google Compute Engine, AWS EC2, and Azure ACS), Kubernetes also enables you to request it to provision a public IP address for your application. - -For example, [nginx](http://wiki.nginx.org/Main) is a popular HTTP server, with a [pre-built container on Docker hub](https://registry.hub.docker.com/_/nginx/). The [`kubectl run`](/docs/user-guide/kubectl/kubectl_run) commands below will create two nginx replicas, listening on port 80, and a public IP address for your application. - -```shell -$ kubectl run my-nginx --image=nginx --replicas=2 --port=80 -deployment "my-nginx" created -``` - -To expose your service to the public Internet, run: - -```shell -$ kubectl expose deployment my-nginx --target-port=80 --type=LoadBalancer -service "my-nginx" exposed -``` -Note: The type, LoadBalancer, is highly dependent upon the underlying platform that Kubernetes is running on. If your cloud provider doesn't have a load balancer implementation (e.g. OpenStack) for Kubernetes, you can simply use the allocated [NodePort](http://kubernetes.io/docs/user-guide/services/#type-nodeport) as a rudimentary form of load balancing across your endpoints. - -You can see that they are running by: - -```shell -$ kubectl get po -NAME READY STATUS RESTARTS AGE -my-nginx-3800858182-h9v8d 1/1 Running 0 1m -my-nginx-3800858182-wqafx 1/1 Running 0 1m -``` - -Kubernetes will ensure that your application keeps running, by automatically restarting containers that fail, spreading containers across nodes, and recreating containers on new nodes when nodes fail. - -To find the public IP address assigned to your application, execute: - -```shell -$ kubectl get service my-nginx -NAME CLUSTER_IP EXTERNAL_IP PORT(S) AGE -my-nginx 10.179.240.1 25.1.2.3 80/TCP 8s -``` - -You may need to wait for a minute or two for the external IP address to be provisioned. - -In order to access your nginx landing page, you also have to make sure that traffic from external IPs is allowed. Do this by opening a [firewall to allow traffic on port 80](/docs/user-guide/services-firewalls). - -If you're running on AWS, Kubernetes creates an ELB for you. ELBs use host -names, not IPs, so you will have to do `kubectl describe service/my-nginx` and look -for the `LoadBalancer Ingress` host name. Traffic from external IPs is allowed -automatically. - -## Killing the application - -To kill the application and delete its containers and public IP address, do: - -```shell -$ kubectl delete deployment,service my-nginx -deployment "my-nginx" deleted -service "my-nginx" deleted -``` - -## What's next? - -* [Learn about how to configure common container parameters, such as commands and environment variables.](/docs/user-guide/configuring-containers) +[Using a Service to Access an Application in a Cluster](https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address-service/) From 7bd4d8ba44079136835ece48e4f8d07ef46928ed Mon Sep 17 00:00:00 2001 From: scjane Date: Wed, 8 Feb 2017 17:56:59 +0800 Subject: [PATCH 084/213] Update debugging-services.md --- docs/user-guide/debugging-services.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/debugging-services.md b/docs/user-guide/debugging-services.md index de9cec5c3f..6a1a692e8a 100644 --- a/docs/user-guide/debugging-services.md +++ b/docs/user-guide/debugging-services.md @@ -352,7 +352,7 @@ they are running fine and not crashing. The `-l app=hostnames` argument is a label selector - just like our `Service` has. Inside the Kubernetes system is a control loop which evaluates the -selector of every `Service` and save the results into an `Endpoints` object. +selector of every `Service` and saves the results into an `Endpoints` object. ```shell $ kubectl get endpoints hostnames From d584b78bed11263c0f16f61d8fb8e73735955ed8 Mon Sep 17 00:00:00 2001 From: James Duncan Date: Thu, 9 Feb 2017 08:27:42 +1300 Subject: [PATCH 085/213] Corrected syntax of Networking Section Removed an unnecessary 'the' from a sentence. --- docs/concepts/abstractions/pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/pod.md b/docs/concepts/abstractions/pod.md index 07f0d18934..f8b9cf2f72 100644 --- a/docs/concepts/abstractions/pod.md +++ b/docs/concepts/abstractions/pod.md @@ -41,7 +41,7 @@ Pods provide two kinds of shared resources for their constituent containers: *ne #### Networking -Each Pod is assigned a unique IP address. Every the container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports). +Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers *inside a Pod* can communicate with one another using `localhost`. When containers in a Pod communicate with entities *outside the Pod*, they must coordinate how they use the shared network resources (such as ports). #### Storage From 34ab8024ec3a0713651c4f8929f07ed497c158af Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Wed, 8 Feb 2017 13:56:18 -0800 Subject: [PATCH 086/213] Remove Guide topic: Deploying Applications. --- docs/user-guide/deploying-applications.md | 94 +---------------------- 1 file changed, 2 insertions(+), 92 deletions(-) diff --git a/docs/user-guide/deploying-applications.md b/docs/user-guide/deploying-applications.md index 9bbcd34282..a1c04e1003 100644 --- a/docs/user-guide/deploying-applications.md +++ b/docs/user-guide/deploying-applications.md @@ -6,96 +6,6 @@ assignees: title: Deploying Applications --- -* TOC -{:toc} +{% include user-guide-content-moved.md %} -## Launching a set of replicas using a configuration file - -Kubernetes creates and manages sets of replicated containers (actually, replicated [Pods](/docs/user-guide/pods)) using [*Deployments*](/docs/user-guide/deployments). - -A Deployment simply ensures that a specified number of pod "replicas" are running at any one time. If there are too many, it will kill some. If there are too few, it will start more. It's analogous to Google Compute Engine's [Instance Group Manager](https://cloud.google.com/compute/docs/instance-groups/manager/) or AWS's [Auto-scaling Group](http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingGroup.html) (with no scaling policies). - -The Deployment created to run nginx by `kubectl run` in the [Quick start](/docs/user-guide/quick-start) could be specified using YAML as follows: - -{% include code.html language="yaml" file="run-my-nginx.yaml" ghlink="/docs/user-guide/run-my-nginx.yaml" %} - -Some differences compared to specifying just a pod are that the `kind` is `Deployment`, the number of `replicas` desired is specified, and the pod specification is under the `template` field. The names of the pods don't need to be specified explicitly because they are generated from the name of the Deployment. -View the [Deployment API -object](/docs/api-reference/extensions/v1beta1/definitions/#_v1beta1_deployment) -to view the list of supported fields. - -This Deployment can be created using `create`, just as with pods: - -```shell -$ kubectl create -f ./run-my-nginx.yaml -deployment "my-nginx" created -``` - -Unlike in the case where you directly create pods, a Deployment replaces pods that are deleted or terminated for any reason, such as in the case of node failure. For this reason, we recommend that you use a Deployment for a continuously running application even if your application requires only a single pod, in which case you can omit `replicas` and it will default to a single replica. - -## Viewing Deployment status - -You can view the Deployment you created using `get`: - -```shell -$ kubectl get deployment -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -my-nginx 2 2 2 2 6s -``` - -This tells you that your Deployment will ensure that you have two nginx replicas (desired replicas = 2). - -You can see those replicas using `get`, just as with pods you created directly: - -```shell -$ kubectl get pods -NAME READY STATUS RESTARTS AGE -my-nginx-3800858182-9hk43 1/1 Running 0 8m -my-nginx-3800858182-e529s 1/1 Running 0 8m -``` - -## Deleting Deployments - -When you want to kill your application, delete your Deployment, as in the [Quick start](/docs/user-guide/quick-start): - -```shell -$ kubectl delete deployment/my-nginx -deployment "my-nginx" deleted -``` - -By default, this will also cause the pods managed by the Deployment to be deleted. If there were a large number of pods, this may take a while to complete. If you want to leave the pods running instead, specify `--cascade=false`. - -If you try to delete the pods before deleting the Deployments, it will just replace them, as it is supposed to do. - -## Labels - -Kubernetes uses user-defined key-value attributes called [*labels*](/docs/user-guide/labels) to categorize and identify sets of resources, such as pods and Deployments. The example above specified a single label in the pod template, with key `run` and value `my-nginx`. All pods created carry that label, which can be viewed using `-L`: - -```shell -$ kubectl get pods -L run -NAME READY STATUS RESTARTS AGE RUN -my-nginx-3800858182-1v53o 1/1 Running 0 46s my-nginx -my-nginx-3800858182-2ds1q 1/1 Running 0 46s my-nginx -``` - -The labels from the pod template are copied to the Deployment's labels by default, as well -- all resources in Kubernetes support labels: - -```shell -$ kubectl get deployment/my-nginx -L run -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE RUN -my-nginx 2 2 2 2 2m my-nginx -``` - -More importantly, the pod template's labels are used to create a [`selector`](/docs/user-guide/labels/#label-selectors) that will match pods carrying those labels. You can see this field by requesting it using the [Go template output format of `kubectl get`](/docs/user-guide/kubectl/kubectl_get): - -```shell{% raw %} -$ kubectl get deployment/my-nginx -o template --template="{{.spec.selector}}" -map[matchLabels:map[run:my-nginx]]{% endraw %} -``` - -You could also specify the `selector` explicitly, such as if you wanted to specify labels in the pod template that you didn't want to select on, but you should ensure that the selector will match the labels of the pods created from the pod template, and that it won't match pods created by other Deployments. The most straightforward way to ensure the latter is to create a unique label value for the Deployment, and to specify it in both the pod template's labels and in the selector's -matchLabels. - -## What's next? - -[Learn about exposing applications to users and clients, and connecting tiers of your application together.](/docs/user-guide/connecting-applications) +[Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/) From ed4770e3d8212d5e6faf46998378776712aa61bf Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Wed, 8 Feb 2017 14:10:23 -0800 Subject: [PATCH 087/213] Remove Guide topic: Secrets Walkthrough. --- docs/user-guide/secrets/walkthrough.md | 58 +------------------------- 1 file changed, 2 insertions(+), 56 deletions(-) diff --git a/docs/user-guide/secrets/walkthrough.md b/docs/user-guide/secrets/walkthrough.md index 11ca7672df..bb069c675e 100644 --- a/docs/user-guide/secrets/walkthrough.md +++ b/docs/user-guide/secrets/walkthrough.md @@ -1,61 +1,7 @@ --- -assignees: title: Secrets Walkthrough --- -Following this example, you will create a secret and a [pod](/docs/user-guide/pods/) that consumes that secret in a [volume](/docs/user-guide/volumes/). See [Secrets design document](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/secrets.md) for more information. +{% include user-guide-content-moved.md %} -## Step Zero: Prerequisites - -This example assumes you have a Kubernetes cluster installed and running, and that you have -installed the `kubectl` command line tool somewhere in your path. Please see the [getting -started](/docs/getting-started-guides/) for installation instructions for your platform. - -## Step One: Create the secret - -A secret contains a set of named byte arrays. - -Use the [`secret.yaml`](/docs/user-guide/secrets/secret.yaml) file to create a secret: - -```shell -$ kubectl create -f docs/user-guide/secrets/secret.yaml -``` - -You can use `kubectl` to see information about the secret: - -```shell -$ kubectl get secrets -NAME TYPE DATA -test-secret Opaque 2 - -$ kubectl describe secret test-secret -Name: test-secret -Labels: -Annotations: - -Type: Opaque - -Data -==== -data-1: 9 bytes -data-2: 11 bytes -``` - -## Step Two: Create a pod that consumes a secret - -Pods consume secrets in volumes. Now that you have created a secret, you can create a pod that -consumes it. - -Use the [`secret-pod.yaml`](/docs/user-guide/secrets/secret-pod.yaml) file to create a Pod that consumes the secret. - -```shell -$ kubectl create -f docs/user-guide/secrets/secret-pod.yaml -``` - -This pod runs a binary that displays the content of one of the pieces of secret data in the secret -volume: - -```shell -$ kubectl logs secret-test-pod -2015-04-29T21:17:24.712206409Z content of file "/etc/secret-volume/data-1": value-1 -``` \ No newline at end of file +[Distributing Credentials Securely](docs/tasks/configure-pod-container/distribute-credentials-secure/) From a70480af0047539220c3a428205a97a6e3c004db Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Wed, 8 Feb 2017 14:20:30 -0800 Subject: [PATCH 088/213] Update walkthrough.md --- docs/user-guide/secrets/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/secrets/walkthrough.md b/docs/user-guide/secrets/walkthrough.md index bb069c675e..a58364859f 100644 --- a/docs/user-guide/secrets/walkthrough.md +++ b/docs/user-guide/secrets/walkthrough.md @@ -4,4 +4,4 @@ title: Secrets Walkthrough {% include user-guide-content-moved.md %} -[Distributing Credentials Securely](docs/tasks/configure-pod-container/distribute-credentials-secure/) +[Distributing Credentials Securely](/docs/tasks/configure-pod-container/distribute-credentials-secure/) From 25a3aac7b764a078644df45c9dd6997534ac60ed Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Wed, 8 Feb 2017 16:58:11 -0800 Subject: [PATCH 089/213] Remove Guide topic: kubectl to Manage Resources. --- docs/user-guide/working-with-resources.md | 52 +---------------------- 1 file changed, 2 insertions(+), 50 deletions(-) diff --git a/docs/user-guide/working-with-resources.md b/docs/user-guide/working-with-resources.md index 07a9bd55b7..7b55db4e25 100644 --- a/docs/user-guide/working-with-resources.md +++ b/docs/user-guide/working-with-resources.md @@ -5,54 +5,6 @@ assignees: title: Using kubectl to Manage Resources --- -*This document is aimed at users who have worked through some of the examples, -and who want to learn more about using kubectl to manage resources such -as pods and services. Users who want to access the REST API directly, -and developers who want to extend the Kubernetes API should -refer to the [api conventions](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md) and -the [api document](/docs/api/).* +{% include user-guide-content-moved.md %} -## Resources are Automatically Modified - -When you create a resource such as pod, and then retrieve the created -resource, a number of the fields of the resource are added. -You can see this at work in the following example: - -```shell -$ cat > /tmp/original.yaml < /tmp/current.yaml -pods/original -$ wc -l /tmp/original.yaml /tmp/current.yaml - 51 /tmp/current.yaml - 9 /tmp/original.yaml - 60 total -``` - -The resource we posted had only 9 lines, but the one we got back had 51 lines. -If you `diff -u /tmp/original.yaml /tmp/current.yaml`, you can see the fields added to the pod. -The system adds fields in several ways: - - - Some fields are added synchronously with creation of the resource and some are set asynchronously. - - For example: `metadata.uid` is set synchronously. (Read more about [metadata](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#metadata)). - - For example, `status.hostIP` is set only after the pod has been scheduled. This often happens fast, but you may notice pods which do not have this set yet. This is called Late Initialization. (Read more about [status](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) and [late initialization](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#late-initialization)). - - Some fields are set to default values. Some defaults vary by cluster and some are fixed for the API at a certain version. (Read more about [defaulting](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#defaulting)). - - For example, `spec.containers[0].imagePullPolicy` always defaults to `IfNotPresent` in api v1. - - For example, `spec.containers[0].resources.limits.cpu` may be defaulted to `100m` on some clusters, to some other value on others, and not defaulted at all on others. - -The API will generally not modify fields that you have set; it just sets ones which were unspecified. - -## Finding Documentation on Resource Fields - -You can browse auto-generated API documentation [here](/docs/api/). +[Kubernetes Object Management](/docs/concepts/tools/kubectl/object-management-overview/) From 554d6b7e9fc081f58a73fc1aba541e946e255e83 Mon Sep 17 00:00:00 2001 From: sallydeng Date: Thu, 9 Feb 2017 15:49:59 +0800 Subject: [PATCH 090/213] Update ui.md I reword it base on comment. --- docs/user-guide/ui.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/ui.md b/docs/user-guide/ui.md index 3456a7e98a..cb330f1f9b 100644 --- a/docs/user-guide/ui.md +++ b/docs/user-guide/ui.md @@ -98,7 +98,7 @@ track=stable - **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/admin/namespaces/). They let you partition resources into logically named groups. Dashboard offers all available namespaces in a dropdown list, and allows you to create a new namespace. The namespace name may contain a maximum of 63 alphanumeric characters and dashes (-) but can not contain capital letters. - When the namespace name only contains number, such as "10", the pod can't be created in this kind of namespace, the pod will be put in default namespace. + Namespace names should not consist of only numbers. If the name is set as a number, such as 10, the pod will be put in the default namespace. In case the creation of the namespace is successful, it is selected by default. If the creation fails, the first namespace is selected. From 667c1818dc139ac0b0c382d0711ba80ec3fece63 Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Thu, 9 Feb 2017 10:18:59 -0800 Subject: [PATCH 091/213] Migrate Init Containers to Concepts (#2438) * Initial commit for Init Containers migration to Concepts section * Add 1.5 beta include file * Change include to renamed user-guide-content-moved.md file * Fix Concepts/KO/Pods ToC * reformat examples to bullet points * fix formatting * Add back Detailed Behavior, Support and compatibility * Adjust formatting issues * revised based on feedback from Steve * complete sentence rewrite --- _data/concepts.yml | 8 +- _includes/1-5-beta.md | 1 + docs/concepts/abstractions/init-containers.md | 184 ++++++++++++++++++ docs/user-guide/pods/init-container.md | 165 +--------------- 4 files changed, 192 insertions(+), 166 deletions(-) create mode 100644 _includes/1-5-beta.md create mode 100644 docs/concepts/abstractions/init-containers.md diff --git a/_data/concepts.yml b/_data/concepts.yml index 4f41c2c818..4227231cc1 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -9,12 +9,14 @@ toc: - docs/concepts/tools/kubectl/object-management-using-imperative-commands.md - docs/concepts/tools/kubectl/object-management-using-imperative-config.md - docs/concepts/tools/kubectl/object-management-using-declarative-config.md - + - title: Kubernetes Objects section: - docs/concepts/abstractions/overview.md - - docs/concepts/abstractions/pod.md - + - title: Pods + section: + - docs/concepts/abstractions/pod.md + - docs/concepts/abstractions/init-containers.md - title: Controllers section: - docs/concepts/abstractions/controllers/statefulsets.md diff --git a/_includes/1-5-beta.md b/_includes/1-5-beta.md new file mode 100644 index 0000000000..abccaa303c --- /dev/null +++ b/_includes/1-5-beta.md @@ -0,0 +1 @@ +***NOTE: This feature is beta in Kubernetes 1.5.*** \ No newline at end of file diff --git a/docs/concepts/abstractions/init-containers.md b/docs/concepts/abstractions/init-containers.md new file mode 100644 index 0000000000..1bea00b3a2 --- /dev/null +++ b/docs/concepts/abstractions/init-containers.md @@ -0,0 +1,184 @@ +--- +assignees: +- erictune +title: Init Containers +--- + +{% capture overview %} +This page provides an overview of Init Containers, which are specialized +Containers that run before app Containers and can contain utilities or setup +scripts not present in an app image. +{% endcapture %} + +{:toc} + +{% include 1-5-beta.md %} + +**Once the feature exits beta, Init Containers will be specified in the PodSpec +alongside the app `containers` array.** + +{% capture body %} +## Understanding Init Containers + +A [Pod](/docs/concepts/abstractions/pod/) can have multiple Containers running +apps within it, but it can also have one or more Init Containers, which are run +before the app Containers are started. + +Init Containers are exactly like regular Containers, except: + +* They always run to completion. +* Each one must complete successfully before the next one is started. + +If an Init Container fails for a Pod, Kubernetes restarts the Pod repeatedly until the Init +Container succeeds. However, if the Pod has a `restartPolicy` of Never, it is not restarted. + +To specify a Container as an Init Container, add the `annotations` key +`pod.beta.kubernetes.io/init-containers`. Its value should be a +JSON array of objects of type +[Container](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_container). + +The status of an Init Container is returned as another annotation, +`pod.beta.kubernetes.io/init-container-statuses`, which is an array of +container statuses similar to the `status.containerStatuses` field. + +### Differences from regular Containers + +Init Containers support all the fields and features of app Containers, +including resource limits, volumes, and security settings. However, the +resource requests and limits for an Init Container are handled slightly +differently, which are documented in [Resources](#resources) below. Also, Init Containers do not +support readiness probes because they must run to completion before the Pod can +be ready. + +If multiple Init Containers are specified for a Pod, those Containers are run +one at a time in sequential order. Each must succeed before the next can run. +When all of the Init Containers have run to completion, Kubernetes initializes +the Pod and runs the application Containers as usual. + +## What can Init Containers be used for? + +Because Init Containers have separate images from app Containers, they +have some advantages for start-up related code: + +* They can contain and run utilities that are not desirable to include in the + app Container image for security reasons. +* They can contain utilities or custom code for setup that is not present in an app + image. For example, there is no need to make an image `FROM` another image just to use a tool like + `sed`, `awk`, `python`, or `dig` during setup. +* The application image builder and deployer roles can work independently without + the need to jointly build a single app image. +* They use Linux namespaces so they have a different filesystem view from app Containers. + Consequently, they can be given access to Secrets that app Containers are not able to + access. +* They run to completion before any app Containers start, whereas app + Containers run in parallel, so Init Containers provide an easy way to block or + delay the startup of app Containers until some set of preconditions are met. + +### Examples +Here are some ideas for how to use Init Containers: + +* Wait for a service to be created with a shell command like: + + for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1 + +* Register this Pod with a remote server from the downward API with a command like: + + curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()' + +* Wait for some time before starting the app Container with a command like `sleep 60`. +* Clone a git repository into a volume. +* Place values into a configuration file and run a template tool to dynamically + generate a configuration file for the the main app Container. For example, + place the POD_IP value in a configuration and generate the main app + configuration file using Jinja. + +More detailed usage examples can be found in the [StatefulSets documentation](/docs/concepts/abstractions/controllers/statefulsets/) +and the [Production Pods guide](/docs/user-guide/production-pods.md#handling-initialization). + +## Detailed behavior + +During the startup of a Pod, the Init Containers are started in order, after the +network and volumes are initialized. Each Container must exit successfully before +the next is started. If a Container fails to start due to the runtime or +exits with failure, it is retried according to the Pod `restartPolicy`. However, +if the Pod `restartPolicy` is set to Always, the Init Containers use +`RestartPolicy` OnFailure. + +A Pod cannot be `Ready` until all Init Containers have succeeded. The ports on an +Init Container are not aggregated under a service. A Pod that is initializing +is in the `Pending` state but should have a condition `Initializing` set to true. + +If the Pod is [restarted](#pod-restart-reasons), all Init Containers must +execute again. + +Changes to the Init Container spec are limited to the container image field. +Altering an Init Container image field is equivalent to restarting the Pod. + +Because Init Containers can be restarted, retried, or re-executed, Init Container +code should be idempotent. In particular, code that writes to files on `EmptyDirs` +should be prepared for the possibility that an output file already exists. + +Init Containers have all of the fields of an app Container. However, Kubernetes +prohibits `readinessProbe` from being used because Init Containers cannot +define readiness distinct from completion. This is enforced during validation. + +Use `activeDeadlineSeconds` on the Pod and `livenessProbe` on the Container to +prevent Init Containers from failing forever. The active deadline includes Init +Containers. + +The name of each app and Init Container in a Pod must be unique; a +validation error is thrown for any Container sharing a name with another. + +### Resources + +Given the ordering and execution for Init Containers, the following rules +for resource usage apply: + +* The highest of any particular resource request or limit defined on all Init + Containers is the *effective init request/limit* +* The Pod's *effective request/limit* for a resource is the higher of: + * the sum of all app Containers request/limit for a resource + * the effective init request/limit for a resource +* Scheduling is done based on effective requests/limits, which means + Init Containers can reserve resources for initialization that are not used + during the life of the Pod. +* QoS tier of the Pod's *effective QoS tier* is the QoS tier for Init Containers + and app containers alike. + +Quota and limits are applied based on the effective Pod request and +limit. + +Pod level cgroups are based on the effective Pod request and limit, the +same as the scheduler. + + +### Pod restart reasons + +A Pod can restart, causing re-execution of Init Containers, for the following +reasons: + +* A user updates the PodSpec causing the Init Container image to change. + App Container image changes only restart the app Container. +* The Pod infrastructure container is restarted. This is uncommon and would + have to be done by someone with root access to nodes. +* All containers in a Pod are terminated while `restartPolicy` is set to Always, + forcing a restart, and the Init Container completion record has been lost due + to garbage collection. + +## Support and compatibility + +A cluster with Kubelet and Apiserver version 1.4.0 or greater supports Init +Containers with the beta annotations. Support varies for other combinations of +Kubelet and Apiserver versions; see the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md) for details. + +{% endcapture %} + + +{% capture whatsnext %} + +* [Creating a Pod that has an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) + +{% endcapture %} + + +{% include templates/concept.md %} \ No newline at end of file diff --git a/docs/user-guide/pods/init-container.md b/docs/user-guide/pods/init-container.md index ce7679d40e..90a862ea02 100644 --- a/docs/user-guide/pods/init-container.md +++ b/docs/user-guide/pods/init-container.md @@ -1,168 +1,7 @@ --- -assignees: -- erictune title: Init Containers --- -* TOC -{:toc} - -In addition to having one or more main containers (or **app containers**), a -pod can also have one or more **init containers** which run before the app -containers. Init containers allow you to reduce and reorganize setup scripts -and "glue code". - -## Overview - -An init container is exactly like a regular container, except that it always -runs to completion and each init container must complete successfully before -the next one is started. If the init container fails, Kubernetes will restart -the pod until the init container succeeds. If a pod is marked as `RestartNever`, -the pod will fail if the init container fails. - -You specify a container as an init container by adding an annotation. -The annotation key is `pod.beta.kubernetes.io/init-containers`. The annotation -value is a JSON array of [objects of type `v1.Container` -](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_container) - -Once the feature exits beta, the init containers will be specified on the Pod -Spec alongside the app `containers` array. -The status of the init containers is returned as another annotation - -`pod.beta.kubernetes.io/init-container-statuses` -- as an array of the -container statuses (similar to the `status.containerStatuses` field). - -Init containers support all of the same features as normal containers, -including resource limits, volumes, and security settings. The resource -requests and limits for an init container are [handled slightly differently]( -#resources). Init containers do not support readiness probes since they will -run to completion before the pod can be ready. -An init container has all of the fields of an app container. - -If you specify multiple init containers for a pod, those containers run one at -a time in sequential order. Each must succeed before the next can run. Once all -init containers have run to completion, Kubernetes initializes the pod and runs -the application containers as usual. - -## What are Init Containers Good For? - -Because init containers have separate images from application containers, they -have some advantages for start-up related code. These include: - -* they can contain utilities that are not desirable to include in the app container - image for security reasons, -* they can contain utilities or custom code for setup that is not present in an app - image. (No need to make an image `FROM` another image just to use a tool like - `sed`, `awk`, `python`, `dig`, etc during setup). -* the application image builder and the deployer roles can work independently without - the need to jointly build a single app image. - -Because init containers have different filesystem view (Linux namespaces) from -app containers, they can be given access to Secrets that the app containers are -not able to access. - -Since init containers run to completion before any app containers start, and -since app containers run in parallel, they provide an easier way to block or -delay the startup of application containers until some precondition is met. - -Because init containers run in sequence and there can be multiple init containers, -they can be composed easily. - -Here are some ideas for how to use init containers: -- Wait for a service to be created with a shell command like: - `for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; exit 1` -- Register this pod with a remote server with a command like: - `curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(POD_NAME)&ip=$(POD_IP)'` - using `POD_NAME` and `POD_IP` from the downward API. -- Wait for some time before starting the app container with a command like `sleep 60`. -- Clone a git repository into a volume -- Place values like a POD_IP into a configuration file, and run a template tool (e.g. jinja) - to generate a configuration file to be consumed by the main app contianer. - -Complete usage examples can be found in the [StatefulSets -documentation](/docs/concepts/abstractions/controllers/statefulsets/) and the [Production Pods -guide](/docs/user-guide/production-pods.md#handling-initialization). - - -## Detailed Behavior - -Each pod may have 0..N init containers defined along with the existing -1..M app containers. - -On startup of the pod, after the network and volumes are initialized, the init -containers are started in order. Each container must exit successfully before -the next is invoked. If a container fails to start (due to the runtime) or -exits with failure, it is retried according to the pod RestartPolicy, except -when the pod restart policy is RestartPolicyAlways, in which case just the init -containers use RestartPolicyOnFailure. - -A pod cannot be ready until all init containers have succeeded. The ports on an -init container are not aggregated under a service. A pod that is being -initialized is in the `Pending` phase but should has a condition `Initializing` -set to `true`. - -If the pod is [restarted](#pod-restart-reasons) all init containers must -execute again. - -Changes to the init container spec are limited to the container image field. -Altering an init container image field is equivalent to restarting the pod. - -Because init containers can be restarted, retried, or reexecuted, init container -code should be idempotent. In particular, code that writes to files on EmptyDirs -should be prepared for the possibility that an output file already exists. - -An init container has all of the fields of an app container. The following -fields are prohibited from being used on init containers by validation: - -* `readinessProbe` - init containers must exit for pod startup to continue, - are not included in rotation, and so cannot define readiness distinct from - completion. - -Init container authors may use `activeDeadlineSeconds` on the pod and -`livenessProbe` on the container to prevent init containers from failing -forever. The active deadline includes init containers. - -The name of each app and init container in a pod must be unique - it is a -validation error for any container to share a name. - -### Resources - -Given the ordering and execution for init containers, the following rules -for resource usage apply: - -* The highest of any particular resource request or limit defined on all init - containers is the **effective init request/limit** -* The pod's **effective request/limit** for a resource is the higher of: - * sum of all app containers request/limit for a resource - * effective init request/limit for a resource -* Scheduling is done based on effective requests/limits, which means - init containers can reserve resources for initialization that are not used - during the life of the pod. -* QoS tier of the pod's **effective QoS tier** is the QoS tier for init containers - and app containers alike. - -Quota and limits are applied based on the effective pod request and -limit. - -Pod level cGroups are based on the effective pod request and limit, the -same as the scheduler. - - -## Pod Restart Reasons - -A Pod may "restart", causing reexecution of init containers, for the following -reasons: - -* An init container image is changed by a user updating the Pod Spec. - * App container image changes only restart the app container. -* The pod infrastructure container is restarted. - * This is uncommon and would have to be done by someone with root access to nodes. -* All containers in a pod are terminated, requiring a restart (RestartPolicyAlways) AND the record of init container completion has been lost due to garbage collection. - -## Support and compatibility - -A cluster with Kubelet and Apiserver version 1.4.0 or greater supports init -containers with the beta annotations. Support varies for other combinations of -Kubelet and Apiserver version; see the [release notes -](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md) for details. - +{% include user-guide-content-moved.md %} +* [Init Containers](/docs/concepts/abstractions/init-containers/) \ No newline at end of file From 50db7c5b29684854b0a6d5f30f946c3d5ccd1cc5 Mon Sep 17 00:00:00 2001 From: scjane Date: Thu, 9 Feb 2017 16:18:48 +0800 Subject: [PATCH 092/213] Update accessing-the-cluster.md --- docs/user-guide/accessing-the-cluster.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/user-guide/accessing-the-cluster.md b/docs/user-guide/accessing-the-cluster.md index 8fb9e6b0b4..1f5a65aa61 100644 --- a/docs/user-guide/accessing-the-cluster.md +++ b/docs/user-guide/accessing-the-cluster.md @@ -1,10 +1,10 @@ ---- -assignees: -- lavalamp -- mikedanese -title: Accessing Clusters ---- - +--- +assignees: +- lavalamp +- mikedanese +title: Accessing Clusters +--- + * TOC {:toc} @@ -125,6 +125,7 @@ with future high-availability support. The Kubernetes project-supported Go client library is at [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go). To use it, + * To get the library, run the following command: `go get k8s.io/client-go//kubernetes` See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported. * Write an application atop of the client-go clients. Note that client-go defines its own API objects, so if needed, please import API definitions from client-go rather than from the main repository, e.g., `import "k8s.io/client-go/1.4/pkg/api/v1"` is correct. From efbf64d09d62805707b523aa0e8eeaf90befb8b6 Mon Sep 17 00:00:00 2001 From: Himanshu Raj Date: Thu, 9 Feb 2017 00:09:44 -0800 Subject: [PATCH 093/213] Add Contiv Information to addons.md --- docs/admin/addons.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/admin/addons.md b/docs/admin/addons.md index aeee68cc30..fc1c4ec83c 100644 --- a/docs/admin/addons.md +++ b/docs/admin/addons.md @@ -14,6 +14,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply * [Calico](http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider. * [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy. +* [Contiv](http://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](http://github.com/contiv). The [installer](http://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is an overlay network provider that can be used with Kubernetes. * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. From 1c04cedd412b31bbcd8b708e8ac1033fac8e31a6 Mon Sep 17 00:00:00 2001 From: xilabao Date: Wed, 8 Feb 2017 20:43:18 -0600 Subject: [PATCH 094/213] add authorizationMode to kubeadm config ref to https://github.com/kubernetes/kubernetes/pull/39846 --- docs/admin/kubeadm.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 1014ee1ab6..edf9c87a7d 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -191,6 +191,7 @@ available as configuration file options. externalDNSNames: - - + authorizationMode: cloudProvider: discovery: bindPort: From 76938f5b68aeca4e2368f879851e9bf66d2f7042 Mon Sep 17 00:00:00 2001 From: Klaus Ma Date: Sat, 28 Jan 2017 21:59:13 +0800 Subject: [PATCH 095/213] Updated multiple scheduler beta docs. --- docs/admin/multiple-schedulers.md | 22 ++++++++++------------ docs/admin/multiple-schedulers/pod2.yaml | 3 +-- docs/admin/multiple-schedulers/pod3.yaml | 3 +-- 3 files changed, 12 insertions(+), 16 deletions(-) diff --git a/docs/admin/multiple-schedulers.md b/docs/admin/multiple-schedulers.md index bf7386e492..3e3b4d270b 100644 --- a/docs/admin/multiple-schedulers.md +++ b/docs/admin/multiple-schedulers.md @@ -61,7 +61,7 @@ config. Save it as `my-scheduler.yaml`: {% include code.html language="yaml" file="multiple-schedulers/my-scheduler.yaml" ghlink="/docs/admin/multiple-schedulers/my-scheduler.yaml" %} An important thing to note here is that the name of the scheduler specified as an -argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `scheduler.alpha.kubernetes.io/name` annotation on pods, to determine whether this scheduler is responsible for scheduling a particular pod. +argument to the scheduler command in the container spec should be unique. This is the name that is matched against the value of the optional `spec.schedulername` on pods, to determine whether this scheduler is responsible for scheduling a particular pod. Please see the [kube-scheduler documentation](/docs/admin/kube-scheduler/) for @@ -92,14 +92,14 @@ pod in this list. ### 4. Specify schedulers for pods Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the -scheduler as an annotation in that pod spec. Let's look at three examples. +scheduler in that pod spec. Let's look at three examples. -1. Pod spec without any scheduler annotation +1. Pod spec without any scheduler name {% include code.html language="yaml" file="multiple-schedulers/pod1.yaml" ghlink="/docs/admin/multiple-schedulers/pod1.yaml" %} - When no scheduler annotation is supplied, the pod is automatically scheduled using the + When no scheduler name is supplied, the pod is automatically scheduled using the default-scheduler. Save this file as `pod1.yaml` and submit it to the Kubernetes cluster. @@ -108,12 +108,11 @@ scheduler as an annotation in that pod spec. Let's look at three examples. kubectl create -f pod1.yaml ``` -2. Pod spec with `default-scheduler` annotation +2. Pod spec with `default-scheduler` {% include code.html language="yaml" file="multiple-schedulers/pod2.yaml" ghlink="/docs/admin/multiple-schedulers/pod2.yaml" %} - A scheduler is specified by supplying the scheduler name as a value to the annotation - with key `scheduler.alpha.kubernetes.io/name`. In this case, we supply the name of the + A scheduler is specified by supplying the scheduler name as a value to `spec.schedulername`. In this case, we supply the name of the default scheduler which is `default-scheduler`. Save this file as `pod2.yaml` and submit it to the Kubernetes cluster. @@ -122,13 +121,12 @@ scheduler as an annotation in that pod spec. Let's look at three examples. kubectl create -f pod2.yaml ``` -3. Pod spec with `my-scheduler` annotation +3. Pod spec with `my-scheduler` {% include code.html language="yaml" file="multiple-schedulers/pod3.yaml" ghlink="/docs/admin/multiple-schedulers/pod3.yaml" %} In this case, we specify that this pod should be scheduled using the scheduler that we - deployed - `my-scheduler`. Note that the value of the annotation with key - `scheduler.alpha.kubernetes.io/name` should match the name supplied to the scheduler + deployed - `my-scheduler`. Note that the value of `spec.schedulername` should match the name supplied to the scheduler command as an argument in the deployment config for the scheduler. Save this file as `pod3.yaml` and submit it to the Kubernetes cluster. @@ -149,9 +147,9 @@ In order to make it easier to work through these examples, we did not verify tha pods were actually scheduled using the desired schedulers. We can verify that by changing the order of pod and deployment config submissions above. If we submit all the pod configs to a Kubernetes cluster before submitting the scheduler deployment config, -we see that the pod `annotation-second-scheduler` remains in "Pending" state forever +we see that the pod `second-scheduler` remains in "Pending" state forever while the other two pods get scheduled. Once we submit the scheduler deployment config -and our new scheduler starts running, the `annotation-second-scheduler` pod gets +and our new scheduler starts running, the `second-scheduler` pod gets scheduled as well. Alternatively, one could just look at the "Scheduled" entries in the event logs to diff --git a/docs/admin/multiple-schedulers/pod2.yaml b/docs/admin/multiple-schedulers/pod2.yaml index 2f9fdf9875..26b0376967 100644 --- a/docs/admin/multiple-schedulers/pod2.yaml +++ b/docs/admin/multiple-schedulers/pod2.yaml @@ -2,11 +2,10 @@ apiVersion: v1 kind: Pod metadata: name: annotation-default-scheduler - annotations: - scheduler.alpha.kubernetes.io/name: default-scheduler labels: name: multischeduler-example spec: + schedulername: default-scheduler containers: - name: pod-with-default-annotation-container image: gcr.io/google_containers/pause:2.0 \ No newline at end of file diff --git a/docs/admin/multiple-schedulers/pod3.yaml b/docs/admin/multiple-schedulers/pod3.yaml index 52276df5f6..e64070abfa 100644 --- a/docs/admin/multiple-schedulers/pod3.yaml +++ b/docs/admin/multiple-schedulers/pod3.yaml @@ -2,11 +2,10 @@ apiVersion: v1 kind: Pod metadata: name: annotation-second-scheduler - annotations: - scheduler.alpha.kubernetes.io/name: my-scheduler labels: name: multischeduler-example spec: + schedulername: my-scheduler containers: - name: pod-with-second-annotation-container image: gcr.io/google_containers/pause:2.0 \ No newline at end of file From 601fd27c56f7b9fe5c20f6f288f7bed089199559 Mon Sep 17 00:00:00 2001 From: Robert Roland Date: Fri, 3 Feb 2017 11:23:45 -0800 Subject: [PATCH 096/213] Adds documentation for new vSphere vm-uuid parameter. Related to kubernetes/kubernetes#40892 --- docs/getting-started-guides/vsphere.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/getting-started-guides/vsphere.md b/docs/getting-started-guides/vsphere.md index ba07d14890..61ea733bf3 100644 --- a/docs/getting-started-guides/vsphere.md +++ b/docs/getting-started-guides/vsphere.md @@ -69,6 +69,7 @@ Sample Config: datacenter = datastore = working-dir = + vm-uuid = [Disk] scsicontrollertype = pvscsi ``` From 380fc428863c1cd942c8efe77007b09172f1c794 Mon Sep 17 00:00:00 2001 From: cwitte4191 Date: Fri, 3 Feb 2017 13:52:34 -0600 Subject: [PATCH 097/213] Update service-accounts.md Added an automated code snippet to populate the registrykey on a serviceaccount using jq. --- docs/user-guide/service-accounts.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/user-guide/service-accounts.md b/docs/user-guide/service-accounts.md index d1129a1983..ad1c0a68bf 100644 --- a/docs/user-guide/service-accounts.md +++ b/docs/user-guide/service-accounts.md @@ -147,8 +147,18 @@ NAME TYPE DATA myregistrykey kubernetes.io/.dockerconfigjson 1 ``` -Next, read/modify/write the service account for the namespace to use this secret as an imagePullSecret +Next, read/modify/write the service account for the namespace to use this secret as an imagePullSecret. +Automated version using json and the jq utility: +```shell +kubectl get serviceaccounts default -o json | + jq 'del(.metadata.resourceVersion)'| + jq 'setpath(["imagePullSecrets"];[{"name":"myregistrykey"}])' | + kubectl replace serviceaccount default -f - + +``` + +Interactive version requiring manual edit: ```shell $ kubectl get serviceaccounts default -o yaml > ./sa.yaml $ cat sa.yaml From 94aab012c02ae53ff0445513ea495f27afecab48 Mon Sep 17 00:00:00 2001 From: Phillip Wittrock Date: Wed, 8 Feb 2017 17:03:17 -0800 Subject: [PATCH 098/213] Kubectl task document for printing out containers in a cluster. --- _data/tasks.yml | 4 + .../list-all-running-container-images.md | 122 ++++++++++++++++++ 2 files changed, 126 insertions(+) create mode 100644 docs/tasks/kubectl/list-all-running-container-images.md diff --git a/_data/tasks.yml b/_data/tasks.yml index de066c9ed2..f301de1edc 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -3,6 +3,10 @@ abstract: "Step-by-step instructions for performing operations with Kubernetes." toc: - docs/tasks/index.md +- title: Using the Kubectl Command-Line + section: + - docs/tasks/kubectl/list-all-running-container-images.md + - title: Configuring Pods and Containers section: - docs/tasks/configure-pod-container/define-environment-variable-container.md diff --git a/docs/tasks/kubectl/list-all-running-container-images.md b/docs/tasks/kubectl/list-all-running-container-images.md new file mode 100644 index 0000000000..4fb64ee442 --- /dev/null +++ b/docs/tasks/kubectl/list-all-running-container-images.md @@ -0,0 +1,122 @@ +--- +title: Listing all Container images running in the cluster +--- + +{% capture overview %} + +This page shows how to use kubectl to list all of the Container images +for Pods running in a cluster. + +{% endcapture %} + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + +{% capture steps %} + +In this exercise you will use kubectl to fetch all of the Pods +running in a cluster, and format the output to pull out the list +of Containers for each. + +## List all Containers in all namespaces + +- Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces` +- Format the output to include only the list of Container image names + using `-o jsonpath={..image}`. This will recursively parse out the + `image` field from the returned json. + - See the [jsonpath reference](/docs/user-guide/jsonpath/) + for further information on how to use jsonpath. +- Format the output using standard tools: `tr`, `sort`, `uniq` + - Use `tr` to replace spaces with newlines + - Use `sort` to sort the results + - Use `uniq` to aggregate image counts + +```sh +kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +tr -s '[[:space:]]' '\n' |\ +sort |\ +uniq -c +``` + +The above command will recursively return all fields named `image` +for all items returned. + +As an alternative, it is possible to use the absolute path to the image +field within the Pod. This ensures the correct field is retrieved +in the even the field name is repeated, +e.g. many fields are called `name` within a given item: + +```sh +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +The jsonpath is interpreted as follows: + +- `.items[*]`: for each returned value +- `.spec`: get the spec +- `.containers[*]`: for each container +- `.image`: get the image + +**Note:** When fetching a single Pod by name, e.g. `kubect get pod nginx`, +the `.items[*]` portion of the path should be omitted because a single +Pod is returned instead of a list of items. + +## List Containers by Pod + +The formatting can be controlled further by using the `range` operation to +iterate over elements individually. + +```sh +kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +sort +``` + +## List Containers filtering by Pod label + +To target only Pods matching a specific label, use the -l flag. The +following matches only Pods with labels matching `app=nginx`. + +```sh +kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +``` + +## List Containers filtering by Pod namespace + +To target only pods in a specific namespace, use the namespace flag. The +following matches only Pods in the `kube-system` namespace. + +```sh +kubectl get pods --namespace kube-system -o jsonpath="{..image}" +``` + +## List Containers using a go-template instead of jsonpath + +As an alternative to jsonpath, Kubectl supports using [go-templates](https://golang.org/pkg/text/template/) +for formatting the output: + +{% raw %} +```sh +kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" +``` +{% endraw %} + + +{% endcapture %} + +{% capture discussion %} + +{% endcapture %} + +{% capture whatsnext %} + +### Reference + +* [Jsonpath](/docs/user-guide/jsonpath/) reference guide +* [Go template](https://golang.org/pkg/text/template/) reference guide + +{% endcapture %} + +{% include templates/task.md %} From 3a993cdadc42db2ae7d38de270cd4a74aeb4cbbb Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Thu, 9 Feb 2017 14:08:54 -0800 Subject: [PATCH 099/213] New Task: Exposing Pod Info ... Env Vars --- _data/tasks.yml | 1 + .../dapi-envars-container.yaml | 45 +++++ .../dapi-envars-pod.yaml | 38 ++++ ...ronment-variable-expose-pod-information.md | 163 ++++++++++++++++++ 4 files changed, 247 insertions(+) create mode 100644 docs/tasks/configure-pod-container/dapi-envars-container.yaml create mode 100644 docs/tasks/configure-pod-container/dapi-envars-pod.yaml create mode 100644 docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md diff --git a/_data/tasks.yml b/_data/tasks.yml index f301de1edc..cb61b1a05a 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -14,6 +14,7 @@ toc: - docs/tasks/configure-pod-container/assign-cpu-ram-container.md - docs/tasks/configure-pod-container/configure-volume-storage.md - docs/tasks/configure-pod-container/configure-persistent-volume-storage.md + - docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md - docs/tasks/configure-pod-container/distribute-credentials-secure.md - docs/tasks/configure-pod-container/pull-image-private-registry.md - docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md diff --git a/docs/tasks/configure-pod-container/dapi-envars-container.yaml b/docs/tasks/configure-pod-container/dapi-envars-container.yaml new file mode 100644 index 0000000000..8b3b3a39d3 --- /dev/null +++ b/docs/tasks/configure-pod-container/dapi-envars-container.yaml @@ -0,0 +1,45 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-envars-resourcefieldref +spec: + containers: + - name: test-container + image: gcr.io/google_containers/busybox:1.24 + command: [ "sh", "-c"] + args: + - while true; do + echo -en '\n'; + printenv MY_CPU_REQUEST MY_CPU_LIMIT; + printenv MY_MEM_REQUEST MY_MEM_LIMIT; + sleep 10; + done; + resources: + requests: + memory: "32Mi" + cpu: "125m" + limits: + memory: "64Mi" + cpu: "250m" + env: + - name: MY_CPU_REQUEST + valueFrom: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + - name: MY_CPU_LIMIT + valueFrom: + resourceFieldRef: + containerName: test-container + resource: limits.cpu + - name: MY_MEM_REQUEST + valueFrom: + resourceFieldRef: + containerName: test-container + resource: requests.memory + - name: MY_MEM_LIMIT + valueFrom: + resourceFieldRef: + containerName: test-container + resource: limits.memory + restartPolicy: Never diff --git a/docs/tasks/configure-pod-container/dapi-envars-pod.yaml b/docs/tasks/configure-pod-container/dapi-envars-pod.yaml new file mode 100644 index 0000000000..00762373b3 --- /dev/null +++ b/docs/tasks/configure-pod-container/dapi-envars-pod.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-envars-fieldref +spec: + containers: + - name: test-container + image: gcr.io/google_containers/busybox + command: [ "sh", "-c"] + args: + - while true; do + echo -en '\n'; + printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE; + printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT; + sleep 10; + done; + env: + - name: MY_NODE_NAME + valueFrom: + fieldRef: + fieldPath: spec.nodeName + - name: MY_POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name + - name: MY_POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace + - name: MY_POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP + - name: MY_POD_SERVICE_ACCOUNT + valueFrom: + fieldRef: + fieldPath: spec.serviceAccountName + restartPolicy: Never diff --git a/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md b/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md new file mode 100644 index 0000000000..1390727000 --- /dev/null +++ b/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md @@ -0,0 +1,163 @@ +--- +title: Exposing Pod Information to Containers Through Environment Variables +--- + +{% capture overview %} + +This page shows how a Pod can use environment variables to expose information +about itself to Containers running in the Pod. Environment variables can expose +Pod fields and Container fields. + +There are two ways to expose Pod and Container fields to a running Container: +environment variables and +[DownwardAPIVolumeFiles](/docs/resources-reference/v1.5/#downwardapivolumefile-v1). +Together, these two ways of exposing Pod and Container fields are called the +*Downward API*. + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + + +{% capture steps %} + +## Using Pod fields as values for environment variables + +In this exercise, you create a Pod that has one Container. Here is the +configuration file for the Pod: + +{% include code.html language="yaml" file="dapi-envars-pod.yaml" ghlink="/docs/tasks/configure-pod-container/dapi-envars-pod.yaml" %} + +In the configuration file, you can see five environment variables. The `env` +field is an array of +[EnvVars](/docs/resources-reference/v1.5/#envvar-v1). +The first element in the array specifies that the `MY_NODE_NAME` environment +variable gets its value from the Pod's `spec.nodeName` field. Similarly, the +other environment variables get their names from Pod fields. + +**Note**: The fields in this example are Pod fields. They are not fields of the +Container in the Pod. + +Create the Pod: + +```shell +kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/dapi-envars-pod.yaml +``` + +Verify that the Container in the Pod is running: + +``` +kubectl get pods +``` + +View the Container's logs: + +``` +kubectl logs dapi-envars-fieldref +``` + +The output shows the values of selected environment variables: + +``` +minikube +dapi-envars-fieldref +default +172.17.0.4 +default +``` + +To see why these values are in the log, look at the `command` and `args` fields +in the configuration file. When the Container starts, it writes the values of +five environment variables to stdout. It repeats this every ten seconds. + +Next, get a shell into the Container that is running in your Pod: + +``` +kubectl exec -it dapi-envars-fieldref -- sh +``` + +In your shell, view the environment variables: + +``` +/# printenv +``` + +The output shows that certain environment variables have been assigned the +values of Pod fields: + +``` +MY_POD_SERVICE_ACCOUNT=default +... +MY_POD_NAMESPACE=default +MY_POD_IP=172.17.0.4 +... +MY_NODE_NAME=minikube +... +MY_POD_NAME=dapi-envars-fieldref +``` + +## Using Container fields as values for environment variables + +In the preceding exercise, you used Pod fields as the values for environment +variables. In this next exercise, you use Container fields as the values for +environment variables. Here is the configuration file for a Pod that has one +container: + +{% include code.html language="yaml" file="dapi-envars-container.yaml" ghlink="/docs/tasks/configure-pod-container/dapi-envars-container.yaml" %} + +In the configuration file, you can see four environment variables. The `env` +field is an array of +[EnvVars](/docs/resources-reference/v1.5/#envvar-v1). +The first element in the array specifies that the `MY_CPU_REQUEST` environment +variable gets its value from the `requests.cpu` field of a Container named +`test-container`. Similarly, the other environment variables get their values +from Container fields. + +Create the Pod: + +```shell +kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/dapi-envars-container.yaml +``` + +Verify that the Container in the Pod is running: + +``` +kubectl get pods +``` + +View the Container's logs: + +``` +kubectl logs dapi-envars-resourcefieldref +``` + +The output shows the values of selected environment variables: + +``` +1 +1 +33554432 +67108864 +``` + +{% endcapture %} + +{% capture whatsnext %} + +* [Defining Environment Variables for a Container](/docs/tasks/configure-pod-container/define-environment-variable-container/) +* [PodSpec](/docs/resources-reference/v1.5/#podspec-v1) +* [Container](/docs/resources-reference/v1.5/#container-v1) +* [EnvVar](/docs/resources-reference/v1.5/#envvar-v1) +* [EnvVarSource](/docs/resources-reference/v1.5/#envvarsource-v1) +* [ObjectFieldSelector](/docs/resources-reference/v1.5/#objectfieldselector-v1) +* [ResourceFieldSelector](/docs/resources-reference/v1.5/#resourcefieldselector-v1) + +{% endcapture %} + + +{% include templates/task.md %} From 10d678bfc81cecf533e981529f700a0c0859af5c Mon Sep 17 00:00:00 2001 From: Jeff Mendoza Date: Fri, 10 Feb 2017 13:15:15 -0800 Subject: [PATCH 100/213] Fix Travis test builds' vendoring workaround. --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index e527e16dbc..09a28b78cb 100644 --- a/.travis.yml +++ b/.travis.yml @@ -13,6 +13,7 @@ install: - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apimachinery - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go +- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/sample-apiserver - cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ - rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* - cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ From b51f5a2e2c276884eec36f0a82eef4c76c9a286e Mon Sep 17 00:00:00 2001 From: Jasmine Hegman Date: Wed, 8 Feb 2017 17:22:46 -0700 Subject: [PATCH 101/213] Fixed a tiny typo Kubernets -> Kubernetes --- docs/user-guide/logging/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/logging/overview.md b/docs/user-guide/logging/overview.md index a9f00471cc..42b9087172 100644 --- a/docs/user-guide/logging/overview.md +++ b/docs/user-guide/logging/overview.md @@ -68,7 +68,7 @@ When you run [`kubectl logs`](/docs/user-guide/kubectl/kubectl_logs), as in the There are two types of system components: those that run in a container and those that do not run in a container. For example: -* The Kubernets scheduler and kube-proxy run in a container. +* The Kubernetes scheduler and kube-proxy run in a container. * The kubelet and container runtime, for example Docker, do not run in containers. On machines with systemd, the kubelet and container runtime write to journald. If From 2f351db5bbfeec8e226fc2da8a0b6a9cffd8a7df Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Wimsingues?= Date: Wed, 8 Feb 2017 11:28:26 +0100 Subject: [PATCH 102/213] redundnacy => redundancy --- 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 3f131c6358..93e4533caf 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -44,7 +44,7 @@ For example, when you use the Kubernetes API to create a Deployment object, you The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master. -> The "master" refers to a collection of processes managing the cluster state. Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundnacy. +> The "master" refers to a collection of processes managing the cluster state. Typically these processes are all run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy. ### Kubernetes Nodes From 715ccb48e8f34614bc9d15cc077827bed2da53a6 Mon Sep 17 00:00:00 2001 From: scjane Date: Mon, 13 Feb 2017 11:08:33 +0800 Subject: [PATCH 103/213] Update cron-jobs.md --- docs/user-guide/cron-jobs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/cron-jobs.md b/docs/user-guide/cron-jobs.md index 55b85adf46..34402d5568 100644 --- a/docs/user-guide/cron-jobs.md +++ b/docs/user-guide/cron-jobs.md @@ -19,10 +19,10 @@ A _Cron Job_ manages time based [Jobs](/docs/user-guide/jobs/), namely: One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format. -**Note:**: The question mark (`?`) in the schedule has the same meaning as an asterisk `*`, +**Note:** The question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field. -**Note:**: ScheduledJob resource was introduced in Kubernetes version 1.4, but starting +**Note:** ScheduledJob resource was introduced in Kubernetes version 1.4, but starting from version 1.5 its current name is CronJob. A typical use case is: From 822d00df62dbd39e8cab1f6265b6298e4d4d513c Mon Sep 17 00:00:00 2001 From: scjane Date: Mon, 13 Feb 2017 10:40:57 +0800 Subject: [PATCH 104/213] Update index.md --- docs/user-guide/jobs/expansions/index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/user-guide/jobs/expansions/index.md b/docs/user-guide/jobs/expansions/index.md index 767ac65215..f401574519 100644 --- a/docs/user-guide/jobs/expansions/index.md +++ b/docs/user-guide/jobs/expansions/index.md @@ -111,7 +111,7 @@ In the first example, each instance of the template had one parameter, and that used as a label. However label keys are limited in [what characters they can contain](/docs/user-guide/labels/#syntax-and-character-set). -This slightly more complex example uses a the jinja2 template language to generate our objects. +This slightly more complex example uses the jinja2 template language to generate our objects. We will use a one-line python script to convert the template to a file. First, copy and paste the following template of a Job object, into a file called `job.yaml.jinja2`: @@ -179,6 +179,7 @@ cat job.yaml.jinja2 | render_template | kubectl create -f - ## Alternatives If you have a large number of job objects, you may find that: + - even using labels, managing so many Job objects is cumbersome. - You exceed resource quota when creating all the Jobs at once, and do not want to wait to create them incrementally. From 58322206bd4a8ccc635e824ca6d2eb853de96371 Mon Sep 17 00:00:00 2001 From: PassionForPie Date: Sun, 12 Feb 2017 23:57:39 +0000 Subject: [PATCH 105/213] Minor grammatical fix See https://en.wiktionary.org/wiki/greengrocer's_apostrophe --- docs/tutorials/kubernetes-basics/expose-intro.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/kubernetes-basics/expose-intro.html b/docs/tutorials/kubernetes-basics/expose-intro.html index 9ee7a4117a..ad4394b0e4 100644 --- a/docs/tutorials/kubernetes-basics/expose-intro.html +++ b/docs/tutorials/kubernetes-basics/expose-intro.html @@ -28,7 +28,7 @@ title: Using a Service to Expose Your App

Kubernetes Services

-

While Pods do have their own unique IP across the cluster, those IP's are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.

+

While Pods do have their own unique IP across the cluster, those IPs are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.

This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:

    From 9197fb582278638eab4ebe644ca402166f595792 Mon Sep 17 00:00:00 2001 From: scjane Date: Fri, 10 Feb 2017 18:32:47 +0800 Subject: [PATCH 106/213] Update jobs.md --- docs/user-guide/jobs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index cc2f9d38c3..d48b856ae3 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -63,7 +63,7 @@ Events: To view completed pods of a job, use `kubectl get pods --show-all`. The `--show-all` will show completed pods too. -To list all the pods that belong to job in a machine readable form, you can use a command like this: +To list all the pods that belong to a job in a machine readable form, you can use a command like this: ```shell $ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name}) @@ -100,7 +100,7 @@ the same schema as a [pod](/docs/user-guide/pods), except it is nested and does In addition to required fields for a Pod, a pod template in a job must specify appropriate labels (see [pod selector](#pod-selector)) and an appropriate restart policy. -Only a [`RestartPolicy`](/docs/user-guide/pod-states/#restartpolicy) equal to `Never` or `OnFailure` are allowed. +Only a [`RestartPolicy`](/docs/user-guide/pod-states/#restartpolicy) equal to `Never` or `OnFailure` is allowed. ### Pod Selector From c3b483c49f36ee24bfeaa6a9a4d77ef775b3d572 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Wimsingues?= Date: Wed, 8 Feb 2017 11:05:16 +0100 Subject: [PATCH 107/213] Update overview.md comamnd => command --- docs/concepts/abstractions/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/overview.md b/docs/concepts/abstractions/overview.md index dc2e8cf7ab..1a84d74534 100644 --- a/docs/concepts/abstractions/overview.md +++ b/docs/concepts/abstractions/overview.md @@ -17,7 +17,7 @@ This page explains how Kubernetes objects are represented in the Kubernetes API, A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that that object exists. By creating an object, you're effectively telling the Kubernetes system what you want your cluster's workload to look like; this is your cluster's **desired state**. -To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md). When you use the `kubectl` comamnd-line interface, for example, the CLI makes the necessary Kubernetes API calls for you; you can also use the Kubernetes API directly in your own programs. Kubernetes currently provides a `golang` [client library](https://github.com/kubernetes/client-go) for this purpose, and other language libraries (such as [Python](https://github.com/kubernetes-incubator/client-python)) are being developed. +To work with Kubernetes objects--whether to create, modify, or delete them--you'll need to use the [Kubernetes API](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md). When you use the `kubectl` command-line interface, for example, the CLI makes the necessary Kubernetes API calls for you; you can also use the Kubernetes API directly in your own programs. Kubernetes currently provides a `golang` [client library](https://github.com/kubernetes/client-go) for this purpose, and other language libraries (such as [Python](https://github.com/kubernetes-incubator/client-python)) are being developed. ### Object Spec and Status From eccf13d47b847485de34e7c2547a8fe7549ece63 Mon Sep 17 00:00:00 2001 From: Bruce Auyeung Date: Fri, 10 Feb 2017 11:02:18 +0800 Subject: [PATCH 108/213] Update kubefed.md --- docs/admin/federation/kubefed.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/admin/federation/kubefed.md b/docs/admin/federation/kubefed.md index 695edf7bee..4af8db60b5 100644 --- a/docs/admin/federation/kubefed.md +++ b/docs/admin/federation/kubefed.md @@ -36,11 +36,11 @@ in your `$PATH` and set the executable permission on those binaries. Note: The URL in the curl command below downloads the binaries for Linux amd64. If you are on a different platform, please use the URL for the binaries appropriate for your platform. You can find the list -of available binaries on the [release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-3). +of available binaries on the [release page](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#client-binaries-1). ```shell -curl -O https://storage.googleapis.com/kubernetes-release/release/v1.5.0/kubernetes-client-linux-amd64.tar.gz +curl -O https://storage.googleapis.com/kubernetes-release/release/v1.5.2/kubernetes-client-linux-amd64.tar.gz tar -xzvf kubernetes-client-linux-amd64.tar.gz sudo cp kubernetes/client/bin/kubefed /usr/local/bin sudo chmod +x /usr/local/bin/kubefed @@ -78,7 +78,7 @@ control plane. ## Deploying a federation control plane. -"To deploy a federation control plane on your host cluster, run +To deploy a federation control plane on your host cluster, run `kubefed init` command. When you use `kubefed init`, you must provide the following: @@ -94,7 +94,7 @@ domain suffix `example.com`: kubefed init fellowship --host-cluster-context=rivendell --dns-zone-name="example.com" ``` -The domain suffix you specify in `--dns-zone-name` must be an existing +The domain suffix specified in `--dns-zone-name` must be an existing domain that you control, and that is programmable by your DNS provider. `kubefed init` sets up the federation control plane in the host From 0123149feb11612d5b6a3806be2d373f55b490fb Mon Sep 17 00:00:00 2001 From: Ahmet Alp Balkan Date: Mon, 13 Feb 2017 09:21:14 -0800 Subject: [PATCH 109/213] Add SIG meetings calendar to /community/ Signed-off-by: Ahmet Alp Balkan --- community/index.html | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/community/index.html b/community/index.html index 201c70a776..5843b4829e 100644 --- a/community/index.html +++ b/community/index.html @@ -27,6 +27,13 @@ cid: community lists of SIGs, from AWS and Openstack to Big Data and Scalability, there's a place for you to contribute and instructions for forming a new SIG if your special interest isn't covered (yet).

    + +

    As a member of the Kubernetes community, you are welcome to join any of the SIG meetings + you are interested in. No registration required.

    +
    + +

Events

From 34ff10be2fbc78dcd8fd71385d12e16009d02809 Mon Sep 17 00:00:00 2001 From: Jason Lock Date: Fri, 30 Dec 2016 09:31:06 -0800 Subject: [PATCH 110/213] Increase font-size and line-height CSS Properties Increase the font-size and line-height CSS properties for the paragraph and list items within the documentation body content. Adjusting these properties will make the information a little easier to read. --- _sass/_base.sass | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/_sass/_base.sass b/_sass/_base.sass index 72557bb983..3149232bec 100644 --- a/_sass/_base.sass +++ b/_sass/_base.sass @@ -816,9 +816,9 @@ dd font-weight: 500 p - font-size: 14px + font-size: 16px font-weight: 300 - line-height: 1.25em + line-height: 1.75em p + p margin-top: 10px @@ -894,6 +894,7 @@ dd li margin-bottom: 0.75em + font-size: 16px table width: 100% From 896c2ddd184112186bff9a31ab86b8d05b348ea0 Mon Sep 17 00:00:00 2001 From: Jason Lock Date: Fri, 30 Dec 2016 09:58:26 -0800 Subject: [PATCH 111/213] Add line-height to List Item Add line-height to the body content list items. The same line-height as the paragraph. --- _sass/_base.sass | 1 + 1 file changed, 1 insertion(+) diff --git a/_sass/_base.sass b/_sass/_base.sass index 3149232bec..4b9e051af4 100644 --- a/_sass/_base.sass +++ b/_sass/_base.sass @@ -895,6 +895,7 @@ dd li margin-bottom: 0.75em font-size: 16px + line-height: 1.75em table width: 100% From 809c1b8ebe32b973bfa9646eb26fa0556874b5ab Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Mon, 13 Feb 2017 10:05:51 -0800 Subject: [PATCH 112/213] reimplement PR #2217 socks shop port changed --- docs/getting-started-guides/kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index a4e5679ffb..a2d4e1b834 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -269,7 +269,7 @@ It takes several minutes to download and start all the containers, watch the out Then go to the IP address of your cluster's master node in your browser, and specify the given port. So for example, `http://:`. -In the example above, this was `31869`, but it is a different port for you. +In the example above, this was `30001`, but it is a different port for you. If there is a firewall, make sure it exposes this port to the internet before you try to access it. From 49dea6f23b3244e3c4d54f8e400ec066e4deb4df Mon Sep 17 00:00:00 2001 From: samiam Date: Mon, 13 Feb 2017 11:18:16 -0500 Subject: [PATCH 113/213] Update kubectl_completion.md Quote shell commands to improve format --- docs/user-guide/kubectl/kubectl_completion.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/kubectl/kubectl_completion.md b/docs/user-guide/kubectl/kubectl_completion.md index 125b7791cd..f870bbd482 100644 --- a/docs/user-guide/kubectl/kubectl_completion.md +++ b/docs/user-guide/kubectl/kubectl_completion.md @@ -11,17 +11,19 @@ Output shell completion code for the given shell (bash or zsh). This command prints shell code which must be evaluation to provide interactive completion of kubectl commands. - $ source <(kubectl completion bash) + `$ source <(kubectl completion bash)` will load the kubectl completion code for bash. Note that this depends on the bash-completion framework. It must be sourced before sourcing the kubectl completion, e.g. on the Mac: +``` $ brew install bash-completion $ source $(brew --prefix)/etc/bash_completion $ source <(kubectl completion bash) +``` If you use zsh [1], the following will load kubectl zsh completion: - $ source <(kubectl completion zsh) + `$ source <(kubectl completion zsh)` [1] zsh completions are only supported in versions of zsh >= 5.2 From 3808e4ccd786b78f4411cf61e2153113f873c974 Mon Sep 17 00:00:00 2001 From: Andreas Kohn Date: Mon, 13 Feb 2017 15:42:53 +0100 Subject: [PATCH 114/213] Improve grammar --- docs/user-guide/jsonpath.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/jsonpath.md b/docs/user-guide/jsonpath.md index 74ce7bbc77..54c2780da8 100644 --- a/docs/user-guide/jsonpath.md +++ b/docs/user-guide/jsonpath.md @@ -6,8 +6,8 @@ JSONPath template is composed of JSONPath expressions enclosed by {}. And we add three functions in addition to the original JSONPath syntax: 1. The `$` operator is optional since the expression always start from the root object by default. -2. We can use `""` to quote text inside JSONPath expression. -3. We can use `range` operator to iterate list. +2. We can use `""` to quote text inside JSONPath expressions. +3. We can use `range` operator to iterate lists. The result object is printed as its String() function. From 3137a4926a2c77d229f14a50c0e5fd40ef720d5d Mon Sep 17 00:00:00 2001 From: scjane Date: Mon, 13 Feb 2017 17:10:28 +0800 Subject: [PATCH 115/213] Update index.md --- docs/user-guide/jobs/work-queue-2/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/jobs/work-queue-2/index.md b/docs/user-guide/jobs/work-queue-2/index.md index 5e2e8a03ec..4fd806d392 100644 --- a/docs/user-guide/jobs/work-queue-2/index.md +++ b/docs/user-guide/jobs/work-queue-2/index.md @@ -47,7 +47,7 @@ If you're not working from the source tree, you could also download [`redis-pod. ## Filling the Queue with tasks -Now lets fill the queue with some "tasks". In our example, our tasks are just strings to be +Now let's fill the queue with some "tasks". In our example, our tasks are just strings to be printed. Start a temporary interactive pod for running the Redis CLI From 01cea0c7139002c506f63e7f6c12ea54a088388b Mon Sep 17 00:00:00 2001 From: caiyixiang Date: Mon, 13 Feb 2017 16:54:22 +0800 Subject: [PATCH 116/213] Update source-ip.md --- docs/tutorials/services/source-ip.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md index 56daa8b345..e1eac87c4e 100644 --- a/docs/tutorials/services/source-ip.md +++ b/docs/tutorials/services/source-ip.md @@ -20,8 +20,8 @@ of Services, and how you can toggle this behavior according to your needs. This document makes use of the following terms: * [NAT](https://en.wikipedia.org/wiki/Network_address_translation): network address translation -* [Source NAT](/docs/user-guide/services/#ips-and-vips): replacing the source IP on a packet, usually with a node's IP -* [Destination NAT](/docs/user-guide/services/#ips-and-vips): replacing the destination IP on a packet, usually with a pod IP +* [Source NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): replacing the source IP on a packet, usually with a node's IP +* [Destination NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): replacing the destination IP on a packet, usually with a pod IP * [VIP](/docs/user-guide/services/#ips-and-vips): a virtual IP, such as the one assigned to every Kubernetes Service * [Kube-proxy](/docs/user-guide/services/#virtual-ips-and-service-proxies): a network daemon that orchestrates Service VIP management on every node From a5fe6ae18b2ecda9947c2c7c04a6785c357439cc Mon Sep 17 00:00:00 2001 From: foxyriver Date: Mon, 13 Feb 2017 15:24:26 +0800 Subject: [PATCH 117/213] fix parallelism result According to job.yaml, the parallelism is 2 --- docs/user-guide/jobs/work-queue-1/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/jobs/work-queue-1/index.md b/docs/user-guide/jobs/work-queue-1/index.md index 4ce1ffb667..f926f4211f 100644 --- a/docs/user-guide/jobs/work-queue-1/index.md +++ b/docs/user-guide/jobs/work-queue-1/index.md @@ -227,7 +227,7 @@ Name: job-wq-1 Namespace: default Image(s): gcr.io/causal-jigsaw-637/job-wq-1 Selector: app in (job-wq-1) -Parallelism: 4 +Parallelism: 2 Completions: 8 Labels: app=job-wq-1 Pods Statuses: 0 Running / 8 Succeeded / 0 Failed From 068818e1c68596bcfd9262fad1e6434778d53084 Mon Sep 17 00:00:00 2001 From: Christoph Blecker Date: Thu, 9 Feb 2017 17:41:08 -0800 Subject: [PATCH 118/213] Fix link to StatefulSet docs from Pods page --- docs/user-guide/pods/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/user-guide/pods/index.md b/docs/user-guide/pods/index.md index 321900c948..47e2dcaf3b 100644 --- a/docs/user-guide/pods/index.md +++ b/docs/user-guide/pods/index.md @@ -1,5 +1,5 @@ --- -assignees: +assignees: title: Pods --- @@ -60,7 +60,7 @@ related thing (e.g. volume) is also destroyed and created anew. ![pod diagram](/images/docs/pod.svg){: style="max-width: 50%" } -*A multi-container pod that contains a file puller and a +*A multi-container pod that contains a file puller and a web server that uses a persistent volume for shared storage between the containers.* ## Motivation for pods @@ -150,7 +150,7 @@ Pod is exposed as a primitive in order to facilitate: * clean composition of Kubelet-level functionality with cluster-level functionality — Kubelet is effectively the "pod controller" * high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions, image prefetching, or live pod migration [#3949](http://issue.k8s.io/3949) -There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/user-guide/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). +There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/abstractions/controllers/statefulsets/) controller (currently in beta). The feature was alpha in 1.4 and was called [PetSet](/docs/user-guide/petset/). For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). ## Termination of Pods @@ -168,7 +168,7 @@ An example flow: 6. When the grace period expires, any processes still running in the Pod are killed with SIGKILL. 7. The Kubelet will finish deleting the Pod on the API server by setting grace period 0 (immediate deletion). The Pod disappears from the API and is no longer visible from the client. -By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/user-guide/pods/#force-termination-of-pods) the pod. In kubectl version >= 1.5, you must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. +By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports the `--grace-period=` option which allows a user to override the default and specify their own value. The value `0` [force deletes](/docs/user-guide/pods/#force-termination-of-pods) the pod. In kubectl version >= 1.5, you must specify an additional flag `--force` along with `--grace-period=0` in order to perform force deletions. ### Force deletion of pods From f1ffbe959903983532d13d1c0eb84c6cd310fcad Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Fri, 10 Feb 2017 11:47:39 +0800 Subject: [PATCH 119/213] replace 30 seconds with 35 seconds replace 30 seconds with 35 seconds --- .../configure-liveness-readiness-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index 8c877ac16c..d168ceb211 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -84,7 +84,7 @@ FirstSeen LastSeen Count From SubobjectPath Type 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e ``` -After 30 seconds, view the Pod events again: +After 35 seconds, view the Pod events again: ```shell kubectl describe pod liveness-exec From a35d5d3320f88f36f0017eb6e4662a75d97496f7 Mon Sep 17 00:00:00 2001 From: Ahmet Alp Balkan Date: Fri, 10 Feb 2017 14:48:21 -0800 Subject: [PATCH 120/213] Move "User Guide" up in the sidebar So that it is above "Accessing the Cluster" article which describes more advanced topics and does not look coherent when it is read linearly. Signed-off-by: Ahmet Alp Balkan --- _data/guides.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_data/guides.yml b/_data/guides.yml index 511ece0885..98ef2db801 100644 --- a/_data/guides.yml +++ b/_data/guides.yml @@ -5,6 +5,8 @@ toc: - docs/whatisk8s.md +- docs/user-guide/index.md + - title: Accessing the Cluster section: - docs/user-guide/prereqs.md @@ -12,8 +14,6 @@ toc: - docs/user-guide/sharing-clusters.md - docs/user-guide/kubeconfig-file.md -- docs/user-guide/index.md - - docs/user-guide/ui.md - title: Workload Deployment and Management From e79c6662f52c1862db9b4736fdb9a573d179c0bf Mon Sep 17 00:00:00 2001 From: Jesse Johnston Date: Thu, 9 Feb 2017 09:14:26 -0800 Subject: [PATCH 121/213] Update overview.md Update link to Kubernetes API Conventions to point to current document location. --- docs/concepts/abstractions/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/overview.md b/docs/concepts/abstractions/overview.md index 1a84d74534..712ad0f99f 100644 --- a/docs/concepts/abstractions/overview.md +++ b/docs/concepts/abstractions/overview.md @@ -25,7 +25,7 @@ Every Kubernetes object includes two nested object fields that govern the object For example, a Kubernetes Deployment is an object that can represent an application running on your cluster. When you create the Deployment, you might set the Deployment spec to specify that you want three replicas of the application to be running. The Kubernetes system reads the Deployment spec and starts three instances of your desired application--updating the status to match your spec. If any of those instances should fail (a status change), the Kubernetes system responds to the difference between spec and status by making a correction--in this case, starting a replacement instance. -For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#spec-and-status). +For more information on the object spec, status, and metadata, see the [Kubernetes API Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md). ### Describing a Kubernetes Object From fe9a0c14476e3872c19d6151424d801ea8792c60 Mon Sep 17 00:00:00 2001 From: Erik Bean Date: Mon, 13 Feb 2017 13:25:40 -0800 Subject: [PATCH 122/213] Fix unmatched closing paren End of line 60 had a closing parenthesis, with no opening one to match. Probably left over from a previous version of the document --- docs/concepts/abstractions/pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/pod.md b/docs/concepts/abstractions/pod.md index f8b9cf2f72..5c364c5376 100644 --- a/docs/concepts/abstractions/pod.md +++ b/docs/concepts/abstractions/pod.md @@ -57,7 +57,7 @@ Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fail ### Pods and Controllers -A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node). +A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node. Some examples of Controllers that contain one or more pods include: From ec8fd54d0fa8a91b463907236eed6a37c22f198e Mon Sep 17 00:00:00 2001 From: Albert Vaca Date: Mon, 13 Feb 2017 20:58:10 +0100 Subject: [PATCH 123/213] Updated dead links --- docs/user-guide/ingress.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/ingress.md b/docs/user-guide/ingress.md index 809a025c57..009fd13f45 100644 --- a/docs/user-guide/ingress.md +++ b/docs/user-guide/ingress.md @@ -220,7 +220,7 @@ Note that there is a gap between TLS features supported by various Ingress contr An Ingress controller is bootstrapped with some loadbalancing policy settings that it applies to all Ingress, such as the loadbalancing algorithm, backend weight scheme etc. More advanced loadbalancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/contrib/tree/master/service-loadbalancer). With time, we plan to distill loadbalancing patterns that are applicable cross platform into the Ingress resource. -It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/README.md), [GCE](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/README.md#health-checks)). +It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://github.com/kubernetes/ingress/blob/master/controllers/nginx/README.md), [GCE](https://github.com/kubernetes/ingress/blob/master/controllers/gce/README.md#health-checks)). ## Updating an Ingress From 2a597e378960b2256536feb3e8944cda4c379ced Mon Sep 17 00:00:00 2001 From: James Gregory Date: Tue, 14 Feb 2017 11:01:07 +1100 Subject: [PATCH 124/213] Update links to ingress repository Ingress moved out of contrib to kubernetes/ingress. --- docs/user-guide/ingress.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/user-guide/ingress.md b/docs/user-guide/ingress.md index 009fd13f45..4628d5050d 100644 --- a/docs/user-guide/ingress.md +++ b/docs/user-guide/ingress.md @@ -81,11 +81,11 @@ __Global Parameters__: For the sake of simplicity the example Ingress has no glo ## Ingress controllers -In order for the Ingress resource to work, the cluster must have an Ingress controller running. This is unlike other types of controllers, which typically run as part of the `kube-controller-manager` binary, and which are typically started automatically as part of cluster creation. You need to choose the ingress controller implementation that is the best fit for your cluster, or implement one. Examples and instructions can be found [here](https://github.com/kubernetes/contrib/tree/master/ingress/controllers). +In order for the Ingress resource to work, the cluster must have an Ingress controller running. This is unlike other types of controllers, which typically run as part of the `kube-controller-manager` binary, and which are typically started automatically as part of cluster creation. You need to choose the ingress controller implementation that is the best fit for your cluster, or implement one. Examples and instructions can be found [here](https://github.com/kubernetes/ingress/tree/master/controllers). ## Before you begin -The following document describes a set of cross platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. The docs for the GCE and nginx controllers are [here](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/README.md) and [here](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/README.md) respectively. **Make sure you review controller specific docs so you understand the caveats of each one**. +The following document describes a set of cross platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. The docs for the GCE and nginx controllers are [here](https://github.com/kubernetes/ingress/blob/master/controllers/gce/README.md) and [here](https://github.com/kubernetes/ingress/blob/master/controllers/nginx/README.md) respectively. **Make sure you review controller specific docs so you understand the caveats of each one**. ## Types of Ingress @@ -214,7 +214,7 @@ spec: servicePort: 80 ``` -Note that there is a gap between TLS features supported by various Ingress controllers. Please refer to documentation on [nginx](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#https), [GCE](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/gce#tls), or any other platform specific Ingress controller to understand how TLS works in your environment. +Note that there is a gap between TLS features supported by various Ingress controllers. Please refer to documentation on [nginx](https://github.com/kubernetes/ingress/blob/master/controllers/nginx/README.md#https), [GCE](https://github.com/kubernetes/ingress/blob/master/controllers/gce/README.md#tls), or any other platform specific Ingress controller to understand how TLS works in your environment. ### Loadbalancing @@ -282,7 +282,7 @@ Techniques for spreading traffic across failure domains differs between cloud pr * Combining L4 and L7 Ingress * More Ingress controllers -Please track the [L7 and Ingress proposal](https://github.com/kubernetes/kubernetes/pull/12827) for more details on the evolution of the resource, and the [Ingress sub-repository](https://github.com/kubernetes/contrib/tree/master/ingress) for more details on the evolution of various Ingress controllers. +Please track the [L7 and Ingress proposal](https://github.com/kubernetes/kubernetes/pull/12827) for more details on the evolution of the resource, and the [Ingress repository](https://github.com/kubernetes/ingress/tree/master) for more details on the evolution of various Ingress controllers. ## Alternatives From 5d0f273f348ffa8e5aac00e06dd68f6013328618 Mon Sep 17 00:00:00 2001 From: Zhou Tao Date: Sat, 11 Feb 2017 12:03:38 +0800 Subject: [PATCH 125/213] doc(kubeadm.md) - change base64 decode option to '--decode' `base64 -D` will lead to error on Ubuntu: "base64: invalid option -- 'D'" --- docs/getting-started-guides/kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index a2d4e1b834..5fc815ea9c 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -352,7 +352,7 @@ Please note: `kubeadm` is a work in progress and these limitations will be addre 1. There is no built-in way of fetching the token easily once the cluster is up and running, but here is a `kubectl` command you can copy and paste that will print out the token for you: ```console - # kubectl -n kube-system get secret clusterinfo -o yaml | grep token-map | awk '{print $2}' | base64 -D | sed "s|{||g;s|}||g;s|:|.|g;s/\"//g;" | xargs echo + # kubectl -n kube-system get secret clusterinfo -o yaml | grep token-map | awk '{print $2}' | base64 --decode | sed "s|{||g;s|}||g;s|:|.|g;s/\"//g;" | xargs echo ``` 1. If you are using VirtualBox (directly or via Vagrant), you will need to ensure that `hostname -i` returns a routable IP address (i.e. one on the second network interface, not the first one). From 2c9b093c37a09c877cd90ca0ee24b31347fcecf6 Mon Sep 17 00:00:00 2001 From: Bruce Auyeung Date: Mon, 13 Feb 2017 16:39:37 +0800 Subject: [PATCH 126/213] Update index.md --- docs/user-guide/persistent-volumes/index.md | 34 ++++++++++----------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 3ecc8ea99f..8b1178e45d 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -172,23 +172,23 @@ In the CLI, the access modes are abbreviated to: | Volume Plugin | ReadWriteOnce| ReadOnlyMany| ReadWriteMany| | :--- | :---: | :---: | :---: | -| AWSElasticBlockStore | x | - | - | -| AzureFile | x | x | x | -| AzureDisk | x | - | - | -| CephFS | x | x | x | -| Cinder | x | - | - | -| FC | x | x | - | -| FlexVolume | x | x | - | -| Flocker | x | - | - | -| GCEPersistentDisk | x | x | - | -| Glusterfs | x | x | x | -| HostPath | x | - | - | -| iSCSI | x | x | - | -| PhotonPersistentDisk | x | - | - | -| Quobyte | x | x | x | -| NFS | x | x | x | -| RBD | x | x | - | -| VsphereVolume | x | - | - | +| AWSElasticBlockStore | ✓ | - | - | +| AzureFile | ✓ | ✓ | ✓ | +| AzureDisk | ✓ | - | - | +| CephFS | ✓ | ✓ | ✓ | +| Cinder | ✓ | - | - | +| FC | ✓ | ✓ | - | +| FlexVolume | ✓ | ✓ | - | +| Flocker | ✓ | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | +| Glusterfs | ✓ | ✓ | ✓ | +| HostPath | ✓ | - | - | +| iSCSI | ✓ | ✓ | - | +| PhotonPersistentDisk | ✓ | - | - | +| Quobyte | ✓ | ✓ | ✓ | +| NFS | ✓ | ✓ | ✓ | +| RBD | ✓ | ✓ | - | +| VsphereVolume | ✓ | - | - | ### Class From 07c4b9f6f8379d2e65d82f2481ae343e188656ae Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 14 Feb 2017 14:25:31 +0800 Subject: [PATCH 127/213] fix typo --- docs/user-guide/kubeconfig-file.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubeconfig-file.md b/docs/user-guide/kubeconfig-file.md index b4d7425127..93877f8a84 100644 --- a/docs/user-guide/kubeconfig-file.md +++ b/docs/user-guide/kubeconfig-file.md @@ -305,7 +305,7 @@ $ kubectl config use-context federal-context ### Final notes for tying it all together -So, tying this all together, a quick start to creating your own kubeconfig file: +So, tying this all together, a quick start to create your own kubeconfig file: - Take a good look and understand how your api-server is being launched: You need to know YOUR security requirements and policies before you can design a kubeconfig file for convenient authentication. From a334d932e1b860c5c89ebcda85d2ee75b04c0b8c Mon Sep 17 00:00:00 2001 From: yupengzte Date: Tue, 14 Feb 2017 10:36:00 +0800 Subject: [PATCH 128/213] fix typo Signed-off-by: yupengzte --- docs/deprecation-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/deprecation-policy.md b/docs/deprecation-policy.md index c51326bbc5..cdc0bb0102 100644 --- a/docs/deprecation-policy.md +++ b/docs/deprecation-policy.md @@ -233,7 +233,7 @@ after their announced deprecation for no less than:** * **Beta: 3 months or 1 release (whichever is longer)** * **Alpha: 0 releases** -**Rule #6: Deprecated CLI elements must emit warnings (optionally disableable) +**Rule #6: Deprecated CLI elements must emit warnings (optionally disable) when used.** ## Deprecating a feature or behavior From 5a24d6d68125254d2fbc58c67b11efb469c98fca Mon Sep 17 00:00:00 2001 From: Pierre Ozoux Date: Tue, 14 Feb 2017 15:18:45 +0000 Subject: [PATCH 129/213] Fix the standard storageClass for GCE As you can see here: https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/gce/gce.go#L117-L121 The default is not ssd --- docs/user-guide/persistent-volumes/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 8b1178e45d..4508a1a25f 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -396,7 +396,7 @@ parameters: zone: us-central1-a ``` -* `type`: `pd-standard` or `pd-ssd`. Default: `pd-ssd` +* `type`: `pd-standard` or `pd-ssd`. Default: `pd-standard` * `zone`: GCE zone. If not specified, a random zone in the same region as controller-manager will be chosen. #### Glusterfs From 87f0e317abd84abbfc94880ee76eb8d55fee2cff Mon Sep 17 00:00:00 2001 From: scjane Date: Tue, 14 Feb 2017 15:03:43 +0800 Subject: [PATCH 130/213] Update multiple-schedulers.md Similar to #2518. But I think an unordered list can be used here :) --- docs/admin/multiple-schedulers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/admin/multiple-schedulers.md b/docs/admin/multiple-schedulers.md index 3e3b4d270b..c20e129b19 100644 --- a/docs/admin/multiple-schedulers.md +++ b/docs/admin/multiple-schedulers.md @@ -95,7 +95,7 @@ Now that our second scheduler is running, let's create some pods, and direct the scheduler in that pod spec. Let's look at three examples. -1. Pod spec without any scheduler name +- Pod spec without any scheduler name {% include code.html language="yaml" file="multiple-schedulers/pod1.yaml" ghlink="/docs/admin/multiple-schedulers/pod1.yaml" %} @@ -108,7 +108,7 @@ scheduler in that pod spec. Let's look at three examples. kubectl create -f pod1.yaml ``` -2. Pod spec with `default-scheduler` +- Pod spec with `default-scheduler` {% include code.html language="yaml" file="multiple-schedulers/pod2.yaml" ghlink="/docs/admin/multiple-schedulers/pod2.yaml" %} @@ -121,7 +121,7 @@ scheduler in that pod spec. Let's look at three examples. kubectl create -f pod2.yaml ``` -3. Pod spec with `my-scheduler` +- Pod spec with `my-scheduler` {% include code.html language="yaml" file="multiple-schedulers/pod3.yaml" ghlink="/docs/admin/multiple-schedulers/pod3.yaml" %} From 886f15554f000f683c17bdc2c681c79c89da521a Mon Sep 17 00:00:00 2001 From: Fabrizio Milo Date: Tue, 14 Feb 2017 09:29:08 -0800 Subject: [PATCH 131/213] Update pod.md --- docs/concepts/abstractions/pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/pod.md b/docs/concepts/abstractions/pod.md index 5c364c5376..59a7beaee5 100644 --- a/docs/concepts/abstractions/pod.md +++ b/docs/concepts/abstractions/pod.md @@ -27,7 +27,7 @@ The [Kubernetes Blog](http://blog.kubernetes.io) has some additional information * [The Distributed System Toolkit: Patterns for Composite Containers](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) * [Container Design Patterns](http://blog.kubernetes.io/2016/06/container-design-patterns.html) -Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run muliple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information. +Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as _replication_. Replicated Pods are usually created and managed as a group by an abstraction called a Controller. See [Pods and Controllers](#pods-and-controllers) for more information. ### How Pods Manage Multiple Containers From 3a5b4c74d3844475c0f80e74f4e66dd5f184e4c6 Mon Sep 17 00:00:00 2001 From: Fabrizio Milo Date: Tue, 14 Feb 2017 09:20:59 -0800 Subject: [PATCH 132/213] Update overview.md --- docs/concepts/abstractions/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/overview.md b/docs/concepts/abstractions/overview.md index 712ad0f99f..4e832eaffb 100644 --- a/docs/concepts/abstractions/overview.md +++ b/docs/concepts/abstractions/overview.md @@ -9,7 +9,7 @@ This page explains how Kubernetes objects are represented in the Kubernetes API, {% capture body %} ## Understanding Kubernetes Objects -*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubenetes uses these entities to represent the state of your cluster. Specifically, they can describe: +*Kubernetes Objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe: * What containerized applications are running (and on which nodes) * The resources available to those applications From 4e3f6ae0e3e3c748998b8c4caf7ba5ffec42fd86 Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 14 Feb 2017 11:07:33 -0800 Subject: [PATCH 133/213] fix Kubenetes typo Kubenetes -> Kubernetes --- .../configure-liveness-readiness-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index d168ceb211..ff05756350 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -247,7 +247,7 @@ where you would set it. Suppose the Container listens on 127.0.0.1 and the Pod's If your pod relies on virtual hosts, which is probably the more common case, you should not use `host`, but rather set the `Host` header in `httpHeaders`. -In addition to command probes and HTTP probes, Kubenetes supports +In addition to command probes and HTTP probes, Kubernetes supports [TCP probes](/docs/api-reference/v1/definitions/#_v1_tcpsocketaction). {% endcapture %} From aaca71474ec9fa9a73fc94b96c867ad0c336da75 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Tue, 14 Feb 2017 16:37:49 +0800 Subject: [PATCH 134/213] column READY is missed column READY is missed --- docs/user-guide/deployments.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index 0b4ae0d85a..52d24391c4 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -62,8 +62,8 @@ This indicates that the Deployment has created all three replicas, and all repli ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-2035384211 3 3 18s +NAME DESIRED CURRENT READY AGE +nginx-deployment-2035384211 3 3 0 18s ``` You may notice that the name of the Replica Set is always `-`. @@ -180,9 +180,9 @@ We can run `kubectl get rs` to see that the Deployment updated the Pods by creat ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 3 3 6s -nginx-deployment-2035384211 0 0 36s +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 0 6s +nginx-deployment-2035384211 0 0 0 36s ``` Running `get pods` should now show only the new Pods: @@ -287,10 +287,10 @@ You will also see that both the number of old replicas (nginx-deployment-1564180 ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 2 2 25s -nginx-deployment-2035384211 0 0 36s -nginx-deployment-3066724191 2 2 6s +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 2 2 0 25s +nginx-deployment-2035384211 0 0 0 36s +nginx-deployment-3066724191 2 2 2 6s ``` Looking at the Pods created, you will see that the 2 Pods created by new Replica Set are stuck in an image pull loop. @@ -514,10 +514,10 @@ The Deployment was still in progress when we paused it, so the actions of scalin ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 2 2 1h -nginx-deployment-2035384211 2 2 1h -nginx-deployment-3066724191 0 0 1h +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 2 2 2 1h +nginx-deployment-2035384211 2 2 0 1h +nginx-deployment-3066724191 0 0 0 1h ``` In a separate terminal, watch for rollout status changes and you'll see the rollout won't continue: @@ -546,10 +546,10 @@ deployment nginx-deployment successfully rolled out ```shell $ kubectl get rs -NAME DESIRED CURRENT AGE -nginx-deployment-1564180365 3 3 1h -nginx-deployment-2035384211 0 0 1h -nginx-deployment-3066724191 0 0 1h +NAME DESIRED CURRENT READY AGE +nginx-deployment-1564180365 3 3 3 1h +nginx-deployment-2035384211 0 0 0 1h +nginx-deployment-3066724191 0 0 0 1h ``` Note: You cannot rollback a paused Deployment until you resume it. From 40399ff6365825c65f71d89e64830b8975bec7cf Mon Sep 17 00:00:00 2001 From: Arthur Miranda Date: Tue, 14 Feb 2017 15:41:28 -0300 Subject: [PATCH 135/213] Fix broken/outdated links in the ingress.md file The Ingress controllers have moved to the kubernetes/ingress repository, then some links are broken or outdated. --- docs/user-guide/ingress.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/user-guide/ingress.md b/docs/user-guide/ingress.md index 4628d5050d..0a4f13da2f 100644 --- a/docs/user-guide/ingress.md +++ b/docs/user-guide/ingress.md @@ -44,9 +44,9 @@ It can be configured to give services externally-reachable urls, load balance tr Before you start using the Ingress resource, there are a few things you should understand. The Ingress is a beta resource, not available in any Kubernetes release prior to 1.1. You need an Ingress controller to satisfy an Ingress, simply creating the resource will have no effect. -GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers) and [here](https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc). +GCE/GKE deploys an ingress controller on the master. You can deploy any number of custom ingress controllers in a pod. You must annotate each ingress with the appropriate class, as indicated [here](https://github.com/kubernetes/ingress/tree/master/controllers/nginx#running-multiple-ingress-controllers) and [here](https://github.com/kubernetes/ingress/blob/master/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc). -Make sure you review the [beta limitations](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers) as a pod. +Make sure you review the [beta limitations](https://github.com/kubernetes/ingress/blob/master/controllers/gce/BETA_LIMITATIONS.md) of this controller. In environments other than GCE/GKE, you need to [deploy a controller](https://github.com/kubernetes/ingress/tree/master/controllers) as a pod. ## The Ingress Resource @@ -71,7 +71,7 @@ spec: __Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see [here](/docs/user-guide/deploying-applications), [here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources). -__Lines 5-7__: Ingress [spec](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules. +__Lines 5-7__: Ingress [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules. __Lines 8-9__: Each http rule contains the following information: A host (e.g.: foo.bar.com, defaults to * in this example), a list of paths (e.g.: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend. From 3ac058495389eb3194fdb73f80bcb796610a4f5f Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Tue, 14 Feb 2017 10:36:08 +0800 Subject: [PATCH 136/213] add "--show-all" to kubectl get pods add "--show-all" to "kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name}" ,because the pod was ended --- docs/user-guide/jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index d48b856ae3..d64ae9d730 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -66,7 +66,7 @@ To view completed pods of a job, use `kubectl get pods --show-all`. The `--show To list all the pods that belong to a job in a machine readable form, you can use a command like this: ```shell -$ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name}) +$ pods=$(kubectl get pods --show-all --selector=job-name=pi --output=jsonpath={.items..metadata.name}) echo $pods pi-aiw0a ``` From a8009333b1e831cf13384076936d87ec93133747 Mon Sep 17 00:00:00 2001 From: Robert Kubis Date: Sat, 11 Feb 2017 16:05:47 +0000 Subject: [PATCH 137/213] Update cheatsheet for multi-container handling Added how to retrieve logs for containers in multi-container pods --- docs/user-guide/kubectl-cheatsheet.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index c147304a7d..7fc0142f04 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -197,7 +197,9 @@ $ kubectl -n my-ns delete po,svc --all # Delete all pods and servic ```console $ kubectl logs my-pod # dump pod logs (stdout) +$ kubectl logs my-pod -c my-container # dump pod container logs (stdout, multi-container case) $ kubectl logs -f my-pod # stream pod logs (stdout) +$ kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case) $ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell $ kubectl attach my-pod -i # Attach to Running Container $ kubectl port-forward my-pod 5000:6000 # Forward port 6000 of Pod to your to 5000 on your local machine From 523bb2a1fd531e92316b4cf273d7427b47c9ad4d Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 14 Feb 2017 13:49:14 -0800 Subject: [PATCH 138/213] re: issue #1671; update to direct link Update Docker Volumes link to https://docs.docker.com/engine/tutorials/dockervolumes/ --- docs/user-guide/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/index.md b/docs/user-guide/index.md index 9c69683525..0d4e77a97d 100644 --- a/docs/user-guide/index.md +++ b/docs/user-guide/index.md @@ -54,7 +54,7 @@ Before running examples in the user guides, please ensure you have completed the : A service defines a set of pods and a means by which to access them, such as single stable IP address and corresponding DNS name. [**Volume**](/docs/user-guide/volumes/) -: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/userguide/dockervolumes/), adding provisioning of the volume directory and/or device. +: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/), adding provisioning of the volume directory and/or device. [**Secret**](/docs/user-guide/secrets/) : A secret stores sensitive data, such as authentication tokens, which can be made available to containers upon request. From 1c634023f6ab5552d4dec0d9112e991961114d46 Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 14 Feb 2017 14:34:13 -0800 Subject: [PATCH 139/213] re: issue #2034; fix docker image link (#2532) * re: issue #2034; fix docker image link change link in line 26 to: https://gcr.io/google_containers/hpa-example * point link to local Dockerfile * specify it as the Dockerfile, not image --- docs/user-guide/horizontal-pod-autoscaling/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md index f0a5cbc64a..616061e930 100644 --- a/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md +++ b/docs/user-guide/horizontal-pod-autoscaling/walkthrough.md @@ -23,7 +23,7 @@ heapster monitoring will be turned-on by default). ## Step One: Run & expose php-apache server To demonstrate Horizontal Pod Autoscaler we will use a custom docker image based on the php-apache image. -The image can be found [here](/docs/user-guide/horizontal-pod-autoscaling/image). +The Dockerfile can be found [here](/docs/user-guide/horizontal-pod-autoscaling/image/Dockerfile). It defines an [index.php](/docs/user-guide/horizontal-pod-autoscaling/image/index.php) page which performs some CPU intensive computations. First, we will start a deployment running the image and expose it as a service: From e1eb525f0164b99d4783e88aa43a65c15402ba83 Mon Sep 17 00:00:00 2001 From: foxish Date: Wed, 15 Feb 2017 13:27:00 -0800 Subject: [PATCH 140/213] Fix travis.yml --- .travis.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.travis.yml b/.travis.yml index 09a28b78cb..d05639d195 100644 --- a/.travis.yml +++ b/.travis.yml @@ -14,6 +14,7 @@ install: - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/sample-apiserver +- rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/kube-aggregator - cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ - rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* - cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ From 183fc3d41cbd474c129f466aa00c3a997a3a7e08 Mon Sep 17 00:00:00 2001 From: sallydeng Date: Tue, 14 Feb 2017 20:03:22 +0800 Subject: [PATCH 141/213] The key-value "optional:true" doesn't work The key-value "optional:true" doesn't work in 1.5.2 yet. So should we add a note here? "The key-value "optional:true" will be work after kubernetes 1.5.2." --- docs/user-guide/configmap/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 3227e416c0..e2de3a7aec 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -590,3 +590,5 @@ Kubelet only supports use of ConfigMap for pods it gets from the API server. Th created using kubectl, or indirectly via a replication controller. It does not include pods created via the Kubelet's `--manifest-url` flag, its `--config` flag, or its REST API (these are not common ways to create pods.) + +The key-value "optional:true" will be work after kubernetes 1.5.2. From 3e48da5f8bf976d9206df13c641f4329af33648d Mon Sep 17 00:00:00 2001 From: sallydeng Date: Wed, 15 Feb 2017 13:15:20 +0800 Subject: [PATCH 142/213] Change sentence base on reviewer's comment "NOTE: The key-value optional:true is supported for kubernetes 1.5.3 and above." --- docs/user-guide/configmap/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index e2de3a7aec..5e074e5787 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -591,4 +591,4 @@ created using kubectl, or indirectly via a replication controller. It does not via the Kubelet's `--manifest-url` flag, its `--config` flag, or its REST API (these are not common ways to create pods.) -The key-value "optional:true" will be work after kubernetes 1.5.2. +NOTE: The key-value optional:true is supported for kubernetes 1.5.3 and above. From 2aea9f942494fc9e7d8141e5327902abc48b82ed Mon Sep 17 00:00:00 2001 From: Michael Mrowetz Date: Wed, 15 Feb 2017 11:58:43 +0900 Subject: [PATCH 143/213] #2534 mark openstack-heat as standalone-salt-conf --- docs/admin/salt.md | 12 ++++++------ docs/getting-started-guides/openstack-heat.md | 9 +++++++-- 2 files changed, 13 insertions(+), 8 deletions(-) diff --git a/docs/admin/salt.md b/docs/admin/salt.md index 05d0ae9250..b570dc8473 100644 --- a/docs/admin/salt.md +++ b/docs/admin/salt.md @@ -10,11 +10,11 @@ The Salt scripts are shared across multiple hosting providers and depending on w ## Salt cluster setup -The **salt-master** service runs on the kubernetes-master [(except on the default GCE setup)](#standalone-salt-configuration-on-gce). +The **salt-master** service runs on the kubernetes-master [(except on the default GCE and OpenStack-Heat setup)](#standalone-salt-configuration-on-gce-and-others). The **salt-minion** service runs on the kubernetes-master and each kubernetes-node in the cluster. -Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce). +Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE and OpenStack-Heat)](#standalone-salt-configuration-on-gce-and-others). ```shell [root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf @@ -25,15 +25,15 @@ The salt-master is contacted by each salt-minion and depending upon the machine If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master. It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API. -## Standalone Salt Configuration on GCE +## Standalone Salt Configuration on GCE and others -On GCE, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state. +On GCE and OpenStack, using the Openstack-Heat provider, the master and nodes are all configured as [standalone minions](http://docs.saltstack.com/en/latest/topics/tutorials/standalone_minion.html). The configuration for each VM is derived from the VM's [instance metadata](https://cloud.google.com/compute/docs/metadata) and then stored in Salt grains (`/etc/salt/minion.d/grains.conf`) and pillars (`/srv/salt-overlay/pillar/cluster-params.sls`) that local Salt uses to enforce state. -All remaining sections that refer to master/minion setups should be ignored for GCE. One fallout of the GCE setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes. +All remaining sections that refer to master/minion setups should be ignored for GCE and OpenStack. One fallout of this setup is that the Salt mine doesn't exist - there is no sharing of configuration amongst nodes. ## Salt security -*(Not applicable on default GCE setup.)* +*(Not applicable on default GCE and OpenStack-Heat setup.)* Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.) diff --git a/docs/getting-started-guides/openstack-heat.md b/docs/getting-started-guides/openstack-heat.md index e4fb7c277d..8a2fd52d11 100644 --- a/docs/getting-started-guides/openstack-heat.md +++ b/docs/getting-started-guides/openstack-heat.md @@ -23,7 +23,7 @@ This guide assumes you have access to a working OpenStack cluster with the follo - Heat - DNS resolution of instance names -By default this provider provisions 4 m1.medium instances. If you do not have resources available, please see the [Set additional configuration values](#set-additional-configuration-values) section for information on reducing the footprint of your cluster. +By default this provider provisions 4 `m1.medium` instances. If you do not have resources available, please see the [Set additional configuration values](#set-additional-configuration-values) section for information on reducing the footprint of your cluster. ## Pre-Requisites If you already have the required versions of the OpenStack CLI tools installed and configured, you can move on to the [Starting a cluster](#starting-a-cluster) section. @@ -92,7 +92,7 @@ Please see the contents of these files for documentation regarding each variable ## Starting a cluster -Once Kubernetes version 1.3 is released, and you've installed the OpenStack CLI tools and have set your OpenStack environment variables, issue this command: +Once you've installed the OpenStack CLI tools and have set your OpenStack environment variables, issue this command: ```sh export KUBERNETES_PROVIDER=openstack-heat; curl -sS https://get.k8s.io | bash @@ -194,6 +194,11 @@ nova list --name=$STACK_NAME See the [OpenStack CLI Reference](http://docs.openstack.org/cli-reference/) for more details. +### Salt + +The OpenStack-Heat provider uses a [standalone Salt configuration](/docs/admin/salt/#standalone-salt-configuration-on-gce-and-others). +It only uses Salt for bootstraping the machines and creates no salt-master and does not auto-start the salt-minion service on the nodes. + ## SSHing to your nodes Your public key was added during the cluster turn-up, so you can easily ssh to them for troubleshooting purposes. From dec125aa533e80f9293a6b0243004202b2df4a54 Mon Sep 17 00:00:00 2001 From: Arthur Miranda Date: Wed, 15 Feb 2017 15:07:08 -0300 Subject: [PATCH 144/213] Update the links of Deployment User Guide The file 'blob/master/docs/devel/api-conventions.md' has moved to 'community/blob/master/contributors/devel/api-conventions.md' Updates the links associated with these file. --- docs/user-guide/deployments.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index 52d24391c4..fb8f2cc0e0 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -615,7 +615,7 @@ the Deployment's `status.conditions`: * Status=False * Reason=ProgressDeadlineExceeded -See the [Kubernetes API conventions](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/devel/api-conventions.md#typical-status-properties) for more information on status conditions. +See the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions. Note that in version 1.5, Kubernetes will take no action on a stalled Deployment other than to report a status condition with `Reason=ProgressDeadlineExceeded`. @@ -725,7 +725,7 @@ As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, a `metadata` fields. For general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications), [configuring containers](/docs/user-guide/configuring-containers), and [using kubectl to manage resources](/docs/user-guide/working-with-resources) documents. -A Deployment also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status). +A Deployment also needs a [`.spec` section](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status). ### Pod Template From 0fca22e65953a6237bdf8916fcf05373083ea8b3 Mon Sep 17 00:00:00 2001 From: sallydeng Date: Wed, 15 Feb 2017 16:15:20 +0800 Subject: [PATCH 145/213] kubectl_apply.md-change it for label key When I test this command, if the configmap has a label, it just delete the configmaps which has the same label key and that are not in the file. kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap So I advise change the description like this: "Apply the configuration in manifest.yaml and delete all the other configmaps with the same label key that are not in the file." --- docs/user-guide/kubectl/kubectl_apply.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubectl/kubectl_apply.md b/docs/user-guide/kubectl/kubectl_apply.md index c729263d6c..81c1a12137 100644 --- a/docs/user-guide/kubectl/kubectl_apply.md +++ b/docs/user-guide/kubectl/kubectl_apply.md @@ -32,7 +32,7 @@ kubectl apply -f FILENAME # Apply the configuration in manifest.yaml that matches label app=nginx and delete all the other resources that are not in the file and match label app=nginx. kubectl apply --prune -f manifest.yaml -l app=nginx - # Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file. + # Apply the configuration in manifest.yaml and delete all the other configmaps with the same label key that are not in the file. kubectl apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap ``` From 4e5e79f35f6a4db8dde18b4ef0160f5c083ebdba Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Wed, 15 Feb 2017 14:40:39 -0800 Subject: [PATCH 146/213] rollback PR #2522 Rollingback PR #2522 until we can verify which version optional:true will be available in. --- docs/user-guide/configmap/index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 5e074e5787..40b3fa181b 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -591,4 +591,3 @@ created using kubectl, or indirectly via a replication controller. It does not via the Kubelet's `--manifest-url` flag, its `--config` flag, or its REST API (these are not common ways to create pods.) -NOTE: The key-value optional:true is supported for kubernetes 1.5.3 and above. From 0ce865cc763f16336b96485c824f9a24ab215399 Mon Sep 17 00:00:00 2001 From: Michail Kargakis Date: Wed, 25 Jan 2017 10:44:31 +0100 Subject: [PATCH 147/213] Update deployment completeness documentation --- docs/user-guide/deployments.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index fb8f2cc0e0..f2e854690e 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -578,6 +578,7 @@ Kubernetes marks a Deployment as _complete_ when it has the following characteri equals or exceeds the number required by the Deployment strategy. * All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any updates you've requested have been completed. +* No old pods for the Deployment are running. You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code. From 3ed3018153c3eb0c5b9ca2da8c2d0b1c51cf6f8f Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Wed, 15 Feb 2017 14:56:39 -0800 Subject: [PATCH 148/213] Move Pod Lifecycle to Concepts. (#2420) * Move Pod Lifecycle to Concepts. * Put moved note on old page. * Update pod-lifecycle.md --- _data/concepts.yml | 6 + docs/concepts/workloads/pods/pod-lifecycle.md | 282 ++++++++++++++++++ docs/user-guide/pod-states.md | 166 +---------- 3 files changed, 290 insertions(+), 164 deletions(-) create mode 100644 docs/concepts/workloads/pods/pod-lifecycle.md diff --git a/_data/concepts.yml b/_data/concepts.yml index 4227231cc1..432f4c86e1 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -25,6 +25,12 @@ toc: section: - docs/concepts/object-metadata/annotations.md +- title: Workloads + section: + - title: Pods + section: + - docs/concepts/workloads/pods/pod-lifecycle.md + - title: Configuration section: - docs/concepts/configuration/container-command-args.md diff --git a/docs/concepts/workloads/pods/pod-lifecycle.md b/docs/concepts/workloads/pods/pod-lifecycle.md new file mode 100644 index 0000000000..540ba506fc --- /dev/null +++ b/docs/concepts/workloads/pods/pod-lifecycle.md @@ -0,0 +1,282 @@ +--- +title: Pod Lifecycle +--- + +{% capture overview %} + +{% comment %}Updated: 4/14/2015{% endcomment %} +{% comment %}Edited and moved to Concepts section: 2/2/17{% endcomment %} + +This page describes the lifecycle of a Pod. + +{% endcapture %} + + +{% capture body %} + +## Pod phase + +A Pod's `status` field is a +[PodStatus](/docs/resources-reference/v1.5/#podstatus-v1) +object, which has a `phase` field. + +The phase of a Pod is a simple, high-level summary of where the Pod is in its +lifecycle. The phase is not intended to be a comprehensive rollup of observations +of Container or Pod state, nor is it intended to be a comprehensive state machine. + +The number and meanings of Pod phase values are tightly guarded. +Other than what is documented here, nothing should be assumed about Pods that +have a given `phase` value. + +Here are the possible values for `phase`: + +* Pending: The Pod has been accepted by the Kubernetes system, but one or more of + the Container images has not been created. This includes time before being + scheduled as well as time spent downloading images over the network, + which could take a while. + +* Running: The Pod has been bound to a node, and all of the Containers have been + created. At least one Container is still running, or is in the process of + starting or restarting. + +* Succeeded: All Containers in the Pod have terminated in success, and will not + be restarted. + +* Failed: All Containers in the Pod have terminated, and at least one Container + has terminated in failure. That is, the Container either exited with non-zero + status or was terminated by the system. + +* Unknown: For some reason the state of the Pod could not be obtained, typically + due to an error in communicating with the host of the Pod. + +## Pod conditions + +A Pod has a PodStatus, which has an array of +[PodConditions](docs/resources-reference/v1.5/#podcondition). Each element +of the PodCondition array has a `type` field and a `status` field. The `type` +field is a string, with possible values PodScheduled, Ready, Initialized, and +Unschedulable. The `status` field is a string, with possible values True, False, +and Unknown. + +## Container probes + +A [Probe](/docs/resources-reference/v1.5/#probe-v1) is a diagnostic +performed periodically by the [kubelet](/docs/admin/kubelet/) +on a Container. To perform a diagnostic, +the kublet calls a +[Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by +the Container. There are three types of handlers: + +* [ExecAction](/docs/resources-reference/v1.5/#execaction-v1): + Executes a specified command inside the Container. The diagnostic + is considered successful if the command exits with a status code of 0. + +* [TCPSocketAction](/docs/resources-reference/v1.5/#tcpsocketaction-v1): + Performs a TCP check against the Container's IP address on + a specified port. The diagnostic is considered successful if the port is open. + +* [HTTPGetAction](/docs/resources-reference/v1.5/#httpgetaction-v1): + Performs an HTTP Get request against the Container's IP + address on a specified port and path. The diagnostic is considered successful + if the response has a status code greater than or equal to 200 and less than 400. + +Each probe has one of three results: + +* Success: The Container passed the diagnostic. +* Failure: The Container failed the diagnostic. +* Unknown: The diagnostic failed, so no action should be taken. + +The kubelet can optionally perform and react to two kinds of probes on running +Containers: + +* `livenessProbe`: Indicates whether the Container is running. If + the liveness probe fails, the kubelet kills the Container, and the Container + is subjected to its [restart policy](#restart-policy). If a Container does not + provide a liveness probe, the default state is `Success`. + +* `readinessProbe`: Indicates whether the Container is ready to service requests. + If the readiness probe fails, the endpoints controller removes the Pod's IP + address from the endpoints of all Services that match the Pod. The default + state of readiness before the initial delay is `Failure`. If a Container does + not provide a readiness probe, the default state is `Success`. + +### When should you use liveness or readiness probes? + +If the process in your Container is able to crash on its own whenever it +encounters an issue or becomes unhealthy, you do not necessarily need a liveness +probe; the kubelet will automatically perform the correct action in accordance +with the Pod's `restartPolicy`. + +If you'd like your Container to be killed and restarted if a probe fails, then +specify a liveness probe, and specify a `restartPolicy` of Always or OnFailure. + +If you'd like to start sending traffic to a Pod only when a probe succeeds, +specify a readiness probe. In this case, the readiness probe might be the same +as the liveness probe, but the existence of the readiness probe in the spec means +that the Pod will start without receiving any traffic and only start receiving +traffic after the probe starts succeeding. + +If you want your Container to be able to take itself down for maintenance, you +can specify a readiness probe that checks an endpoint specific to readiness that +is different from the liveness probe. + +Note that if you just want to be able to drain requests when the Pod is deleted, +you do not necessarily need a readiness probe; on deletion, the Pod automatically +puts itself into an unready state regardless of whether the readiness probe exists. +The Pod remains in the unready state while it waits for the Containers in the Pod +to stop. + +## Pod and Container status + +For detailed information about Pod Container status, see +[PodStatus](/docs/resources-reference/v1.5/#podstatus-v1) +and +[ContainerStatus](/docs/resources-reference/v1.5/#containerstatus-v1). +Note that the information reported as Pod status depends on the current +[ContainerState](/docs/resources-reference/v1.5/#containerstate-v1). + +## Restart policy + +A PodSpec has a `restartPolicy` field with possible values Always, OnFailure, +and Never. The default value is Always. +`restartPolicy` applies to all Containers in the Pod. `restartPolicy` only +refers to restarts of the Containers by the kubelet on the same node. Failed +Containers that are restarted by the kubelet are restarted with an exponential +back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten +minutes of successful execution. As discussed in the +[Pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), +once bound to a node, a Pod will never be rebound to another node. + + + +## Pod lifetime + +In general, Pods do not disappear until someone destroys them. This might be a +human or a controller. The only exception to +this rule is that Pods with a `phase` of Succeeded or Failed for more than some +duration (determined by the master) will expire and be automatically destroyed. + +Three types of controllers are available: + +- Use a [Job](/docs/user-guide/jobs/) for Pods that are expected to terminate, + for example, batch computations. Jobs are appropriate only for Pods with + `restartPolicy` equal to OnFailure or Never. + +- Use a [ReplicationController](/docs/user-guide/replication-controller/), + [ReplicaSet](/docs/user-guide/replicasets/), or + [Deployment](/docs/user-guide/deployments/) + for Pods that are not expected to terminate, for example, web servers. + ReplicationControllers are appropriate only for Pods with a `restartPolicy` of + Always. + +- Use a [DaemonSet](/docs/admin/daemons/) for Pods that need to run one per + machine, because they provide a machine-specific system service. + +All three types of controllers contain a PodTemplate. It +is recommended to create the appropriate controller and let +it create Pods, rather than directly create Pods yourself. That is because Pods +alone are not resilient to machine failures, but controllers are. + +If a node dies or is disconnected from the rest of the cluster, Kubernetes +applies a policy for setting the `phase` of all Pods on the lost node to Failed. + +## Examples + +### Advanced liveness probe example + +Liveness probes are executed by the kubelet, so all requests are made in the +kubelet network namespace. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + test: liveness + name: liveness-http +spec: + containers: + - args: + - /server + image: gcr.io/google_containers/liveness + livenessProbe: + httpGet: + # when "host" is not defined, "PodIP" will be used + # host: my-host + # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed + # scheme: HTTPS + path: /healthz + port: 8080 + httpHeaders: + - name: X-Custom-Header + value: Awesome + initialDelaySeconds: 15 + timeoutSeconds: 1 + name: liveness +``` + +### Example states + + * Pod is running and has one Container. Container exits with success. + * Log completion event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Pod `phase` becomes Succeeded. + * Never: Pod `phase` becomes Succeeded. + + * Pod is running and has one Container. Container exits with failure. + * Log failure event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Pod `phase` becomes Failed. + + * Pod is running and has two Containers. Container 1 exits with failure. + * Log failure event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Do not restart Container; Pod `phase` stays Running. + * If Container 1 is not running, and Container 2 exits: + * Log failure event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Pod `phase` becomes Failed. + + * Pod is running and has one Container. Container runs out of memory. + * Container terminates in failure. + * Log OOM event. + * If `restartPolicy` is: + * Always: Restart Container; Pod `phase` stays Running. + * OnFailure: Restart Container; Pod `phase` stays Running. + * Never: Log failure event; Pod `phase` becomes Failed. + + * Pod is running, and a disk dies. + * Kill all Containers. + * Log appropriate event. + * Pod `phase` becomes Failed. + * If running under a controller, Pod is recreated elsewhere. + + * Pod is running, and its node is segmented out. + * Node controller waits for timeout. + * Node controller sets Pod `phase` to Failed. + * If running under a controller, Pod is recreated elsewhere. + +{% endcapture %} + + +{% capture whatsnext %} + +* Get hands-on experience + [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +* Get hands-on experience + [configuring liveness and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). + +* [Container Lifecycle Hooks](/docs/user-guide/container-environment/) + +{% endcapture %} + +{% include templates/concept.md %} + diff --git a/docs/user-guide/pod-states.md b/docs/user-guide/pod-states.md index 462f8b65bd..a3cea728cc 100644 --- a/docs/user-guide/pod-states.md +++ b/docs/user-guide/pod-states.md @@ -4,168 +4,6 @@ assignees: title: The Lifecycle of a Pod --- -Updated: 4/14/2015 - -This document covers the lifecycle of a pod. It is not an exhaustive document, but an introduction to the topic. - -## Pod Phase - -As consistent with the overall [API convention](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine. - -The number and meanings of `PodPhase` values are tightly guarded. Other than what is documented here, nothing should be assumed about pods with a given `PodPhase`. - -* Pending: The pod has been accepted by the system, but one or more of the container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while. -* Running: The pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. -* Succeeded: All containers in the pod have terminated in success, and will not be restarted. -* Failed: All containers in the pod have terminated, at least one container has terminated in failure (exited with non-zero exit status or was terminated by the system). -* Unknown: For some reason the state of the pod could not be obtained, typically due to an error in communicating with the host of the pod. - -## Pod Conditions - -A pod containing containers that specify readiness probes will also report the Ready condition. Condition status values may be `True`, `False`, or `Unknown`. - -## Container Probes - -A [Probe](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Probe) is a diagnostic performed periodically by the kubelet on a container. Specifically the diagnostic is one of three [Handlers](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler): - -* `ExecAction`: executes a specified command inside the container expecting on success that the command exits with status code 0. -* `TCPSocketAction`: performs a tcp check against the container's IP address on a specified port expecting on success that the port is open. -* `HTTPGetAction`: performs an HTTP Get against the container's IP address on a specified port and path expecting on success that the response has a status code greater than or equal to 200 and less than 400. - -Each probe will have one of three results: - -* `Success`: indicates that the container passed the diagnostic. -* `Failure`: indicates that the container failed the diagnostic. -* `Unknown`: indicates that the diagnostic failed so no action should be taken. - -The kubelet can optionally perform and react to two kinds of probes on running containers: - -* `LivenessProbe`: indicates whether the container is *live*, i.e. running. If the LivenessProbe fails, the kubelet will kill the container and the container will be subjected to its [RestartPolicy](#restartpolicy). The default state of Liveness before the initial delay is `Success`. The state of Liveness for a container when no probe is provided is assumed to be `Success`. -* `ReadinessProbe`: indicates whether the container is *ready* to service requests. If the ReadinessProbe fails, the endpoints controller will remove the pod's IP address from the endpoints of all services that match the pod. The default state of Readiness before the initial delay is `Failure`. The state of Readiness for a container when no probe is provided is assumed to be `Success`. - -### When should I use liveness or readiness probes? - -If the process in your container is able to crash on its own whenever it encounters an issue or becomes unhealthy, you do not necessarily need a liveness probe - the kubelet will automatically perform the correct action in accordance with the RestartPolicy when the process crashes. - -If you'd like your container to be killed and restarted if a probe fails, then specify a LivenessProbe and a RestartPolicy of `Always` or `OnFailure`. - -If you'd like to start sending traffic to a pod only when a probe succeeds, specify a ReadinessProbe. In this case, the ReadinessProbe may be the same as the LivenessProbe, but the existence of the ReadinessProbe in the spec means that the pod will start without receiving any traffic and only start receiving traffic once the probe starts succeeding. - -If a container wants the ability to take itself down for maintenance, you can specify a ReadinessProbe that checks an endpoint specific to readiness which is different than the LivenessProbe. - -Note that if you just want to be able to drain requests when the pod is deleted, you do not necessarily need a ReadinessProbe - on deletion, the pod automatically puts itself into an unready state regardless of whether the ReadinessProbe exists or not while it waits for the containers in the pod to stop. - -## Container Statuses - -More detailed information about the current (and previous) container statuses can be found in [ContainerStatuses](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#PodStatus). The information reported depends on the current [ContainerState](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#ContainerState), which may be Waiting, Running, or Terminated. - -## RestartPolicy - -The possible values for RestartPolicy are `Always`, `OnFailure`, or `Never`. If RestartPolicy is not set, the default value is `Always`. RestartPolicy applies to all containers in the pod. RestartPolicy only refers to restarts of the containers by the Kubelet on the same node. Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x ... capped at 5 minutes and is reset after 10 minutes of successful execution. As discussed in the [pods document](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), once bound to a node, a pod will never be rebound to another node. This means that some kind of controller is necessary in order for a pod to survive node failure, even if just a single pod at a time is desired. - -Three types of controllers are currently available: - -- Use a [`Job`](/docs/user-guide/jobs/) for pods which are expected to terminate (e.g. batch computations). -- Use a [`ReplicationController`](/docs/user-guide/replication-controller/) or [`Deployment`](/docs/user-guide/deployments/) - for pods which are not expected to terminate (e.g. web servers). -- Use a [`DaemonSet`](/docs/admin/daemons/): Use for pods which need to run 1 per machine because they provide a - machine-specific system service. -If you are unsure whether to use ReplicationController or Daemon, then see [Daemon Set versus -Replication Controller](/docs/admin/daemons/#daemon-set-versus-replication-controller). - -`ReplicationController` is *only* appropriate for pods with `RestartPolicy = Always`. -`Job` is *only* appropriate for pods with `RestartPolicy` equal to `OnFailure` or `Never`. - -All 3 types of controllers contain a PodTemplate, which has all the same fields as a Pod. -It is recommended to create the appropriate controller and let it create pods, rather than to -directly create pods yourself. That is because pods alone are not resilient to machine failures, -but Controllers are. - -## Pod lifetime - -In general, pods which are created do not disappear until someone destroys them. This might be a human or a `ReplicationController`, or another controller. The only exception to this rule is that pods with a `PodPhase` of `Succeeded` or `Failed` for more than some duration (determined by the master) will expire and be automatically reaped. - -If a node dies or is disconnected from the rest of the cluster, some entity within the system (call it the NodeController for now) is responsible for applying policy (e.g. a timeout) and marking any pods on the lost node as `Failed`. - -## Examples - -### Advanced livenessProbe example - -Liveness probes are executed by `kubelet`, so all requests will be made within kubelet network namespace. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - labels: - test: liveness - name: liveness-http -spec: - containers: - - args: - - /server - image: gcr.io/google_containers/liveness - livenessProbe: - httpGet: - # when "host" is not defined, "PodIP" will be used - # host: my-host - # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed - # scheme: HTTPS - path: /healthz - port: 8080 - httpHeaders: - - name: X-Custom-Header - value: Awesome - initialDelaySeconds: 15 - timeoutSeconds: 1 - name: liveness -``` - -### Example states - - * Pod is `Running`, 1 container, container exits success - * Log completion event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: pod becomes `Succeeded` - * Never: pod becomes `Succeeded` - - * Pod is `Running`, 1 container, container exits failure - * Log failure event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: pod becomes `Failed` - - * Pod is `Running`, 2 containers, container 1 exits failure - * Log failure event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: pod stays `Running` - * When container 2 exits... - * Log failure event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: pod becomes `Failed` - - * Pod is `Running`, container becomes OOM - * Container terminates in failure - * Log OOM event - * If RestartPolicy is: - * Always: restart container, pod stays `Running` - * OnFailure: restart container, pod stays `Running` - * Never: log failure event, pod becomes `Failed` - - * Pod is `Running`, a disk dies - * All containers are killed - * Log appropriate event - * Pod becomes `Failed` - * If running under a controller, pod will be recreated elsewhere - - * Pod is `Running`, its node is segmented out - * NodeController waits for timeout - * NodeController marks pod `Failed` - * If running under a controller, pod will be recreated elsewhere +{% include user-guide-content-moved.md %} +[Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) From 33da5e4fb19ca91b35c1565e9548ad3ad4d3c7f0 Mon Sep 17 00:00:00 2001 From: foxish Date: Wed, 15 Feb 2017 16:06:49 -0800 Subject: [PATCH 149/213] Fix travis and add comments --- .travis.yml | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index d05639d195..b0a565803c 100644 --- a/.travis.yml +++ b/.travis.yml @@ -7,9 +7,17 @@ install: - export PATH=$GOPATH/bin:$PATH - mkdir -p $HOME/gopath/src/k8s.io - mv $TRAVIS_BUILD_DIR $HOME/gopath/src/k8s.io/kubernetes.github.io + +# (1) Fetch dependencies for us to run the tests in test/examples_test.go - go get -t -v k8s.io/kubernetes.github.io/test -- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check -- go get -t -v k8s.io/md-check + +# The dependencies are complicated for test/examples_test.go +# k8s.io/kubernetes/pkg is a dependency, which in turn depends on apimachinery +# but we also have apimachinery directly as one of our dependencies, which causes a conflict. +# Additionally, we get symlinks when we clone the directory. The below steps do the following: + +# (a) Replace the symlink with the actual dependencies from kubernetes/staging/src/ +# (b) copy all the vendored files to $GOPATH/src - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apimachinery - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/apiserver - rm $GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/client-go @@ -18,6 +26,12 @@ install: - cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ - rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* - cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ + +# (2) Fetch md-check along with all its dependencies. +- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check +- go get -t -v k8s.io/md-check + +# (3) Fetch mungedocs - go get -v k8s.io/kubernetes/cmd/mungedocs script: From e71b14fa5c89df9104648732b35cafdd8ab89a4d Mon Sep 17 00:00:00 2001 From: steveperry-53 Date: Mon, 13 Feb 2017 15:03:37 -0800 Subject: [PATCH 150/213] Move Guide toic to Tasks: kubectl exec. --- _data/tasks.yml | 1 + .../kubectl/get-shell-running-container.md | 148 ++++++++++++++++++ docs/tasks/kubectl/shell-demo.yaml | 14 ++ docs/user-guide/getting-into-containers.md | 68 +------- 4 files changed, 165 insertions(+), 66 deletions(-) create mode 100644 docs/tasks/kubectl/get-shell-running-container.md create mode 100644 docs/tasks/kubectl/shell-demo.yaml diff --git a/_data/tasks.yml b/_data/tasks.yml index cb61b1a05a..6d7cdb921e 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -6,6 +6,7 @@ toc: - title: Using the Kubectl Command-Line section: - docs/tasks/kubectl/list-all-running-container-images.md + - docs/tasks/kubectl/get-shell-running-container.md - title: Configuring Pods and Containers section: diff --git a/docs/tasks/kubectl/get-shell-running-container.md b/docs/tasks/kubectl/get-shell-running-container.md new file mode 100644 index 0000000000..a005f3e0fe --- /dev/null +++ b/docs/tasks/kubectl/get-shell-running-container.md @@ -0,0 +1,148 @@ +--- +assignees: +- caesarxuchao +- mikedanese +title: Getting a Shell to a Running Container +--- + +{% capture overview %} + +This page shows how to use `kubectl exec` to get a shell to a +running Container. + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + + +{% capture steps %} + +## Getting a shell to a Container + +In this exercise, you create a Pod that has one Container. The Container +runs the nginx image. Here is the configuration file for the Pod: + +{% include code.html language="yaml" file="shell-demo.yaml" ghlink="/docs/tasks/kubectl/shell-demo.yaml" %} + +Create the Pod: + +```shell +kubectl create -f https://k8s.io/docs/tasks/kubectl/shell-demo.yaml +``` + +Verify that the Container is running: + +```shell +kubectl get pod shell-demo +``` + +Get a shell to the running Container: + +```shell +kubectl exec -it shell-demo -- /bin/bash +``` + +In your shell, list the running processes: + +```shell +root@shell-demo:/# ps aux +``` + +In your shell, list the nginx processes: + +```shell +root@shell-demo:/# ps aux | grep nginx +``` + +In your shell, experiment with other commands. Here are +some examples: + +```shell +root@shell-demo:/# ls / +root@shell-demo:/# cat /proc/mounts +root@shell-demo:/# cat /proc/1/maps +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install tcpdump +root@shell-demo:/# tcpdump +root@shell-demo:/# apt-get install lsof +root@shell-demo:/# lsof +``` + +## Writing the root page for nginx + +Look again at the configuration file for your Pod. The Pod +has an `emptyDir` volume, and the Container mounts the volume +at `/usr/share/nginx/html`. + +In your shell, create an `index.html` file in the `/usr/share/nginx/html` +directory: + +```shell +root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html +``` + +In your shell, send a GET request to the nginx server: + +```shell +root@shell-demo:/# apt-get update +root@shell-demo:/# apt-get install curl +root@shell-demo:/# curl localhost +``` + +The output shows the text that you wrote to the `index.html` file: + +```shell +Hello shell demo +``` + +When you are finished with your shell, enter `exit`. + +## Running individual commands in a Container + +In an ordinary command window, not your shell, list the environment +variables in the running Container: + +```shell +kubectl exec shell-demo env +``` + +Experiment running other commands. Here are some examples: + +```shell +kubectl exec shell-demo ps aux +kubectl exec shell-demo ls / +kubectl exec shell-demo cat /proc/1/mounts +``` + +{% endcapture %} + +{% capture discussion %} + +## Opening a shell when a Pod has more than one Container + +If a Pod has more than one Container, use `--container` or `-c` to +specify a Container in the `kubectl exec` command. For example, +suppose you have a Pod named my-pod, and the Pod has two containers +named main-app and helper-app. The following command would open a +shell to the main-app Container. + +```shell +kubectl exec -it my-pod --container main-app -- /bin/bash +``` + +{% endcapture %} + + +{% capture whatsnext %} + +* [kubectl exec](/docs/user-guide/kubectl/v1.5/#exec) + +{% endcapture %} + + +{% include templates/task.md %} diff --git a/docs/tasks/kubectl/shell-demo.yaml b/docs/tasks/kubectl/shell-demo.yaml new file mode 100644 index 0000000000..2a7d274a64 --- /dev/null +++ b/docs/tasks/kubectl/shell-demo.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: shell-demo +spec: + volumes: + - name: shared-data + emptyDir: {} + containers: + - name: nginx + image: nginx + volumeMounts: + - name: shared-data + mountPath: /usr/share/nginx/html diff --git a/docs/user-guide/getting-into-containers.md b/docs/user-guide/getting-into-containers.md index bf6a5a8a2f..ff89f111f6 100644 --- a/docs/user-guide/getting-into-containers.md +++ b/docs/user-guide/getting-into-containers.md @@ -5,70 +5,6 @@ assignees: title: Running Commands in a Container with kubectl exec --- -Developers can use `kubectl exec` to run commands in a container. This guide demonstrates two use cases. +{% include user-guide-content-moved.md %} -## Using kubectl exec to check the environment variables of a container - -Kubernetes exposes [services](/docs/user-guide/services/#environment-variables) through environment variables. It is convenient to check these environment variables using `kubectl exec`. - -We first create a pod and a service, - -```shell -$ kubectl create -f examples/guestbook/redis-master-controller.yaml -$ kubectl create -f examples/guestbook/redis-master-service.yaml -``` -wait until the pod is Running and Ready, - -```shell -$ kubectl get pod -NAME READY REASON RESTARTS AGE -redis-master-ft9ex 1/1 Running 0 12s -``` - -then we can check the environment variables of the pod, - -```shell -$ kubectl exec redis-master-ft9ex env -... -REDIS_MASTER_SERVICE_PORT=6379 -REDIS_MASTER_SERVICE_HOST=10.0.0.219 -... -``` - -We can use these environment variables in applications to find the service. - - -## Using kubectl exec to check the mounted volumes - -It is convenient to use `kubectl exec` to check if the volumes are mounted as expected. -We first create a Pod with a volume mounted at /data/redis, - -```shell -kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml -``` - -wait until the pod is Running and Ready, - -```shell -$ kubectl get pods -NAME READY REASON RESTARTS AGE -storage 1/1 Running 0 1m -``` - -we then use `kubectl exec` to verify that the volume is mounted at /data/redis, - -```shell -$ kubectl exec storage ls /data -redis -``` - -## Using kubectl exec to open a bash terminal in a pod - -After all, open a terminal in a pod is the most direct way to introspect the pod. Assuming the pod/storage is still running, run - -```shell -$ kubectl exec -ti storage -- bash -root@storage:/data# -``` - -This gets you a terminal. \ No newline at end of file +[Getting a Shell to a Running Container](/docs/tasks/kubectl/get-shell-running-container/) From 771a20326eb8745a426c1b62df0dc340dcf86598 Mon Sep 17 00:00:00 2001 From: "Jorge O. Castro" Date: Thu, 16 Feb 2017 07:44:49 -0500 Subject: [PATCH 151/213] Let's put kubectl in ~/bin. --- docs/getting-started-guides/ubuntu/installation.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/getting-started-guides/ubuntu/installation.md b/docs/getting-started-guides/ubuntu/installation.md index cc93995144..9e3bdd8b2b 100644 --- a/docs/getting-started-guides/ubuntu/installation.md +++ b/docs/getting-started-guides/ubuntu/installation.md @@ -159,15 +159,17 @@ juju scp kubernetes-master/0:config ~/.kube/config Fetch a binary for the architecture you have deployed. If your client is a different architecture you will need to get the appropriate `kubectl` binary -through other means. +through other means. In this example we copy kubectl to `~/bin` for convenience, +by default this should be in your $PATH. ``` -juju scp kubernetes-master/0:kubectl ./kubectl +mkdir -p ~/bin +juju scp kubernetes-master/0:kubectl ~/bin/kubectl ``` Query the cluster: - ./kubectl cluster-info + kubectl cluster-info Output: From 8140e9c2cfacb71448a417f7500985c1399defdc Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Thu, 16 Feb 2017 16:20:08 +0800 Subject: [PATCH 152/213] remove its name from file content --- docs/admin/service-accounts-admin.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/admin/service-accounts-admin.md b/docs/admin/service-accounts-admin.md index 4a31fbeced..0c7b495a10 100644 --- a/docs/admin/service-accounts-admin.md +++ b/docs/admin/service-accounts-admin.md @@ -71,8 +71,9 @@ account. To create additional API tokens for a service account, create a secret of type `ServiceAccountToken` with an annotation referencing the service account, and the controller will update it with a generated token: -```json secret.json: + +```json { "kind": "Secret", "apiVersion": "v1", @@ -100,4 +101,4 @@ kubectl delete secret mysecretname ### Service Account Controller Service Account Controller manages ServiceAccount inside namespaces, and ensures -a ServiceAccount named "default" exists in every active namespace. \ No newline at end of file +a ServiceAccount named "default" exists in every active namespace. From 1a81cfd224d66da68c30462be9cbeca011a166b1 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Thu, 16 Feb 2017 17:17:54 +0800 Subject: [PATCH 153/213] replace kubernetes.d with kubelet.d replace kubernetes.d with kubelet.d --- docs/admin/static-pods.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/admin/static-pods.md b/docs/admin/static-pods.md index 8c9e482d0d..cacf6e2010 100644 --- a/docs/admin/static-pods.md +++ b/docs/admin/static-pods.md @@ -26,11 +26,11 @@ For example, this is how to start a simple web server as a static pod: [joe@host ~] $ ssh my-node1 ``` -2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubernetes.d/static-web.yaml`: +2. Choose a directory, say `/etc/kubelet.d` and place a web server pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`: ```shell -[root@my-node1 ~] $ mkdir /etc/kubernetes.d/ -[root@my-node1 ~] $ cat </etc/kubernetes.d/static-web.yaml +[root@my-node1 ~] $ mkdir /etc/kubelet.d/ +[root@my-node1 ~] $ cat </etc/kubelet.d/static-web.yaml apiVersion: v1 kind: Pod metadata: @@ -114,11 +114,11 @@ CONTAINER ID IMAGE COMMAND CREATED ... Running kubelet periodically scans the configured directory (`/etc/kubelet.d` in our example) for changes and adds/removes pods as files appear/disappear in this directory. ```shell -[joe@my-node1 ~] $ mv /etc/kubernetes.d/static-web.yaml /tmp +[joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp [joe@my-node1 ~] $ sleep 20 [joe@my-node1 ~] $ docker ps // no nginx container is running -[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubernetes.d/ +[joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubelet.d/ [joe@my-node1 ~] $ sleep 20 [joe@my-node1 ~] $ docker ps CONTAINER ID IMAGE COMMAND CREATED ... From b8c5b721118725c54ba1d1fe55da784ae2e24407 Mon Sep 17 00:00:00 2001 From: liangxiaoping Date: Thu, 16 Feb 2017 18:37:34 +0800 Subject: [PATCH 154/213] fix etcd disaster-recovery hyperlink --- docs/admin/etcd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/etcd.md b/docs/admin/etcd.md index 41a3e35ddb..06b0eda07c 100644 --- a/docs/admin/etcd.md +++ b/docs/admin/etcd.md @@ -20,7 +20,7 @@ Data Reliability: for reasonable safety, either etcd needs to be run as a etcd) or etcd's data directory should be located on durable storage (e.g., GCE's persistent disk). In either case, if high availability is required--as it might be in a production cluster--the data directory ought to be [backed up -periodically](https://coreos.com/etcd/docs/2.2.1/admin_guide.html#disaster-recovery), +periodically](https://coreos.com/etcd/docs/latest/op-guide/recovery.html), to reduce downtime in case of corruption. ## Default configuration From 3c262fa8d847f58e1116693228b8729a01a28b7e Mon Sep 17 00:00:00 2001 From: "architect.bian" Date: Thu, 16 Feb 2017 18:43:21 +0800 Subject: [PATCH 155/213] modify typora modify namespace-kube-system to namespace=kube-system --- docs/tasks/administer-cluster/dns-horizontal-autoscaling.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md index 069409058a..3d80cc77b2 100644 --- a/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md +++ b/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md @@ -156,7 +156,7 @@ The output is: Verify that the replica count is zero: - kubectl get deployment --namespace-kube-system + kubectl get deployment --namespace=kube-system The output displays 0 in the DESIRED and CURRENT columns: From fe734530ba107c5f6e2f0537386adc0ecbedd7de Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Thu, 16 Feb 2017 12:59:54 -0800 Subject: [PATCH 156/213] Move Guide topic to Tasks: Downward API (#2439) --- _data/tasks.yml | 1 + .../dapi-volume-resources.yaml | 54 ++++ .../configure-pod-container/dapi-volume.yaml | 39 +++ ...nward-api-volume-expose-pod-information.md | 242 ++++++++++++++++++ ...ronment-variable-expose-pod-information.md | 12 + docs/tasks/index.md | 3 + 6 files changed, 351 insertions(+) create mode 100644 docs/tasks/configure-pod-container/dapi-volume-resources.yaml create mode 100644 docs/tasks/configure-pod-container/dapi-volume.yaml create mode 100644 docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md diff --git a/_data/tasks.yml b/_data/tasks.yml index 6d7cdb921e..5dae817f8e 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -16,6 +16,7 @@ toc: - docs/tasks/configure-pod-container/configure-volume-storage.md - docs/tasks/configure-pod-container/configure-persistent-volume-storage.md - docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md + - docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md - docs/tasks/configure-pod-container/distribute-credentials-secure.md - docs/tasks/configure-pod-container/pull-image-private-registry.md - docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md diff --git a/docs/tasks/configure-pod-container/dapi-volume-resources.yaml b/docs/tasks/configure-pod-container/dapi-volume-resources.yaml new file mode 100644 index 0000000000..65770f283f --- /dev/null +++ b/docs/tasks/configure-pod-container/dapi-volume-resources.yaml @@ -0,0 +1,54 @@ +apiVersion: v1 +kind: Pod +metadata: + name: kubernetes-downwardapi-volume-example-2 +spec: + containers: + - name: client-container + image: gcr.io/google_containers/busybox:1.24 + command: ["sh", "-c"] + args: + - while true; do + echo -en '\n'; + if [[ -e /etc/cpu_limit ]]; then + echo -en '\n'; cat /etc/cpu_limit; fi; + if [[ -e /etc/cpu_request ]]; then + echo -en '\n'; cat /etc/cpu_request; fi; + if [[ -e /etc/mem_limit ]]; then + echo -en '\n'; cat /etc/mem_limit; fi; + if [[ -e /etc/mem_request ]]; then + echo -en '\n'; cat /etc/mem_request; fi; + sleep 5; + done; + resources: + requests: + memory: "32Mi" + cpu: "125m" + limits: + memory: "64Mi" + cpu: "250m" + volumeMounts: + - name: podinfo + mountPath: /etc + readOnly: false + volumes: + - name: podinfo + downwardAPI: + items: + - path: "cpu_limit" + resourceFieldRef: + containerName: client-container + resource: limits.cpu + - path: "cpu_request" + resourceFieldRef: + containerName: client-container + resource: requests.cpu + - path: "mem_limit" + resourceFieldRef: + containerName: client-container + resource: limits.memory + - path: "mem_request" + resourceFieldRef: + containerName: client-container + resource: requests.memory + diff --git a/docs/tasks/configure-pod-container/dapi-volume.yaml b/docs/tasks/configure-pod-container/dapi-volume.yaml new file mode 100644 index 0000000000..7126cefae5 --- /dev/null +++ b/docs/tasks/configure-pod-container/dapi-volume.yaml @@ -0,0 +1,39 @@ +apiVersion: v1 +kind: Pod +metadata: + name: kubernetes-downwardapi-volume-example + labels: + zone: us-est-coast + cluster: test-cluster1 + rack: rack-22 + annotations: + build: two + builder: john-doe +spec: + containers: + - name: client-container + image: gcr.io/google_containers/busybox + command: ["sh", "-c"] + args: + - while true; do + if [[ -e /etc/labels ]]; then + echo -en '\n\n'; cat /etc/labels; fi; + if [[ -e /etc/annotations ]]; then + echo -en '\n\n'; cat /etc/annotations; fi; + sleep 5; + done; + volumeMounts: + - name: podinfo + mountPath: /etc + readOnly: false + volumes: + - name: podinfo + downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "annotations" + fieldRef: + fieldPath: metadata.annotations + diff --git a/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md b/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md new file mode 100644 index 0000000000..a55d22f387 --- /dev/null +++ b/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information.md @@ -0,0 +1,242 @@ +--- +title: Exposing Pod Information to Containers Using a DownwardApiVolumeFile +--- + +{% capture overview %} + +This page shows how a Pod can use a DownwardAPIVolumeFile to expose information +about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose +Pod fields and Container fields. + +{% endcapture %} + + +{% capture prerequisites %} + +{% include task-tutorial-prereqs.md %} + +{% endcapture %} + +{% capture steps %} + +## The Downward API + +There are two ways to expose Pod and Container fields to a running Container: + +* [Environment variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/) +* DownwardAPIVolumeFiles + +Together, these two ways of exposing Pod and Container fields are called the +*Downward API*. + +## Storing Pod fields + +In this exercise, you create a Pod that has one Container. +Here is the configuration file for the Pod: + +{% include code.html language="yaml" file="dapi-volume.yaml" ghlink="/docs/tasks/configure-pod-container/dapi-volume.yaml" %} + +In the configuration file, you can see that the Pod has a `downwardAPI` Volume, +and the Container mounts the Volume at `/etc`. + +Look at the `items` array under `downwardAPI`. Each element of the array is a +[DownwardAPIVolumeFile](/docs/resources-reference/v1.5/#downwardapivolumefile-v1). +The first element specifies that the value of the Pod's +`metadata.labels` field should be stored in a file named `labels`. +The second element specifies that the value of the Pod's `annotations` +field should be stored in a file named `annotations`. + +**Note**: The fields in this example are Pod fields. They are not +fields of the Container in the Pod. + +Create the Pod: + +```shell +kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/dapi-volume.yaml +``` + +Verify that Container in the Pod is running: + +```shell +kubectl get pods +``` + +View the Container's logs: + +```shell +kubectl logs kubernetes-downwardapi-volume-example +``` + +The output shows the contents of the `labels` file and the `annotations` file: + +```shell +cluster="test-cluster1" +rack="rack-22" +zone="us-est-coast" + +build="two" +builder="john-doe" +``` + +Get a shell into the Container that is running in your Pod: + +``` +kubectl exec -it kubernetes-downwardapi-volume-example -- sh +``` + +In your shell, view the `labels` file: + +```shell +/# cat /etc/labels +``` + +The output shows that all of the Pod's labels have been written +to the `labels` file: + +```shell +cluster="test-cluster1" +rack="rack-22" +zone="us-est-coast" +``` + +Similarly, view the `annotations` file: + +```shell +/# cat /etc/annotations +``` + +View the files in the `/etc` directory: + +```shell +/# ls -laR /etc +``` + +In the output, you can see that the `labels` and `annotations` files +are in a temporary subdirectory: in this example, +`..2982_06_02_21_47_53.299460680`. In the `/etc` directory, `..data` is +a symbolic link to the temporary subdirectory. Also in the `/etc` directory, +`labels` and `annotations` are symbolic links. + +``` +drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680 +lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680 +lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations +lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels + +/etc/..2982_06_02_21_47_53.299460680: +total 8 +-rw-r--r-- ... Feb 6 21:47 annotations +-rw-r--r-- ... Feb 6 21:47 labels +``` + +Using symbolic links enables dynamic atomic refresh of the metadata; updates are +written to a new temporary directory, and the `..data` symlink is updated +atomically using +[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html). + +Exit the shell: + +```shell +/# exit +``` + +## Storing Container fields + +The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile. +In this next exercise, you store Container fields. Here is the configuration +file for a Pod that has one Container: + +{% include code.html language="yaml" file="dapi-volume-resources.yaml" ghlink="/docs/tasks/configure-pod-container/dapi-volume-resources.yaml" %} + +In the configuration file, you can see that the Pod has a `downwardAPI` Volume, +and the Container mounts the Volume at `/etc`. + +Look at the `items` array under `downwardAPI`. Each element of the array is a +DownwardAPIVolumeFile. + +The first element specifies that in the Container named `client-container`, +the value of the `limits.cpu` field +`metadata.labels` field should be stored in a file named `cpu_limit`. + +Create the Pod: + +```shell +kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/dapi-volume-resources.yaml +``` + +Get a shell into the Container that is running in your Pod: + +``` +kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh +``` + +In your shell, view the `cpu_limit` file: + +```shell +/# cat /etc/cpu_limit +``` +You can use similar commands to view the `cpu_request`, `mem_limit` and +`mem_request` files. + +{% endcapture %} + +{% capture discussion %} + +## Capabilities of the Downward API + +The following information is available to Containers through environment +variables and DownwardAPIVolumeFiles: + +* The node’s name +* The Pod’s name +* The Pod’s namespace +* The Pod’s IP address +* The Pod’s service account name +* A Container’s CPU limit +* A container’s CPU request +* A Container’s memory limit +* A Container’s memory request + +In addition, the following information is available through +DownwardAPIVolumeFiles. + +* The Pod's labels +* The Pod's annotations + +**Note**: If CPU and memory limits are not specified for a Container, the +Downward API defaults to the node allocatable value for CPU and memory. + +## Projecting keys to specific paths and file permissions + +You can project keys to specific paths and specific permissions on a per-file +basis. For more information, see +[Secrets](/docs/user-guide/secrets/). + +## Motivation for the Downward API + +It is sometimes useful for a Container to have information about itself, without +being overly coupled to Kubernetes. The Downward API allows containers to consume +information about themselves or the cluster without using the Kubernetes client +or API server. + +An example is an existing application that assumes a particular well-known +environment variable holds a unique identifier. One possibility is to wrap the +application, but that is tedious and error prone, and it violates the goal of low +coupling. A better option would be to use the Pod's name as an identifier, and +inject the Pod's name into the well-known environment variable. + +{% endcapture %} + + +{% capture whatsnext %} + +* [PodSpec](/docs/resources-reference/v1.5/#podspec-v1) +* [Volume](/docs/resources-reference/v1.5/#volume-v1) +* [DownwardAPIVolumeSource](/docs/resources-reference/v1.5/#downwardapivolumesource-v1) +* [DownwardAPIVolumeFile](/docs/resources-reference/v1.5/#downwardapivolumefile-v1) +* [ResourceFieldSelector](/docs/resources-reference/v1.5/#resourcefieldselector-v1) + +{% endcapture %} + +{% include templates/task.md %} + diff --git a/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md b/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md index 1390727000..10ac238c5e 100644 --- a/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md +++ b/docs/tasks/configure-pod-container/environment-variable-expose-pod-information.md @@ -26,6 +26,17 @@ Together, these two ways of exposing Pod and Container fields are called the {% capture steps %} +## The Downward API + +There are two ways to expose Pod and Container fields to a running Container: + +* Environment variables +* [DownwardAPIVolumeFiles](/docs/resources-reference/v1.5/#downwardapivolumefile-v1) + +Together, these two ways of exposing Pod and Container fields are called the +*Downward API*. + + ## Using Pod fields as values for environment variables In this exercise, you create a Pod that has one Container. Here is the @@ -161,3 +172,4 @@ The output shows the values of selected environment variables: {% include templates/task.md %} + diff --git a/docs/tasks/index.md b/docs/tasks/index.md index 39f81c6751..d490fe5532 100644 --- a/docs/tasks/index.md +++ b/docs/tasks/index.md @@ -12,6 +12,8 @@ single thing, typically by giving a short sequence of steps. * [Defining a Command and Arguments for a Container](/docs/tasks/configure-pod-container/define-command-argument-container/) * [Assigning CPU and RAM Resources to a Container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) * [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/) +* [Exposing Pod Information to Containers Through Environment Variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/) +* [Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) * [Distributing Credentials Securely](/docs/tasks/configure-pod-container/distribute-credentials-secure/) * [Pulling an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry/) * [Configuring Liveness and Readiness Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) @@ -55,3 +57,4 @@ single thing, typically by giving a short sequence of steps. If you would like to write a task page, see [Creating a Documentation Pull Request](/docs/contribute/create-pull-request/). + From cd69b5b1e30bf2613191d0f8e80b2ac9a400b436 Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Thu, 16 Feb 2017 13:20:48 -0800 Subject: [PATCH 157/213] Add note about moved content. (#2563) --- docs/user-guide/downward-api/index.md | 135 +------------------ docs/user-guide/downward-api/volume/index.md | 116 +--------------- 2 files changed, 4 insertions(+), 247 deletions(-) diff --git a/docs/user-guide/downward-api/index.md b/docs/user-guide/downward-api/index.md index 33b2b06c49..beb1cddd9b 100644 --- a/docs/user-guide/downward-api/index.md +++ b/docs/user-guide/downward-api/index.md @@ -5,137 +5,6 @@ assignees: title: Using the Downward API to Convey Pod Properties --- -It is sometimes useful for a container to have information about itself, but we -want to be careful not to over-couple containers to Kubernetes. The downward -API allows containers to consume information about themselves or the system and -expose that information how they want it, without necessarily coupling to the -Kubernetes client or REST API. +{% include user-guide-content-moved.md %} -An example of this is a "legacy" app that is already written assuming -that a particular environment variable will hold a unique identifier. While it -is often possible to "wrap" such applications, this is tedious and error prone, -and violates the goal of low coupling. Instead, the user should be able to use -the Pod's name, for example, and inject it into this well-known variable. - - -## Capabilities - -The following information is available to a `Pod` through the downward API: - -* The node's name -*   The pod's name -* The pod's namespace -* The pod's IP -* The pod's service account name -* A container's cpu limit -* A container's cpu request -* A container's memory limit -* A container's memory request - -More information will be exposed through this same API over time. - - -## Exposing pod information into a container - -Containers consume information from the downward API using environment -variables or using a volume plugin. - - -## Environment variables - -Most environment variables in the Kubernetes API use the `value` field to carry -simple values. However, the alternate `valueFrom` field allows you to specify -a `fieldRef` to select fields from the pod's definition, and a `resourceFieldRef` -to select fields from one of its container's definition. - -The `fieldRef` field is a structure that has an `apiVersion` field and a `fieldPath` -field. The `fieldPath` field is an expression designating a field of the pod. The -`apiVersion` field is the version of the API schema that the `fieldPath` is -written in terms of. If the `apiVersion` field is not specified it is -defaulted to the API version of the enclosing object. - -The `fieldRef` is evaluated and the resulting value is used as the value for -the environment variable. This allows users to publish their pod's name in any -environment variable they want. - -The `resourceFieldRef` is a structure that has a `containerName` field, a `resource` -field, and a `divisor` field. The `containerName` is the name of a container, -whose resource (cpu or memory) information is to be exposed. The `containerName` is -optional for environment variables and defaults to the current container. The -`resource` field is an expression designating a resource in a container, and the `divisor` -field specifies an output format of the resource being exposed. If the `divisor` -is not specified, it defaults to "1" for cpu and memory. The table shows possible -values for cpu and memory resources for `resource` and `divisor` settings: - - -| Setting | Cpu | Memory | -| ------------- |-------------| -----| -| resource | limits.cpu, requests.cpu| limits.memory, requests.memory| -| divisor | 1(cores), 1m(millicores) | 1(bytes), 1k(kilobytes), 1M(megabytes), 1G(gigabytes), 1T(terabytes), 1P(petabytes), 1E(exabytes), 1Ki(kibibyte), 1Mi(mebibyte), 1Gi(gibibyte), 1Ti(tebibyte), 1Pi(pebibyte), 1Ei(exbibyte)| - - -### Example - -This is an example of a pod that consumes its name and namespace via the -downward API: - -{% include code.html language="yaml" file="dapi-pod.yaml" ghlink="/docs/user-guide/downward-api/dapi-pod.yaml" %} - -This is an example of a pod that consumes its container's resources via the downward API: - -{% include code.html language="yaml" file="dapi-container-resources.yaml" ghlink="/docs/user-guide/downward-api/dapi-container-resources.yaml" %} - -## Downward API volume - -Using a similar syntax it's possible to expose pod information to containers using plain text files. -Downward API are dumped to a mounted volume. This is achieved using a `downwardAPI` -volume type and the different items represent the files to be created. `fieldPath` references the field to be exposed. -For exposing a container's resources limits and requests, `containerName` must be specified with `resourceFieldRef`. - -Downward API volume permits to store more complex data like [`metadata.labels`](/docs/user-guide/labels) and [`metadata.annotations`](/docs/user-guide/annotations). Currently key/value pair set fields are saved using `key="value"` format: - -```conf -key1="value1" -key2="value2" -``` - -In future, it will be possible to specify an output format option. - -Downward API volumes can expose: - -* The node's name -* The pod's name -* The pod's namespace -* The pod's labels -* The pod's annotations -* The pod's service account name -* A container's cpu limit -* A container's cpu request -* A container's memory limit -* A container's memory request - -The downward API volume refreshes its data in step with the kubelet refresh loop. When labels will be modifiable on the fly without respawning the pod containers will be able to detect changes through mechanisms such as [inotify](https://en.wikipedia.org/wiki/Inotify). - -In future, it will be possible to specify a specific annotation or label. - -#### Projecting keys to specific paths and file permissions - -You can project keys to specific paths and specific permissions on a per-file -basis. The [Secrets](/docs/user-guide/secrets/) user guide explains the syntax. - -### Example - -This is an example of a pod that consumes its labels and annotations via the downward API volume, labels and annotations are dumped in `/etc/labels` and in `/etc/annotations`, respectively: - -{% include code.html language="yaml" file="volume/dapi-volume.yaml" ghlink="/docs/user-guide/downward-api/volume/dapi-volume.yaml" %} - -This is an example of a pod that consumes its container's resources via the downward API volume. - -{% include code.html language="yaml" file="volume/dapi-volume-resources.yaml" ghlink="/docs/user-guide/downward-api/volume/dapi-volume-resources.yaml" %} - -For a more thorough example, see -[environment variables](/docs/user-guide/environment-guide/). - -## Default values for container resource limits - -If cpu and memory limits are not specified for a container, the downward API will default to the node allocatable value for cpu and memory. +[Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) diff --git a/docs/user-guide/downward-api/volume/index.md b/docs/user-guide/downward-api/volume/index.md index 882b2da1e9..6f359cc797 100644 --- a/docs/user-guide/downward-api/volume/index.md +++ b/docs/user-guide/downward-api/volume/index.md @@ -2,118 +2,6 @@ title: Downward API Volumes --- -Following this example, you will create a pod with a downward API volume. -A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be for example some [metadata](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#metadata) or a container's [resources](/docs/user-guide/compute-resources). +{% include user-guide-content-moved.md %} -Supported metadata fields: - -1. `metadata.annotations` -2. `metadata.namespace` -3. `metadata.name` -4. `metadata.labels` - -Supported container's resources: - -1. `limits.cpu` -2. `limits.memory` -3. `requests.cpu` -4. `requests.memory` - -### Step Zero: Prerequisites - -This example assumes you have a Kubernetes cluster installed and running, and the `kubectl` command line tool somewhere in your path. Please see the [gettingstarted](/docs/getting-started-guides/) for installation instructions for your platform. - -### Step One: Create the pod - -Use the [dapi-volume.yaml](/docs/user-guide/downward-api/volume/dapi-volume.yaml) file to create a Pod with a downward API volume which stores pod labels and pod annotations to `/etc/labels` and `/etc/annotations` respectively. - -```shell -$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume.yaml -``` - -### Step Two: Examine pod/container output - -The pod displays (every 5 seconds) the content of the dump files which can be executed via the usual `kubectl log` command - -```shell -$ kubectl logs kubernetes-downwardapi-volume-example -cluster="test-cluster1" -rack="rack-22" -zone="us-est-coast" -build="two" -builder="john-doe" -kubernetes.io/config.seen="2015-08-24T13:47:23.432459138Z" -kubernetes.io/config.source="api" -``` - -### Internals - -In pod's `/etc` directory one may find the file created by the plugin (system files elided): - -```shell -$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh -/ # ls -laR /etc -/etc: -total 4 -drwxrwxrwt 3 0 0 120 Jun 1 19:55 . -drwxr-xr-x 17 0 0 4096 Jun 1 19:55 .. -drwxr-xr-x 2 0 0 80 Jun 1 19:55 ..6986_01_06_15_55_10.473583074 -lrwxrwxrwx 1 0 0 31 Jun 1 19:55 ..data -> ..6986_01_06_15_55_10.473583074 -lrwxrwxrwx 1 0 0 18 Jun 1 19:55 annotations -> ..data/annotations -lrwxrwxrwx 1 0 0 13 Jun 1 19:55 labels -> ..data/labels - -/etc/..6986_01_06_15_55_10.473583074: -total 8 -drwxr-xr-x 2 0 0 80 Jun 1 19:55 . -drwxrwxrwt 3 0 0 120 Jun 1 19:55 .. --rw-r--r-- 1 0 0 129 Jun 1 19:55 annotations --rw-r--r-- 1 0 0 59 Jun 1 19:55 labels -/ # -``` - -The file `labels` is stored in a temporary directory (`..6986_01_06_15_55_10.473583074` in the example above) which is symlinked to by `..data`. Symlinks for annotations and labels in `/etc` point to files containing the actual metadata through the `..data` indirection.  This structure allows for dynamic atomic refresh of the metadata: updates are written to a new temporary directory, and the `..data` symlink is updated atomically using `rename(2)`. - -## Example of downward API volume with container resources - -Use the `docs/user-guide/downward-api/volume/dapi-volume-resources.yaml` file to create a Pod with a downward API volume which stores its container's limits and requests in /etc. - -```shell -$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume-resources.yaml -``` - -### Examine pod/container output - -In pod's `/etc` directory one may find the files created by the plugin: - -```shell -$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh -/ # ls -alR /etc -/etc: -total 4 -drwxrwxrwt 3 0 0 160 Jun 1 19:47 . -drwxr-xr-x 17 0 0 4096 Jun 1 19:48 .. -drwxr-xr-x 2 0 0 120 Jun 1 19:47 ..6986_01_06_15_47_23.076909525 -lrwxrwxrwx 1 0 0 31 Jun 1 19:47 ..data -> ..6986_01_06_15_47_23.076909525 -lrwxrwxrwx 1 0 0 16 Jun 1 19:47 cpu_limit -> ..data/cpu_limit -lrwxrwxrwx 1 0 0 18 Jun 1 19:47 cpu_request -> ..data/cpu_request -lrwxrwxrwx 1 0 0 16 Jun 1 19:47 mem_limit -> ..data/mem_limit -lrwxrwxrwx 1 0 0 18 Jun 1 19:47 mem_request -> ..data/mem_request - -/etc/..6986_01_06_15_47_23.076909525: -total 16 -drwxr-xr-x 2 0 0 120 Jun 1 19:47 . -drwxrwxrwt 3 0 0 160 Jun 1 19:47 .. --rw-r--r-- 1 0 0 1 Jun 1 19:47 cpu_limit --rw-r--r-- 1 0 0 1 Jun 1 19:47 cpu_request --rw-r--r-- 1 0 0 8 Jun 1 19:47 mem_limit --rw-r--r-- 1 0 0 8 Jun 1 19:47 mem_request - -/ # cat /etc/cpu_limit -1 -/ # cat /etc/mem_limit -67108864 -/ # cat /etc/cpu_request -1 -/ # cat /etc/mem_request -33554432 -``` +[Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) From 17daf981f7476756611414e4abc247baa8c1d736 Mon Sep 17 00:00:00 2001 From: Guillaume Breton Date: Thu, 16 Feb 2017 18:07:10 +0000 Subject: [PATCH 158/213] Fix typos in running zookeeper article --- docs/tutorials/stateful-application/zookeeper.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/tutorials/stateful-application/zookeeper.md b/docs/tutorials/stateful-application/zookeeper.md index ba2bb219d6..e31d8e280b 100644 --- a/docs/tutorials/stateful-application/zookeeper.md +++ b/docs/tutorials/stateful-application/zookeeper.md @@ -580,7 +580,7 @@ env: key: purge.interval ``` -The entry point of the container invokes a bash script, `zkConfig.sh`, prior to +The entry point of the container invokes a bash script, `zkGenConfig.sh`, prior to launching the ZooKeeper server process. This bash script generates the ZooKeeper configuration files from the supplied environment variables. @@ -653,7 +653,7 @@ ZK_LOG_DIR=/var/log/zookeeper ### Configuring Logging -One of the files generated by the `zkConfigGen.sh` script controls ZooKeeper's logging. +One of the files generated by the `zkGenConfig.sh` script controls ZooKeeper's logging. ZooKeeper uses [Log4j](http://logging.apache.org/log4j/2.x/), and, by default, it uses a time and size based rolling file appender for its logging configuration. Get the logging configuration from one of Pods in the `zk` StatefulSet. From e854c082ad5e3144ffd0f023b55d2eec8e19db02 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Fri, 17 Feb 2017 16:54:23 +0800 Subject: [PATCH 159/213] fix typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1、column PORTS is missed 2、fix command `kubectl get pods`output --- docs/admin/static-pods.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/admin/static-pods.md b/docs/admin/static-pods.md index cacf6e2010..610da03da7 100644 --- a/docs/admin/static-pods.md +++ b/docs/admin/static-pods.md @@ -72,8 +72,8 @@ When kubelet starts, it automatically starts all pods defined in directory speci ```shell [joe@my-node1 ~] $ docker ps -CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES -f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c ``` If we look at our Kubernetes API server (running on host `my-master`), we see that a new mirror-pod was created there too: @@ -81,9 +81,9 @@ If we look at our Kubernetes API server (running on host `my-master`), we see th ```shell [joe@host ~] $ ssh my-master [joe@my-master ~] $ kubectl get pods -POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE -static-web-my-node1 172.17.0.3 my-node1/192.168.100.71 role=myrole Running 11 minutes - web nginx Running 11 minutes +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 2m + ``` Labels from the static pod are propagated into the mirror-pod and can be used as usual for filtering. @@ -94,8 +94,9 @@ Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/ [joe@my-master ~] $ kubectl delete pod static-web-my-node1 pods/static-web-my-node1 [joe@my-master ~] $ kubectl get pods -POD IP CONTAINER(S) IMAGE(S) HOST ... -static-web-my-node1 172.17.0.3 my-node1/192.168.100.71 ... +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 12s + ``` Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while: From 632b2ba4742ac1e8517e194f1887055cdfd6ca29 Mon Sep 17 00:00:00 2001 From: jianglingxia Date: Wed, 15 Feb 2017 16:33:38 +0800 Subject: [PATCH 160/213] modify one word examples to example --- docs/user-guide/walkthrough/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/walkthrough/index.md b/docs/user-guide/walkthrough/index.md index d7872b2260..e0400ec7ed 100644 --- a/docs/user-guide/walkthrough/index.md +++ b/docs/user-guide/walkthrough/index.md @@ -9,7 +9,7 @@ title: Kubernetes 101 For Kubernetes 101, we will cover kubectl, pods, volumes, and multiple containers -In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes). +In order for the kubectl usage examples to work, make sure you have an example directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes). * TOC {:toc} From f8c25df15616e25140c84a2fedfe6c5f8adf05e6 Mon Sep 17 00:00:00 2001 From: Michael Fraenkel Date: Fri, 17 Feb 2017 08:34:06 -0500 Subject: [PATCH 161/213] Revert "mend" This reverts commit 324451c3378b4ba01d27e3db6117f86d0517a598. --- docs/user-guide/configmap/index.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 40b3fa181b..36d3e89394 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -317,7 +317,10 @@ spec: restartPolicy: Never ``` -When this pod is run, the output will be empty. +When this pod is run, its output will include the lines: + +```shell +``` ### Use-Case: Set command-line arguments with ConfigMap From ce82d6301da92b61818ce2d7135ee206ffe463e2 Mon Sep 17 00:00:00 2001 From: Michael Fraenkel Date: Fri, 17 Feb 2017 08:34:15 -0500 Subject: [PATCH 162/213] Revert "Document new optional support for ConfigMap and Secret" This reverts commit 7abcc6c8540a7b0a4f6712e77e0f5cb134271bed. --- docs/user-guide/configmap/index.md | 70 ++-------------------------- docs/user-guide/secrets/index.md | 74 +++--------------------------- 2 files changed, 10 insertions(+), 134 deletions(-) diff --git a/docs/user-guide/configmap/index.md b/docs/user-guide/configmap/index.md index 36d3e89394..1355e599f2 100644 --- a/docs/user-guide/configmap/index.md +++ b/docs/user-guide/configmap/index.md @@ -291,37 +291,6 @@ SPECIAL_LEVEL_KEY=very SPECIAL_TYPE_KEY=charm ``` -#### Optional ConfigMap in environment variables - -There might be situations where environment variables are not -always required. These environment variables can be marked as optional in a -pod like so: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: dapi-test-pod -spec: - containers: - - name: test-container - image: gcr.io/google_containers/busybox - command: [ "/bin/sh", "-c", "env" ] - env: - - name: SPECIAL_LEVEL_KEY - valueFrom: - configMapKeyRef: - name: a-config - key: akey - optional: true - restartPolicy: Never -``` - -When this pod is run, its output will include the lines: - -```shell -``` - ### Use-Case: Set command-line arguments with ConfigMap ConfigMaps can also be used to set the value of the command or arguments in a container. This is @@ -453,38 +422,6 @@ very You can project keys to specific paths and specific permissions on a per-file basis. The [Secrets](/docs/user-guide/secrets/) user guide explains the syntax. -#### Optional ConfigMap via volume plugin - -Volumes and files provided by a ConfigMap can be also be marked as optional. -The ConfigMap or the key specified does not have to exist. The mount path for -such items will always be created. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: dapi-test-pod -spec: - containers: - - name: test-container - image: gcr.io/google_containers/busybox - command: [ "/bin/sh", "-c", "ls /etc/config" ] - volumeMounts: - - name: config-volume - mountPath: /etc/config - volumes: - - name: config-volume - configMap: - name: no-config - optional: true - restartPolicy: Never -``` - -When this pod is run, the output will be: - -```shell -``` - ## Real World Example: Configuring Redis Let's take a look at a real-world example: configuring redis using ConfigMap. Say we want to inject @@ -580,10 +517,9 @@ $ kubectl exec -it redis redis-cli ## Restrictions -ConfigMaps must be created before they are consumed in pods unless they are -marked as optional. Controllers may be written to tolerate missing -configuration data; consult individual components configured via ConfigMap on -a case-by-case basis. +ConfigMaps must be created before they are consumed in pods. Controllers may be written to tolerate +missing configuration data; consult individual components configured via ConfigMap on a case-by-case +basis. ConfigMaps reside in a namespace. They can only be referenced by pods in the same namespace. diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md index 9723e00aee..29e9044fde 100644 --- a/docs/user-guide/secrets/index.md +++ b/docs/user-guide/secrets/index.md @@ -375,41 +375,6 @@ However, it is using its local ttl-based cache for getting the current value of As a result, the total delay from the moment when the secret is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of secrets cache in kubelet. -#### Optional Secrets as Files from a Pod - -Volumes and files provided by a Secret can be also be marked as optional. -The Secret or the key within a Secret does not have to exist. The mount path for -such items will always be created. - -```json -{ - "apiVersion": "v1", - "kind": "Pod", - "metadata": { - "name": "mypod", - "namespace": "myns" - }, - "spec": { - "containers": [{ - "name": "mypod", - "image": "redis", - "volumeMounts": [{ - "name": "foo", - "mountPath": "/etc/foo" - }] - }], - "volumes": [{ - "name": "foo", - "secret": { - "secretName": "mysecret", - "defaultMode": 256, - "optional": true - } - }] - } -} -``` - #### Using Secrets as Environment Variables To use a secret in an environment variable in a pod: @@ -456,30 +421,6 @@ $ echo $SECRET_PASSWORD 1f2d1e2e67df ``` -#### Optional Secrets from Environment Variables - -You may not want to require all your secrets to exist. They can be marked as -optional as shown in the pod: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: optional-secret-env-pod -spec: - containers: - - name: mycontainer - image: redis - env: - - name: OPTIONAL_SECRET - valueFrom: - secretKeyRef: - name: mysecret - key: username - optional: true - restartPolicy: Never -``` - #### Using imagePullSecrets An imagePullSecret is a way to pass a secret that contains a Docker (or other) image registry @@ -511,8 +452,7 @@ can be automatically attached to pods based on their service account. Secret volume sources are validated to ensure that the specified object reference actually points to an object of type `Secret`. Therefore, a secret -needs to be created before any pods that depend on it, unless it is marked as -optional. +needs to be created before any pods that depend on it. Secret API objects reside in a namespace. They can only be referenced by pods in that same namespace. @@ -532,12 +472,12 @@ not common ways to create pods.) When a pod is created via the API, there is no check whether a referenced secret exists. Once a pod is scheduled, the kubelet will try to fetch the -secret value. If a required secret cannot be fetched because it does not -exist or because of a temporary lack of connection to the API server, the -kubelet will periodically retry. It will report an event about the pod -explaining the reason it is not started yet. Once the secret is fetched, the -kubelet will create and mount a volume containing it. None of the pod's -containers will start until all the pod's volumes are mounted. +secret value. If the secret cannot be fetched because it does not exist or +because of a temporary lack of connection to the API server, kubelet will +periodically retry. It will report an event about the pod explaining the +reason it is not started yet. Once the secret is fetched, the kubelet will +create and mount a volume containing it. None of the pod's containers will +start until all the pod's volumes are mounted. ## Use cases From 8e490b4251601507ead8f853a2fb0c74431aa280 Mon Sep 17 00:00:00 2001 From: Harry Zhang Date: Sat, 18 Feb 2017 03:06:01 +0800 Subject: [PATCH 163/213] Add kubelet eviction in GC doc (#2484) --- docs/admin/garbage-collection.md | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index a960172426..9717a41dd8 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -42,15 +42,34 @@ to free. Default is 80%. We also allow users to customize garbage collection policy through the following kubelet flags: 1. `minimum-container-ttl-duration`, minimum age for a finished container before it is -garbage collected. Default is 1 minute. +garbage collected. Default is 0 minute, which means any finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to retain -per container. Default is 2. +per container. Default is 1. 3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. -Default is 100. +Default is -1, which means there is no global limit. Containers can potentially be garbage collected before their usefulness has expired. These containers can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for -`maximum-dead-containers-per-container` is highly recommended to allow at least 2 dead containers to be +`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be retained per expected container. A higher value for `maximum-dead-containers` is also recommended for a similar reason. See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. + + +### Deprecation + +Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future. + +Including: + +| Existing Flag | New Flag | Rationale | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` | existing eviction signals can trigger image garbage collection | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | +| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | +| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | +| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources | + +See [kubelet eviction design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/kubelet-eviction.md) for more details. From 7022b43bc23b959a837bb85b924bf0768231f62c Mon Sep 17 00:00:00 2001 From: Bruce Auyeung Date: Mon, 20 Feb 2017 10:24:13 +0800 Subject: [PATCH 164/213] dedent yaml code blocks otherwise extra redundant ````yaml` characters will be displayed because github code fencing doesn't need any indentation --- docs/admin/kubeadm.md | 80 +++++++++++++++++++++---------------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index edf9c87a7d..a43beec497 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -180,49 +180,49 @@ available as configuration file options. ### Sample Master Configuration - ```yaml - apiVersion: kubeadm.k8s.io/v1alpha1 - kind: MasterConfiguration - api: - advertiseAddresses: - - - - - bindPort: - externalDNSNames: - - - - - authorizationMode: - cloudProvider: - discovery: - bindPort: - etcd: - endpoints: - - - - - caFile: - certFile: - keyFile: - kubernetesVersion: - networking: - dnsDomain: - serviceSubnet: - podSubnet: - secrets: - givenToken: - ``` +```yaml +apiVersion: kubeadm.k8s.io/v1alpha1 +kind: MasterConfiguration +api: + advertiseAddresses: + - + - + bindPort: + externalDNSNames: + - + - +authorizationMode: +cloudProvider: +discovery: + bindPort: +etcd: + endpoints: + - + - + caFile: + certFile: + keyFile: +kubernetesVersion: +networking: + dnsDomain: + serviceSubnet: + podSubnet: +secrets: + givenToken: +``` ### Sample Node Configuration - ```yaml - apiVersion: kubeadm.k8s.io/v1alpha1 - kind: NodeConfiguration - apiPort: - discoveryPort: - masterAddresses: - - - secrets: - givenToken: - ``` +```yaml +apiVersion: kubeadm.k8s.io/v1alpha1 +kind: NodeConfiguration +apiPort: +discoveryPort: +masterAddresses: +- +secrets: + givenToken: +``` ## Automating kubeadm From dc053ed54fd3e5a8964915cd04bde4d739eb6e4e Mon Sep 17 00:00:00 2001 From: xuxinkun Date: Fri, 17 Feb 2017 18:19:33 +0800 Subject: [PATCH 165/213] Add more options for self-registration. --- docs/admin/node.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/admin/node.md b/docs/admin/node.md index 0923169256..f91f155919 100644 --- a/docs/admin/node.md +++ b/docs/admin/node.md @@ -176,6 +176,9 @@ For self-registration, the kubelet is started with the following options: - `--kubeconfig=` - Path to credentials to authenticate itself to the apiserver. - `--cloud-provider=` - How to talk to a cloud provider to read metadata about itself. - `--register-node` - Automatically register with the API server. + - `--node-ip` IP address of the node. + - `--node-labels` - Labels to add when registering the node in the cluster. + - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master. Currently, any kubelet is authorized to create/modify any node resource, but in practice it only creates/modifies its own. (In the future, we plan to only allow a kubelet to modify its own node resource.) From dfb8b79b15ddea13a96fefee9dd30666ca1b7464 Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Thu, 16 Feb 2017 16:44:45 +0800 Subject: [PATCH 166/213] Parallel Jobs with a *work queue*: do not specify `.spec.completions`, default to `.spec.Parallelism`, not default to 1 --- docs/user-guide/jobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/jobs.md b/docs/user-guide/jobs.md index d64ae9d730..438b63dff7 100644 --- a/docs/user-guide/jobs.md +++ b/docs/user-guide/jobs.md @@ -120,7 +120,7 @@ There are three main types of jobs: - the job is complete when there is one successful pod for each value in the range 1 to `.spec.completions`. - **not implemented yet:** each pod passed a different index in the range 1 to `.spec.completions`. 1. Parallel Jobs with a *work queue*: - - do not specify `.spec.completions` + - do not specify `.spec.completions`, default to `.spec.Parallelism` - the pods must coordinate with themselves or an external service to determine what each should work on - each pod is independently capable of determining whether or not all its peers are done, thus the entire Job is done. - when _any_ pod terminates with success, no new pods are created. From b807813244847ccea3b5fdb2c61439334cf63422 Mon Sep 17 00:00:00 2001 From: Olegs Jeremejevs Date: Tue, 21 Feb 2017 17:48:51 +0200 Subject: [PATCH 167/213] Fix typo in concepts --- 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 93e4533caf..8e738e809e 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -17,7 +17,7 @@ Once you've set your desired state, the *Kubernetes Control Plane* works to make ## Kubernetes Objects -Kubernetes contains a number of abstractions that represent your the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. +Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. The basic Kubernetes objects include: From 65eacf1145151a8be3b019a0f688fac5a488f47a Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 21 Feb 2017 15:23:24 +0800 Subject: [PATCH 168/213] fix typo --- .../configure-pod-container/pull-image-private-registry.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/pull-image-private-registry.md b/docs/tasks/configure-pod-container/pull-image-private-registry.md index e9b640873a..f54d881178 100644 --- a/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -80,7 +80,7 @@ Copy the base64 representation of the secret data into a file named `secret64`. **Important**: Make sure there are no line breaks in your `secret64` file. -To understand what is in the `dockercfg` field, convert the secret data to a +To understand what is in the `.dockercfg` field, convert the secret data to a readable format: base64 -d secret64 From 4806f01d8f8e646bcfbb513811e5fab339c9d337 Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 21 Feb 2017 11:52:18 +0800 Subject: [PATCH 169/213] add an example --- docs/concepts/configuration/container-command-args.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/concepts/configuration/container-command-args.md b/docs/concepts/configuration/container-command-args.md index 25d555f702..3f39baff57 100644 --- a/docs/concepts/configuration/container-command-args.md +++ b/docs/concepts/configuration/container-command-args.md @@ -66,6 +66,7 @@ Here are some examples: | `[/ep-1]` | `[foo bar]` | <not set> | <not set> | `[ep-1 foo bar]` | | `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <not set> | `[ep-2]` | | `[/ep-1]` | `[foo bar]` | <not set> | `[zoo boo]` | `[ep-1 zoo boo]` | +| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` | {% endcapture %} From 406fe2683bff73ac4fb5dc3040dc3e71ed5393ba Mon Sep 17 00:00:00 2001 From: Ben Mathews Date: Fri, 17 Feb 2017 14:39:48 -0700 Subject: [PATCH 170/213] Remove reference to port-forward to services port forwarding to services isn't supported. --- docs/user-guide/kubectl-cheatsheet.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index 7fc0142f04..6b67cba4a0 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -203,7 +203,6 @@ $ kubectl logs -f my-pod -c my-container # stream pod container log $ kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell $ kubectl attach my-pod -i # Attach to Running Container $ kubectl port-forward my-pod 5000:6000 # Forward port 6000 of Pod to your to 5000 on your local machine -$ kubectl port-forward my-svc 6000 # Forward port to service $ kubectl exec my-pod -- ls / # Run command in existing pod (1 container case) $ kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case) $ kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers From 363db9d8afcd1cd330fc60cacac457be9eb09b10 Mon Sep 17 00:00:00 2001 From: Guangya Liu Date: Mon, 20 Feb 2017 22:37:54 +0800 Subject: [PATCH 171/213] Fixed typos in persistent volume index.md --- docs/user-guide/persistent-volumes/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/persistent-volumes/index.md b/docs/user-guide/persistent-volumes/index.md index 4508a1a25f..e2d2661d13 100644 --- a/docs/user-guide/persistent-volumes/index.md +++ b/docs/user-guide/persistent-volumes/index.md @@ -421,7 +421,7 @@ parameters: * `restauthenabled` : Gluster REST service authentication boolean that enables authentication to the REST server. If this value is 'true', `restuser` and `restuserkey` or `secretNamespace` + `secretName` have to be filled. This option is deprecated, authentication is enabled when any of `restuser`, `restuserkey`, `secretName` or `secretNamespace` is specified. * `restuser` : Gluster REST service/Heketi user who has access to create volumes in the Gluster Trusted Pool. * `restuserkey` : Gluster REST service/Heketi user's password which will be used for authentication to the REST server. This parameter is deprecated in favor of `secretNamespace` + `secretName`. -* `secretNamespace` + `secretName` : Identification of Secret instance that containes user password to use when talking to Gluster REST service. These parameters are optional, empty password will be used when both `secretNamespace` and `secretName` are omitted. The provided secret must have type "kubernetes.io/glusterfs", e.g. created in this way: +* `secretNamespace` + `secretName` : Identification of Secret instance that contains user password to use when talking to Gluster REST service. These parameters are optional, empty password will be used when both `secretNamespace` and `secretName` are omitted. The provided secret must have type "kubernetes.io/glusterfs", e.g. created in this way: ``` $ kubectl create secret generic heketi-secret --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' --namespace=default ``` @@ -507,7 +507,7 @@ parameters: * `quobyteAPIServer`: API Server of Quobyte in the format `http(s)://api-server:7860` * `registry`: Quobyte registry to use to mount the volume. You can specify the registry as ``:`` pair or if you want to specify multiple registries you just have to put a comma between them e.q. ``:,:,:``. The host can be an IP address or if you have a working DNS you can also provide the DNS names. * `adminSecretNamespace`: The namespace for `adminSecretName`. Default is "default". -* `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate agains the API server. The provided secret must have type "kubernetes.io/quobyte", e.g. created in this way: +* `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate against the API server. The provided secret must have type "kubernetes.io/quobyte", e.g. created in this way: ``` $ kubectl create secret generic quobyte-admin-secret --type="kubernetes.io/quobyte" --from-literal=key='opensesame' --namespace=kube-system ``` From 4731f33d4887f500da3ab8811530d2695e090c22 Mon Sep 17 00:00:00 2001 From: Guangya Liu Date: Mon, 20 Feb 2017 21:29:07 +0800 Subject: [PATCH 172/213] Highlight some keyworks in garbage-collection.md. --- docs/admin/garbage-collection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index 9717a41dd8..8164fbb7d9 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -24,9 +24,9 @@ threshold has been met. ### Container Collection The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers any single -pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting 'MinAge' to zero and setting 'MaxPerPodContainer' and 'MaxContainers' respectively to less than zero. +pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero. -Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. 'MaxPerPodContainer' and 'MaxContainer' may potentially conflict with each other in situations where retaining the maximum number of containers per pod ('MaxPerPodContainer') would go outside the allowable range of global dead containers ('MaxContainers'). 'MaxPerPodContainer' would be adjusted in this situation: A worst case scenario would be to downgrade 'MaxPerPodContainer' to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. +Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`). `MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. Containers that are not managed by kubelet are not subject to container garbage collection. From 0b9dca5a36f81187fb8079cdb21211fab416259c Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Sat, 18 Feb 2017 15:14:37 +0800 Subject: [PATCH 173/213] replace argumment with argument replace argumment with argument --- docs/admin/network-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/network-plugins.md b/docs/admin/network-plugins.md index d5e05ac7b1..f06d22fb87 100644 --- a/docs/admin/network-plugins.md +++ b/docs/admin/network-plugins.md @@ -49,7 +49,7 @@ The plugin requires a few things: * The standard CNI `bridge`, `lo` and `host-local` plugins are required, at minimum version 0.2.0. Kubenet will first search for them in `/opt/cni/bin`. Specify `network-plugin-dir` to supply additional search path. The first found match will take effect. * Kubelet must be run with the `--network-plugin=kubenet` argument to enable the plugin -* Kubelet should also be run with the `--non-masquerade-cidr=` argumment to ensure traffic to IPs outside this range will use IP masquerade. +* Kubelet should also be run with the `--non-masquerade-cidr=` argument to ensure traffic to IPs outside this range will use IP masquerade. * The node must be assigned an IP subnet through either the `--pod-cidr` kubelet command-line option or the `--allocate-node-cidrs=true --cluster-cidr=` controller-manager command-line options. ### Customizing the MTU (with kubenet) From 142bf7dcc4293678d3f14b6e844d86bfa3720787 Mon Sep 17 00:00:00 2001 From: "Ricardo M. Augusto" Date: Tue, 21 Feb 2017 13:16:27 -0300 Subject: [PATCH 174/213] Updated result of command Actually according to the command in example: kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub The keys will be available with names ssh-publickey and ssh-privatekey. --- docs/user-guide/secrets/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/secrets/index.md b/docs/user-guide/secrets/index.md index 29e9044fde..8b7c7ae2fb 100644 --- a/docs/user-guide/secrets/index.md +++ b/docs/user-guide/secrets/index.md @@ -534,8 +534,8 @@ consumes it in a volume: When the container's command runs, the pieces of the key will be available in: ```shell -/etc/secret-volume/id-rsa.pub -/etc/secret-volume/id-rsa +/etc/secret-volume/ssh-publickey +/etc/secret-volume/ssh-privatekey ``` The container is then free to use the secret data to establish an ssh connection. From b89155a35103b93aaa755c4877e9edbb1c778f83 Mon Sep 17 00:00:00 2001 From: tanshanshan Date: Tue, 21 Feb 2017 16:08:27 +0800 Subject: [PATCH 175/213] replace petset with statefulsets --- docs/user-guide/kubectl-cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubectl-cheatsheet.md b/docs/user-guide/kubectl-cheatsheet.md index 6b67cba4a0..56f6d71de4 100644 --- a/docs/user-guide/kubectl-cheatsheet.md +++ b/docs/user-guide/kubectl-cheatsheet.md @@ -243,7 +243,7 @@ Resource type | Abbreviated alias `namespaces` |`ns` `networkpolicies` | `nodes` |`no` -`petset` | +`statefulsets` | `persistentvolumeclaims` |`pvc` `persistentvolumes` |`pv` `pods` |`po` From c5a79de79c19243e3b690f1ab7a49e486f8f5ddd Mon Sep 17 00:00:00 2001 From: Cao Shufeng Date: Mon, 20 Feb 2017 23:45:50 -0500 Subject: [PATCH 176/213] Remove details about where authenticator is implemented It not necessary to mention where the functions are implemented in document. Further more, the directories recorded here is out of date. Now they are in: staging/src/k8s.io/apiserver/plugin/pkg/authenticator/... --- docs/admin/authentication.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/admin/authentication.md b/docs/admin/authentication.md index 7c59c955ac..7a7d8f1bc3 100644 --- a/docs/admin/authentication.md +++ b/docs/admin/authentication.md @@ -85,9 +85,9 @@ See [APPENDIX](#appendix) for how to generate a client cert. The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line. Currently, tokens last indefinitely, and the token list cannot be changed without restarting API server. -The token file format is implemented in `plugin/pkg/auth/authenticator/token/tokenfile/...` -and is a csv file with a minimum of 3 columns: token, user name, user uid, followed by -optional group names. Note, if you have more than one group the column must be double quoted e.g. +The token file is a csv file with a minimum of 3 columns: token, user name, user uid, +followed by optional group names. Note, if you have more than one group the column must be +double quoted e.g. ```conf token,user,uid,"group1,group2,group3" @@ -115,9 +115,9 @@ and the password cannot be changed without restarting API server. Note that basi authentication is currently supported for convenience while we finish making the more secure modes described above easier to use. -The basic auth file format is implemented in `plugin/pkg/auth/authenticator/password/passwordfile/...` -and is a csv file with a minimum of 3 columns: password, user name, user id, followed by -optional group names. Note, if you have more than one group the column must be double quoted e.g. +The basic auth file is a csv file with a minimum of 3 columns: password, +user name, user id, followed by optional group names. Note, if you have more than +one group the column must be double quoted e.g. ```conf password,user,uid,"group1,group2,group3" From 82613412954fb14eb5384a912b003d8b0703c7eb Mon Sep 17 00:00:00 2001 From: Alexander Kanevskiy Date: Tue, 21 Feb 2017 20:41:52 +0200 Subject: [PATCH 177/213] Updated description for kubeadm init --kubernetes-version --- docs/admin/kubeadm.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index a43beec497..32bd70812f 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -143,10 +143,11 @@ By default, `kubeadm init` automatically generates the token used to initialise each new node. If you would like to manually specify this token, you can use the `--token` flag. The token must be of the format `<6 character string>.<16 character string>`. -- `--use-kubernetes-version` (default 'v1.5.1') the kubernetes version to initialise +- `--kubernetes-version` (default 'latest') the kubernetes version to initialise `kubeadm` was originally built for Kubernetes version **v1.4.0**, older versions are not -supported. With this flag you can try any future version, e.g. **v1.6.0-beta.1** +supported. The current version of `kubeadm` requires at least **v1.6.0-alpha.3** due to RBAC being enabled by default. +With this flag you can try any future version, e.g. **v1.6.0-beta.1** whenever it comes out (check [releases page](https://github.com/kubernetes/kubernetes/releases) for a full list of available versions). From a7192a9e9a7b5b3bebd746256bd1b8870fa627b8 Mon Sep 17 00:00:00 2001 From: Andrew Chen Date: Tue, 21 Feb 2017 12:35:15 -0800 Subject: [PATCH 178/213] Revert "Updated description for kubeadm init --kubernetes-version" --- docs/admin/kubeadm.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 32bd70812f..a43beec497 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -143,11 +143,10 @@ By default, `kubeadm init` automatically generates the token used to initialise each new node. If you would like to manually specify this token, you can use the `--token` flag. The token must be of the format `<6 character string>.<16 character string>`. -- `--kubernetes-version` (default 'latest') the kubernetes version to initialise +- `--use-kubernetes-version` (default 'v1.5.1') the kubernetes version to initialise `kubeadm` was originally built for Kubernetes version **v1.4.0**, older versions are not -supported. The current version of `kubeadm` requires at least **v1.6.0-alpha.3** due to RBAC being enabled by default. -With this flag you can try any future version, e.g. **v1.6.0-beta.1** +supported. With this flag you can try any future version, e.g. **v1.6.0-beta.1** whenever it comes out (check [releases page](https://github.com/kubernetes/kubernetes/releases) for a full list of available versions). From a512e93e9d1c7f71d47acf3f7098c0ee752b2271 Mon Sep 17 00:00:00 2001 From: divyenpatel Date: Fri, 17 Feb 2017 14:58:30 -0800 Subject: [PATCH 179/213] updated vsphere getting started guide addressed review comments addressed chenopis's review comments --- docs/getting-started-guides/vsphere.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/getting-started-guides/vsphere.md b/docs/getting-started-guides/vsphere.md index 61ea733bf3..a22d38609f 100644 --- a/docs/getting-started-guides/vsphere.md +++ b/docs/getting-started-guides/vsphere.md @@ -79,8 +79,7 @@ Sample Config: #### Known issues -* [Volumes are not removed from a VM configuration if the VM is down](https://github.com/kubernetes/kubernetes/issues/33061). The workaround is to manually remove the disk from VM settings before powering it up. -* [FS groups are not supported in 1.4.7](https://github.com/kubernetes/kubernetes/issues/34039) - This issue is fixed in 1.4.8 +* [Unable to execute command on pod container using kubectl exec](https://github.com/kubernetes/kubernetes-anywhere/issues/337) ### Kube-up (Deprecated) @@ -216,7 +215,7 @@ going on (find yourself authorized with your SSH key, or use the password IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu))([@luomiao](https://github.com/luomiao)) +Vmware vSphere | Kube-anywhere | Photon OS | Flannel | [docs](/docs/getting-started-guides/vsphere) | | Community ([@abrarshivani](https://github.com/abrarshivani)), ([@kerneltime](https://github.com/kerneltime)), ([@BaluDontu](https://github.com/BaluDontu)), ([@luomiao](https://github.com/luomiao)), ([@divyenpatel](https://github.com/divyenpatel)) For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions) chart. From b61c95f0723a34d3803bf0c31d6d07a336b5b848 Mon Sep 17 00:00:00 2001 From: "Elijah C. Voigt" Date: Fri, 17 Feb 2017 17:12:13 -0800 Subject: [PATCH 180/213] concepts/abstractions: init containers example. --- docs/concepts/abstractions/init-containers.md | 94 ++++++++++++++++++- 1 file changed, 93 insertions(+), 1 deletion(-) diff --git a/docs/concepts/abstractions/init-containers.md b/docs/concepts/abstractions/init-containers.md index 1bea00b3a2..89738eef56 100644 --- a/docs/concepts/abstractions/init-containers.md +++ b/docs/concepts/abstractions/init-containers.md @@ -95,6 +95,98 @@ Here are some ideas for how to use Init Containers: More detailed usage examples can be found in the [StatefulSets documentation](/docs/concepts/abstractions/controllers/statefulsets/) and the [Production Pods guide](/docs/user-guide/production-pods.md#handling-initialization). +### Init Containers in use + +The following yaml file outlines a simple Pod which has two Init Containers. +The first waits for `myservice` and the second waits for `mydb`. Once both +containers complete the Pod will begin. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp + annotations: + pod.beta.kubernetes.io/init-containers: '[ + { + "name": "init-myservice", + "image": "busybox", + "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] + }, + { + "name": "init-mydb", + "image": "busybox", + "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] + } + ]' +spec: + containers: + - name: myapp-container + image: busybox + command: ['sh', '-c', 'echo The app is running! && sleep 3600'] +``` + +This Pod can be started and debugged with the following commands: + +``` +$ kubectl create -f myapp.yaml +pod "myapp-pod" created +$ kubectl get -f myapp.yaml +NAME READY STATUS RESTARTS AGE +myapp-pod 0/1 Init:0/2 0 6m +$ kubectl describe -f myapp.yaml +i11:32 $ kubectl describe -f examples/init-container.yaml +Name: myapp-pod +Namespace: default +[...] +Labels: app=myapp +Status: Pending +[...] +Init Containers: + init-myservice: +[...] + State: Running +[...] + init-mydb: +[...] + State: Running +[...] +Containers: + myapp-container: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201 + 16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 +$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container +$ kubectl logs myapp-pod -c init-mydd # Inspect the second init container +``` + +Once we start the `mydb` and `myservice` Services we can see the Init Containers +complete and the `myapp-pod` is created: + +``` +$ kubectl create -f services.yaml +service "myservice" created +service "mydb" created +$ kubectl get -f myapp.yaml +NAME READY STATUS RESTARTS AGE +myapp-pod 1/1 Running 0 9m +``` + +This example is very simple but should provide some inspiration for you to +create your own Init Containers. + ## Detailed behavior During the startup of a Pod, the Init Containers are started in order, after the @@ -181,4 +273,4 @@ Kubelet and Apiserver versions; see the [release notes](https://github.com/kuber {% endcapture %} -{% include templates/concept.md %} \ No newline at end of file +{% include templates/concept.md %} From c295346b055f897cdaa797a6e0f09afa6b66b10f Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Tue, 21 Feb 2017 09:15:27 +0800 Subject: [PATCH 181/213] Update source-ip.md --- docs/tutorials/services/source-ip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md index e1eac87c4e..6366690e88 100644 --- a/docs/tutorials/services/source-ip.md +++ b/docs/tutorials/services/source-ip.md @@ -132,7 +132,7 @@ client_address=10.240.0.5 client_address=10.240.0.3 ``` -Note that these are not your IPs, they're cluster internal IPs. This is what happens: +Note that these are not right client IPs, they're cluster internal IPs. This is what happens: * Client sends packet to `node2:nodePort` * `node2` replaces the source IP address (SNAT) in the packet with its own IP address From 0a76c67c5b07fa9c4b070fd625c66fd97f165038 Mon Sep 17 00:00:00 2001 From: ztewyk <10110918@zte.com.cn> Date: Wed, 22 Feb 2017 08:40:09 +0800 Subject: [PATCH 182/213] Update source-ip.md --- docs/tutorials/services/source-ip.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tutorials/services/source-ip.md b/docs/tutorials/services/source-ip.md index 6366690e88..4f5f7d884a 100644 --- a/docs/tutorials/services/source-ip.md +++ b/docs/tutorials/services/source-ip.md @@ -132,7 +132,7 @@ client_address=10.240.0.5 client_address=10.240.0.3 ``` -Note that these are not right client IPs, they're cluster internal IPs. This is what happens: +Note that these are not the correct client IPs, they're cluster internal IPs. This is what happens: * Client sends packet to `node2:nodePort` * `node2` replaces the source IP address (SNAT) in the packet with its own IP address From 69cfd63deffb6cfb4a893765f37ea27460043b90 Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Tue, 21 Feb 2017 19:12:47 -0800 Subject: [PATCH 183/213] Move Guide topic: Garbage Collection. (#2488) --- _data/concepts.yml | 1 + .../controllers/garbage-collection.md | 110 ++++++++++++++++++ .../abstractions/controllers/my-repset.yaml | 17 +++ docs/user-guide/garbage-collection.md | 33 +----- 4 files changed, 130 insertions(+), 31 deletions(-) create mode 100644 docs/concepts/abstractions/controllers/garbage-collection.md create mode 100644 docs/concepts/abstractions/controllers/my-repset.yaml diff --git a/_data/concepts.yml b/_data/concepts.yml index 432f4c86e1..56a556a801 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -20,6 +20,7 @@ toc: - title: Controllers section: - docs/concepts/abstractions/controllers/statefulsets.md + - docs/concepts/abstractions/controllers/garbage-collection.md - title: Object Metadata section: diff --git a/docs/concepts/abstractions/controllers/garbage-collection.md b/docs/concepts/abstractions/controllers/garbage-collection.md new file mode 100644 index 0000000000..889049c1ba --- /dev/null +++ b/docs/concepts/abstractions/controllers/garbage-collection.md @@ -0,0 +1,110 @@ +--- +title: Garbage Collection +--- + +{% capture overview %} + +The role of the Kubernetes garbage collector is to delete certain objects +that once had an owner, but no longer have an owner. + +**Note**: Garbage collection is a beta feature and is enabled by default in +Kubernetes version 1.4 and later. + +{% endcapture %} + + +{% capture body %} + +## Owners and dependents + +Some Kubernetes objects are owners of other objects. For example, a ReplicaSet +is the owner of a set of Pods. The owned objects are called *dependents* of the +owner object. Every dependent object has a `metadata.ownerReferences` field that +points to the owning object. + +Sometimes, Kubernetes sets the value of `ownerReference` automatically. For +example, when you create a ReplicaSet, Kubernetes automatically sets the +`ownerReference` field of each Pod in the ReplicaSet. You can also specify +relationships between owners and dependents by manually setting the +`ownerReference` field. + +Here's a configuration file for a ReplicaSet that has three Pods: + +{% include code.html language="yaml" file="my-repset.yaml" ghlink="/docs/concepts/abstractions/controllers/my-repset.yaml" %} + +If you create the ReplicaSet and then view the Pod metadata, you can see +OwnerReferences field: + +```shell +kubectl create -f http://k8s.io/docs/concepts/abstractions/controllers/my-repset.yaml +kubectl get pods --output=yaml +``` + +The output shows that the Pod owner is a ReplicaSet named my-repset: + +```shell +apiVersion: v1 +kind: Pod +metadata: + ... + ownerReferences: + - apiVersion: extensions/v1beta1 + controller: true + kind: ReplicaSet + name: my-repset + uid: d9607e19-f88f-11e6-a518-42010a800195 + ... +``` + +## Controlling whether the garbage collector deletes dependents + +When you delete object, you can specify whether the object's dependents +are deleted automatically. Deleting dependents automatically is called +*cascading deletion*. If you delete an object without deleting its +dependents automatically, the dependents are said to be *orphaned*. + +To delete dependent objects automatically, set the `orphanDependents` query +parameter to false in your request to delete the owner object. + +To orphan the dependents of an owner object, set the `orphanDependents` query +parameter to true in your request to delete the owner object. + +The default value for `orphanDependents` is true. So unless you specify +otherwise, dependent objects are orphaned. + +Here's an example that deletes dependents automatically: + +```shell +kubectl proxy --port=8080 +curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset?orphanDependents=false +``` + +To delete dependents automatically using kubectl, set `--cascade` to true. +To orphan dependents, set `--cascade` to false. The default value for +`--cascade` is true. + +Here's an example that orphans the dependents of a ReplicaSet: + +```shell +kubectl delete replicaset my-repset --cascade=false +``` + +## Ongoing development + +In Kubernetes version 1.5, synchronous garbage collection is under active +development. See the tracking +[issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details. + +{% endcapture %} + + +{% capture whatsnext %} + +[Design Doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/garbage-collection.md) + +[Known issues](https://github.com/kubernetes/kubernetes/issues/26120) + +{% endcapture %} + + +{% include templates/concept.md %} diff --git a/docs/concepts/abstractions/controllers/my-repset.yaml b/docs/concepts/abstractions/controllers/my-repset.yaml new file mode 100644 index 0000000000..54befd8f9d --- /dev/null +++ b/docs/concepts/abstractions/controllers/my-repset.yaml @@ -0,0 +1,17 @@ +apiVersion: extensions/v1beta1 +kind: ReplicaSet +metadata: + name: my-repset +spec: + replicas: 3 + selector: + matchLabels: + pod-is-for: garbage-collection-example + template: + metadata: + labels: + pod-is-for: garbage-collection-example + spec: + containers: + - name: nginx + image: nginx diff --git a/docs/user-guide/garbage-collection.md b/docs/user-guide/garbage-collection.md index af90b4dd1a..16f9380866 100644 --- a/docs/user-guide/garbage-collection.md +++ b/docs/user-guide/garbage-collection.md @@ -4,35 +4,6 @@ assignees: title: Garbage Collection (Beta) --- -* TOC -{:toc} +{% include user-guide-content-moved.md %} -## Garbage Collection - -Note: the Garbage Collection is a beta feature and is enabled by default in Kubernetes version 1.4. - -### What does Garbage Collector do - -When you delete, for example, a ReplicaSet, it is often desirable for the server to automatically garbage collect all the Pods that the ReplicaSet creates. The Garbage Collector (GC) implements this. In general, when you delete an owner object, GC deletes that owner's dependent objects. - -### How to establish an owner-dependent relationship between objects - -Kubernetes 1.3 added a metadata.ownerReferences field to every Kubernetes API object. If an API object is a dependent of another object, ownerReference should point to the owning API object. - -When you create a ReplicationController or a ReplicaSet in Kubernetes 1.4, the Kubernetes control plane automatically sets the ownerReference field in each created pod to point to the owning ReplicationController or ReplicaSet. - -You can set up owner-dependent relationships among other objects by manually setting the ownerReference field on dependent objects. - -### Controlling whether Garbage Collector deletes dependents - -When deleting an object, you can request the GC to ***asynchronously*** delete its dependents by ***explicitly*** specifying `deleteOptions.orphanDependents=false` in the deletion request that you send to the API server. A 200 OK response from the API server indicates the owner is deleted. - -In Kubernetes version 1.5, synchronous garbage collection is under active development. See the tracking [issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details. - -If you specify `deleteOptions.orphanDependents=true`, or leave it blank, then the GC will first reset the `ownerReferences` in the dependents, then delete the owner. Note that the deletion of the owner object is asynchronous, that is, a 200 OK response will be sent by the API server before the owner object gets deleted. - -### Other references - -[Design Doc](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/garbage-collection.md) - -[Known issues](https://github.com/kubernetes/kubernetes/issues/26120) +[Garbage Collection](/docs/concepts/abstractions/controllers/garbage-collection/) From 8f6de25c987a4a3e09e9e0c00d723f5e47c7dff5 Mon Sep 17 00:00:00 2001 From: Jared Date: Wed, 22 Feb 2017 10:54:28 -0800 Subject: [PATCH 184/213] Update review-issues.md --- docs/contribute/review-issues.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/contribute/review-issues.md b/docs/contribute/review-issues.md index f5430d0b11..1353620e81 100644 --- a/docs/contribute/review-issues.md +++ b/docs/contribute/review-issues.md @@ -12,6 +12,8 @@ This page explains how documentation issues are reviewed and prioritized for the ## Categorizing issues Issues should be sorted into different buckets of work using the following labels and definitions. If an issue doesn't have enough information to identify a problem that can be researched, reviewed, or worked on (i.e. the issue doesn't fit into any of the categories below) you should close the issue with a comment explaining why it is being closed. +### Needs Clarification +* Issues that need more information from the original submitter to make them actionable. Issues with this label that aren't followed up within a week may be closed. ### Actionable * Issues that can be worked on with current information (or may need a comment to explain what needs to be done to make it more clear) @@ -26,8 +28,9 @@ Issues should be sorted into different buckets of work using the following label * Issues that are suggestions for better processes or site improvements that require community agreement to be implemented * Topics can be brought to SIG meetings as agenda items -#### Needs UX Review -* Issues that are suggestions for improving the user interface of the site or fixing a broken UX. +### Needs UX Review +* Issues that are suggestions for improving the user interface of the site. +* Fixing broken site elements. ## Prioritizing Issues From f5e5175247234df0a3414d77d09af80ed84b4043 Mon Sep 17 00:00:00 2001 From: Guangya Liu Date: Wed, 22 Feb 2017 10:11:42 +0800 Subject: [PATCH 185/213] Fixed flag for eviction-soft. --- docs/admin/garbage-collection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/garbage-collection.md b/docs/admin/garbage-collection.md index 8164fbb7d9..ad55b773a5 100644 --- a/docs/admin/garbage-collection.md +++ b/docs/admin/garbage-collection.md @@ -64,7 +64,7 @@ Including: | Existing Flag | New Flag | Rationale | | ------------- | -------- | --------- | -| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` | existing eviction signals can trigger image garbage collection | +| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | | `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | | `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | | `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | From fd3b6e66d888e93be53b330077bc7d49c8ae5c59 Mon Sep 17 00:00:00 2001 From: Xiuyu Li Date: Tue, 21 Feb 2017 16:18:52 +0800 Subject: [PATCH 186/213] show kubectl_rollingupdate svg --- docs/user-guide/kubectl/kubectl_rolling-update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/kubectl/kubectl_rolling-update.md b/docs/user-guide/kubectl/kubectl_rolling-update.md index 382e630c78..f20483e125 100644 --- a/docs/user-guide/kubectl/kubectl_rolling-update.md +++ b/docs/user-guide/kubectl/kubectl_rolling-update.md @@ -13,7 +13,7 @@ Perform a rolling update of the given ReplicationController. Replaces the specified replication controller with a new replication controller by updating one pod at a time to use the new PodTemplate. The new-controller.json must specify the same namespace as the existing replication controller and overwrite at least one (common) label in its replicaSelector. -! http://kubernetes.io/images/docs/kubectl_rollingupdate.svg +![kubectl_rollingupdate](http://kubernetes.io/images/docs/kubectl_rollingupdate.svg) ``` kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) From da2ebff41729fb9e979c7f48071b821df58bcad8 Mon Sep 17 00:00:00 2001 From: Andres Villarroel Date: Tue, 7 Feb 2017 09:30:13 -0800 Subject: [PATCH 187/213] Update hello-minikube.md - Proposing a different way to run curl without proxy, without touching current environment - There's a formatting problem and the whole thing is being displayed in a single line ![screenshot](http://imgur.com/download/nfk02hd) --- docs/tutorials/stateless-application/hello-minikube.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/tutorials/stateless-application/hello-minikube.md b/docs/tutorials/stateless-application/hello-minikube.md index 6f2a47b897..70fed7db16 100644 --- a/docs/tutorials/stateless-application/hello-minikube.md +++ b/docs/tutorials/stateless-application/hello-minikube.md @@ -74,10 +74,9 @@ chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl ``` Determine whether you can access sites like [https://cloud.google.com/container-registry/](https://cloud.google.com/container-registry/) directly without a proxy, by opening a new terminal and using + ```shell -export http_proxy="" -export https_proxy="" -curl https://cloud.google.com/container-registry/ +curl --proxy "" https://cloud.google.com/container-registry/ ``` If NO proxy is required, start the Minikube cluster: From 47ae58f3c476bb92cf3095bf7011e54cbf7b8fa8 Mon Sep 17 00:00:00 2001 From: tailnode Date: Thu, 23 Feb 2017 16:08:38 +0800 Subject: [PATCH 188/213] fix some wrong links --- _includes/v1.5/extensions-v1beta1-definitions.html | 2 +- _includes/v1.5/v1-definitions.html | 2 +- docs/api-reference/apps/v1beta1/definitions.html | 2 +- docs/api-reference/batch/v1/definitions.html | 2 +- docs/api-reference/extensions/v1beta1/definitions.html | 2 +- docs/api-reference/v1.5/index.html | 2 +- .../api-reference/extensions/v1beta1/definitions.html | 2 +- docs/resources-reference/v1.5/index.html | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/_includes/v1.5/extensions-v1beta1-definitions.html b/_includes/v1.5/extensions-v1beta1-definitions.html index bd86db7daa..f210a6350b 100755 --- a/_includes/v1.5/extensions-v1beta1-definitions.html +++ b/_includes/v1.5/extensions-v1beta1-definitions.html @@ -3453,7 +3453,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i
- + diff --git a/_includes/v1.5/v1-definitions.html b/_includes/v1.5/v1-definitions.html index 16858392bc..b42f1ad675 100755 --- a/_includes/v1.5/v1-definitions.html +++ b/_includes/v1.5/v1-definitions.html @@ -4172,7 +4172,7 @@ The resulting set of endpoints can be viewed as:
- + diff --git a/docs/api-reference/apps/v1beta1/definitions.html b/docs/api-reference/apps/v1beta1/definitions.html index 77ef25e10c..c62a8bf681 100755 --- a/docs/api-reference/apps/v1beta1/definitions.html +++ b/docs/api-reference/apps/v1beta1/definitions.html @@ -3620,7 +3620,7 @@ The StatefulSet guarantees that a given network identity will always map to the - + diff --git a/docs/api-reference/batch/v1/definitions.html b/docs/api-reference/batch/v1/definitions.html index 9989f4c4ca..0a17bce0a7 100755 --- a/docs/api-reference/batch/v1/definitions.html +++ b/docs/api-reference/batch/v1/definitions.html @@ -3609,7 +3609,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i - + diff --git a/docs/api-reference/extensions/v1beta1/definitions.html b/docs/api-reference/extensions/v1beta1/definitions.html index 3f1129b1b6..47dc1d4f76 100755 --- a/docs/api-reference/extensions/v1beta1/definitions.html +++ b/docs/api-reference/extensions/v1beta1/definitions.html @@ -3457,7 +3457,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i - + diff --git a/docs/api-reference/v1.5/index.html b/docs/api-reference/v1.5/index.html index 84caadbe95..ae50987334 100644 --- a/docs/api-reference/v1.5/index.html +++ b/docs/api-reference/v1.5/index.html @@ -8010,7 +8010,7 @@ Appears In PodPodTemplateSp - + diff --git a/docs/federation/api-reference/extensions/v1beta1/definitions.html b/docs/federation/api-reference/extensions/v1beta1/definitions.html index 897ab5aca8..28b2883fc2 100755 --- a/docs/federation/api-reference/extensions/v1beta1/definitions.html +++ b/docs/federation/api-reference/extensions/v1beta1/definitions.html @@ -3073,7 +3073,7 @@ Populated by the system when a graceful deletion is requested. Read-only. More i - + diff --git a/docs/resources-reference/v1.5/index.html b/docs/resources-reference/v1.5/index.html index c3902110de..8b5c05ec19 100644 --- a/docs/resources-reference/v1.5/index.html +++ b/docs/resources-reference/v1.5/index.html @@ -1062,7 +1062,7 @@ Appears In PodPodTemplateSp - + From 741292ddb65669805c684f436d11eac53f30e699 Mon Sep 17 00:00:00 2001 From: roopakparikh Date: Wed, 22 Feb 2017 11:06:01 -0800 Subject: [PATCH 189/213] Added KUBE2GO.io Adding a new Free service KUBE2GO.io that provides quick creation of K8s clusters on AWS and other public clouds. --- docs/getting-started-guides/index.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/getting-started-guides/index.md b/docs/getting-started-guides/index.md index 9ee9e01301..c58c6cf297 100644 --- a/docs/getting-started-guides/index.md +++ b/docs/getting-started-guides/index.md @@ -46,6 +46,7 @@ clusters. [AppsCode.com](https://appscode.com/products/cloud-deployment/) provides managed Kubernetes clusters for various public clouds (including AWS and Google Cloud Platform). [KCluster.io](https://kcluster.io) provides highly available and scalable managed Kubernetes clusters for AWS. +[KUBE2GO.io] (https://kube2go.io) get started with highly available Kubernetes clusters on multiple public clouds along with useful tools for development, debugging, monitoring. [Platform9](https://platform9.com/products/kubernetes/) offers managed Kubernetes on-premises or any public cloud, and provides 24/7 health monitoring and alerting. @@ -62,6 +63,7 @@ few commands, and have active community support. - [CenturyLink Cloud](/docs/getting-started-guides/clc) - [IBM SoftLayer](https://github.com/patrocinio/kubernetes-softlayer) - [Stackpoint.io](/docs/getting-started-guides/stackpoint/) +- [KUBE2GO.io](https://kube2go.io/) ### Custom Solutions @@ -131,6 +133,7 @@ GKE | | | GCE | [docs](https://clou Stackpoint.io | | multi-support | multi-support | [docs](http://www.stackpointcloud.com) | Commercial AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial KCluster.io | | multi-support | multi-support | [docs](https://kcluster.io) | Commercial +KUBE2GO.io | | multi-support | multi-support | [docs](https://kube2go.io) | Commercial Platform9 | | multi-support | multi-support | [docs](https://platform9.com/products/kubernetes/) | Commercial GCE | Saltstack | Debian | GCE | [docs](/docs/getting-started-guides/gce) | Project Azure Container Service | | Ubuntu | Azure | [docs](https://azure.microsoft.com/en-us/services/container-service/) | Commercial From fb7a756a77840e26012a0463c419168ad71b8a56 Mon Sep 17 00:00:00 2001 From: roopakparikh Date: Thu, 23 Feb 2017 14:16:47 -0800 Subject: [PATCH 190/213] Removed Extra space in the KUBE2GO commit Last pull request had an extra space and was missing a newline between the last provider and KUBE2GO --- docs/getting-started-guides/index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/getting-started-guides/index.md b/docs/getting-started-guides/index.md index c58c6cf297..4ed17d4f47 100644 --- a/docs/getting-started-guides/index.md +++ b/docs/getting-started-guides/index.md @@ -46,7 +46,8 @@ clusters. [AppsCode.com](https://appscode.com/products/cloud-deployment/) provides managed Kubernetes clusters for various public clouds (including AWS and Google Cloud Platform). [KCluster.io](https://kcluster.io) provides highly available and scalable managed Kubernetes clusters for AWS. -[KUBE2GO.io] (https://kube2go.io) get started with highly available Kubernetes clusters on multiple public clouds along with useful tools for development, debugging, monitoring. + +[KUBE2GO.io](https://kube2go.io) get started with highly available Kubernetes clusters on multiple public clouds along with useful tools for development, debugging, monitoring. [Platform9](https://platform9.com/products/kubernetes/) offers managed Kubernetes on-premises or any public cloud, and provides 24/7 health monitoring and alerting. From 58867752f51235621c55a6bd0b43167767f5df9d Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Sat, 18 Feb 2017 10:46:57 +0800 Subject: [PATCH 191/213] Delete the parameter "--google-json-key string" Delete the parameter "--google-json-key string" --- docs/admin/kube-proxy.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/admin/kube-proxy.md b/docs/admin/kube-proxy.md index ea13d528e3..bf72aee787 100644 --- a/docs/admin/kube-proxy.md +++ b/docs/admin/kube-proxy.md @@ -41,7 +41,6 @@ DynamicKubeletConfig=true|false (ALPHA - default=false) DynamicVolumeProvisioning=true|false (ALPHA - default=true) ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false) StreamingProxyRedirects=true|false (ALPHA - default=false) - --google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication. --healthz-bind-address ip The IP address for the health check server to serve on, defaulting to 127.0.0.1 (set to 0.0.0.0 for all interfaces) (default 127.0.0.1) --healthz-port int32 The port to bind the health check server. Use 0 to disable. (default 10249) --hostname-override string If non-empty, will use this string as identification instead of the actual hostname. From fc9b83e95d0a02f8239452f5559a9638ad79d286 Mon Sep 17 00:00:00 2001 From: Jeff Mendoza Date: Fri, 24 Feb 2017 14:36:12 -0800 Subject: [PATCH 192/213] Fix apimachinery vendored dependencies in examples_test. --- .travis.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.travis.yml b/.travis.yml index b0a565803c..691d897659 100644 --- a/.travis.yml +++ b/.travis.yml @@ -26,6 +26,8 @@ install: - cp -r $GOPATH/src/k8s.io/kubernetes/vendor/* $GOPATH/src/ - rm -rf $GOPATH/src/k8s.io/kubernetes/vendor/* - cp -r $GOPATH/src/k8s.io/kubernetes/staging/src/* $GOPATH/src/ +- cp -r $GOPATH/src/k8s.io/apimachinery/vendor/* $GOPATH/src/ +- rm -rf $GOPATH/src/k8s.io/apimachinery/vendor/* # (2) Fetch md-check along with all its dependencies. - git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check From 180a9b6abc026b3072b0e982764f8c5c77a7fcaa Mon Sep 17 00:00:00 2001 From: huzhifeng Date: Fri, 24 Feb 2017 09:40:33 +0800 Subject: [PATCH 193/213] package apt-transport-https should be installed Ubuntu default install not include apt-transport-https. so if you want to download package from https repo, you need install apt-transport-https package first --- docs/getting-started-guides/kubeadm.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index 5fc815ea9c..b5a9845b44 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -69,6 +69,7 @@ For each host in turn: * SSH into the machine and become `root` if you are not already (for example, run `sudo su -`). * If the machine is running Ubuntu or HypriotOS, run: + apt-get update && apt-get install -y apt-transport-https curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - cat < /etc/apt/sources.list.d/kubernetes.list deb http://apt.kubernetes.io/ kubernetes-xenial main From eeb1367c64bd245ba81fe4138927b9715cccd6dd Mon Sep 17 00:00:00 2001 From: jianglingxia Date: Sat, 18 Feb 2017 12:53:35 +0800 Subject: [PATCH 194/213] doc-walkthrough-content modify --- docs/admin/namespaces/walkthrough.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/namespaces/walkthrough.md b/docs/admin/namespaces/walkthrough.md index 7576d2c2e0..e3aa0c7bfc 100644 --- a/docs/admin/namespaces/walkthrough.md +++ b/docs/admin/namespaces/walkthrough.md @@ -145,7 +145,7 @@ dev At this point, all requests we make to the Kubernetes cluster from the command line are scoped to the development namespace. -Let's create some content. +Let's create some contents. ```shell $ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2 From 474ae68f2508b0db2aea8ecdce89428ad6fdbf40 Mon Sep 17 00:00:00 2001 From: jianglingxia Date: Fri, 24 Feb 2017 14:31:58 +0800 Subject: [PATCH 195/213] limitrange-update I think it's redundant that the second to ,in order to do sth and do sth!thanks! --- docs/admin/limitrange/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/limitrange/index.md b/docs/admin/limitrange/index.md index 82bed781f1..1791f14f4d 100644 --- a/docs/admin/limitrange/index.md +++ b/docs/admin/limitrange/index.md @@ -24,7 +24,7 @@ each namespace. 3. Users may create a pod which consumes resources just below the capacity of a machine. The left over space may be too small to be useful, but big enough for the waste to be costly over the entire cluster. As a result, the cluster operator may want to set limits that a pod must consume at least 20% of the memory and CPU of their -average node size in order to provide for more uniform scheduling and to limit waste. +average node size in order to provide for more uniform scheduling and limit waste. This example demonstrates how limits can be applied to a Kubernetes [namespace](/docs/admin/namespaces/walkthrough/) to control min/max resource limits per pod. In addition, this example demonstrates how you can From 4508f114f954dab50f76894ffc6bcb5ebb501b7b Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Fri, 24 Feb 2017 14:38:27 +0800 Subject: [PATCH 196/213] fix command kubectl get svc,pod output fix command kubectl get svc,pod output --- .../network-policy/walkthrough.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/getting-started-guides/network-policy/walkthrough.md b/docs/getting-started-guides/network-policy/walkthrough.md index 21a74278c5..041c4e99f8 100644 --- a/docs/getting-started-guides/network-policy/walkthrough.md +++ b/docs/getting-started-guides/network-policy/walkthrough.md @@ -31,12 +31,13 @@ This will run two nginx Pods in the default Namespace, and expose them through a ```console $ kubectl get svc,pod -NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE -kubernetes 10.100.0.1 443/TCP 46m -nginx 10.100.0.16 80/TCP 33s -NAME READY STATUS RESTARTS AGE -nginx-701339712-e0qfq 1/1 Running 0 35s -nginx-701339712-o00ef 1/1 Running 0 35s +NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE +svc/kubernetes 10.100.0.1 443/TCP 46m +svc/nginx 10.100.0.16 80/TCP 33s + +NAME READY STATUS RESTARTS AGE +po/nginx-701339712-e0qfq 1/1 Running 0 35s +po/nginx-701339712-o00ef 1/1 Running 0 35s ``` We should be able to access our new nginx Service from other Pods. Let's try to access it from another Pod From 30023fb5b5d4a0f48cb3c86049a883833fff3ba6 Mon Sep 17 00:00:00 2001 From: Patrick Decat Date: Fri, 24 Feb 2017 16:14:16 +0100 Subject: [PATCH 197/213] Fix typo: federation-controller-mananger => federation-controller-manager --- _data/guides.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_data/guides.yml b/_data/guides.yml index 98ef2db801..30ee93078c 100644 --- a/_data/guides.yml +++ b/_data/guides.yml @@ -228,5 +228,5 @@ toc: - title: Federation Components section: - docs/admin/federation-apiserver.md - - title : federation-controller-mananger + - title : federation-controller-manager path: /docs/admin/federation-controller-manager From ae56b5bf072706f7df3e6e3b333b8d4078c0725b Mon Sep 17 00:00:00 2001 From: Patrick Decat Date: Fri, 24 Feb 2017 16:15:24 +0100 Subject: [PATCH 198/213] Fix typo: federation-controller-mananger => federation-controller-manager --- docs/admin/federation-controller-manager.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/federation-controller-manager.md b/docs/admin/federation-controller-manager.md index d3dca5bf06..caa001e4c8 100644 --- a/docs/admin/federation-controller-manager.md +++ b/docs/admin/federation-controller-manager.md @@ -1,5 +1,5 @@ --- -title: federation-controller-mananger +title: federation-controller-manager notitle: true --- From 6d133c64d5d27b18e09516a54a46b96359d6982c Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Fri, 24 Feb 2017 11:18:24 -0500 Subject: [PATCH 199/213] Clarify minimum version of kubernetes supporting PSP authz --- docs/user-guide/pod-security-policy/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/pod-security-policy/index.md b/docs/user-guide/pod-security-policy/index.md index da1c6514d6..d3b40902ea 100644 --- a/docs/user-guide/pod-security-policy/index.md +++ b/docs/user-guide/pod-security-policy/index.md @@ -163,5 +163,5 @@ following ## Working With RBAC -Use PodSecurityPolicy to control access to privileged containers based on role and groups. +In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to privileged containers based on user role and groups. (see [more details](https://github.com/kubernetes/kubernetes/blob/master/examples/podsecuritypolicy/rbac/README.md)). From 29b3f2b99a720bf209c4795f3a3d6623da43e10a Mon Sep 17 00:00:00 2001 From: Stephen Gordon Date: Sat, 25 Feb 2017 16:12:07 -0500 Subject: [PATCH 200/213] Provide correct location for KUBE_ETCD_SERVERS Provide correct location for KUBE_ETCD_SERVERS configuration key. It was previously listed as being in /etc/kubernetes/config but is actually in /etc/kubernetes/apiserver. Related: https://github.com/kubernetes/kubernetes.github.io/issues/1600 --- docs/getting-started-guides/centos/centos_manual_config.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/getting-started-guides/centos/centos_manual_config.md b/docs/getting-started-guides/centos/centos_manual_config.md index 031a5bb3f5..b64af60475 100644 --- a/docs/getting-started-guides/centos/centos_manual_config.md +++ b/docs/getting-started-guides/centos/centos_manual_config.md @@ -61,9 +61,6 @@ echo "192.168.121.9 centos-master * Edit /etc/kubernetes/config which will be the same on all hosts to contain: ```shell -# Comma separated list of nodes in the etcd cluster -KUBE_ETCD_SERVERS="--etcd-servers=http://centos-master:2379" - # logging to stderr means we get it in the systemd journal KUBE_LOGTOSTDERR="--logtostderr=true" @@ -111,6 +108,9 @@ KUBE_API_PORT="--port=8080" # Port kubelets listen on KUBELET_PORT="--kubelet-port=10250" +# Comma separated list of nodes in the etcd cluster +KUBE_ETCD_SERVERS="--etcd-servers=http://centos-master:2379" + # Address range to use for services KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16" From 650d632519d1e03cf113825448fd4f2f09a9c0ad Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Mon, 27 Feb 2017 14:16:14 -0800 Subject: [PATCH 201/213] Move Compute Resources topic to Concepts. (#2410) --- _data/concepts.yml | 1 + .../manage-compute-resources-container.md | 430 ++++++++++++++++++ docs/user-guide/compute-resources.md | 366 +-------------- 3 files changed, 433 insertions(+), 364 deletions(-) create mode 100644 docs/concepts/configuration/manage-compute-resources-container.md diff --git a/_data/concepts.yml b/_data/concepts.yml index 56a556a801..bd187c6cee 100644 --- a/_data/concepts.yml +++ b/_data/concepts.yml @@ -35,6 +35,7 @@ toc: - title: Configuration section: - docs/concepts/configuration/container-command-args.md + - docs/concepts/configuration/manage-compute-resources-container.md - title: Policies section: diff --git a/docs/concepts/configuration/manage-compute-resources-container.md b/docs/concepts/configuration/manage-compute-resources-container.md new file mode 100644 index 0000000000..2754260d65 --- /dev/null +++ b/docs/concepts/configuration/manage-compute-resources-container.md @@ -0,0 +1,430 @@ +--- +title: Managing Compute Resources for Containers +--- + +{% capture overview %} + +When you specify a [Pod](/docs/user-guide/pods), you can optionally specify how +much CPU and memory (RAM) each Container needs. When Containers have resource +requests specified, the scheduler can make better decisions about which nodes to +place Pods on. And when Containers have their limits specified, contention for +resources on a node can be handled in a specified manner. For more details about +the difference between requests and limits, see +[Resource QoS](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-qos.md). + +{% endcapture %} + + +{% capture body %} + +## Resource types + +*CPU* and *memory* are each a *resource type*. A resource type has a base unit. +CPU is specified in units of cores, and memory is specified in units of bytes. + +CPU and memory are collectively referred to as *compute resources*, or just +*resources*. Compute +resources are measurable quantities that can be requested, allocated, and +consumed. They are distinct from +[API resources](/docs/api/). API resources, such as Pods and +[Services](/docs/user-guide/services) are objects that can be read and modified +through the Kubernetes API server. + +## Resource requests and limits of Pod and Container + +Each Container of a Pod can specify one or more of the following: + +* `spec.containers[].resources.limits.cpu` +* `spec.containers[].resources.limits.memory` +* `spec.containers[].resources.requests.cpu` +* `spec.containers[].resources.requests.memory` + +Although requests and limits can only be specified on individual Containers, it +is convenient to talk about Pod resource requests and limits. A +*Pod resource request/limit* for a particular resource type is the sum of the +resource requests/limits of that type for each Container in the Pod. + +## Meaning of CPU + +Limits and requests for CPU resources are measured in *cpu* units. +One cpu, in Kubernetes, is equivalent to: + +- 1 AWS vCPU +- 1 GCP Core +- 1 Azure vCore +- 1 *Hyperthread* on a bare-metal Intel processor with Hyperthreading + +Fractional requests are allowed. A Container with +`spec.containers[].resources.requests.cpu` of `0.5` is guaranteed half as much +CPU as one that asks for 1 CPU. The expression `0.1` is equivalent to the +expression `100m`, which can be read as "one hundred millicpu". Some people say +"one hundred millicores", and this is understood to mean the same thing. A +request with a decimal point, like `0.1`, is converted to `100m` by the API, and +precision finer than `1m` is not allowed. For this reason, the form `100m` might +be preferred. + +CPU is always requested as an absolute quantity, never as a relative quantity; +0.1 is the same amount of CPU on a single-core, dual-core, or 48-core machine. + +## Meaning of memory + +Limits and requests for `memory` are measured in bytes. You can express memory as +a plain integer or as a fixed-point integer using one of these SI suffixes: +E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +Mi, Ki. For example, the following represent roughly the same value: + +```shell +128974848, 129e6, 129M, 123Mi +``` + +Here's an example. +The following Pod has two Containers. Each Container has a request of 0.25 cpu +and 64MiB (226 bytes) of memory Each Container has a limit of 0.5 +cpu and 128MiB of memory. You can say the Pod has a request of 0.5 cpu and 128 +MiB of memory, and a limit of 1 core and 256MiB of memory. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: wp + image: wordpress + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + +## How Pods with resource requests are scheduled + +When you create a Pod, the Kubernetes scheduler selects a node for the Pod to +run on. Each node has a maximum capacity for each of the resource types: the +amount of CPU and memory it can provide for Pods. The scheduler ensures that, +for each resource type, the sum of the resource requests of the scheduled +Containers is less than the capacity of the node. Note that although actual memory +or CPU resource usage on nodes is very low, the scheduler still refuses to place +a Pod on a node if the capacity check fails. This protects against a resource +shortage on a node when resource usage later increases, for example, during a +daily peak in request rate. + +## How Pods with resource limits are run + +When the kubelet starts a Container of a Pod, it passes the CPU and memory limits +to the container runtime. + +When using Docker: + +- The `spec.containers[].resources.requests.cpu` is converted to its core value, + which is potentially fractional, and multiplied by 1024. This number is used + as the value of the + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) + flag in the `docker run` command. + +- The `spec.containers[].resources.limits.cpu` is converted to its millicore value, + multiplied by 100000, and then divided by 1000. This number is used as the value + of the [`--cpu-quota`](https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint) + flag in the `docker run` command. he [`--cpu-period`] flag is set to 100000, + which represents the default 100ms period for measuring quota usage. The + kubelet enforces cpu limits if it is started with the + [`--cpu-cfs-quota`] flag set to true. As of Kubernetes version 1.2, this flag + defaults to true. + +- The `spec.containers[].resources.limits.memory` is converted to an integer, and + used as the value of the + [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + flag in the `docker run` command. + +If a Container exceeds its memory limit, it might be terminated. If it is +restartable, the kubelet will restart it, as with any other type of runtime +failure. + +If a Container exceeds its memory request, it is likely that its Pod will +be evicted whenever the node runs out of memory. + +A Container might or might not be allowed to exceed its CPU limit for extended +periods of time. However, it will not be killed for excessive CPU usage. + +To determine whether a Container cannot be scheduled or is being killed due to +resource limits, see the +[Troubleshooting](#troubleshooting) section. + +## Monitoring compute resource usage + +The resource usage of a Pod is reported as part of the Pod status. + +If [optional monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) +is configured for your cluster, then Pod resource usage can be retrieved from +the monitoring system. + +## Troubleshooting + +### My Pods are pending with event message failedScheduling + +If the scheduler cannot find any node where a Pod can fit, the Pod remains +unscheduled until a place can be found. An event is produced each time the +scheduler fails to find a place for the Pod, like this: + +```shell +$ kubectl describe pod frontend | grep -A 3 Events +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + +In the preceding example, the Pod named "frontend" fails to be scheduled due to +insufficient CPU resource on the node. Similar error messages can also suggest +failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod +is pending with a message of this type, there are several things to try: + +- Add more nodes to the cluster. +- Terminate unneeded Pods to make room for pending Pods. +- Check that the Pod is not larger than all the nodes. For example, if all the + nodes have a capacity of `cpu: 1`, then a Pod with a limit of `cpu: 1.1` will + never be scheduled. + +You can check node capacities and amounts allocated with the +`kubectl describe nodes` command. For example: + +```shell +$ kubectl.sh describe nodes e2e-test-minion-group-4lw4 +Name: e2e-test-minion-group-4lw4 +[ ... lines removed for clarity ...] +Capacity: + alpha.kubernetes.io/nvidia-gpu: 0 + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + alpha.kubernetes.io/nvidia-gpu: 0 + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... lines removed for clarity ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + +In the preceding output, you can see that if a Pod requests more than 1120m +CPUs or 6.23Gi of memory, it will not fit on the node. + +By looking at the `Pods` section, you can see which Pods are taking up space on +the node. + +The amount of resources available to Pods is less than the node capacity, because +system daemons use a portion of the available resources. The `allocatable` field +[NodeStatus](/docs/resources-reference/v1.5/#nodestatus-v1) +gives the amount of resources that are available to Pods. For more information, see +[Node Allocatable Resources](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node-allocatable.md). + +The [resource quota](/docs/admin/resourcequota/) feature can be configured +to limit the total amount of resources that can be consumed. If used in conjunction +with namespaces, it can prevent one team from hogging all the resources. + +### My Container is terminated + +Your Container might get terminated because it is resource-starved. To check +whether a Container is being killed because it is hitting a resource limit, call +`kubectl describe pod` on the Pod of interest: + +```shell +[12:54:41] $ ./cluster/kubectl.sh describe pod simmemleak-hra99 +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "gcr.io/google_containers/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + +In the preceding example, the `Restart Count: 5` indicates that the `simmemleak` +Container in the Pod was terminated and restarted five times. + +You can call `get pod` with the `-o go-template=...` option to fetch the status +of previously terminated Containers: + +```shell{% raw %} +[13:59:01] $ ./cluster/kubectl.sh get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-60xbc +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]{% endraw %} +``` + +You can see that the Container was terminated because of `reason:OOM Killed`, +where `OOM` stands for Out Of Memory. + +## Opaque integer resources (Alpha feature) + +Kubernetes version 1.5 introduces Opaque integer resources. Opaque +integer resources allow cluster operators to advertise new node-level +resources that would be otherwise unknown to the system. + +Users can consume these resources in Pod specs just like CPU and memory. +The scheduler takes care of the resource accounting so that no more than the +available amount is simultaneously allocated to Pods. + +**Note:** Opaque integer resources are Alpha in Kubernetes version 1.5. +Only resource accounting is implemented; node-level isolation is still +under active development. + +Opaque integer resources are resources that begin with the prefix +`pod.alpha.kubernetes.io/opaque-int-resource-`. The API server +restricts quantities of these resources to whole numbers. Examples of +_valid_ quantities are `3`, `3000m` and `3Ki`. Examples of _invalid_ +quantities are `0.5` and `1500m`. + +There are two steps required to use opaque integer resources. First, the +cluster operator must advertise a per-node opaque resource on one or more +nodes. Second, users must request the opaque resource in Pods. + +To advertise a new opaque integer resource, the cluster operator should +submit a `PATCH` HTTP request to the API server to specify the available +quantity in the `status.capacity` for a node in the cluster. After this +operation, the node's `status.capacity` will include a new resource. The +`status.allocatable` field is updated automatically with the new resource +asynchronously by the kubelet. Note that because the scheduler uses the +node `status.allocatable` value when evaluating Pod fitness, there may +be a short delay between patching the node capacity with a new resource and the +first pod that requests the resource to be scheduled on that node. + +**Example:** + +Here is an HTTP request that advertises five "foo" resources on node `k8s-node-1`. + +```http +PATCH /api/v1/nodes/k8s-node-1/status HTTP/1.1 +Accept: application/json +Content-Type: application/json-patch+json +Host: k8s-master:8080 + +[ + { + "op": "add", + "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-foo", + "value": "5" + } +] +``` + +**Note**: In the preceding request, `~1` is the encoding for the character `/` +in the patch path. The operation path value in JSON-Patch is interpreted as a +JSON-Pointer. For more details, see +[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). + +To consume an opaque resource in a Pod, include the name of the opaque +resource as a key in the `spec.containers[].resources.requests` map. + +The Pod is scheduled only if all of the resource requests are +satisfied, including cpu, memory and any opaque resources. The Pod will +remain in the `PENDING` state as long as the resource request cannot be met by +any node. + +**Example:** + +The Pod below requests 2 cpus and 1 "foo" (an opaque resource.) + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + pod.alpha.kubernetes.io/opaque-int-resource-foo: 1 +``` + +## Planned Improvements + +Kubernetes version 1.5 only allows resource quantities to be specified on a +Container. It is planned to improve accounting for resources that are shared by +all Containers in a Pod, such as +[emptyDir volumes](/docs/user-guide/volumes/#emptydir). + +Kubernetes version 1.5 only supports Container requests and limits for CPU and +memory. It is planned to add new resource types, including a node disk space +resource, and a framework for adding custom +[resource types](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/resources.md). + +Kubernetes supports overcommitment of resources by supporting multiple levels of +[Quality of Service](http://issue.k8s.io/168). + +In Kubernetes version 1.5, one unit of CPU means different things on different +cloud providers, and on different machine types within the same cloud providers. +For example, on AWS, the capacity of a node is reported in +[ECUs](http://aws.amazon.com/ec2/faqs/), while in GCE it is reported in logical +cores. We plan to revise the definition of the cpu resource to allow for more +consistency across providers and platforms. + +{% endcapture %} + + +{% capture whatsnext %} + +* Get hands-on experience +[assigning CPU and RAM resources to a container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/). + +* [Container](/docs/api-reference/v1/definitions/#_v1_container) + +* [ResourceRequirements](/docs/resources-reference/v1.5/#resourcerequirements-v1) + +{% endcapture %} + +{% include templates/concept.md %} + diff --git a/docs/user-guide/compute-resources.md b/docs/user-guide/compute-resources.md index d2856f50aa..51fcaafa9d 100644 --- a/docs/user-guide/compute-resources.md +++ b/docs/user-guide/compute-resources.md @@ -5,368 +5,6 @@ assignees: title: Managing Compute Resources --- -* TOC -{:toc} +{% include user-guide-content-moved.md %} -When specifying a [pod](/docs/user-guide/pods), you can optionally specify how much CPU and memory (RAM) each -container needs. When containers have their resource requests specified, the scheduler is -able to make better decisions about which nodes to place pods on; and when containers have their -limits specified, contention for resources on a node can be handled in a specified manner. For -more details about the difference between requests and limits, please refer to -[Resource QoS](https://github.com/kubernetes/kubernetes/blob/{{page.githubbranch}}/docs/design/resource-qos.md). - -*CPU* and *memory* are each a *resource type*. A resource type has a base unit. CPU is specified -in units of cores. Memory is specified in units of bytes. - -CPU and RAM are collectively referred to as *compute resources*, or just *resources*. Compute -resources are measureable quantities which can be requested, allocated, and consumed. They are -distinct from [API resources](/docs/user-guide/working-with-resources). API resources, such as pods and -[services](/docs/user-guide/services) are objects that can be written to and retrieved from the Kubernetes API -server. - -## Resource Requests and Limits of Pod and Container - -Each container of a pod can optionally specify one or more of the following: - -* `spec.containers[].resources.limits.cpu` -* `spec.containers[].resources.limits.memory` -* `spec.containers[].resources.requests.cpu` -* `spec.containers[].resources.requests.memory`. - -Specifying resource requests and/or limits is optional. In some clusters, unset limits or requests -may be replaced with default values when a pod is created or updated. The default value depends on -how the cluster is configured. If the requests values are not specified, they are set to be equal -to the limits values by default. Please note that limits must always be greater than or equal to -requests. - -Although requests/limits can only be specified on individual containers, it is convenient to talk -about pod resource requests/limits. A *pod resource request/limit* for a particular resource -type is the sum of the resource requests/limits of that type for each container in the pod, with -unset values treated as zero (or equal to default values in some cluster configurations). - -### Meaning of CPU -Limits and requests for `cpu` are measured in cpus. -One cpu, in Kubernetes, is equivalent to: - -- 1 AWS vCPU -- 1 GCP Core -- 1 Azure vCore -- 1 *Hyperthread* on a bare-metal Intel processor with Hyperthreading - -Fractional requests are allowed. A container with `spec.containers[].resources.requests.cpu` of `0.5` will -be guaranteed half as much CPU as one that asks for `1`. The expression `0.1` is equivalent to the expression -`100m`, which can be read as "one hundred millicpu" (some may say "one hundred millicores", and this is understood -to mean the same thing when talking about Kubernetes). A request with a decimal point, like `0.1` is converted to -`100m` by the API, and precision finer than `1m` is not allowed. For this reason, the form `100m` may be preferred. - -CPU is always requested as an absolute quantity, never as a relative quantity; 0.1 is the same amount of cpu on a single -core, dual core, or 48 core machine. - -# Meaning of Memory - -Limits and requests for `memory` are measured in bytes. -Memory can be expressed a plain integer or as fixed-point integers with one of these SI suffixes (E, P, T, G, M, K) -or their power-of-two equivalents (Ei, Pi, Ti, Gi, Mi, Ki). For example, the following represent roughly the same value: -`128974848`, `129e6`, `129M` , `123Mi`. - -### Example -The following pod has two containers. Each has a request of 0.25 core of cpu and 64MiB -(226 bytes) of memory and a limit of 0.5 core of cpu and 128MiB of memory. The pod can -be said to have a request of 0.5 core and 128 MiB of memory and a limit of 1 core and 256MiB of -memory. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: frontend -spec: - containers: - - name: db - image: mysql - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" - - name: wp - image: wordpress - resources: - requests: - memory: "64Mi" - cpu: "250m" - limits: - memory: "128Mi" - cpu: "500m" -``` - -## How Pods with Resource Requests are Scheduled - -When a pod is created, the Kubernetes scheduler selects a node for the pod to -run on. Each node has a maximum capacity for each of the resource types: the -amount of CPU and memory it can provide for pods. The scheduler ensures that, -for each resource type (CPU and memory), the sum of the resource requests of the -containers scheduled to the node is less than the capacity of the node. Note -that although actual memory or CPU resource usage on nodes is very low, the -scheduler will still refuse to place pods onto nodes if the capacity check -fails. This protects against a resource shortage on a node when resource usage -later increases, such as due to a daily peak in request rate. - -## How Pods with Resource Limits are Run - -When kubelet starts a container of a pod, it passes the CPU and memory limits to the container -runner (Docker or rkt). - -When using Docker: - -- The `spec.containers[].resources.requests.cpu` is converted to its core value (potentially fractional), - and multiplied by 1024, and used as the value of the [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#/cpu-share-constraint) - flag to the `docker run` command. -- The `spec.containers[].resources.limits.cpu` is converted to its millicore value, - multiplied by 100000, and then divided by 1000, and used as the value of the [`--cpu-quota`]( - https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint) flag to the `docker run` - command. The [`--cpu-period`] flag is set to 100000 which represents the default 100ms period - for measuring quota usage. The kubelet enforces cpu limits if it was started with the - [`--cpu-cfs-quota`] flag set to true. As of version 1.2, this flag will now default to true. -- The `spec.containers[].resources.limits.memory` is converted to an integer, and used as the value - of the [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) flag - to the `docker run` command. - -**TODO: document behavior for rkt** - -If a container exceeds its memory limit, it may be terminated. If it is restartable, it will be -restarted by kubelet, as will any other type of runtime failure. - -A container may or may not be allowed to exceed its CPU limit for extended periods of time. -However, it will not be killed for excessive CPU usage. - -To determine if a container cannot be scheduled or is being killed due to resource limits, see the -"Troubleshooting" section below. - -## Monitoring Compute Resource Usage - -The resource usage of a pod is reported as part of the Pod status. - -If [optional monitoring](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md) is configured for your cluster, -then pod resource usage can be retrieved from the monitoring system. - -## Troubleshooting - -### My pods are pending with event message failedScheduling - -If the scheduler cannot find any node where a pod can fit, then the pod will remain unscheduled -until a place can be found. An event will be produced each time the scheduler fails to find a -place for the pod, like this: - -```shell -$ kubectl describe pod frontend | grep -A 3 Events -Events: - FirstSeen LastSeen Count From Subobject PathReason Message - 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others -``` - -In the case shown above, the pod "frontend" fails to be scheduled due to insufficient -CPU resource on the node. Similar error messages can also suggest failure due to insufficient -memory (PodExceedsFreeMemory). In general, if a pod or pods are pending with this message and -alike, then there are several things to try: - -- Add more nodes to the cluster. -- Terminate unneeded pods to make room for pending pods. -- Check that the pod is not larger than all the nodes. For example, if all the nodes -have a capacity of `cpu: 1`, then a pod with a limit of `cpu: 1.1` will never be scheduled. - -You can check node capacities and amounts allocated with the `kubectl describe nodes` command. -For example: - -```shell -$ kubectl describe nodes gke-cluster-4-386701dd-node-ww4p -Name: gke-cluster-4-386701dd-node-ww4p -[ ... lines removed for clarity ...] -Capacity: - cpu: 1 - memory: 464Mi - pods: 40 -Allocated resources (total requests): - cpu: 910m - memory: 2370Mi - pods: 4 -[ ... lines removed for clarity ...] -Pods: (4 in total) - Namespace Name CPU(milliCPU) Memory(bytes) - frontend webserver-ffj8j 500 (50% of total) 2097152000 (50% of total) - kube-system fluentd-cloud-logging-gke-cluster-4-386701dd-node-ww4p 100 (10% of total) 209715200 (5% of total) - kube-system kube-dns-v8-qopgw 310 (31% of total) 178257920 (4% of total) -TotalResourceLimits: - CPU(milliCPU): 910 (91% of total) - Memory(bytes): 2485125120 (59% of total) -[ ... lines removed for clarity ...] -``` - -Here you can see from the `Allocated resources` section that that a pod which ask for more than -90 millicpus or more than 1341MiB of memory will not be able to fit on this node. - -Looking at the `Pods` section, you can see which pods are taking up space on the node. - -The [resource quota](/docs/admin/resourcequota/) feature can be configured -to limit the total amount of resources that can be consumed. If used in conjunction -with namespaces, it can prevent one team from hogging all the resources. - -### My container is terminated - -Your container may be terminated because it's resource-starved. To check if a container is being killed because it is hitting a resource limit, call `kubectl describe pod` -on the pod you are interested in: - -```shell -[12:54:41] $ ./cluster/kubectl.sh describe pod simmemleak-hra99 -Name: simmemleak-hra99 -Namespace: default -Image(s): saadali/simmemleak -Node: kubernetes-node-tf0f/10.240.216.66 -Labels: name=simmemleak -Status: Running -Reason: -Message: -IP: 10.244.2.75 -Replication Controllers: simmemleak (1/1 replicas created) -Containers: - simmemleak: - Image: saadali/simmemleak - Limits: - cpu: 100m - memory: 50Mi - State: Running - Started: Tue, 07 Jul 2015 12:54:41 -0700 - Last Termination State: Terminated - Exit Code: 1 - Started: Fri, 07 Jul 2015 12:54:30 -0700 - Finished: Fri, 07 Jul 2015 12:54:33 -0700 - Ready: False - Restart Count: 5 -Conditions: - Type Status - Ready False -Events: - FirstSeen LastSeen Count From SubobjectPath Reason Message - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "gcr.io/google_containers/pause:0.8.0" already present on machine - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d - Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a -``` - -The `Restart Count: 5` indicates that the `simmemleak` container in this pod was terminated and restarted 5 times. - -You can call `get pod` with the `-o go-template=...` option to fetch the status of previously terminated containers: - -```shell{% raw %} -[13:59:01] $ ./cluster/kubectl.sh get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-60xbc -Container Name: simmemleak -LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]{% endraw %} -``` - -We can see that this container was terminated because `reason:OOM Killed`, where *OOM* stands for Out Of Memory. - -## Opaque Integer Resources (Alpha Feature) - -Kubernetes version 1.5 introduces Opaque integer resources. Opaque -integer resources allow cluster operators to advertise new node-level -resources that would be otherwise unknown to the system. - -Users can consume these resources in pod specs just like CPU and memory. -The scheduler takes care of the resource accounting so that no more than the -available amount is simultaneously allocated to pods. - -**Note:** Opaque integer resources are Alpha in Kubernetes version 1.5. -Only resource accounting is implemented; node-level isolation is still -under active development. - -Opaque integer resources are resources that begin with the prefix -`pod.alpha.kubernetes.io/opaque-int-resource-`. The API server -restricts quantities of these resources to whole numbers. Examples of -_valid_ quantities are `3`, `3000m` and `3Ki`. Examples of _invalid_ -quantities are `0.5` and `1500m`. - -There are two steps required to use opaque integer resources. First, the -cluster operator must advertise a per-node opaque resource on one or more -nodes. Second, users must request the opaque resource in pods. - -To advertise a new opaque integer resource, the cluster operator should -submit a `PATCH` HTTP request to the API server to specify the available -quantity in the `status.capacity` for a node in the cluster. After this -operation, the node's `status.capacity` will include a new resource. The -`status.allocatable` field is updated automatically with the new resource -asychronously by the Kubelet. Note that since the scheduler uses the -node `status.allocatable` value when evaluating pod fitness, there may -be a short delay between patching the node capacity with a new resource and the -first pod that requests the resource to be scheduled on that node. - -**Example:** - -The HTTP request below advertises 5 "foo" resources on node `k8s-node-1`. - -_NOTE: `~1` is the encoding for the character `/` in the patch path. -The operation path value in JSON-Patch is interpreted as a JSON-Pointer. -For more details, please refer to -[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3)._ - -```http -PATCH /api/v1/nodes/k8s-node-1/status HTTP/1.1 -Accept: application/json -Content-Type: application/json-patch+json -Host: k8s-master:8080 - -[ - { - "op": "add", - "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-foo", - "value": "5" - } -] -``` - -To consume opaque resources in pods, include the name of the opaque -resource as a key in the `spec.containers[].resources.requests` map. - -The pod will be scheduled only if all of the resource requests are -satisfied (including cpu, memory and any opaque resources.) The pod will -remain in the `PENDING` state while the resource request cannot be met by any -node. - -**Example:** - -The pod below requests 2 cpus and 1 "foo" (an opaque resource.) - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: my-pod -spec: - containers: - - name: my-container - image: myimage - resources: - requests: - cpu: 2 - pod.alpha.kubernetes.io/opaque-int-resource-foo: 1 -``` - -## Planned Improvements - -The current system only allows resource quantities to be specified on a container. -It is planned to improve accounting for resources which are shared by all containers in a pod, -such as [EmptyDir volumes](/docs/user-guide/volumes/#emptydir). - -The current system only supports container requests and limits for CPU and Memory. -It is planned to add new resource types, including a node disk space -resource, and a framework for adding custom [resource types](https://github.com/kubernetes/community/blob/{{page.githubbranch}}/contributors/design-proposals/resources.md). - -Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168). - -Currently, one unit of CPU means different things on different cloud providers, and on different -machine types within the same cloud providers. For example, on AWS, the capacity of a node -is reported in [ECUs](http://aws.amazon.com/ec2/faqs/), while in GCE it is reported in logical -cores. We plan to revise the definition of the cpu resource to allow for more consistency -across providers and platforms. +[Managing Compute Resources for Containers](/docs/concepts/configuration/manage-compute-resources-container/) From 11f3e0fec14504ff2f86b02953c5275f2febfc7c Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Mon, 27 Feb 2017 15:24:11 +0800 Subject: [PATCH 202/213] Delete the parameter "--google-json-key string" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit “# kube-scheduler -help”can not find --google-json-key option # kubectl version Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-23T00:04:39Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.1+82450d0", GitCommit:"f5ef9802914a47c848fd84c287333f8b4d28bbc1", GitTreeState:"dirty", BuildDate:"2017-01-22T23:56:57Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64", USEEVersion:"V1.02.01_alpha", USEEPublishDate:"2017-1-10 00:00:00"} --- docs/admin/kube-scheduler.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/admin/kube-scheduler.md b/docs/admin/kube-scheduler.md index 15e47d2f46..91ffc303aa 100644 --- a/docs/admin/kube-scheduler.md +++ b/docs/admin/kube-scheduler.md @@ -36,7 +36,6 @@ DynamicKubeletConfig=true|false (ALPHA - default=false) DynamicVolumeProvisioning=true|false (ALPHA - default=true) ExperimentalHostUserNamespaceDefaulting=true|false (ALPHA - default=false) StreamingProxyRedirects=true|false (ALPHA - default=false) - --google-json-key string The Google Cloud Platform Service Account JSON Key to use for authentication. --hard-pod-affinity-symmetric-weight int RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule corresponding to every RequiredDuringScheduling affinity rule. --hard-pod-affinity-symmetric-weight represents the weight of implicit PreferredDuringScheduling affinity rule. (default 1) --kube-api-burst int32 Burst to use while talking with Kubernetes apiserver (default 100) --kube-api-content-type string Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") From d30c4a7c7885a6a2e8e4ca5bcf732cc804112382 Mon Sep 17 00:00:00 2001 From: huzhifeng Date: Sun, 26 Feb 2017 11:39:46 +0800 Subject: [PATCH 203/213] Add diagnose tips when you face problem. --- docs/getting-started-guides/kubeadm.md | 32 ++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index b5a9845b44..229ef993f0 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -195,6 +195,38 @@ Once a pod network has been installed, you can confirm that it is working by che And once the `kube-dns` pod is up and running, you can continue by joining your nodes. +If you see following status +``` +NAMESPACE NAME READY STATUS RESTARTS AGE +kube-system canal-node-f0lqp 2/3 RunContainerError 2 48s +``` +Or + +``` +kube-system canal-node-77d0h 2/3 CrashLoopBackOff 3 3m +kube-system kube-dns-2924299975-7q1vq 0/4 ContainerCreating 0 15m +``` +The three status ```RunContainerError``` and ```CrashLoopBackOff``` and ```ContainerCreating``` very common. + +You may have trouble in configure. to diagnose what happened. you can using ```kubectl describe -n kube-system po {YOUR_POD_NAME}``` to check what's in logs. do not using kubectl logs. you will got +``` +# kubectl logs -n kube-system canal-node-f0lqp +Error from server (BadRequest): the server rejected our request for an unknown reason (get pods canal-node-f0lqp) +``` +The kubectl describe will gave you more details about the logs + +``` +# kubectl describe -n kube-system po kube-dns-2924299975-1l2t7 + 2m 2m 1 {kubelet nac} spec.containers{flannel} Warning Failed Failed to start container with docker id 927e7ccdc32b with error: Error response from daemon: {"message":"chown /etc/resolv.conf: operation not permitted"} + +``` +Or +``` + 6m 1m 191 {kubelet nac} Warning FailedSync Error syncing pod, skipping: failed to "SetupNetwork" for "kube-dns-2924299975-1l2t7_kube-system" with SetupNetworkError: "Failed to setup network for pod \"kube-dns-2924299975-1l2t7_kube-system(dee8ef21-fbcb-11e6-ba19-38d547e0006a)\" using network plugins \"cni\": open /run/flannel/subnet.env: no such file or directory; Skipping pod" +``` + +Then you can do some search with google, and you will find solutions. + ### (4/4) Joining your nodes The nodes are where your workloads (containers and pods, etc) run. From 06104e35a3d89d3b00139d165a0a6a907be7e5f5 Mon Sep 17 00:00:00 2001 From: huzhifeng Date: Tue, 28 Feb 2017 08:01:23 +0800 Subject: [PATCH 204/213] Update grammar for kubeadm.md, thanks @chenopis --- docs/getting-started-guides/kubeadm.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index 229ef993f0..aba4e1d52d 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -195,37 +195,47 @@ Once a pod network has been installed, you can confirm that it is working by che And once the `kube-dns` pod is up and running, you can continue by joining your nodes. -If you see following status +If you see the following status ``` NAMESPACE NAME READY STATUS RESTARTS AGE kube-system canal-node-f0lqp 2/3 RunContainerError 2 48s ``` + Or ``` kube-system canal-node-77d0h 2/3 CrashLoopBackOff 3 3m kube-system kube-dns-2924299975-7q1vq 0/4 ContainerCreating 0 15m ``` -The three status ```RunContainerError``` and ```CrashLoopBackOff``` and ```ContainerCreating``` very common. +The three statuses ```RunContainerError``` and ```CrashLoopBackOff``` and ```ContainerCreating``` are very common. + +You may have trouble in the configuration. To help diagnose what happened, you can use the following command to check what is in the logs: + +```bash +kubectl describe -n kube-system po {YOUR_POD_NAME} +``` + +Do not using kubectl logs. you will got the following error: -You may have trouble in configure. to diagnose what happened. you can using ```kubectl describe -n kube-system po {YOUR_POD_NAME}``` to check what's in logs. do not using kubectl logs. you will got ``` # kubectl logs -n kube-system canal-node-f0lqp Error from server (BadRequest): the server rejected our request for an unknown reason (get pods canal-node-f0lqp) ``` -The kubectl describe will gave you more details about the logs + +The ```kubectl describe``` gives you more details about the logs ``` # kubectl describe -n kube-system po kube-dns-2924299975-1l2t7 2m 2m 1 {kubelet nac} spec.containers{flannel} Warning Failed Failed to start container with docker id 927e7ccdc32b with error: Error response from daemon: {"message":"chown /etc/resolv.conf: operation not permitted"} ``` + Or ``` 6m 1m 191 {kubelet nac} Warning FailedSync Error syncing pod, skipping: failed to "SetupNetwork" for "kube-dns-2924299975-1l2t7_kube-system" with SetupNetworkError: "Failed to setup network for pod \"kube-dns-2924299975-1l2t7_kube-system(dee8ef21-fbcb-11e6-ba19-38d547e0006a)\" using network plugins \"cni\": open /run/flannel/subnet.env: no such file or directory; Skipping pod" ``` -Then you can do some search with google, and you will find solutions. +You can then do some Google searches on the error messages, which may help you to find some solutions. ### (4/4) Joining your nodes From 1cbd24e888ae2f952bf8cb2db5d374f934a6f15f Mon Sep 17 00:00:00 2001 From: huzhifeng Date: Tue, 28 Feb 2017 09:13:50 +0800 Subject: [PATCH 205/213] Merge two pieces to one words --- docs/getting-started-guides/kubeadm.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/docs/getting-started-guides/kubeadm.md b/docs/getting-started-guides/kubeadm.md index aba4e1d52d..24c9498e44 100644 --- a/docs/getting-started-guides/kubeadm.md +++ b/docs/getting-started-guides/kubeadm.md @@ -195,34 +195,32 @@ Once a pod network has been installed, you can confirm that it is working by che And once the `kube-dns` pod is up and running, you can continue by joining your nodes. -If you see the following status + +You may have trouble in the configuration if you see the following statuses + ``` NAMESPACE NAME READY STATUS RESTARTS AGE kube-system canal-node-f0lqp 2/3 RunContainerError 2 48s -``` - -Or - -``` kube-system canal-node-77d0h 2/3 CrashLoopBackOff 3 3m kube-system kube-dns-2924299975-7q1vq 0/4 ContainerCreating 0 15m ``` + The three statuses ```RunContainerError``` and ```CrashLoopBackOff``` and ```ContainerCreating``` are very common. -You may have trouble in the configuration. To help diagnose what happened, you can use the following command to check what is in the logs: +To help diagnose what happened, you can use the following command to check what is in the logs: ```bash kubectl describe -n kube-system po {YOUR_POD_NAME} ``` -Do not using kubectl logs. you will got the following error: +Do not using kubectl logs. You will got the following error: ``` # kubectl logs -n kube-system canal-node-f0lqp Error from server (BadRequest): the server rejected our request for an unknown reason (get pods canal-node-f0lqp) ``` -The ```kubectl describe``` gives you more details about the logs +The ```kubectl describe``` comand gives you more details about the logs ``` # kubectl describe -n kube-system po kube-dns-2924299975-1l2t7 From eb57603fcbf52f8114aa000172e482fd46e5262b Mon Sep 17 00:00:00 2001 From: xilabao Date: Sun, 26 Feb 2017 21:09:41 -0600 Subject: [PATCH 206/213] add http proxy infomation in kubeadm --- docs/admin/kubeadm.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index a43beec497..24f39217f0 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -258,6 +258,8 @@ These environment variables are a short-term solution, eventually they will be i | `KUBE_ETCD_IMAGE` | `gcr.io/google_containers/etcd-:2.2.5` | The etcd container image to use. | | `KUBE_REPO_PREFIX` | `gcr.io/google_containers` | The image prefix for all images that are used. | +If you want to use kubeadm with an http proxy, you may need to configure it to support http_proxy, https_proxy, or no_proxy. + ## Releases and release notes If you already have kubeadm installed and want to upgrade, run `apt-get update && apt-get upgrade` or `yum update` to get the latest version of kubeadm. From 3c20c4da09024eaa4874f2ed68b57fdd24e7016c Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Mon, 27 Feb 2017 17:45:20 -0800 Subject: [PATCH 207/213] Update landing pages for Tasks and Tutorials. (#2634) --- _data/tasks.yml | 2 +- docs/tasks/index.md | 6 ++++++ docs/tasks/kubectl/list-all-running-container-images.md | 2 +- docs/tutorials/index.md | 6 +++--- 4 files changed, 11 insertions(+), 5 deletions(-) diff --git a/_data/tasks.yml b/_data/tasks.yml index 5dae817f8e..ab237c3474 100644 --- a/_data/tasks.yml +++ b/_data/tasks.yml @@ -3,7 +3,7 @@ abstract: "Step-by-step instructions for performing operations with Kubernetes." toc: - docs/tasks/index.md -- title: Using the Kubectl Command-Line +- title: Using the kubectl Command-Line section: - docs/tasks/kubectl/list-all-running-container-images.md - docs/tasks/kubectl/get-shell-running-container.md diff --git a/docs/tasks/index.md b/docs/tasks/index.md index d490fe5532..6bd8db2e6c 100644 --- a/docs/tasks/index.md +++ b/docs/tasks/index.md @@ -6,12 +6,18 @@ This section of the Kubernetes documentation contains pages that show how to do individual tasks. A task page shows how to do a single thing, typically by giving a short sequence of steps. +#### Using the kubectl Command Line + +* [Listing Alll Container Images Running in a Cluster](/docs/tasks/kubectl/list-all-running-container-images/) +* [Getting a Shell to a Running Container](/docs/tasks/kubectl/get-shell-running-container/) + #### Configuring Pods and Containers * [Defining Environment Variables for a Container](/docs/tasks/configure-pod-container/define-environment-variable-container/) * [Defining a Command and Arguments for a Container](/docs/tasks/configure-pod-container/define-command-argument-container/) * [Assigning CPU and RAM Resources to a Container](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) * [Configuring a Pod to Use a Volume for Storage](/docs/tasks/configure-pod-container/configure-volume-storage/) +* [Configuring a Pod to Use a PersistentVolume for Storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) * [Exposing Pod Information to Containers Through Environment Variables](/docs/tasks/configure-pod-container/environment-variable-expose-pod-information/) * [Exposing Pod Information to Containers Using a DownwardAPIVolumeFile](/docs/tasks/configure-pod-container/downward-api-volume-expose-pod-information/) * [Distributing Credentials Securely](/docs/tasks/configure-pod-container/distribute-credentials-secure/) diff --git a/docs/tasks/kubectl/list-all-running-container-images.md b/docs/tasks/kubectl/list-all-running-container-images.md index 4fb64ee442..070de69004 100644 --- a/docs/tasks/kubectl/list-all-running-container-images.md +++ b/docs/tasks/kubectl/list-all-running-container-images.md @@ -1,5 +1,5 @@ --- -title: Listing all Container images running in the cluster +title: Listing All Container Images Running in a Cluster --- {% capture overview %} diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index 76e42570b1..25b8cca32e 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -7,14 +7,14 @@ A tutorial shows how to accomplish a goal that is larger than a single [task](/docs/tasks/). Typically a tutorial has several sections, each of which has a sequence of steps. -#### Kubernetes Basics - * [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features. -#### Stateless Applications +* [Online Training Course](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) * [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) +#### Stateless Applications + * [Running a Stateless Application Using a Deployment](/docs/tutorials/stateless-application/run-stateless-application-deployment/) * [Using a Service to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address-service/) From 6f83f5070a1dd42c58259cda5308b44c39e943eb Mon Sep 17 00:00:00 2001 From: Steve Perry Date: Tue, 28 Feb 2017 09:08:11 -0800 Subject: [PATCH 208/213] Move Guide Topic: Multi-container pods. (#2642) --- docs/user-guide/pods/multi-container.md | 170 +----------------------- 1 file changed, 2 insertions(+), 168 deletions(-) diff --git a/docs/user-guide/pods/multi-container.md b/docs/user-guide/pods/multi-container.md index 55e0e56f84..465379e51c 100644 --- a/docs/user-guide/pods/multi-container.md +++ b/docs/user-guide/pods/multi-container.md @@ -4,172 +4,6 @@ assignees: title: Creating Multi-Container Pods --- -* TOC -{:toc} +{% include user-guide-content-moved.md %} -A pod is a group of containers that are scheduled -onto the same host. Pods serve as units of scheduling, deployment, and -horizontal scaling/replication. Pods share fate, and share some resources, such -as storage volumes and IP addresses. - -## Creating a pod - -Multi-container pods must be created with the `create` command. Properties -are passed to the command as a YAML- or JSON-formatted configuration file. - -The `create` command can be used to create a pod directly, or it can create -a pod or pods through a `Deployment`. It is highly recommended that -you use a -[Deployment](/docs/user-guide/deployments/) -to create your pods. It watches for failed pods and will start up -new pods as required to maintain the specified number. - -If you don't want a Deployment to monitor your pod (e.g. your pod -is writing non-persistent data which won't survive a restart, or your pod is -intended to be very short-lived), you can create a pod directly with the -`create` command. - -### Using `create` - -Note: We recommend using a -[Deployment](/docs/user-guide/deployments/) -to create pods. You should use the instructions below only if you don't want -to create a Deployment. - -If your pod will contain more than one container, or if you don't want to -create a Deployment to manage your pod, use the -`kubectl create` command and pass a pod specification as a JSON- or -YAML-formatted configuration file. - -```shell -$ kubectl create -f FILE -``` - -Where: - -* `-f FILE` or `--filename FILE` is the name of a - [pod configuration file](#pod-configuration-file) in either JSON or YAML - format. - -A successful create request returns the pod name. Use the -[`kubectl get`](#viewing_a_pod) command to view status after creation. - -### Pod configuration file - -A pod configuration file specifies required information about the pod. -It can be formatted as YAML or as JSON, and supports the following fields: - -{% capture tabspec %}configfiles -JSON,json,pod-config.json,/docs/user-guide/pods/pod-config.json -YAML,yaml,pod-config.yaml,/docs/user-guide/pods/pod-config.yaml{% endcapture %} -{% include tabs.html %} - -Required fields are: - -* `kind`: Always `Pod`. -* `apiVersion`: Currently `v1`. -* `metadata`: An object containing: - * `name`: Required if `generateName` is not specified. The name of this pod. - It must be an - [RFC1035](https://www.ietf.org/rfc/rfc1035.txt) compatible value and be - unique within the namespace. - * `labels`: Optional. Labels are arbitrary key:value pairs that can be used - by - [Deployment](/docs/user-guide/deployments/) - and [services](/docs/user-guide/services/) for grouping and targeting - pods. - * `generateName`: Required if `name` is not set. A prefix to use to generate - a unique name. Has the same validation rules as `name`. - * `namespace`: Required. The namespace of the pod. - * `annotations`: Optional. A map of string keys and values that can be used - by external tooling to store and retrieve arbitrary metadata about - objects. -* `spec`: The pod specification. See [The `spec` schema](#the_spec_schema) for - details. - - -### The `spec` schema - -A full description of the `spec` schema is contained in the -[Kubernetes API reference](/docs/api-reference/v1/definitions/#_v1_podspec). - -The following fields are required or commonly used in the `spec` schema: - -{% capture tabspec %}specfiles -JSON,json,pod-spec-common.json,/docs/user-guide/pods/pod-spec-common.json -YAML,yaml,pod-spec-common.yaml,/docs/user-guide/pods/pod-spec-common.yaml{% endcapture %} -{% include tabs.html %} - -#### `containers[]` - -A list of containers belonging to the pod. Containers cannot be added or removed once the pod is created, and there must be at least one container in a pod. - -The `containers` object **must contain**: - -* `name`: Name of the container. It must be a DNS_LABEL and be unique within the pod. Cannot be updated. -* `image`: Docker image name. - -The `containers` object **commonly contains** the following optional properties: - -* `command[]`: The entrypoint array. Commands are not executed within a shell. The docker image's entrypoint is used if this is not provided. Cannot be updated. -* `args[]`: A command array containing arguments to the entrypoint. The docker image's `cmd` is used if this is not provided. Cannot be updated. -* `env[]`: A list of environment variables in key:value format to set in the container. Cannot be updated. - * `name`: The name of the environment variable; must be a `C_IDENTIFIER`. - * `value`: The value of the environment variable. Defaults to empty string. -* `imagePullPolicy`: The image pull policy. Accepted values are: - * `Always` - * `Never` - * `IfNotPresent`Defaults to `Always` if `:latest` tag is specified, or `IfNotPresent` otherwise. Cannot be updated. -* `ports[]`: A list of ports to expose from the container. Cannot be updated. - * `containerPort`: The port number to expose on the pod's IP address. - * `name`: The name for the port that can be referred to by services. Must be a `DNS_LABEL` and be unique without the pod. - * `protocol`: Protocol for the port. Must be UDP or TCP. Default is TCP. -* `resources`: The Compute resources required by this container. Contains: - * `cpu`: CPUs to reserve for each container. Default is whole CPUs; scale suffixes (e.g. `100m` for one hundred milli-CPUs) are supported. If the host does not have enough available resources, your pod will not be scheduled. - * `memory`: Memory to reserve for each container. Default is bytes; [binary scale suffixes](http://en.wikipedia.org/wiki/Binary_prefix) (e.g. `100Mi` for one hundred mebibytes) are supported. If the host does not have enough available resources, your pod will not be scheduled.Cannot be updated. - -#### `restartPolicy` - -Restart policy for all containers within the pod. Options are: - -* `Always` -* `OnFailure` -* `Never` - -#### `volumes[]` - -A list of volumes that can be mounted by containers belonging to the pod. You must specify a `name` and a source for each volume. The container must also include a `volumeMount` with matching `name`. Source is one of: - -* `emptyDir`: A temporary directory that shares a pod's lifetime. Contains: - * `medium`: The type of storage used to back the volume. Must be an empty string (default) or `Memory`. -* `hostPath`: A pre-existing host file or directory. This is generally used for privileged system daemons or other agents tied to the host. Contains: - * `path`: The path of the directory on the host. -* `secret`: Secret to populate volume. Secrets are used to hold sensitive information, such as passwords, OAuth tokens, and SSH keys. Learn more from [the docs on secrets](/docs/user-guide/secrets/). Contains: - * `secretName`: The name of a secret in the pod's namespace. - -The `name` must be a DNS_LABEL and unique within the pod. - - -### Sample file - -For example, the following configuration file creates two containers: a -`redis` key-value store image, and a `django` frontend image. - -{% capture tabspec %}samplefiles -JSON,json,pod-sample.json,/docs/user-guide/pods/pod-sample.json -YAML,yaml,pod-sample.yaml,/docs/user-guide/pods/pod-sample.yaml{% endcapture %} -{% include tabs.html %} - -## Viewing a pod - -{% include_relative _viewing-a-pod.md %} - -## Deleting a pod - -If you created your pod directly with `kubectl create`, use `kubectl delete`: - -```shell -$ kubectl delete pod NAME -``` - -A successful delete request returns the name of the deleted pod. +[Communicating Between Containers Running in the Same Pod](/docs/tasks/configure-pod-container/communicate-containers-same-pod/) From 8b97c4265f09ca4a520aaf475062192ddf467f3d Mon Sep 17 00:00:00 2001 From: EJ Date: Wed, 15 Feb 2017 19:05:45 -0800 Subject: [PATCH 209/213] fix link to go to pod-lifecycle page --- .../configure-liveness-readiness-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md index ff05756350..a5c3d8ee56 100644 --- a/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md +++ b/docs/tasks/configure-pod-container/configure-liveness-readiness-probes.md @@ -255,7 +255,7 @@ In addition to command probes and HTTP probes, Kubernetes supports {% capture whatsnext %} * Learn more about -[Container Probes](/docs/user-guide/pod-states/#container-probes). +[Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). * Learn more about [Health Checking section](/docs/user-guide/walkthrough/k8s201/#health-checking). From 764225a7a018a7853d66690ab887516e133cde58 Mon Sep 17 00:00:00 2001 From: chenhuan12 Date: Tue, 28 Feb 2017 14:58:36 +0800 Subject: [PATCH 210/213] fix the command output fix the command output --- docs/getting-started-guides/gce.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/getting-started-guides/gce.md b/docs/getting-started-guides/gce.md index 245de295f9..109dcb8d95 100644 --- a/docs/getting-started-guides/gce.md +++ b/docs/getting-started-guides/gce.md @@ -134,10 +134,10 @@ $ kubectl get --all-namespaces services should show a set of [services](/docs/user-guide/services) that look something like this: ```shell -NAMESPACE NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE -default kubernetes 10.0.0.1 443/TCP 1d -kube-system kube-dns 10.0.0.2 53/TCP,53/UDP k8s-app=kube-dns 1d -kube-system kube-ui 10.0.0.3 80/TCP k8s-app=kube-ui 1d +NAMESPACE NAME CLUSTER_IP EXTERNAL_IP PORT(S) AGE +default kubernetes 10.0.0.1 443/TCP 1d +kube-system kube-dns 10.0.0.2 53/TCP,53/UDP 1d +kube-system kube-ui 10.0.0.3 80/TCP 1d ... ``` From 2ef4477df3d8a2b84baf592decbfee4c28ef6fd0 Mon Sep 17 00:00:00 2001 From: mlambert890b Date: Sat, 4 Feb 2017 00:06:16 -0800 Subject: [PATCH 211/213] mirantis_logo.png ,/images/community_logos/mirantis_logo.png updated per Mirantis request --- images/community_logos/mirantis_logo.png | Bin 11543 -> 8607 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/images/community_logos/mirantis_logo.png b/images/community_logos/mirantis_logo.png index d2c395e323e80f86b3ba57d55731ab0707023f77..4f407a37bb6a3b411f8209c789232391adb43e83 100644 GIT binary patch literal 8607 zcmb`NWl$Sm*tdhb6e#Z6;$B<}4Nh?@Qb>W~P^<(94#k7J1t{(koZ=d!KufVuq)^-; z1s?wMetPHm`rI?S=flqIIkWf9?)AIo#OP|jA;PD{2LJ#>YQWcePvg?l5r~WZbQZe1 zl6@L5y_D1paGwf{YZnawFay+HD;oIa9_IOjzc0WaDqR%U9F7_)x2{(0bImJhZmF?9>)e(_P2E-0|JWyvCf$iK^RE4V}-j!cM8u5YvD= z)Q-~`|2>5LT()4HNzIxQ#rtyu71V9A14j7g+Y9^eI3xUtH<15-35{>K(+TDp+-a0e zY)Z`e62>?(TflurVWAr5tK!GL=XQ^EJC}ZEc-eZmx)jFlYuO;OJ1_^x6oz$SiZ=WZ9Noy$8m>e_DI|9l}-@oG6?<1x+ml9Uki=0)SFf3 zT^V%a{g(92LucL-6OWKN<#$UBwI8dt6|w~AF)>gO|gl1;s&5yCdvELAHFRzK( z__APo?blTFlTG#tW-kWxaJkTPaan!)lwhv_{80<)CK0wrM}P2g#9IjS7xqLp^PG^) z5&pI{5Aic_Ksr=(z-8W=%^?R;ASHUuyWYA}gKXuZ$=*RQc`>IO&-S!_I} zHKX+jg`HA%;4(H+@y(I#{HyQ1xi%tExzBbjo~!i3i9KSYy@15vAMTiJ z6)|)13$u4`B7ac=ehB#<{rHg32@qt$6vCNvhDjAC87X%l6p%E36RRb6qdjVMk)i%4 zSpwu;cI_@S4M0S6S65lXQA?3gxBptPU~A9k7Q5;8A=4?{w^nf0!Om z9;%mK+6-+};?hVYvyfS7jiY1_aMFT3?DQ|riv~YrhPgg)pv&Q$!J5PIgh+eGJr7;x z#R=~-2HXXmr(5jQW7a>Qj#xaV-G2&ZC(i)e3%({)-Lf_xy__*esTiFoL#`nOYJ6^fXV7dDEIehIBgQk5A-k{LjPJDE9(f4x+_HLVe z$^-RhFGx z=7Dl{)8Ap+_Mls9e`x+8k9)J@5SLA@jy(idQXv?(nLJk0KH7taABI2h+jJJj4`?qO|%C0RRoV-k#I&nW;Zm{ve>FJsn`v|m4-lEx@H8PU9bQjZlnr?hq4P27+_|cc4ovzv-8F~f`jI$zop^2 z$L;?vF5-jDGiYKHwdZ_lbqg;vV7GFxuZ2|~Sub@ye5*&o*jOLcL)sEx(crKF?dKTv zqEzj6as4t@0VJ)mtNH4Fj18>>A9@zk(~>(9R;At%4gs7 zg4Kd}z*Mmv{u0Ja((g)>?cG(iI|szzhtjPT(rNo~e&=zQh?>#pen!CD zjf_&rMz6+;>iEdsxDxB%_1vWYut(j9TP$(!YSQcw4fe;P=-Vw8wxoWB8`C|`G8B2B)_>Yyv7&tTt$%U5aJ8tI zUvL5kEL?!QO{T9EptBJAJ#So{FG6)GF|guj*D`Z%L+Id*wkjI~%CDC;uBccsz^z#f zoBlTjw`cVEc{F(=ZLHj^vgC4I zZO=-!_pM*A;l^?6Kv#J_stEYk?U5=$G^7KMg~+ZD9{Gk{zLze13Z)2bKV zZqN9a@#z2(?4f2O%ug$#J{-GJW#(Yz zX1oEj7L2NUHJ}45s$^B{o>)rxAnk!J-0CT%-hr`t^<>6%$` z)3+_QCbR4Kk!eSD@!sIoiww&P#sMo+ zSbl|?5znU?*}AL4$nJ`9>L~+l-Yfv1qAM5y$4-VvfZBFxS2ikT8#m+VH#Wgx5t4_> z1Hch6fFrL_*G5z~FKYWlezPFYsCnZ6{r5lm*B-;-4b}OL?sZl1;?7g4qsiK(y$AG4 zTy3i74*}1OhM+FTl1t29dqVw{M(+M9uBe~|lU8X%p1GLnnbxtbS8Gj2aH~OiY5$KW zsm0F!1PLr;99Tq*NX+(&mVx)r=(r7^y~uOv>jbpdxO6x#Oy89mZ23)#jlNzt_o1-~ zk{oI#dA#E3zOTd^7BEVQFA*%RmV^iKK``a~f^0=b?e|+%U z0tFzFXW5I%2Htdi+VYfZr=Lpt%Td&zrEkk=Vo zh%&fj#ts2(ZJgPhH2OytzH^oJAO{-Nt0^|ww{H!6@`XBbw|dbbc5c-%-yfOZ!Jpp4 zOuq9_CeQ5^71l$78>t;bgf^Aj(4~|3kUY<2M$jiRf3DF!ARcilDaM798OkBn*3xW2 zLRg1Cqhuw+@VjSdQ9#0|KoTzipw?J#$iwR7BvLfuRZG}#yJh{{nh{%4?42nk1fyGG zU}5AZ$L0CU2o8H}`duLn%6N+MeIm6-%nNoEc;xAC+FZ%GaE41-;NDfRlD9N^3 z@wxan>yS1 z-5J-&Qu>^J8C_N!`>-u(3~jzPxKk|49apNeS2WhKGBzf+vNVwho|NIbUgJG0W}B;k zDnPL|(Ak-z?3R1mpxxb^dXEu=nM*wRUPMVXUK7*qHa+NJr8Li8e5Z2?ma$b{9XK5t z(I(0lUX6PCE(+}70#V{~q$k;Sbu?cBJD%kr9bhNJYO&fWvtj(VYjL=#mg0SeB9@j- z9pxilfj2Ib?pF@E#_^vp?~S!=Z~iKmBD`uXe+c^`Rro!+qpdlm{1i!MTYM2Kq?Ysc z-IS@^#`4U2Dy8s(f+dK_fHs3qRw{Bd(v8Q9)IFWClr85CT5q5h6bP$VKQj8m+L0Wwr`Fi0mkz ze{M*FyJkO%u=`eBf~D5Udw`X-OsJh!vJAJBcbvsh2!w8dfYJlCmKhh#IyX}nm)?jE z!{2yGlikCiysCKFyG`O^4#M^`n8PJyE~&HYrbzNJU1n8fiC{|oSQ_Fz-}vfn}E3U--$a{#qa+E739U?S;_Xv{aH_zOOm zFS86`A?MB+JWU$0b+uk`$8LxVG^YXbIt4|iX`;d=_Bn3;TBd{S7d_GTNr z==LG>Ik}`R=q5Ujd_+r{Z2?Q3_p>Rct;N>;9>ex>#3uvclp&g8^9mo5#nmm)mbYtM zrh-jdyzV;(T=Y0;o=vy-tNQbM=GbTQifAn6IuPBbegWi$h74Y)9Y_0xeXAn%!S##% z&L3R|I3f^PDo?lG0&d0O9p`1{6g;9Sqbwm5KLsedU>G2=mw?6n*)p@^ZR~evb@W#Fq<^t7($G1^k3qmxW|wyJHvH2FMKYbYobP zLk?Me-Y#PaeylDoW+k3n46Er}ld+lqGqEZN{ff^kF&x_Ta*|y_*;=Tm0>BxP$;`|I zQHHSM_LDWUE;Ap7orn{zg*LzYCJu4?wsFbZc3JQrN=vRByGc-kca`ABHKsUc*E_-p zF8k`LRu57y2IdK|Pk)vv|B6hN8KN4IN9VW1^vh(dmAj3?USn?ecjJr;l zv@5KSl~no#H3X}cuG3@aDzdlC*1oj&0)GyS_WdtuBFn*XCEMjAja50TZpSFZm-Gh* zv3mN}80q4|>u<(`R7O~o^cWJ?1gw2VdPB7b@fdIia78csBlA=#<}{W>q8;-CJUkH7 zvSsEYY2t!-Y{X#(OS4t90;Er;621R^A^AiAYWO3KBchaRB9lwXs_9$+ znVP@9TQch*RPlwufBVY&Gq<`1jz>(2NLg5!sJ8d;v+svJLQB~m31KrxM7rQcbI%s{1#+~i|G;oQpFjTcm#t0{*3UV> zd8)LqqZRq<;-o<$SAKE+tBfvzcm4ncB*yBcJL_4lP8mzPZpZtr0K(g>u74}%*vp)tT~?v#Q%BRvLo{XzTsg(f zxKDP3G_ZAhFcC{|JvW08$BQv^fB!`8a6~Cv=Nm$Snll{4RQrkq5JXZ229PFQ<-IRb z_({O7f%?vNc{{|Hjb=5Pu~>7(u0wzoDqj^7UZ>gWGHUf%axAf|ME*HD>g7CTz~Uu{ zYA7S6)*6YCD+J4X;VBnVrI?^Ysvu)(+I;eTxlD{sZ&qH?x>h0M^qyrlvZ?AHh~p_* zMH<*$^=!?>3XqD!h7A^2Dwjp^tN> zKw-M!Acj7b3YxxHsd8L~bttR<9}MzOXb?has*!tCbg1J?H(bg?K{+LEmghw zQhr99zVVyI9=P--<0El^CEK4ESYB+Ocu4OaClGASe0Yr+ssoXc?9rU515^VS(~Feq zUybx~zWre)Ve@t_l-@hf$#6+^psmdcwEQy1*30^HZVE@ljaDe0IgRK}0(bCOZZjxR zJi0M_X)cJSTHQz!gLZk*+1$&z@G|8X4k>Qk30oT754rKA<;TZTXF9BM0To`*LYdSk zzG{iZBQ;*qYd+1oc^I9prcQlMC&k6d_WNS2Jdtf`;S{u39O$Nf^G<1-a8dTx7#-jSZ`0(2`)#iHG&FGoT`0vU^ONIV%kWu8fJ4U+}Q;NCKiWGpqTORi4%eaE=uyd3%k@K`{$-9u5FF8Mu?oa!sl!0d|M7cxhuB zPqNK5aOROCZeLQaXNYZy!laQ zmGe?`TG?=@Kb&ae91UkMu@ev4U0depGPimzn0(SiRxe*M%uuD}amZxWQ^kT0c*36A zum$~7L>}+El**#RGa|G?PP50-(!K z5j<`dSmXqE-V7beS8&G~8?;Hi7}*B~w&gpsd-}{)=qu(^Se5b1npzp$YV1HXZ&+Dp zIlyr`oLywKCNhpT9%qX_Bh+3+uy>~*)`#6E!GKl=j{opuM~<<#9RtAr*v(C9(Pp>r z*o3X&W;TrlXqi1Zgg($)sSfB@q4&!J6w-PxIDNvI8B`y?CWJ?U6L}1mHK$84&o(Ej z;}?jUyEjnIn@%;=u7rOR;$QLn3vd{e+8=I^MZo`7B2vb+H_lEMD^9TT*Tb9f=0pP5@QkLKo*W}gD;ym6t z4v7Ziv0?MLfm}VBO7BM2v>y+j=#XIlTewn{tKu-vy4gG~aw(?tUmJ|*C}O|t>t!Q;tokzGxgl+orNm%w;cM=DHMY|&H z6v6Otf{$#M1FZ+OnGEhX>MC#ddOr{lv3rq6Y&3+7kB-rLagK!#(b{UYIRpdTOFPN% z2{Vi^)l;m_jw7B@X$sU*=LH4h*!L4Jm_9jP!OPg=Ys2!@Sxpy1=Jr<eXhcBDn?pe-+^%p5!YGV!9PC}RMRUIJV8im}+m9hO}>9^cqOC#6dBs8!OHh5L@?n8tC7X@_J=uQJC@X{Hk z+gXAv&33q1&IbBr7wP~jk8AitWT5M`Df5e;jI0&)0&-})`2i;?YY)-YmWO7HvB>$X zMX^-iovIc)_=B)ZTy8i#9X54O6l0ED<3ygkVwYs}|DY!P8C4>#cO9q}oG2i&)ds!a zmPFTmN^QPk$?o-9NAx^kGb5cVla$Hp{^~k>UccZ(L;$nxz&Gu58-0y5N-(2@%mt){ zs&3`&(%*Fup^FBcj+gVxq3xq%t!Bpc-!J z#O`y`_ao>g3+tZYvS;{tDy^_{v-OYi&u!9v^0XDJlNH(tKEx^=rBSv;z3W6)%PiU2 zM68A(DUV%m%`7Z(WTAkXDG}Daa#a3@ZscqH=I;}2%T_S&*#IA5lHkTYV- z;k@Q=Lk~i^IBe4bKpJxp0BiRaMK<{s@|C z*B!&3)SBKL`6&nnuWXcPuWu9oPwAN9v!+(Yce`sxZleLR%^UfXQ%MIucBmxMcUP}< ze`X2~_&oufrpSYLx9r)?X}w=Z}f#j@*_3fdDW(p7(*7qpp1vt zi9-S`sP=H>7!WYugyw~Y)U|T(f43^ACewkYG(EXsWrbt7W&)>0hK@I%Nd5gzB2BXm z(g8HpDu(mKzHVsky-jg;A>NlRfP%wr5dA@`@STG19C7lDgyf9QsN_{p*brrZSK!$0;k6)A1Di?&%-;7_ZChXOwZEv;Kq~ z1$8mseZ8_X$9f{|g1}kcs{tL08rY_5%3&J6FLc)FUUcJ!eWI)tH}lnaK}ranbTAlo zR~jx2U~@xv*XI>=Q!k% zI`inZ0tvp5t1o{fqa`KTziMa$^9?QO4@9^=OI1gI@8u?P2YsUGOaDO$bSvX|(^ya$ zABmG2%+9gl77oNU~PCbz{7uvopsanH8->g`@2g9Vu@@q3umTK}*q8tCXpuDhO6w-pNPmWGO z`07%cm;HpgnwGEr7pZAzwTtVoHLFg$oL2G*0u2e>L)yIq%&>{9=>yST`Vc zoY8l0biB7)U7=%eJciqDyewxrI`^YkOw&Q{=DQ>;AG*GXeogf}(+I*oF3@Eh;M0W^*xemWOb|zkO0cnS353)?8zP+13Ro?-ZKYyKEt2nDZo7p0~1+4w%kOuL<1A zexgp}LYVh`ObiKDls|G4798~&B5uHCV`ix5YV5Pvo=}h3s=)tH4#OQJIbJvQ@*}b7 zNEZT-QX{wqfGdoYk~L2;Uyr|+J?xh^bPH~fG^CT2`QHV3Br$OkrC)i4>U`R90Z>!X KeqF0%9r{1m>yx$s literal 11543 zcmb`tRZ|>X6E!+WaCZsr?(PnQ1$P;2kl+phhT!fH+})i)2Zvz6A!u;t!9s$byysM% zAMn+8v3l+9i(S=gUvyXZj`^gago#Fm1^@ssRg~qm|MBWS1fd}Pvpi3~CH@hro3fE7 z0DzAFKfnQU@<;#xG))INxlf<$UAV5!qe@8i+TTl=cyaot^h>l`u+1tU|LPfGxTQ7ub}yBjt>GWP3$ zQ#url-VK0*(rQEF`AP=|_!BHH&PEGE?gzm6Euy0UVCuOr?vGLL*k`iYrf`sOIG9(8 zuqq0K03aQZC|d!LR)mA(e`C}E6d?jEr>w2^0iQSkmP{c>ivURepX@+5fJr(HAzV=k zfEwR6S{`682B@3Uk5vE|asvqLR7XSrYa9S>6$3kEKvO3GHj9Ja0zkn4aBD?JumBJP z0hSYVbbf&FYyg4ct%3LrTLaE9>p!KkTg0LCA_}1-v{1_qpz%(E)QYy^TJcu@;UK$yydhpvZ*Yi3=8izdpqpU2$DMjfF?&txWE*SDl=<@->OVF zhF-9}M*!fq$8~Ut83h4iANFg`_x)PxRjG&p0I^d^bq4^<<>@(fzqd+_qW}Q%MWL)s zGUWGzBb}Y{N6s`+uv&60NmKB{wCp3( z+^{%@^t!Ml+_0ZOC=s#?{ zcyf}6igJH=w2?`~3l<;$sI|xbnItJU&J8;uLFOCz%*{DAEZZ#1j+$mY)l6H5Q9DM~ zq+f^76Z2p_*X)ak7pee56-4xvr3O*TC>yF7YOE<&QGcZ8$Nh;ago+TZHN-@lR;Aj; z*p2&lgv5%MC(2Nnoo)p$37-omFj{Uzh#oISj+Y6V46o8$rn`W*pt#_oO?S#(oy)IG zMwd4E)5fURKNStkhhz8IL1gkj^+U}n->5@ZrEsV_<6H?<1V#W>P&U2Y+s^KZx5*x9an zhO8Z|UkFpaqh$ay7&FLOxpb>*Dr&ZC(Dm;0rgW34&2@qr6!rLY_N!5sGHdl}@;{yH zkn4b}#j2uez*VlgQf0wLuQ5nQ!)n8ta%EaY%@+H;W7O!@q^*AJG)|bck=~&KBaF>6 z>tB3Wd%nF=^u$TjR2PfL@d5b^TD9-e?WB)X0FV-3y$3;xMta7A+O+9 zgYwv#I@M%mWg6Bh*J{-&o%abgTvp~+^eOZhJ%?h+j02fWnUuguvmf%0b=GyZD$y#5 z)Fnh88aQj5%E^m+b^QZRX!+T7$UV|&?9YN z%#w(Y3b?z9Q*e!M+-S*}4NJ?FgEBx_zrs_X^Wvq;iV2F?@eX6A`}F(HW6ooxj7W?$ zjH>Eq>Q_11>d*?73NbY?wegwhnUa~6Y=K+}o>kuC+~eHU+?`HKV?Sf|j;f9>Ta}gr z;|imzj$W4tV-cfrLp@`&R>k`KdWMyr`kqSMN~lJfMs2|gc)01NW3r>VleFn@4QZpH z!?_~}1hygucaAm;U#0b>1$74{yhengGEJ@B>^0BRnz5}4wgS*+UfQ5(r z+}7No%c_mWE5R#=tEkPwY5qc%0wX@pAHx%JyIP0yQs{*l+)g`n!J2ZKq2TsoIxcIj z6odNJrp|KTnn%zzvE*+_kHUS)eQ}{}-fbg`X(3qWMCX*|uxo)u#Ex7D-Mh_u!23L) z62brnMu-WO2{nO#{uA(pW*|{Ybi?*{%lf5Ed=XTJP$ubX{nx|6dK&wQi{yHm$K!9a zDYFh(5ubujR(>FZjzDq4!5B;tQ4t1_Qi*QShGg?RSpvTEn{u8z@=x-a^4qy!9!-%( z4xj+5WDTdI_)np3{%)x;PCKLNWy5?!mCvdlML1a-1YJJ&@4Q^zMeXJ9q3;J0f8&}k zbMr5r9lDRGB&z1bV;9YoR*TjUPXA8^hqa0*p5YeXmmv|&e~4lTOv^PdI3K+xXUa;c zajVR#9*}yG(ktLkKgw6meh3X`s!r}z!&KYK6)hmj@u7C+l@RUY2}?~$c9*T8QBUgt zpMj6;e5UGbBU;`@UE(^qC^L{Jom!LYJ{WPJb;wqn=o&MxvLd&DZ4K-OW@5gJWY!k2 z&0J2me&0wI%DXOnzr-8D`<2>J9;s@;L1B2*SLZ0wBJS?LfwoWhfh|%WsZP8rwu9Aq zS+n-iAgdv`k1;^qDb#%M``5vCIHz-TJ+#A!p!3buOEXPFE~A}x&{JeSxg=psYy-gt zaTa078uO;#A$gSR_krxq^tS5S5va|a-Gbfe(Kbhc307uJ)=?Ig3+DRIHq0IUw#$d# z3L9KmGt3)3VI6YN(gE?VUfasa*%>h@-7?*K-6vhatA(w0(CQzT`783k-rxKe%Nr)W zkFS!G{Tq64dg{w|%eK!d&#jMA4KX#Re=?t)&FVFr-7m)x77$*M>99Ihp-amY3lh58 zNh@sUN?7Am{cri#z8si>n0g6$V|#RN^8N>>kElD3l$fGFec}V_ejzVX`A~oYMZ|CCkGxCFiIsa~2 zZj^Kc9$U}uIAXhAcjI{dT2Oe8I~MB|n>D@d^15x=IK(&TGRSEZwQxT3Iun0OThtuy z$?M5!fSNi%uLAno1MMD9$qR&Lx9hpVRLUO4@uZ^ACj_@rXn#T z&kKYlMMUE*MGho^xgEOxGvqn);#z^9m4!>|F`);=SSsp8fjYEJ0iljyBBLd zj*Wl)CbhM)wmJY1zyJV1!T^B3@BjD|0PyAp0M0A{0MTy%0I_ST#i$|xKr5>vFQe=C z^CI83H(xK~ao}0xFtaTeQ5%vRjwfqhtc+VColc9P?gx@)8H%Q}Khl#&Mj}y^DaYLH z-4jkkV)+h3iEaZde3d;}P|>88DBBGF8T@W|KDqwr_9XFmv}yA$S$OQZ0iE-oy}Q^k zcY6J8>_qOwK}kv3uC(hK8WqKq_5b1jKm0H7f9fcO&=^mpUGjqVr2C0C5X2DnAI?cE z$t~%*;YrXi;E@m#Ad{Y0=w1l*(qc_;hUj$*jj9lT*q2>1YNK=P6!o)eTO=lHk=v#&KTH%#S}w_#nTb z`XP6r`>DkU;z)=iU@Tfk^Hs-daTO~_-MNiFxGcW~W%T$UR3QdrUAxg#U8 zG5AFB*nxpldT9HQxoU6G;^@E?;u8Q7GtCh^6})PO8y$ZGIratMqH0{@tVB@scpagO zsOw`Fm7jEySN`@Lp5~vr}TMOV&SYN{LG^A zt-%O<0dn+)kL7YM3ndiglS0`Nfwao zxLp!qA_0wri-ONOTkUUwvFzIJf_6zMaLyl;g{>wHy+atQmp64dwBpR2B(p-ojEgPk zfS?jc&x8LsZIZX$TOmN`ynQLhRL;BPDKGWqQ$hkOZpaE86%FtNA%IGZ0=I;K@jS5K zwB9h~yrdkW$^H^(kh(sJ5q9SnYQhKIJM#!4|JF~sS-cE$dV*PK`5uMAV}~?#`$tvl zZK-b!d?C8T+RYLbBOa39{k*GcQ+^8e{+g|W;DPz!Hxkw---`)W#`<=c$=Q_z#&iR* zZS6WN!HmVur;@~Fn$ck)P1TM6Kkwai(b&7pGgv`sGi*x1yob1@!6zJR8|44>X{QRl zqiw?9Shq^VET#kZTQQG{z=6kB->_$RhR02O@Y^xu_*}uS8AgrZjv;jg^zik~`6c4A zyQ0x>LuQ?48k%H*+MUb}5je9d_Zq`W2W(WG{4m`Ur#i0-l1erEp|$JH!|>B<*VG1X zV>B=kX!w0W4Ve>868(kTO)vX^3?r|CXG=Gsm~|Ady{lFC)I`S>%^;3vb31?UuWsb3 zjziAWCxlKS4*`G$0_UP%1y^`1I8>^d{4OPyh=S~$q%V?t--^El%e!cdIxXD|+Mt7% zvi)w7WUJ5s3O8=KcB&&<-SKr)d$0yJx?{p==z44wew`Xes$j#0TAdjOo5cu>`44!^ zBlQAafY)1&XE+H+WZauu`FoKK^p>|{1}1FK-;1H%x>Qn87)D$mXpJEk^EwgRFSHMf z8`ZS|1WjDDg~xc#m~Qwj)V*aR?RiC4TVRUS&x|cqy@MH7snR{|5)0n!ZT#e(3YE5l zBhlIZt3`f+yyuEnjb|Gyq9EN^>?PT)ip+LSQ0O4iQ3Z!<8K3D+cG>#3*p|gk8;?;4 z`ZDIG9iLP!1DRBB(VjxHpQ8!GxL1P7*wM>t&@Rz#r^4na4ww};ajEc~*vQcke@u4+ zIWnviZmZ+?^Xsuq4#ii?0b5eBYu~VaOqQ6**-yAtWa2Rg7q9*1^}5P6NR~F1e*7s% z&lD=Dz&4=LV_8mn-JcbCB?|7aWUW)u$C(t0<8)0n?*NN$9nSXadhAEz})@qG|5zLhjJ>i?*m1lzo3Uq1KU*ey!t_mQL`UyGz zm7|@xu*nf*BPCh3RHa{yIg`B9J)YwUvuTkk%dGlV+ZmR6vG6gq9 z^u~0>rFqdBZdG7>eOFuzeK;3$2WUJSPwsPG_0n9i419yvk~+`SZMb%ZB-Pm}nxrxa z%Ej@>7oUBO$|S;#*)b1NcSs8YSw}~RNT#~ z&)iXqL&`41jBPb9*kazTo%p$vsP`o?;q1)}{Ut$E9j{};SP#iCFVnAe5T-|=LS&*^ znE|)7G2dIB?1Y%Q;$fbFV8x-GPC~@kL8l$iWBkn};a3T84-}0^VF$)u*=he|Y{wNz z2=k6+@2d!}eGFMP!|+6=LgaLNp94@3bvHpD6y!Mas0KIP-K}kApqS0gmn#KT$9cM= z-o90PzI3VD%Z(*+b^f+ocoH<1+Rj zA*guz_(q8SuXllQOcSqnJ7qQ+mv=H6qqXiA6uzZl)&nyZF1Y1UKA3>xhgeVxE998v zlu9Ypa}~ngP4N+RO^obE{@v#VytX7sHcFA;zC(CAQtIVhxb|-BrC9C+#TXFi8>`n} zMg7uHDX&VS!P5HcGG#1 z{k<_m>_J&~AX0zd;LkY&ULCQVr>U~JN9|;V^za7Ix=ns6#Ma8UETz}5-grbLrl{FtGSSWMPV`& z*kGL!vE1zcwi0Wjwo~f()7XZ`+ta$sxXVEq@0_1rj8^*~=1hThfBH>z?2 z;dcw6o!J#P!h&mBF_ysK&~wE3&IA$Rn4&eHk*wh?J?=DYz?u{pTM?Bq@b6 z=}nsoccqWuOZ&m&(P6r!ZdM__sr$DdeW&X+E$xtnp8YoqWuJ={S~?Rg!jJ_!=+z%T zx9fIw_m%ISq>Y>hLRFl{uI^#Kq_|u)wi;D0jK@TyQq6%?T_8=w^d9w8-!wyPUZ=E@f2F&6gGjHl z?@2ZlAuM12-zn!HM$=$yhOjW%fAYNQVZT^*|L9M})D!W_?l#s82^Ytnn>OIDB*69r zxmmh?z&e*~gF2QltnP=$0=m2o6PDn@-C+Y~tDX}qJESO?=LGGBAfi9l$!ZbfYaW&m zF52o(;2(UrzrDSgvJkvXgzIUB3Q{1iC2-gb+Wa*V%JBPiM|EUoio|O<*Y%QC3K%WIBVS1<+s1zL+;yMQ5e&2_%6QZSamlly2 zR!ia;7@Ic=b(@SThQ?+@;XZS$VXAmYYVAMKrEE^Zl@n1`vl;?Si)9s`_3v?%XhpvA zd2#P_5B?5BP5gNVWVUNE~Nz{?ofPHj>%;Mo>jOrv^NFh z)!zCamxgidoI4TeGkKqX9S%l{?c;eNodL}gbXg5zZQ(YX=WiDq+ZejpFC2E;nRK!> z|JGtk%F#?RJu-_4Rx(s=-h3<6}27u1HfWG`{GkUX_@<1#%^l6108IO%&DI`5g|4%wKV*5tOZ{(dx-b^z+W zpv0W|efn?g73+xZBrfXmCj@toyvV9<@DH7NvuJvSfu&>XvN4xmHf6oP)TCkJ+Z85-KO8;D+b$=JoZiAfeXNGnf-a~MD!jJB7y)t-Y0*rBF z_ipPBex_~-=qC&ng0upmJ^k&*q4OIKQhh%hLe1zHxk8QW52tRJE5}RQj$W3}@X2(o z+A>m>y0XShE49RH>2|=zR1twLr$BQtUT)QGpb4jaG%r(zoj=m7b94)>^^4ZrKO#AtLcb(wCwuy`e(XVyPAP#T0Ij@2K?f~n_&94 zM!RZsb6%CfG&arYMdx2d_OOv?8i&9{h$@+NJjShNBa4anT@kS_7`}!3uNggEzqa^- zO&3Um_3mEiC%!cjd8;a-9aG)GpAXX7W-DWw7B4)k%n1sq?7@*$?d8CGO{MRazt2ZY zjlQ4v4=W4r$y7$Pl9gN#@X*)U=uqLuH7VUM^88SAV$;aI{$Lf2_@1O3pj-Yefq?z3 zVKUiYAmdl=Wekm6yodqvPj6eS^x@>ugUP46FD>ZPY;i9;_PbQchoSBQy>BhE|Z@b!~~iQ6$F z*p{+XVg|#uRa2@v()xi#T>8xmywR$$(Fnq}%+B@sQ&8`0%mZ^t=4|6pVJEW(sl0|H zvtw6-NWTgV-|Qk*YrXTU#6*6|cI-~Y&>j$dDvFdcCx80owq^EUGmgBJ{JmBz!{AA% z@a=||Va3r#{RS@9)e&b5WU%O&rI_6E&4MnbpX!s}B9zf)>x7*U_pE+rlFY{FmuNsU zXqZTbv((p8ee8DBFuYK3TrkBRV9Bpt;l`5zu5X0DiW{1K$jl1a%-HUrD{m)1(E3GE8I}0$nnz}yao3icvj5=f*?@xg({%q<6^D+C` z+XeP<)CQFi`E-#3NlGHZWZdjU7o%%4(ZaN+1xfdYjfmuW%{|C|4#}aFI;5PAs@#Iy zfkqBEtz;~*rk{>P9_9Ahn#_iD&N#P?tbT8+XAFi=hY0N_rFa(`;F7){(q_7UT!`^A zNI-t1?vYcmu;y^F)g+wBP4NgNaW!`S+jT666w`Y_D0g~>JrMRH>g)U z*xjKeg@-J8zA|Kh6a&8&<7ujYDh8Dp7n8?!*>gtHNnpM!Sl3{r=HHOhH#V;op`Xv& zC5IprCA$pN;>Nr>mvwndrvB;Xjq)nhlV8VoNDROTTHK+cSGslVE64#!r>b^8Mehge zc;@BPMkF=1#z3V9{&%bdy$=UjbkCl%WE!{&o>;Y&Nqwe`V-9Y& zD#IEK{U@;|hJHhpQ5B10XyOZrsKt8N^$fhi@LMmd4t}blie-Ec6x07|kQ~0pbTTgg zADm1B!2;!Z&5pTIgUKt#e^e75Fs4@t z?y~|@RBBre1Hn-d8cL9L(1-!1=rd)!O%;`%9ecAe>VtTTp;#`NO`w5t15R2p{ZgqX zd!3%gR@lUiDsvv3B+$A>2j}mXK*4J=y(kTBO@8R}XZ zu}Vgr{`<8wWJ;ICF7wUlvuUby>-(MpoPRw@c{D;&rrK@5G|uo?vwSMOF&COIHL=9# z6NQWd`g88lc)r9n8`H(w;Zq+Po$8*(`w3V&P&_WhL9~@)bZRk(Uw9b%`h^gh8J*Oc z2D)W+PS>OPskW7f)GZ9G`sDtiLvzDSX(DOGw1V|H-22TxIwkYIDmc;{ojD5&$-)#0z$R4fH z@{FQ+7n`p}i4&)k8_XwNwwAV|8Va6Gzmw2vT~{HB8FTzpmKWKKEXWo7Ol|TsUrys; zXl*ONc>ZrHwDK%&g8I;(3cV6!yq*G^@~OoDotMY9aoK8kqzyxyK#bNU)w^S z%vme=+_%(Z-fy8jd>+1irx%d4BfC((t##|GEi{V$8kf@@aeXNOC8|Ufl3bG+NR+)@ z9TR5N@0{%>PiH@0?lY~)#e+23 zrJ=}p4n*Y~Jhs|HLk>46*0hmrGcJ2X+b8p(ARpctU(r;r2dkZJb5>7RXBUOpo(Pi` zD5rFhDWbC6j0}m3W|^Nz#`;npgA2wS!(yG=?`)v4A6q_1p1R@2y%}YEl$O4UU1L}v zUu9bZY~P+KGiLev=kDOll?``Fi*A9;Jy)EVN;q64)9nhuhOg6yZF#0x8SKqgh_bHs zL%1d7!S+&R50)Bln?DnaLo}JODd@H-i@;URYXc$3d|V*Cy3k0GA^LF)=H(~fk2##w z6G6%~HcbXOjJ5nUrUlmVj5P&Wu327IycR~13~zcx>NBXLeZwJ9BxxoSjB3I>!w<^q zcxhvs>}}i9Z7cvZxWqO)Taq|n;9B;#o35wWKx47A60$rlEv}yVb1!x_IKEWzI72>z z(fq9ZJ@gWl@cM`&kVw0PQjVayId&MAhKaEXf3(?$isvC(p&;|0w`#02(+vbvHtd+v z(W!`Ko;IVX!{jFU=@P0P z$Dug5j)hbQJdmLzq(fymB9QcBedQbL=@iHs}F zh4KID{L<dNhT_N2iOKni1D3eIceC$+yHxh0w4 zF~FP;Xa5)_I)Zl#E)k+usdFz|bFFry&ea_^3{J5XPhE0K{&12M`=3ChO#}uln_`84 zjgu0QZjaM{{=N%yDe^7AnssJ36Z%*5KB_qMUKjQjzmGD!Mw!GS$36kGK=?E4$wDB} z>haIAW0No&pY$-?S=z%eb008|*U`jhkgK%pGz%ck&|57gSnOGY-ZH?rypOjJrdCx%qMM_O&!clV6KN9MAyd2R~+V_I+HjJ+?r&rh$& z%2AbH5T6USYlXFw{Ty&zzaTAqtK8%z4?EyFGO41By1!d9oAX6qz%C`wSe^3;=d;6C zZh6pA_FQBrFg*m-&1&;dxCIhYuY#A*Leo{-(p4IqCpzB9RBm)9P*O+8jzmjZkKO1a z>_f_4_MKo1$}zxl;q(i0ZMtMrnB#;%`sdE_uw-YIkb+}x4jZ-)#^0N2uE1Q#DYWJ= zl4FUfN!J&+mMC}jBtr2|NkV5SrZV}dwG78_m)g7DSBl6WSw|6N!ax0=x{i-nd}^mM zHW2+R@@4)FtnM@>|N3KBITBI}72d`j?BFq*9fWw``UIe@-g;UTx(8EHX45|M8Vv>( z#^1Yp#k8ZTj9g8NaQ!bUzuET7bg&@C2~=#KyJn-NQhT#F)BEFpzGs=?YlJM1Rfzi^ z&&jQ*@_z-!4KJTPDk^o8vDlJU-mC`Sv-kF@Fr~ZCYQ^>b_}1_HXLGgMms{(44zWyZ z_48TT509d*2uMN997|=pf*#NmrW)GtL>j7o!UkCd_6xPaDFA=i9B|9Dv?xmCL32P1{2;&%Y^YsZm{$Z zBK{Mrr$#Ohju;Iq?ar`uv&b)Z#;q^10Mp8t%?(vaghxwgp@Cy$5V+)+;(oOyf{<*A zo^R;*F(Pn1&_fS0hy^vC>~Pzja>qv!6M9w$b0-zO2kzMI-unmfqYap}{Tff?W2}X`GZ4{P#oCx*< zK;x>%X)!%yU!d?)0+Y=eY~Ce)8-Jf=`ttsQPangOiXM#P`L|Ks#an11nG6yp+A$np z*d-*9v75hb2s^T#vrX}n-!3iWeiOcBcv2P0iBe>cyF#0Pe8k+`@d_5I&$@bGw{c$v zRBFGQG#u@r<+R_n{NDoRf( zEa9t-y4XV`T|V?pwQ>m4lP-Fkeu;%b7$emSv{2=$mhOJVQsvf5;9BAH-JWKJAFOeDBc9n@XrOr|U8KZUyFz zS%sLMQ-J8aFndV-{3s^{yzonXa0)^S?mAzc+-3$m`rq*oG&9HDv*+Y}*s@xUJrYAi`SM4J?A$Xb1g z#9yR{sw1sHVjk3|6|lP^>KJeF$3sElhYE@gDRg4>4?p(@qYNKkKBNZv=~#j4=l^lb)-ziC)ZH$`SS8Lcx%dEP%iny{q~;w zaWK-S#trSPgvUv{p)MBB0@Dvaqn6QkJqfD>Gnln`!oS#pP)0Ew9*52HxzGroB zO~<)-d+Upg-+t_LP9jSNp_Vwhu(+{d(w-8y%htKiJT6JMZftKbRX~MrpV_W=>tu%kxiOswhXOAp5?W45cgJ(eMHcwM+~T||!VLEC;CJ(I zLX_x%vTv6)ASZ}!<&Op3yokR1?uJhHp??lpXYU~&mM}Z_OsmooarLNse0->|nH_Qe z*{Lanbd@aq21;21)*Nv(J+aTQp3wa>aOGs;W#yqz%2}4NX(0~%-c#U0U+E?(abB`L z50~|0eVc-sLOEwi)O#6-`OW(b=u;&IQtb*ZwBPJZENBUdR!ZKEsDFC&oUl;%*x}{0 z_!yM3_X>DFFg-^EawT`33bZZqDX^{5N>(U2H^^Fk{eJ*G4j@bb From 4bb9a3a6af602f6a26ab88104935ba862868f7c1 Mon Sep 17 00:00:00 2001 From: jianglingxia Date: Tue, 28 Feb 2017 14:34:01 +0800 Subject: [PATCH 212/213] kubeadm reference -- / set up/manage mean set up or manage ? it's better use or? --- docs/admin/kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/admin/kubeadm.md b/docs/admin/kubeadm.md index 24f39217f0..2145b75310 100644 --- a/docs/admin/kubeadm.md +++ b/docs/admin/kubeadm.md @@ -31,7 +31,7 @@ server, as well as an additional kubeconfig file for administration. controller manager and scheduler, and placing them in `/etc/kubernetes/manifests`. The kubelet watches this directory for static resources to create on startup. These are the core components of Kubernetes, and -once they are up and running we can use `kubectl` to set up/manage any +once they are up and running we can use `kubectl` to set up or manage any additional components. 1. kubeadm installs any add-on components, such as DNS or discovery, via the API From 04f2e50caa59ebcfb5db461f65b6733bbf8f2a9e Mon Sep 17 00:00:00 2001 From: Philipp T Date: Tue, 28 Feb 2017 21:53:38 +0100 Subject: [PATCH 213/213] missing word The return of the OCD. --- 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 8e738e809e..39e44fbc97 100644 --- a/docs/concepts/index.md +++ b/docs/concepts/index.md @@ -8,7 +8,7 @@ The Concepts section helps you learn about the parts of the Kubernetes system an To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state. -Once you've set your desired state, the *Kubernetes Control Plane* works to make the cluster's current state match the desired state. To do so, Kuberentes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection processes running on your cluster: +Once you've set your desired state, the *Kubernetes Control Plane* works to make the cluster's current state match the desired state. To do so, Kuberentes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster: * The **Kubernetes Master** is a collection of four processes that run on a single node in your cluster, which is designated as the master node. * Each individual non-master node in your cluster runs two processes:

unschedulable

Unschedulable controls node schedulability of new pods. By default, node is schedulable. More info: http://releases.k8s.io/HEAD/docs/admin/node.md#manual-node-administration"

Unschedulable controls node schedulability of new pods. By default, node is schedulable. More info: http://releases.k8s.io/HEAD/docs/admin/node.md#manual-node-administration

false

boolean

false

nodeSelector

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/README

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection

false

object

nodeSelector

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/README

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection

false

object

nodeSelector

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/README

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection

false

object

nodeSelector

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/README

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection

false

object

nodeSelector

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/README

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection

false

object
nodeSelector
object		NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/READMENodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection
restartPolicy
string

nodeSelector

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/README

NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node’s labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection

false

object
nodeSelector
object		NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection/READMENodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. More info: http://kubernetes.io/docs/user-guide/node-selection
restartPolicy
string