Merge branch 'master' of github.com:kubernetes/website

Author: murillodigital

content/en/blog/_posts/2017-03-00-Advanced-Scheduling-In-Kubernetes.md

@@ -20,21 +20,14 @@ For example, if we want to require scheduling on a node that is in the us-centra
 
 
 ```
-affinity:
-
-  nodeAffinity:
-
-    requiredDuringSchedulingIgnoredDuringExecution:
-
-      nodeSelectorTerms:
-
-        - matchExpressions:
-
-          - key: "failure-domain.beta.kubernetes.io/zone"
-
-            operator: In
-
-            values: ["us-central1-a"]
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+          - matchExpressions:
+            - key: "failure-domain.beta.kubernetes.io/zone"
+              operator: In
+              values: ["us-central1-a"]
  ```
 
 
@@ -44,21 +37,14 @@ Preferred rules mean that if nodes match the rules, they will be chosen first, a
 
 
 ```
-affinity:
-
-  nodeAffinity:
-
-    preferredDuringSchedulingIgnoredDuringExecution:
-
-      nodeSelectorTerms:
-
-        - matchExpressions:
-
-          - key: "failure-domain.beta.kubernetes.io/zone"
-
-            operator: In
-
-            values: ["us-central1-a"]
+  affinity:
+    nodeAffinity:
+      preferredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+          - matchExpressions:
+            - key: "failure-domain.beta.kubernetes.io/zone"
+              operator: In
+              values: ["us-central1-a"]
  ```
 
 
@@ -67,21 +53,14 @@ Node anti-affinity can be achieved by using negative operators. So for instance
 
 
 ```
-affinity:
-
-  nodeAffinity:
-
-    requiredDuringSchedulingIgnoredDuringExecution:
-
-      nodeSelectorTerms:
-
-        - matchExpressions:
-
-          - key: "failure-domain.beta.kubernetes.io/zone"
-
-            operator: NotIn
-
-            values: ["us-central1-a"]
+  affinity:
+    nodeAffinity:
+      requiredDuringSchedulingIgnoredDuringExecution:
+        nodeSelectorTerms:
+          - matchExpressions:
+            - key: "failure-domain.beta.kubernetes.io/zone"
+              operator: NotIn
+              values: ["us-central1-a"]
  ```
 
 
@@ -99,23 +78,19 @@ The kubectl command allows you to set taints on nodes, for example:
 
 ```
 kubectl taint nodes node1 key=value:NoSchedule
- ```
+```
 
 
 creates a taint that marks the node as unschedulable by any pods that do not have a toleration for taint with key key, value value, and effect NoSchedule. (The other taint effects are PreferNoSchedule, which is the preferred version of NoSchedule, and NoExecute, which means any pods that are running on the node when the taint is applied will be evicted unless they tolerate the taint.) The toleration you would add to a PodSpec to have the corresponding pod tolerate this taint would look like this  
 
 
 
 ```
-tolerations:
-
-- key: "key"
-
-  operator: "Equal"
-
-  value: "value"
-
-  effect: "NoSchedule"
+  tolerations:
+  - key: "key"
+    operator: "Equal"
+    value: "value"
+    effect: "NoSchedule"
  ```
 
 
@@ -138,21 +113,13 @@ Let’s look at an example. Say you have front-ends in service S1, and they comm
 
 ```
 affinity:
-
     podAffinity:
-
       requiredDuringSchedulingIgnoredDuringExecution:
-
       - labelSelector:
-
           matchExpressions:
-
           - key: service
-
             operator: In
-
             values: [“S1”]
-
         topologyKey: failure-domain.beta.kubernetes.io/zone
  ```
 
@@ -172,25 +139,15 @@ Here we have a Pod where we specify the schedulerName field:
 
 ```
 apiVersion: v1
-
 kind: Pod
-
 metadata:
-
   name: nginx
-
   labels:
-
     app: nginx
-
 spec:
-
   schedulerName: my-scheduler
-
   containers:
-
   - name: nginx
-
     image: nginx:1.10
  ```
 

content/en/docs/concepts/cluster-administration/flow-control.md

@@ -59,7 +59,7 @@ kube-apiserver \
 ```
 
 Alternatively, you can enable the v1alpha1 version of the API group
-with `--runtime-config=flowcontrol.apiserver.k8s.io/v1beta1=true`.
+with `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true`.
 
 The command-line flag `--enable-priority-and-fairness=false` will disable the
 API Priority and Fairness feature, even if other flags have enabled it.

content/en/docs/concepts/extend-kubernetes/operator.md

@@ -124,6 +124,6 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
     you implement yourself
   * using the [Operator Framework](https://operatorframework.io)
 * [Publish](https://operatorhub.io/) your operator for other people to use
-* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
+* Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern (this is an archived version of the original article).
 * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
 

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

@@ -58,7 +58,7 @@ Neither contention nor changes to quota will affect already created resources.
 ## Enabling Resource Quota
 
 Resource Quota support is enabled by default for many Kubernetes distributions.  It is
-enabled when the API server `--enable-admission-plugins=` flag has `ResourceQuota` as
+enabled when the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} `--enable-admission-plugins=` flag has `ResourceQuota` as
 one of its arguments.
 
 A resource quota is enforced in a particular namespace when there is a

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

@@ -32,7 +32,7 @@ should range from highly restricted to highly flexible:
 
 - **_Privileged_** - Unrestricted policy, providing the widest possible level of permissions. This
   policy allows for known privilege escalations.
-- **_Baseline/Default_** - Minimally restrictive policy while preventing known privilege
+- **_Baseline_** - Minimally restrictive policy while preventing known privilege
   escalations. Allows the default (minimally specified) Pod configuration.
 - **_Restricted_** - Heavily restricted policy, following current Pod hardening best practices.
 
@@ -48,9 +48,9 @@ mechanisms (such as gatekeeper), the privileged profile may be an absence of app
 rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
 Security Policy) the privileged policy should enable all controls (disable all restrictions).
 
-### Baseline/Default
+### Baseline
 
-The Baseline/Default policy is aimed at ease of adoption for common containerized workloads while
+The Baseline policy is aimed at ease of adoption for common containerized workloads while
 preventing known privilege escalations. This policy is targeted at application operators and
 developers of non-critical applications. The following listed controls should be
 enforced/disallowed:
@@ -115,7 +115,9 @@ enforced/disallowed:
 		<tr>
 			<td>AppArmor <em>(optional)</em></td>
 			<td>
-				On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.<br>
+				On supported hosts, the 'runtime/default' AppArmor profile is applied by default.
+				The baseline policy should prevent overriding or disabling the default AppArmor
+				profile, or restrict overrides to an allowed set of profiles.<br>
 				<br><b>Restricted Fields:</b><br>
 				metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
 				<br><b>Allowed Values:</b> 'runtime/default', undefined<br>
@@ -175,7 +177,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
 			<td><strong>Policy</strong></td>
 		</tr>
 		<tr>
-			<td colspan="2"><em>Everything from the default profile.</em></td>
+			<td colspan="2"><em>Everything from the baseline profile.</em></td>
 		</tr>
 		<tr>
 			<td>Volume Types</td>
@@ -275,7 +277,7 @@ of individual policies are not defined here.
 
 ## FAQ
 
-### Why isn't there a profile between privileged and default?
+### Why isn't there a profile between privileged and baseline?
 
 The three profiles defined here have a clear linear progression from most secure (restricted) to least
 secure (privileged), and cover a broad set of workloads. Privileges required above the baseline

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

@@ -49,6 +49,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy.
 * The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an
   ingress controller for the [Traefik](https://traefik.io/traefik/) proxy.
+* [Tyk Operator](https://github.com/TykTechnologies/tyk-operator) extends Ingress with Custom Resources to bring API Management capabilities to Ingress. Tyk Operator works with the Open Source Tyk Gateway & Tyk Cloud control plane.
 * [Voyager](https://appscode.com/products/voyager) is an ingress controller for
   [HAProxy](https://www.haproxy.org/#desc).
 

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -38,8 +38,7 @@ If a {{< glossary_tooltip term_id="node" >}} dies, the Pods scheduled to that no
 are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
 
 Pods do not, by themselves, self-heal. If a Pod is scheduled to a
-{{< glossary_tooltip text="node" term_id="node" >}} that then fails,
-or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't
+{{< glossary_tooltip text="node" term_id="node" >}} that then fails, the Pod is deleted; likewise, a Pod won't
 survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a
 higher-level abstraction, called a
 {{< glossary_tooltip term_id="controller" text="controller" >}}, that handles the work of

content/en/docs/contribute/localization.md

@@ -267,7 +267,7 @@ Teams must merge localized content into the same release branch from which the c
 
 An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch.
 
-At the beginning of every team milestone, it's helpful to open an issue [comparing upstream changes](https://github.com/kubernetes/website/blob/master/scripts/upstream_changes.py) between the previous development branch and the current development branch.
+At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous development branch and the current development branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch.
 
  While only approvers can open a new development branch and merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required.
 

content/en/docs/contribute/style/style-guide.md

@@ -576,6 +576,10 @@ Avoid making promises or giving hints about the future. If you need to talk abou
 an alpha feature, put the text under a heading that identifies it as alpha
 information.
 
+An exception to this rule is documentation about announced deprecations
+targeting removal in future versions. One example of documentation like this
+is the [Deprecated API migration guide](/docs/reference/using-api/deprecation-guide/).
+
 ### Avoid statements that will soon be out of date
 
 Avoid words like "currently" and "new." A feature that is new today might not be

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -351,7 +351,7 @@ different Kubernetes components.
 | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 |
 | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 |
 | `VolumeScheduling` | `true` | GA | 1.13 | - |
-| `VolumeSubpath` | `true` | GA | 1.13 | - |
+| `VolumeSubpath` | `true` | GA | 1.10 | - |
 | `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 |
 | `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | 1.16 |
 | `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |