Merge branch 'master' into release-1.8

_redirects

@@ -147,7 +147,9 @@
 /docs/user-guide/connecting-to-applications-proxy				/docs/tasks/access-kubernetes-api/http-proxy-access-api		301
 /docs/user-guide/container-environment							/docs/concepts/containers/container-lifecycle-hooks		301
 /docs/user-guide/cron-jobs										/docs/concepts/workloads/controllers/cron-jobs		301
-/docs/user-guide/debugging-pods-and-replication-controllers		/docs/tasks/debug-application-cluster/debug-pod-replication-controller		301
+
+/docs/user-guide/debugging-pods-and-replication-controllers/	/docs/tasks/debug-application-cluster/debug-pod-replication-controller/		301
+
 /docs/user-guide/debugging-services								/docs/tasks/debug-application-cluster/debug-service		301
 /docs/user-guide/deploying-applications							/docs/tasks/run-application/run-stateless-application-deployment		301
 /docs/user-guide/deployments									/docs/concepts/workloads/controllers/deployment		301

cn/docs/concepts/example-concept-template.md

@@ -0,0 +1,36 @@
+---
+title: 概念模板示例
+approvers:
+- chenopis
+---
+
+{% capture overview %}
+
+**注意:** 注意为新文档 [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) 。
+
+本页解释了 ...
+
+{% endcapture %}
+
+{% capture body %}
+
+## 了解 ...
+
+Kubernetes 提供 ...
+
+## 使用 ...
+
+使用 ...
+
+{% endcapture %}
+
+{% capture whatsnext %}
+
+**[可选章节]**
+
+* 了解更多 [Writing a New Topic](/docs/home/contribute/write-new-topic/)。
+* 查看 [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) 了解如何使用本模板。
+
+{% endcapture %}
+
+{% include templates/concept.md %}

cn/docs/user-guide/kubectl-overview.md

@@ -0,0 +1,289 @@
+---
+approvers:
+- bgrant0607
+- hw-qiaolei
+title：kubectl概述
+---
+kubectl是用于针对Kubernetes集群运行命令的命令行接口。本概述涵盖`kubectl`语法，描述命令操作，并提供常见的示例。有关每个命令的详细信息，包括所有支持的flags和子命令，请参考[kubectl](/docs/user-guide/kubectl)相关文档。有关安装说明，请参阅[安装kubectl](/docs/tasks/kubectl/install/)。
+
+## 语法
+从您的终端窗口使用以下语法运行`kubectl`命令：
+
+```shell
+kubectl [command] [TYPE] [NAME] [flags]
+```
+
+其中command，TYPE，NAME，和flags分别是：
+
+* `command`: 指定要在一个或多个资源进行操作，例如`create`，`get`，`describe`，`delete`。
+
+* `TYPE`：指定[资源类型](#资源类型)。资源类型区分大小写，您可以指定单数，复数或缩写形式。例如，以下命令产生相同的输出：
+
+    $ kubectl get pod pod1
+    $ kubectl get pods pod1
+    $ kubectl get po pod1
+   
+`NAME`：指定资源的名称。名称区分大小写。如果省略名称，则会显示所有资源的详细信息,比如`$ kubectl get pods`。
+
+   在多个资源上执行操作时，可以按类型和名称指定每个资源，或指定一个或多个文件：
+
+   * 按类型和名称指定资源：
+   
+        * 要分组资源，如果它们都是相同的类型：`TYPE1 name1 name2 name<#>`.<br/>
+        例: `$ kubectl get pod example-pod1 example-pod2`
+
+        * 要分别指定多种资源类型:  `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`.<br/>
+        例: `$ kubectl get pod/example-pod1 replicationcontroller/example-rc1`
+        
+     使用一个或多个文件指定资源： `-f file1 -f file2 -f file<#>` 使用[YAML而不是JSON](/docs/concepts/configuration/overview/#general-config-tips)，因为YAML往往更加用户友好，特别是对于配置文件。<br/>
+     例：$ kubectl get pod -f ./pod.yaml
+
+* flags：指定可选标志。例如，您可以使用`-s`或`--serverflags`来指定Kubernetes API服务器的地址和端口。
+**重要提示**：从命令行指定的标志将覆盖默认值和任何相应的环境变量。
+
+如果您需要帮助，只需从终端窗口运行`kubectl help`。
+
+## 操作
+
+下表包括所有kubectl操作的简短描述和一般语法：
+
+Operation       | Syntax    |       Description
+-------------------- | -------------------- | --------------------
+`annotate`    | `kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | 添加或更新一个或多个资源的注解。
+`api-versions`    | `kubectl api-versions [flags]` | 列出可用的API版本。
+`apply`            | `kubectl apply -f FILENAME [flags]`| 对文件或标准输入流更改资源应用配置。
+`attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | attach 到正在运行的容器来查看输出流或与容器（stdin）进行交互。
+`autoscale`    | `kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]` | 自动弹性伸缩一组被replication controller管理的pods。
+`cluster-info`    | `kubectl cluster-info [flags]` | 显示有关集群中master节点和服务的端点信息。
+`config`        | `kubectl config SUBCOMMAND [flags]` | 修改kubeconfig文件。有关详细信息，请参阅各个子命令。
+`create`        | `kubectl create -f FILENAME [flags]` | 从文件或stdin创建一个或多个资源。
+`delete`        | `kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags]` | 从文件，stdin或指定selector，名称，资源选择器或资源中删除资源。
+`describe`    | `kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags]` | 显示一个或多个资源的详细状态。
+`edit`        | `kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags]` | 使用默认编辑器编辑和更新服务器上一个或多个资源的定义。
+`exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 对pod中的容器执行命令
+`explain`    | `kubectl explain [--include-extended-apis=true] [--recursive=false] [flags]` | 获取各种资源的文档。例如 pods, nodes, services 等.
+`expose`        | `kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [----external-ip=external-ip-of-service] [--type=type] [flags]` | 将暴露replication controller, service, 或者pod为新的Kubernetes服务。
+`get`        | `kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]` | 列出一个或多个资源。
+`label`        | `kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]` | 添加或更新一个或多个资源的标签
+`logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 在pod的容器中打印日志。
+`patch`        | `kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]` | 使用strategic merge patch程序更新资源的一个或多个字段。
+`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 将一个或多个本地端口转发到pod。
+`proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 运行一个代理到Kubernetes API服务器。
+`replace`        | `kubectl replace -f FILENAME` | 从文件或stdin替换资源。
+`rolling-update`    | `kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [flags]` | 通过逐步替换指定的replication controller及其pod来执行滚动更新。
+`run`        | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] [flags]` | 在集群上运行指定的镜像。
+`scale`        | `kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]` | 更新指定replication controller的副本数量。
+`stop`        | `kubectl stop` | 已弃用: 相应的, 请查看 `kubectl delete`.
+`version`        | `kubectl version [--client] [flags]` | 显示在客户端和服务器上运行的Kubernetes版本。
+
+请记住：有关命令操作的更多信息，请参阅[kubectl](/docs/user-guide/kubectl)参考文档。
+
+## 资源类型
+
+下表包括所有支持的资源类型及其缩写别名的列表：
+
+资源类型    | 缩写别名
+-------------------- | --------------------
+`apiservices` |
+`certificatesigningrequests` |`csr`
+`clusters` |
+`clusterrolebindings` |
+`clusterroles` |
+`componentstatuses` |`cs`
+`configmaps` |`cm`
+`controllerrevisions` |
+`cronjobs` |
+`customresourcedefinition` |`crd`
+`daemonsets` |`ds`
+`deployments` |`deploy`
+`endpoints` |`ep`
+`events` |`ev`
+`horizontalpodautoscalers` |`hpa`
+`ingresses` |`ing`
+`jobs` |
+`limitranges` |`limits`
+`namespaces` |`ns`
+`networkpolicies` |`netpol`
+`nodes` |`no`
+`persistentvolumeclaims` |`pvc`
+`persistentvolumes` |`pv`
+`poddisruptionbudget` |`pdb`
+`podpreset` |
+`pods` |`po`
+`podsecuritypolicies` |`psp`
+`podtemplates` |
+`replicasets` |`rs`
+`replicationcontrollers` |`rc`
+`resourcequotas` |`quota`
+`rolebindings` |
+`roles` |
+`secrets` |
+`serviceaccounts` |`sa`
+`services` |`svc`
+`statefulsets` |
+`storageclasses` |
+
+## 输出选项
+请使用以下部分查看如何格式化或排序某些命令的输出的信息，有关哪些命令支持各种输出选项的详细信息，请参阅[kubectl](/docs/user-guide/kubectl)参考文档。
+
+### 格式化输出
+
+所有kubectl命令的默认输出格式是可读的纯文本格式。要以特定格式将详细信息输出到终端窗口，您可以将一个`-o`或多个`-output`标志添加到支持的`kubectl`命令中。
+
+#### 语法
+
+```shell
+kubectl [command] [TYPE] [NAME] -o=<output_format>
+```
+
+根据kubectl操作，支持以下输出格式:
+
+输出格式 | 描述
+--------------| -----------
+`-o=custom-columns=<spec>` | 输入使用逗号分隔的列表打印表格 [custom columns](#custom-columns)。
+`-o=custom-columns-file=<filename>` | 使用文件中的[自定义列模板](#custom-columns)打印表`<filename>`。
+`-o=json`     | 输出JSON格式的API对象。
+`-o=jsonpath=<template>` | 打印在[jsonpath](/docs/user-guide/jsonpath)表达式中定义的字段
+`-o=jsonpath-file=<filename>` | 打印由文件中的[jsonpath](/docs/user-guide/jsonpath)表达式定义的字段`<filename>`。
+`-o=name`     | 仅打印资源名称，没有其他的。
+`-o=wide`     | 以纯文本格式输出任何附加信息。对于pod，包括节点名称。
+`-o=yaml`     | 输出YAML格式的API对象。
+
+例子
+
+在此示例中，以下命令将单个pod的详细信息作为YAML格式化对象输出：
+`$ kubectl get pod web-pod-13je7 -o=yaml`
+记住：有关每个命令支持哪种输出格式的详细信息，请参阅kubectl参考文档。
+
+自定义列
+
+要定义自定义列并仅将所需的详细信息输出到表中，可以使用该custom-columns选项。您可以选择内联定义自定义列或使用模板文件：`-o=custom-columns=<spec>`或`-o=custom-columns-file=<filename>`。
+
+##### 例子
+
+一致：
+
+```shell
+$ kubectl get pods <pod-name> -o=custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
+```
+
+模版文件：
+
+```shell
+$ kubectl get pods <pod-name> -o=custom-columns-file=template.txt
+```
+
+该`template.txt`文件包含：
+
+```
+NAME                    RSRC
+metadata.name           metadata.resourceVersion
+```
+
+运行任一命令的结果是：
+
+```shell
+NAME           RSRC
+submit-queue   610995
+```
+
+### 排序列表对象
+要将对象输出到终端窗口中的排序列表，可以将该`--sort-by`标志添加到支持的`kubectl`命令中。通过使用`--sort-by`标志指定任何数字或字符串字段来对对象进行排序。要指定一个字段，请使用[jsonpath](/docs/user-guide/jsonpath)表达式。
+
+#### 语法
+
+```shell
+kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
+```
+
+##### 例子
+
+打印按名称排序的列表，请运行：
+
+`$ kubectl get pods --sort-by=.metadata.name`
+
+## 示例：常用操作
+
+使用以下一组示例来帮助您熟悉运行常用kubectl操作：
+
+```shell
+// 使用在example-service.yaml中的定义创建一个service.
+$ kubectl create -f example-service.yaml
+
+// 使用在example-controller.yaml中的定义创建一个replication controller.
+$ kubectl create -f example-controller.yaml
+
+// 使用在<directory>目录下的any .yaml, .yml, or .json文件创建对象.
+$ kubectl create -f <directory>
+```
+
+`kubectl get` - 列出一个或更多资源.
+
+```shell
+// 使用文本格式列出所有的pods.
+$ kubectl get pods
+
+// 使用文本格式列出所有的信息，包含一些额外的信息(比如节点名称).
+$ kubectl get pods -o wide
+
+// 使用文本格式列出指定名称的replicationcontroller. 注: 你可以缩短 'replicationcontroller' 资源类型使用别名 'rc'.
+$ kubectl get replicationcontroller <rc-name>
+
+// 使用文本格式列出所有的rc,services.
+$ kubectl get rc,services
+```
+
+```
+`kubectl describe` - 显示一个或多个资源的详情状态.
+
+```shell
+// 显示指定节点名称的详情信息.
+$ kubectl describe nodes <node-name>
+
+// 显示指定pods名称的详情信息.
+$ kubectl describe pods/<pod-name>
+
+// 显示所有被名称为<rc-name>的replication controller管理的所有pods的详情信息.
+// 请记住: 任何被replication controller的pod的名称前缀为replication controller的名称.
+$ kubectl describe pods <rc-name>
+```
+
+`kubectl delete` - 从文件, stdin,或者指定的label selectors, 名称,资源选择器, 或者资源去删除资源.
+
+```shell
+// 通过 pod.yaml 文件中的资源类型和名称删除一个pod.
+$ kubectl delete -f pod.yaml
+
+// 删除所有label名称为name=<label-name>的pods和services.
+$ kubectl delete pods,services -l name=<label-name>
+
+// 删除所有pods.
+$ kubectl delete pods --all
+```
+
+`kubectl exec` - 针对pod中的某个容器执行命令.
+
+```shell
+// 在名称为<pod-name>的pod允许 'date' 命令获得输出. 默认返回的是pod中第一个容器的终端.
+$ kubectl exec <pod-name> date
+
+// 在<pod-name>的pod中的<container-name>容器中运行'date'获取输出.
+$ kubectl exec <pod-name> -c <container-name> date
+
+// 从名称为<pod-name>的pod获取一个交互的终端和运行/bin/bash. 默认返回的是pod中第一个容器的终端.
+$ kubectl exec -ti <pod-name> /bin/bash
+```
+
+`kubectl logs` - 输出一个pod的容器日志.
+
+```shell
+// 从名称为<pod-name>的pod返回日志快照.
+$ kubectl logs <pod-name>
+
+// 从名称为<pod-name>的pod中获取日志流. 这个和Linux命令'tail -f'相似.
+$ kubectl logs -f <pod-name>
+```
+
+## 下一步
+
+开始使用[kubectl](/docs/user-guide/kubectl)命令。

docs/concepts/architecture/nodes.md

@@ -205,7 +205,6 @@ register itself with the API server.  This is the preferred pattern, used by mos
 
 For self-registration, the kubelet is started with the following options:
 
-  - `--api-servers` - Location of the apiservers.
   - `--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.

docs/concepts/configuration/secret.md

@@ -442,7 +442,7 @@ that are considered invalid environment variable names will have those keys
 skipped.  The pod will be allowed to start.  There will be an event whose
 reason is `InvalidVariableNames` and the message will contain the list of
 invalid keys that were skipped. The example shows a pod which refers to the
-default/mysecret ConfigMap that contains 2 invalid keys, 1badkey and 2alsobad.
+default/mysecret that contains 2 invalid keys, 1badkey and 2alsobad.
 
 ```shell
 $ kubectl get events

docs/reference/deprecation-policy.md

@@ -70,41 +70,124 @@ API version at least as stable is released.**
 GA API versions can replace GA API versions as well as beta and alpha API
 versions.  Beta API versions *may not* replace GA API versions.
 
-**Rule #4: Other than the most recent API versions in each track, older API
+**Rule #4a: Other than the most recent API versions in each track, older API
 versions must be supported after their announced deprecation for a duration of
 no less than:**
 
    * **GA: 1 year or 2 releases (whichever is longer)**
-   * **Beta: 3 months or 1 release (whichever is longer)**
+   * **Beta: 6 months or 2 releases (whichever is longer)**
    * **Alpha: 0 releases**
 
-This is best illustrated by example.  Imagine a Kubernetes release, version X,
+NOTE: Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
-which supports a particular API group.  A new Kubernetes release is made every
+resolved, no API versions may be removed.
-approximately 3 months (4 per year).  The following table describes which API
+
-versions are supported in a series of subsequent releases.
+**Rule #4b: The "preferred" API version and the "storage version" for a given
+group may not advance util after a release has been made that supports both the
+new version and the previous version**
+
+Users must be able to upgrade to a new release of Kubernetes and then roll back
+to a previous release, without converting anything to the new API version or
+suffering breakages (unless they explicitly used features only available in the
+newer version).  This is particularly evident in the stored representation of
+objects.
+
+All of this is best illustrated by examples.  Imagine a Kubernetes release,
+version X, which introduces a new API group.  A new Kubernetes release is made
+every approximately 3 months (4 per year).  The following table describes which
+API versions are supported in a series of subsequent releases.
 
 <table>
   <thead>
     <tr>
       <th>Release</th>
       <th>API Versions</th>
+      <th>Preferred/Storage Version</th>
       <th>Notes</th>
     </tr>
   </thead>
   <tbody>
     <tr>
       <td>X</td>
-      <td>v1</td>
+      <td>v1alpha1</td>
+      <td>v1alpha1</td>
       <td></td>
     </tr>
     <tr>
       <td>X+1</td>
-      <td>v1, v2alpha1</td>
+      <td>v1alpha2</td>
-      <td></td>
+      <td>v1alpha2</td>
+      <td>
+        <ul>
+           <li>v1alpha1 is removed, "action required" relnote</li>
+        </ul>
+      </td>
     </tr>
     <tr>
       <td>X+2</td>
-      <td>v1, v2alpha2</td>
+      <td>v1beta1</td>
+      <td>v1beta1</td>
+      <td>
+        <ul>
+          <li>v1alpha2 is removed, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+3</td>
+      <td>v1beta2, v1beta1 (deprecated)</td>
+      <td>v1beta1</td>
+      <td>
+        <ul>
+          <li>v1beta1 is deprecated, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+4</td>
+      <td>v1beta2, v1beta1 (deprecated)</td>
+      <td>v1beta2</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+5</td>
+      <td>v1, v1beta2 (deprecated)</td>
+      <td>v1beta2</td>
+      <td>
+        <ul>
+          <li>v1beta1 is removed, "action required" relnote</li>
+          <li>v1beta2 is deprecated, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+6</td>
+      <td>v1, v1beta2 (deprecated)</td>
+      <td>v1</td>
+      <td>
+        <ul>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+7</td>
+      <td>v1</td>
+      <td>v1</td>
+      <td>
+        <ul>
+          <li>v1beta2 is removed, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+8</td>
+      <td>v2alpha1, v1</td>
+      <td>v1</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>X+9</td>
+      <td>v2alpha2, v1</td>
+      <td>v1</td>
       <td>
         <ul>
            <li>v2alpha1 is removed, "action required" relnote</li>
@@ -112,8 +195,9 @@ versions are supported in a series of subsequent releases.
       </td>
     </tr>
     <tr>
-      <td>X+3</td>
+      <td>X+10</td>
-      <td>v1, v2beta1</td>
+      <td>v2beta1, v1</td>
+      <td>v1</td>
       <td>
         <ul>
           <li>v2alpha2 is removed, "action required" relnote</li>
@@ -121,8 +205,9 @@ versions are supported in a series of subsequent releases.
       </td>
     </tr>
     <tr>
-      <td>X+4</td>
+      <td>X+11</td>
-      <td>v1, v2beta1, v2beta2</td>
+      <td>v2beta2, v2beta1 (deprecated), v1</td>
+      <td>v1</td>
       <td>
         <ul>
           <li>v2beta1 is deprecated, "action required" relnote</li>
@@ -130,19 +215,30 @@ versions are supported in a series of subsequent releases.
       </td>
     </tr>
     <tr>
-      <td>X+5</td>
+      <td>X+12</td>
-      <td>v1, v2, v2beta2</td>
+      <td>v2, v2beta2 (deprecated), v2beta1 (deprecated), v1 (deprecated)</td>
+      <td>v1</td>
       <td>
         <ul>
-          <li>v2beta1 is removed, "action required" relnote</li>
           <li>v2beta2 is deprecated, "action required" relnote</li>
           <li>v1 is deprecated, "action required" relnote</li>
         </ul>
       </td>
     </tr>
     <tr>
-      <td>X+6</td>
+      <td>X+13</td>
-      <td>v1, v2</td>
+      <td>v2, v2beta2 (deprecated), v1 (deprecated)</td>
+      <td>v2</td>
+      <td>
+        <ul>
+          <li>v2beta1 is removed, "action required" relnote</li>
+        </ul>
+      </td>
+    </tr>
+    <tr>
+      <td>X+14</td>
+      <td>v2, v1 (deprecated)</td>
+      <td>v2</td>
       <td>
         <ul>
           <li>v2beta2 is removed, "action required" relnote</li>
@@ -150,17 +246,20 @@ versions are supported in a series of subsequent releases.
       </td>
     </tr>
     <tr>
-      <td>X+7</td>
+      <td>X+15</td>
-      <td>v1, v2</td>
+      <td>v2, v1 (deprecated)</td>
+      <td>v2</td>
       <td></td>
     </tr>
     <tr>
-      <td>X+8</td>
+      <td>X+16</td>
-      <td>v1, v2</td>
+      <td>v2, v1 (deprecated)</td>
+      <td>v2</td>
       <td></td>
     </tr>
     <tr>
-      <td>X+9</td>
+      <td>X+17</td>
+      <td>v2</td>
       <td>v2</td>
       <td>
         <ul>

docs/tasks/access-application-cluster/access-cluster.md

@@ -246,6 +246,16 @@ As mentioned above, you use the `kubectl cluster-info` command to retrieve the s
 
 If you haven't specified a name for your port, you don't have to specify *port_name* in the URL.
 
+By default, the API server proxies to your service using http. To use https, prefix the service name with `https:`:
+`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy`
+
+The supported formats for the name segment of the URL are:
+
+* `<service_name>` - proxies to the default or unnamed port using http
+* `<service_name>:<port_name>` - proxies to the specified port using http
+* `https:<service_name>:` - proxies to the default or unnamed port using https (note the trailing colon)
+* `https:<service_name>:<port_name>` - proxies to the specified port using https
+
 ##### Examples
 
  * To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use:   `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`

docs/tasks/administer-cluster/encrypt-data.md

@@ -14,6 +14,8 @@ This page shows how to enable and configure encryption of secret data at rest.
 
 * Kubernetes version 1.7.0 or later is required
 
+* etcd v3 or later is required
+
 * Encryption at rest is alpha in 1.7.0 which means it may change without notice. Users may be required to decrypt their data prior to upgrading to 1.8.0.
 
 {% endcapture %}

docs/tasks/administer-cluster/highly-available-master.md

@@ -154,5 +154,4 @@ To make such deployment secure, communication between etcd instances is authoriz
 
 ## Additional reading
 
-[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/ha_master.md)
+[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
-

docs/tasks/administer-cluster/memory-constraint-namespace.md

@@ -123,7 +123,7 @@ kubectl delete pod constraints-mem-demo --namespace=constraints-mem-example
 ## Attempt to create a Pod that exceeds the maximum memory constraint
 
 Here's the configuration file for a Pod that has one Container. The Container specifies a
-memory request of 700 MiB and a memory limit of 1.5 GiB.
+memory request of 800 MiB and a memory limit of 1.5 GiB.
 
 {% include code.html language="yaml" file="memory-constraints-pod-2.yaml" ghlink="/docs/tasks/administer-cluster/memory-constraints-pod-2.yaml" %}
 

docs/tasks/administer-cluster/namespaces.md

@@ -63,7 +63,7 @@ to define *Hard* resource usage limits that a *Namespace* may consume.
 A limit range defines min/max constraints on the amount of resources a single entity can consume in
 a *Namespace*.
 
-See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/admission_control_limit_range.md)
+See [Admission control: Limit Range](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
 
 A namespace can be in one of two phases:
 

docs/tasks/debug-application-cluster/debug-stateful-set.md

@@ -18,7 +18,6 @@ This task shows you how to debug a StatefulSet.
 
 {% capture prerequisites %}
 
-
 * You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
 * You should have a StatefulSet running that you want to investigate.
 

docs/tutorials/stateful-application/basic-stateful-set.md

@@ -22,14 +22,14 @@ following Kubernetes concepts.
 * [Pods](/docs/user-guide/pods/single-container/)
 * [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/)
 * [Headless Services](/docs/concepts/services-networking/service/#headless-services)
-* [PersistentVolumes](/docs/concepts/storage/volumes/)
+* [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
 * [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{page.githubbranch}}/staging/persistent-volume-provisioning/)
 * [StatefulSets](/docs/concepts/abstractions/controllers/statefulsets/)
 * [kubectl CLI](/docs/user-guide/kubectl)
 
 This tutorial assumes that your cluster is configured to dynamically provision 
 PersistentVolumes. If your cluster is not configured to do so, you
-will have to manually provision five 1 GiB volumes prior to starting this 
+will have to manually provision two 1 GiB volumes prior to starting this 
 tutorial.
 {% endcapture %}
 
@@ -37,7 +37,7 @@ tutorial.
 StatefulSets are intended to be used with stateful applications and distributed 
 systems. However, the administration of stateful applications and 
 distributed systems on Kubernetes is a broad, complex topic. In order to 
-demonstrate the basic features of a StatefulSet, and to not conflate the former 
+demonstrate the basic features of a StatefulSet, and not to conflate the former 
 topic with the latter, you will deploy a simple web application using a StatefulSet.
 
 After this tutorial, you will be familiar with the following.
@@ -262,8 +262,7 @@ www-web-0   Bound     pvc-15c268c7-b507-11e6-932f-42010a800002   1Gi        RWO
 www-web-1   Bound     pvc-15c79307-b507-11e6-932f-42010a800002   1Gi        RWO           48s
 ```
 The StatefulSet controller created two PersistentVolumeClaims that are 
-bound to two [PersistentVolumes](/docs/concepts/storage/volumes/). As the 
+bound to two [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). As the cluster used in this tutorial is configured to dynamically provision 
-cluster used in this tutorial is configured to dynamically provision 
 PersistentVolumes, the PersistentVolumes were created and bound automatically.
 
 The NGINX webservers, by default, will serve an index file at 
@@ -330,7 +329,7 @@ web-1
 
 Even though `web-0` and `web-1` were rescheduled, they continue to serve their 
 hostnames because the PersistentVolumes associated with their 
-PersistentVolumeClaims are remounted to their `volumeMount`s. No matter what 
+PersistentVolumeClaims are remounted to their `volumeMounts`. No matter what 
 node `web-0`and `web-1` are scheduled on, their PersistentVolumes will be 
 mounted to the appropriate mount points.
 
@@ -338,8 +337,7 @@ mounted to the appropriate mount points.
 Scaling a StatefulSet refers to increasing or decreasing the number of replicas. 
 This is accomplished by updating the `replicas` field. You can use either
 [`kubectl scale`](/docs/user-guide/kubectl/{{page.version}}/#scale) or
-[`kubectl patch`](/docs/user-guide/kubectl/{{page.version}}/#patch) to scale a Stateful 
+[`kubectl patch`](/docs/user-guide/kubectl/{{page.version}}/#patch) to scale a StatefulSet.
-Set.
 
 ### Scaling Up
 
@@ -440,10 +438,7 @@ www-web-4   Bound     pvc-e11bb5f8-b508-11e6-932f-42010a800002   1Gi        RWO
 ```
 
 There are still five PersistentVolumeClaims and five PersistentVolumes. 
-When exploring a Pod's [stable storage](#stable-storage), we saw that the 
+When exploring a Pod's [stable storage](#writing-to-stable-storage), we saw that the PersistentVolumes mounted to the Pods of a StatefulSet are not deleted whenthe StatefulSet's Pods are deleted. This is still true when Pod deletion is caused by scaling the StatefulSet down. 
-PersistentVolumes mounted to the Pods of a StatefulSet are not deleted when 
-the StatefulSet's Pods are deleted. This is still true when Pod deletion is 
-caused by scaling the StatefulSet down. 
 
 ## Updating StatefulSets
 
@@ -721,8 +716,7 @@ automatically update Pods when a modification is made to the StatefulSet's
 ## Deleting StatefulSets
 
 StatefulSet supports both Non-Cascading and Cascading deletion. In a 
-Non-Cascading Delete, the StatefulSet's Pods are not deleted when the Stateful
+Non-Cascading Delete, the StatefulSet's Pods are not deleted when the StatefulSet is deleted. In a Cascading Delete, both the StatefulSet and its Pods are 
-Set is deleted. In a Cascading Delete, both the StatefulSet and its Pods are 
 deleted.
 
 ### Non-Cascading Delete
@@ -866,7 +860,7 @@ web-1     0/1       Terminating   0         29m
 
 ```
 
-As you saw in the [Scaling Down](#ordered-pod-termination) section, the Pods 
+As you saw in the [Scaling Down](#scaling-down) section, the Pods 
 are terminated one at a time, with respect to the reverse order of their ordinal 
 indices. Before terminating a Pod, the StatefulSet controller waits for 
 the Pod's successor to be completely terminated.

docs/user-guide/pod-security-policy/OWNERS.txt

@@ -1,2 +0,0 @@
-approvers:
-- pweil-

docs/user-guide/pod-security-policy/psp.yaml

@@ -1,18 +0,0 @@
-apiVersion: extensions/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  name: permissive
-spec:
-  seLinux:
-    rule: RunAsAny
-  supplementalGroups:
-    rule: RunAsAny
-  runAsUser:
-    rule: RunAsAny
-  fsGroup:
-    rule: RunAsAny
-  hostPorts:
-  - min: 8000
-    max: 8080
-  volumes:
-  - '*'

test/examples_test.go

@@ -234,7 +234,7 @@ func TestExampleObjectSchemas(t *testing.T) {
 			"kitten-rc":   {&api.ReplicationController{}},
 			"nautilus-rc": {&api.ReplicationController{}},
 		},
-		"../docs/user-guide/pod-security-policy": {
+		"../docs/concepts/policy": {
 			"psp": {&extensions.PodSecurityPolicy{}},
 		},
 		"../docs/user-guide/persistent-volumes/volumes": {