Merge branch 'master' into release-1.9

Weekly maintenance 11/22/17
2017-11-22 14:45:43 -06:00
parent 6154442c33 c5319e204b
commit 5de50c956c
74 changed files with 2801 additions and 1034 deletions
@@ -293,14 +293,17 @@ The redirect capabilities have been deprecated and removed.  Please use a proxy

 There are several different proxies you may encounter when using Kubernetes:

-  1. The [kubectl proxy](#directly-accessing-the-rest-api):
+1.  The [kubectl proxy](#directly-accessing-the-rest-api):
+  
    - runs on a user's desktop or in a pod
    - proxies from a localhost address to the Kubernetes apiserver
    - client to proxy uses HTTP
    - proxy to apiserver uses HTTPS
    - locates apiserver
    - adds authentication headers
-  1. The [apiserver proxy](#discovering-builtin-services):
+    
+1.  The [apiserver proxy](#discovering-builtin-services):
+  
    - is a bastion built into the apiserver
    - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
    - runs in the apiserver processes
@@ -308,17 +311,23 @@ There are several different proxies you may encounter when using Kubernetes:
    - proxy to target may use HTTP or HTTPS as chosen by proxy using available information
    - can be used to reach a Node, Pod, or Service
    - does load balancing when used to reach a Service
-  1. The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+    
+1.  The [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips):
+  
    - runs on each node
    - proxies UDP and TCP
    - does not understand HTTP
    - provides load balancing
    - is just used to reach services
-  1. A Proxy/Load-balancer in front of apiserver(s):
+    
+1.  A Proxy/Load-balancer in front of apiserver(s):
+  
    - existence and implementation varies from cluster to cluster (e.g. nginx)
    - sits between all clients and one or more apiservers
    - acts as load balancer if there are several apiservers.
-  1. Cloud Load Balancers on external services:
+    
+1.  Cloud Load Balancers on external services:
+  
    - are provided by some cloud providers (e.g. AWS ELB, Google Cloud Load Balancer)
    - are created automatically when the Kubernetes service has type `LoadBalancer`
    - use UDP/TCP only
@@ -53,7 +53,7 @@ cluster/gce/upgrade.sh release/stable

 Google Kubernetes Engine automatically updates master components (e.g. `kube-apiserver`, `kube-scheduler`) to the latest version. It also handles upgrading the operating system and other components that the master runs on.

-The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine//docs/clusters/upgrade).
+The node upgrade process is user-initiated and is described in the [Google Kubernetes Engine documentation](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade).

 ### Upgrading clusters on other platforms

@@ -79,6 +79,11 @@ CPU request and limit to the Container.

 * Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.

+**Note:** When creating a `LimitRange` object, you can specify limits on huge-pages
+or GPUs as well. However, when both `default` and `defaultRequest` are specified
+on these resources, the two values must be the same.
+{: .note}
+
 Here's the configuration file for a Pod that has one Container. The Container manifest
 specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the
 minimum and maximum CPU constraints imposed by the LimitRange.
@@ -300,6 +300,6 @@ Check that:
 {% capture whatsnext %}
 *  If you need assistance, use one of the [support channels](/docs/tasks/debug-application-cluster/troubleshooting/) to seek assistance.
 *  For details about use cases that motivated this work, see
- [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation/federation.md).
+ [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md).
 {% endcapture %}
 {% include templates/task.md %}
@@ -252,7 +252,7 @@ you can use to more precisely control the behavior of liveness and readiness
 checks:

 * `initialDelaySeconds`: Number of seconds after the container has started
-before liveness probes are initiated.
+before liveness or readiness probes are initiated.
 * `periodSeconds`: How often (in seconds) to perform the probe. Default to 10
 seconds. Minimum value is 1.
 * `timeoutSeconds`: Number of seconds after which the probe times out. Defaults
@@ -261,7 +261,7 @@ to 1 second. Minimum value is 1.
 considered successful after having failed. Defaults to 1. Must be 1 for
 liveness. Minimum value is 1.
 * `failureThreshold`: When a Pod starts and the probe fails, Kubernetes will
-try `failureThreshold` times before giving up and restarting the Pod.
+try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the Pod. In case of readiness probe the Pod will be marked Unready.
 Defaults to 3. Minimum value is 1.

 [HTTP probes](/docs/api-reference/{{page.version}}/#httpgetaction-v1-core)
@@ -75,25 +75,36 @@ only the termination message:
 {% raw %}  kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"{% endraw %}
 ```

-## Setting the termination log file
+## Customizing the termination message

-By default Kubernetes retrieves termination messages from
-`/dev/termination-log`. To change this to a different file,
-specify a `terminationMessagePath` field for your Container.
+Kubernetes retrieves termination messages from the termination message file
+specified in the `terminationMessagePath` field of a Container, which as a default
+value of `/dev/termination-log`. By customizing this field, you can tell Kubernetes
+to use a different file. Kubernetes use the contents from the specified file to
+populate the Container's status message on both success and failure.

-For example, suppose your Container writes termination messages to
-`/tmp/my-log`, and you want Kubernetes to retrieve those messages.
-Set `terminationMessagePath` as shown here:
+In the following example, the container writes termination messages to
+`/tmp/my-log` for Kubernetes to retrieve:

-    apiVersion: v1
-    kind: Pod
-    metadata:
-      name: msg-path-demo
-    spec:
-      containers:
-      - name: msg-path-demo-container
-        image: debian
-        terminationMessagePath: "/tmp/my-log"
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: msg-path-demo
+spec:
+  containers:
+  - name: msg-path-demo-container
+    image: debian
+    terminationMessagePath: "/tmp/my-log"
+```
+
+Moreover, users can set the `terminationMessagePolicy` field of a Container for
+further customization. This field defaults to "`File`" which means the termination
+messages are retrieved only from the termination message file. By setting the
+`terminationMessagePolicy` to "`FallbackToLogsOnError`", you can tell Kubernetes
+to use the last chunk of container log output if the termination message file
+is empty and the container exited with an error. The log output is limited to
+2048 bytes or 80 lines, whichever is smaller.

 {% endcapture %}

@@ -380,4 +380,4 @@ Check that:

 ## For more information

- * [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/federation/federation.md) details use cases that motivated this work.
+ * [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) details use cases that motivated this work.
@@ -493,5 +493,8 @@ federation control plane's etcd. You can delete the federation
 namespace by running the following command:

 ```
-kubectl delete ns federation-system
+kubectl delete ns federation-system --context=rivendell
 ```
+
+Note that `rivendell` is the host cluster name, replace that with the appropriate name in your configuration.
+
@@ -149,7 +149,7 @@ spec:
 - Support for hardware accelerators is in its early stages in Kubernetes.
 - GPUs and other accelerators will soon be a native compute resource across the system.
 - Better APIs will be introduced to provision and consume accelerators in a scalable manner.
- Kubernetes will automatically ensure that applications consuming GPUs gets the best possible performance.
+- Kubernetes will automatically ensure that applications consuming GPUs get the best possible performance.
 - Key usability problems like access to CUDA libraries will be addressed.

 {% endcapture %}
@@ -0,0 +1,100 @@
+---
+title: Install Service Catalog using Helm
+approvers:
+- chenopis
+---
+
+{% capture overview %}
+{% glossary_definition term_id="service-catalog" length="long" %}
+
+Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) repo.
+
+{% endcapture %}
+
+
+{% capture prerequisites %}
+* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
+* Service Catalog requires a Kubernetes cluster running version 1.7 or higher.
+* You must have a Kubernetes cluster with cluster DNS enabled.
+    * If you are using a cloud-based Kubernetes cluster or {% glossary_tooltip text="Minikube" term_id="minikube" %}, you may already have cluster DNS enabled.
+    * If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script.
+* [Install and setup kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
+* Install [Helm](http://helm.sh/) v2.7.0 or newer.
+    * Follow the [Helm install instructions](https://github.com/kubernetes/helm/blob/master/docs/install.md).
+    * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
+
+{% endcapture %}
+
+
+{% capture steps %}
+## Add the service-catalog Helm repository
+
+Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
+
+```shell
+helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
+```
+
+Check to make sure that it installed successfully by executing the following command:
+
+```shell
+helm search service-catalog
+```
+
+If the installation was successful, the command should output the following:
+
+```
+NAME            VERSION DESCRIPTION
+svc-cat/catalog 0.0.1   service-catalog API server and controller-manag...
+```
+
+## Enable RBAC
+
+Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access.
+
+If you are using {% glossary_tooltip text="Minikube" term_id="minikube" %}, run the `minikube start` command with the following flag:
+
+```shell
+minikube start --extra-config=apiserver.Authorization.Mode=RBAC
+```
+
+If you are using `hack/local-up-cluster.sh`, set the `AUTHORIZATION_MODE` environment variable with the following values:
+
+```
+AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
+```
+
+By default, `helm init` installs the Tiller Pod into the `kube-system` namespace, with Tiller configured to use the `default` service account.
+
+**NOTE:** If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
+{: .note}
+
+Configure Tiller to have `cluster-admin` access:
+
+```shell
+kubectl create clusterrolebinding tiller-cluster-admin \
+    --clusterrole=cluster-admin \
+    --serviceaccount=kube-system:default
+```
+
+
+## Install Service Catalog in your Kubernetes cluster
+
+Install Service Catalog from the root of the Helm repository using the following command:
+
+```shell
+helm install svc-cat/catalog \
+    --name catalog --namespace catalog
+```
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
+* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
+
+{% endcapture %}
+
+
+{% include templates/task.md %}
@@ -0,0 +1,77 @@
+---
+title: Install Service Catalog using SC
+approvers:
+- chenopis
+---
+
+{% capture overview %}
+{% glossary_definition term_id="service-catalog" length="long" %}
+
+Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) tool to easily install or uninstall Service Catalog on your Kubernetes cluster. This CLI tool is installed as `sc` in your local environment.
+
+{% endcapture %}
+
+
+{% capture prerequisites %}
+* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
+* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
+* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts. 
+* Service Catalog requires Kubernetes version 1.7+.
+* [Install and setup kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
+* The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command:
+
+        kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
+
+{% endcapture %}
+
+
+{% capture steps %}
+## Install `sc` in your local environment
+
+Install the `sc` CLI tool using the `go get` command:
+
+```Go
+go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
+```
+
+After running the above command, `sc` should be installed in your `GOPATH/bin` directory.
+
+## Install Service Catalog in your Kubernetes cluster
+
+First, verify that all dependencies have been installed. Run:
+
+```shell
+sc check
+```
+
+If the check is successful, it should return: 
+
+```
+Dependency check passed. You are good to go.
+``` 
+
+Next, run the install command and specify the `storageclass` that you want to use for the backup:
+
+```shell
+sc install --etcd-backup-storageclass "standard"
+```
+
+## Uninstall Service Catalog
+
+If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run:
+
+```shell
+sc uninstall
+```
+
+{% endcapture %}
+
+
+{% capture whatsnext %}
+* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
+* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
+
+{% endcapture %}
+
+
+{% include templates/task.md %}