Merge branch 'master' into dev-1.15

Author: makoscafee

content/en/docs/concepts/cluster-administration/addons.md

@@ -44,6 +44,10 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
 * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes.
 * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself.
 
+## Infrastructure
+
+* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) is an add-on to run virtual machines on Kubernetes. Usually run on bare-metal clusters.
+
 ## Legacy Add-ons
 
 There are several other add-ons documented in the deprecated [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) directory.

content/en/docs/concepts/configuration/manage-compute-resources-container.md

@@ -212,10 +212,10 @@ You can check node capacities and amounts allocated with the
 `kubectl describe nodes` command. For example:
 
 ```shell
-kubectl describe nodes e2e-test-minion-group-4lw4
+kubectl describe nodes e2e-test-node-pool-4lw4
 ```
 ```
-Name:            e2e-test-minion-group-4lw4
+Name:            e2e-test-node-pool-4lw4
 [ ... lines removed for clarity ...]
 Capacity:
  cpu:                               2

content/en/docs/concepts/overview/what-is-kubernetes.md

@@ -144,7 +144,7 @@ kind: StatefulSet
 metadata:
   labels:
     app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
     app.kubernetes.io/managed-by: helm
     app.kubernetes.io/component: database
     app.kubernetes.io/part-of: wordpress
@@ -160,7 +160,7 @@ kind: Service
 metadata:
   labels:
     app.kubernetes.io/name: mysql
-    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/instance: mysql-abcxzy
     app.kubernetes.io/managed-by: helm
     app.kubernetes.io/component: database
     app.kubernetes.io/part-of: wordpress
@@ -170,4 +170,4 @@ metadata:
 
 With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and Wordpress, the broader application, are included.
 
-{{% /capture %}}
+{{% /capture %}}

content/en/docs/concepts/overview/working-with-objects/common-labels.md

@@ -26,6 +26,21 @@ See the [identifiers design doc](https://git.k8s.io/community/contributors/desig
 
 By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, `-`, and `.`, but certain resources have more specific restrictions.
 
+For example, here’s the configuration file with a Pod name as `nginx-demo` and a Container name as `nginx`:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx-demo
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.7.9
+    ports:
+    - containerPort: 80
+```
+
 ## UIDs
 
 {{< glossary_definition term_id="uid" length="all" >}}

content/en/docs/concepts/overview/working-with-objects/names.md

@@ -485,8 +485,10 @@ spec:
 minimum value of the first range as the default. Validates against all ranges.
 - *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero
 `runAsUser` or have the `USER` directive defined (using a numeric UID) in the
-image. No default provided. Setting `allowPrivilegeEscalation=false` is strongly
-recommended with this strategy.
+image. Pods which have specified neither `runAsNonRoot` nor `runAsUser` settings
+will be mutated to set `runAsNonRoot=true`, thus requiring a defined non-zero 
+numeric `USER` directive in the container. No default provided. Setting 
+`allowPrivilegeEscalation=false` is strongly recommended with this strategy.
 - *RunAsAny* - No default provided. Allows any `runAsUser` to be specified.
 
 **RunAsGroup** - Controls which primary group ID the containers are run with.

content/en/docs/concepts/policy/pod-security-policy.md

@@ -66,10 +66,8 @@ The following resource types are supported:
 
 | Resource Name | Description |
 | --------------------- | ----------------------------------------------------------- |
-| `cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `limits.cpu` | Across all pods in a non-terminal state, the sum of CPU limits cannot exceed this value. |
 | `limits.memory` | Across all pods in a non-terminal state, the sum of memory limits cannot exceed this value. |
-| `memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
 | `requests.cpu` | Across all pods in a non-terminal state, the sum of CPU requests cannot exceed this value. |
 | `requests.memory` | Across all pods in a non-terminal state, the sum of memory requests cannot exceed this value. |
 

content/en/docs/concepts/policy/resource-quotas.md

@@ -41,11 +41,11 @@ For more up-to-date specification, see
 ### A records
 
 "Normal" (not headless) Services are assigned a DNS A record for a name of the
-form `my-svc.my-namespace.svc.cluster.local`.  This resolves to the cluster IP
+form `my-svc.my-namespace.svc.cluster-domain.example`.  This resolves to the cluster IP
 of the Service.
 
 "Headless" (without a cluster IP) Services are also assigned a DNS A record for
-a name of the form `my-svc.my-namespace.svc.cluster.local`.  Unlike normal
+a name of the form `my-svc.my-namespace.svc.cluster-domain.example`.  Unlike normal
 Services, this resolves to the set of IPs of the pods selected by the Service.
 Clients are expected to consume the set or else use standard round-robin
 selection from the set.
@@ -55,12 +55,12 @@ selection from the set.
 SRV Records are created for named ports that are part of normal or [Headless
 Services](/docs/concepts/services-networking/service/#headless-services).
 For each named port, the SRV record would have the form
-`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local`.
+`_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
 For a regular service, this resolves to the port number and the domain name:
-`my-svc.my-namespace.svc.cluster.local`.
+`my-svc.my-namespace.svc.cluster-domain.example`.
 For a headless service, this resolves to multiple answers, one for each pod
 that is backing the service, and contains the port number and the domain name of the pod
-of the form `auto-generated-name.my-svc.my-namespace.svc.cluster.local`.
+of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
 
 ## Pods
 
@@ -76,7 +76,7 @@ the hostname of the pod. For example, given a Pod with `hostname` set to
 The Pod spec also has an optional `subdomain` field which can be used to specify
 its subdomain. For example, a Pod with `hostname` set to "`foo`", and `subdomain`
 set to "`bar`", in namespace "`my-namespace`", will have the fully qualified
-domain name (FQDN) "`foo.bar.my-namespace.svc.cluster.local`".
+domain name (FQDN) "`foo.bar.my-namespace.svc.cluster-domain.example`".
 
 Example:
 
@@ -133,7 +133,7 @@ record for the Pod's fully qualified hostname.
 For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to
 "`default-subdomain`", and a headless Service named "`default-subdomain`" in
 the same namespace, the pod will see its own FQDN as
-"`busybox-1.default-subdomain.my-namespace.svc.cluster.local`". DNS serves an
+"`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an
 A record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
 "`busybox2`" can have their distinct A records.
 
@@ -143,7 +143,7 @@ along with its IP.
 {{< note >}}
 Because A records are not created for Pod names, `hostname` is required for the Pod's A
 record to be created. A Pod with no `hostname` but with `subdomain` will only create the
-A record for the headless service (`default-subdomain.my-namespace.svc.cluster.local`),
+A record for the headless service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
 pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a
 record unless `publishNotReadyAddresses=True` is set on the Service.
 {{< /note >}}
@@ -234,7 +234,7 @@ in its `/etc/resolv.conf` file:
 
 ```
 nameserver 1.2.3.4
-search ns1.svc.cluster.local my.dns.search.suffix
+search ns1.svc.cluster-domain.example my.dns.search.suffix
 options ndots:2 edns0
 ```
 
@@ -246,7 +246,7 @@ kubectl exec -it dns-example -- cat /etc/resolv.conf
 The output is similar to this:
 ```shell
 nameserver fd00:79:30::a
-search default.svc.cluster.local svc.cluster.local cluster.local
+search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
 options ndots:5
 ```
 

content/en/docs/concepts/services-networking/dns-pod-service.md

@@ -55,7 +55,7 @@ within a cluster. When you create an ingress, you should annotate each ingress w
 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 
 to indicate which ingress controller should be used if more than one exists within your cluster.
 
-If you do not define a class, your cloud provider may use a default ingress provider.
+If you do not define a class, your cloud provider may use a default ingress controller.
 
 Ideally, all ingress controllers should fulfill this specification, but the various ingress
 controllers operate slightly differently.

content/en/docs/concepts/services-networking/ingress-controllers.md

@@ -230,12 +230,13 @@ allows you to still view the logs of completed pods to check for errors, warning
 The job object also remains after it is completed so that you can view its status.  It is up to the user to delete
 old jobs after noting their status.  Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too.
 
-By default, a Job will run uninterrupted unless a Pod fails, at which point the Job defers to the
-`.spec.backoffLimit` described above. Another way to terminate a Job is by setting an active deadline.
-Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds.
+By default, a Job will run uninterrupted unless a Pod fails (`restartPolicy=Never`) or a Container exits in error (`restartPolicy=OnFailure`), at which point the Job defers to the
+`.spec.backoffLimit` described above. Once `.spec.backoffLimit` has been reached the Job will be marked as failed and any running Pods will be terminated.
 
+Another way to terminate a Job is by setting an active deadline.
+Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds.
 The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created.
-Once a Job reaches `activeDeadlineSeconds`, all of its Pods are terminated and the Job status will become `type: Failed` with `reason: DeadlineExceeded`.
+Once a Job reaches `activeDeadlineSeconds`, all of its running Pods are terminated and the Job status will become `type: Failed` with `reason: DeadlineExceeded`.
 
 Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached.