[zh] Move kubectl overview to be section index

content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md

@@ -31,7 +31,7 @@ Windows 应用程序构成了许多组织中运行的服务和应用程序的很
 * Configure an example deployment to run Windows containers on the Windows node
 * (Optional) Configure an Active Directory Identity for your Pod using Group Managed Service Accounts (GMSA)
 -->
-## 目标
+## 目标 {#objectives}
 
 * 配置一个示例 deployment 以在 Windows 节点上运行 Windows 容器
 * （可选）使用组托管服务帐户（GMSA）为你的 Pod 配置 Active Directory 身份
@@ -46,13 +46,13 @@ behaves in much the same way for Linux and Windows containers.
 [Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical.
 The example in the section below is provided to jumpstart your experience with Windows containers.
 -->
-## 在你开始之前
+## 在你开始之前 {#before-you-begin}
 
 * 创建一个 Kubernetes 集群，其中包括一个控制平面和
   [运行 Windows 服务器的工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
 * 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes 
   上创建和部署服务和工作负载的行为几乎相同。
-  与集群接口的 [kubectl 命令](/zh/docs/reference/kubectl/overview/)相同。
+  与集群接口的 [kubectl 命令](/zh/docs/reference/kubectl/)相同。
   提供以下部分中的示例只是为了快速启动  Windows 容器的使用体验。
 
 <!--
@@ -62,7 +62,7 @@ To deploy a Windows container on Kubernetes, you must first create an example ap
 The example YAML file below creates a simple webserver application.
 Create a service spec named `win-webserver.yaml` with the contents below:
 -->
-## 入门：部署 Windows 容器
+## 入门：部署 Windows 容器 {#getting-started-deploying-a-windows-container}
 
 要在 Kubernetes 上部署 Windows 容器，你必须首先创建一个示例应用程序。
 下面的示例 YAML  文件创建了一个简单的 Web 服务器应用程序。
@@ -163,13 +163,13 @@ the container port 80 is exposed directly to the service.
    kubectl get pods -o wide -w
    ```
 
-   正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。
+   正确部署服务后，两个 Pod 都标记为 “Ready”。要退出 watch 命令，请按 Ctrl + C。
 
 1. 检查部署是否成功。验证：
 
    * Windows 节点上每个 Pod 有两个容器，使用  `docker ps` 
    * Linux 控制平面节点列出两个 Pod，使用  `kubectl get pods` 
-   * 跨网络的节点到 Pod 通信，从 Linux 控制平面节点 `curl` 你的 pod IPs 的端口80，以检查 Web 服务器响应
+   * 跨网络的节点到 Pod 通信，从 Linux 控制平面节点 `curl` 你的 pod IPs 的端口 80，以检查 Web 服务器响应
    * Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 Pod 之间
      （以及跨主机，如果你有多个 Windows 节点）进行 ping 操作
    * 服务到 Pod 的通信，从 Linux 控制平面节点和各个 Pod 中 `curl` 虚拟服务 IP
@@ -194,7 +194,7 @@ Only Windows pods are able to access service IPs.
 -->
 ## 可观测性  {#observability}
 
-### 抓取来自工作负载的日志
+### 抓取来自工作负载的日志 {#capturing-logs-from-workloads}
 
 <!--
 Logs are an important element of observability; they enable users to gain insights
@@ -238,7 +238,7 @@ with different usernames than the image defaults.
 The way this is achieved is a bit different from the way it is done for Linux containers.
 Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/).
 -->
-## 使用可配置的容器用户名
+## 使用可配置的容器用户名 {#using-configurable-container-usernames}
 
 从 Kubernetes v1.16 开始，可以为 Windows  容器配置与其镜像默认值不同的用户名
 来运行其入口点和进程。
@@ -255,7 +255,7 @@ simplified service principal name (SPN) management, and the ability to delegate
 Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA.
 Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/).
 -->
-## 使用组托管服务帐户管理工作负载身份
+## 使用组托管服务帐户管理工作负载身份 {#managing-workload-identity-with-group-managed-service-accounts}
 
 从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。
 组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理，
@@ -267,7 +267,7 @@ Windows 容器配置和使用 GMSA 的更多信息。
 <!--
 ## Taints and Tolerations
 -->
-## 污点和容忍度
+## 污点和容忍度 {#taints-and-tolerations}
 
 <!--
 Users today need to use some combination of taints and node selectors in order to
@@ -276,7 +276,7 @@ This likely imposes a burden only on Windows users. The recommended approach is
 with one of its main goals being that this approach should not break compatibility for existing Linux workloads.
 -->
 目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，
-因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。
+因而需要结合使用污点和节点选择算符。这可能仅给 Windows 用户造成不便。
 推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。
 <!--
 If the `IdentifyPodOS` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is
@@ -294,14 +294,15 @@ use normal Kubernetes mechanisms for
 [assigning pods to nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
 to ensure that the control plane for your cluster places pods onto nodes that are running the
 appropriate operating system.
+
 The `.spec.os.name` value has no effect on the scheduling of the Windows pods,
 so taints and tolerations and node selectors are still required
  to ensure that the Windows pods land onto appropriate Windows nodes.
  -->
 如果 `IdentifyPodOS` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是启用的，
 你可以（并且应该）为 Pod 设置 `.spec.os.name` 以表明该 Pod
-中的容器所针对的操作系统。 对于运行 Linux 容器的 Pod，设置 
+中的容器所针对的操作系统。对于运行 Linux 容器的 Pod，设置 
-`.spec.os.name` 为 `linux`。 对于运行 Windows 容器的 Pod，设置 `.spec.os.name`
+`.spec.os.name` 为 `linux`。对于运行 Windows 容器的 Pod，设置 `.spec.os.name`
 为 `Windows`。
 
 {{< note >}}
@@ -317,7 +318,7 @@ so taints and tolerations and node selectors are still required
 <!--
 ### Ensuring OS-specific workloads land on the appropriate container host
 -->
-### 确保特定操作系统的工作负载落在适当的容器主机上
+### 确保特定操作系统的工作负载落在适当的容器主机上 {#ensuring-os-specific-workloads-land-on-the-appropriate-container-host}
 
 <!--
 Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations.
@@ -366,19 +367,19 @@ it would need both the nodeSelector and the appropriate matching toleration to c
 
 ```yaml
 nodeSelector:
-  kubernetes.io/os: windows
+    kubernetes.io/os: windows
-  node.kubernetes.io/windows-build: '10.0.17763'
+    node.kubernetes.io/windows-build: '10.0.17763'
 tolerations:
-  - key: "os"
+    - key: "os"
-    operator: "Equal"
+      operator: "Equal"
-    value: "windows"
+      value: "windows"
-    effect: "NoSchedule"
+      effect: "NoSchedule"
 ```
 
 <!--
 ### Handling multiple Windows versions in the same cluster
 -->
-### 处理同一集群中的多个 Windows 版本
+### 处理同一集群中的多个 Windows 版本 {#handling-multiple-windows-versions-in-the-same-cluster}
 
 <!--
 The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows
@@ -392,7 +393,7 @@ nodeSelector。
 Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this.
 If you're running an older version, then it's recommended to add this label manually to Windows nodes.
 -->
-Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 
+Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。
 如果你运行的是旧版本，则建议手动将此标签添加到 Windows 节点。
 
 <!--
@@ -412,7 +413,7 @@ Windows Server 版本使用的值。
 <!--
 ### Simplifying with RuntimeClass
 -->
-### 使用 RuntimeClass 简化
+### 使用 RuntimeClass 简化 {#simplifying-with-runtimeclass}
 
 <!--
 [RuntimeClass] can be used to simplify the process of using taints and tolerations.
@@ -503,3 +504,5 @@ spec:
   selector:
     app: iis-2019
 ```
+
+[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/

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

@@ -34,9 +34,9 @@ or someone else setup the cluster and provided you with credentials and a locati
 
 Check the location and credentials that kubectl knows about with this command:
 -->
-## 使用 kubectl 完成集群的第一次访问
+## 使用 kubectl 完成集群的第一次访问 {#accessing-for-the-first-time-with-kubectl}
 
-当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI，`kubectl`。
+当你第一次访问 Kubernetes API 的时候，我们建议你使用 Kubernetes CLI 工具 `kubectl`。
 
 访问集群时，你需要知道集群的地址并且拥有访问的凭证。通常，这些在你通过
 [启动安装](/zh/docs/setup/)安装集群时都是自动安装好的，或者其他人安装时
@@ -49,11 +49,12 @@ kubectl config view
 ```
 
 <!--
-Many of the [examples](/docs/user-guide/kubectl-cheatsheet) provide an introduction to using
+Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using
-`kubectl` and complete documentation is found in the [kubectl reference](/docs/reference/kubectl/).
+`kubectl`, and complete documentation is found in the
+[kubectl reference](/docs/reference/kubectl/).
 -->
-有许多 [例子](/zh/docs/reference/kubectl/cheatsheet/) 介绍了如何使用 kubectl，
+有许多[例子](/zh/docs/reference/kubectl/cheatsheet/)介绍了如何使用 kubectl，
-可以在 [kubectl 参考](/zh/docs/reference/kubectl/overview/) 中找到更完整的文档。
+可以在 [kubectl 参考](/zh/docs/reference/kubectl/)中找到更完整的文档。
 
 <!--
 ## Directly accessing the REST API
@@ -73,7 +74,7 @@ curl or wget, or a browser, there are several ways to locate and authenticate:
     - Works with some types of client code that are confused by using a proxy.
     - Need to import a root cert into your browser to protect against MITM.
 -->
-## 直接访问 REST API
+## 直接访问 REST API {#directly-accessing-the-rest-api}
 
 Kubectl 处理 apiserver 的定位和身份验证。
 如果要使用 curl 或 wget 等 http 客户端或浏览器直接访问 REST API，可以通过
@@ -97,13 +98,13 @@ The following command runs kubectl in a mode where it acts as a reverse proxy.
 locating the apiserver and authenticating.
 Run it like this:
 -->
-### 使用 kubectl proxy
+### 使用 kubectl proxy {#using-kubectl-proxy}
 
 以下命令以反向代理的模式运行 kubectl。它处理 apiserver 的定位和验证。
 像这样运行：
 
 ```shell
-kubectl proxy --port=8080 &
+kubectl proxy --port=8080
 ```
 
 <!--
@@ -121,6 +122,12 @@ with [::1] for IPv6, like so:
 ```shell
 curl http://localhost:8080/api/
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
 ```json
 {
   "kind": "APIVersions",
@@ -139,18 +146,18 @@ curl http://localhost:8080/api/
 <!--
 ### Without kubectl proxy
 
-In Kubernetes version 1.3 or later, `kubectl config view` no longer displays the token. Use `kubectl apply` and `kubectl describe secret...` to create a token for the default service account with grep/cut:
+Use `kubectl apply` and `kubectl describe secret...` to create a token for the default service account with grep/cut:
 
 First, create the Secret, requesting a token for the default ServiceAccount:
 
 -->
 
-### 不使用 kubectl proxy
+### 不使用 kubectl proxy {#without-kubectl-proxy}
 
-在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。
 使用 `kubectl apply` 和 `kubectl describe secret ...` 及 grep 和剪切操作来为 default 服务帐户创建令牌，如下所示：
-`grep/cut` 方法实现：
+
 首先，创建 Secret，请求默认 ServiceAccount 的令牌：
+
 ```shell
 kubectl apply -f - <<EOF
 apiVersion: v1
@@ -165,10 +172,9 @@ EOF
 
 <!--
 Next, wait for the token controller to populate the Secret with a token:
-
-Capture and use the generated token:
 -->
 接下来，等待令牌控制器使用令牌填充 Secret：
+
 ```shell
 while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
   echo "waiting for token..." >&2
@@ -176,12 +182,22 @@ while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
 done
 ```
 
+<!--
+Capture and use the generated token:
+-->
 捕获并使用生成的令牌：
+
 ```shell
-APISERVER=$(kubectl config view | grep server | cut -f 2- -d ":" | tr -d " ")
+APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
-TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d ' ')
+TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")
 curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
 ```json
 {
   "kind": "APIVersions",
@@ -197,14 +213,22 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 }
 ```
 
+<!--
+Using `jsonpath`:
+-->
 `jsonpath` 方法实现：
 
 ```shell
 APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
-TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode )
+TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
 curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 ```
 
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
 ```json
 {
   "kind": "APIVersions",
@@ -230,9 +254,8 @@ certificate.
 
 On some clusters, the apiserver does not require authentication; it may serve
 on localhost, or be protected by a firewall.  There is not a standard
-for this.  [Configuring Access to the API](/docs/admin/accessing-the-api)
+for this.  [Controlling Access to the API](/docs/concepts/security/controlling-access)
-describes how a cluster admin can configure this.  Such approaches may conflict
+describes how a cluster admin can configure this.
-with future high-availability support.
 -->
 上面的例子使用了 `--insecure` 参数，这使得它很容易受到 MITM 攻击。
 当 kubectl 访问集群时，它使用存储的根证书和客户端证书来访问服务器
@@ -252,26 +275,26 @@ client libraries.
 
 ### Go client
 
-* To get the library, run the following command: `go get k8s.io/client-go/<version number>/kubernetes`. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) to see which versions are supported.
+* To get the library, run the following command: `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`, see [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user) for detailed installation instructions. See [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) 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.
+* 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/kubernetes"` is correct.
 
 The Go client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go).
 
 If the application is deployed as a Pod in the cluster, please refer to the [next section](#accessing-the-api-from-a-pod).
 -->
-## 以编程方式访问 API
+## 以编程方式访问 API {#programmatic-access-to-the-api}
 
 Kubernetes 官方提供对 [Go](#go-client) 和 [Python](#python-client) 的客户端库支持。
 
-### Go 客户端
+### Go 客户端 {#go-client}
 
-* 想要获得这个库，请运行命令：`go get k8s.io/client-go/<version number>/kubernetes`。
+* 想要获得这个库，请运行命令：`go get k8s.io/client-go@kubernetes-<kubernetes-version-number>`，
-  参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go)
+  有关详细安装说明，请参阅 [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)。
-  来查看目前支持哪些版本。
+  请参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix) 以查看支持的版本。
 * 基于这个 client-go 客户端库编写应用程序。
   请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库
-  导入 API 定义，例如，`import "k8s.io/client-go/1.4/pkg/api/v1"` 才是对的。
+  导入 API 定义，例如，`import "k8s.io/client-go/kubernetes"` 才是对的。
 
 Go 客户端可以像 kubectl CLI 一样使用相同的
 [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
@@ -286,7 +309,7 @@ Go 客户端可以像 kubectl CLI 一样使用相同的
 
 To use [Python client](https://github.com/kubernetes-client/python), run the following command: `pip install kubernetes`. See [Python Client Library page](https://github.com/kubernetes-client/python) for more installation options.
 
-The Python client can use the same [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)
+The Python client can use the same [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
 as the kubectl CLI does to locate and authenticate to the apiserver. See this [example](https://github.com/kubernetes-client/python/tree/master/examples).
 
 ### Other languages
@@ -294,7 +317,7 @@ as the kubectl CLI does to locate and authenticate to the apiserver. See this [e
 There are [client libraries](/docs/reference/using-api/client-libraries/) for accessing the API from other languages.
 See documentation for other libraries for how they authenticate.
 -->
-### Python 客户端
+### Python 客户端 {#python-client}
 
 如果想要使用 [Python 客户端](https://github.com/kubernetes-client/python)，
 请运行命令：`pip install kubernetes`。参阅
@@ -306,7 +329,7 @@ Python 客户端可以像 kubectl CLI 一样使用相同的
 来定位和验证 apiserver，可参阅
 [示例](https://github.com/kubernetes-client/python/tree/master/examples)。
 
-### 其它语言
+### 其它语言 {#other-languages}
 
 目前有多个[客户端库](/zh/docs/reference/using-api/client-libraries/)
 为其它语言提供访问 API 的方法。
@@ -332,23 +355,23 @@ for more details.
 <!--
 ## Accessing services running on the cluster
 
-The previous section describes how to connect to the Kubernetes API server. 
+The previous section describes how to connect to the Kubernetes API server.
 For information about connecting to other services running on a Kubernetes cluster, see
-[Access Cluster Services](/docs/tasks/administer-cluster/access-cluster-services/).
+[Access Cluster Services](/docs/tasks/access-application-cluster/access-cluster-services/).
 -->
 
 ## 访问集群上运行的服务  {#accessing-services-running-on-the-cluster}
 
 上一节介绍了如何连接到 Kubernetes API 服务器。
 有关连接到 Kubernetes 集群上运行的其他服务的信息，请参阅
-[访问集群服务](/zh/docs/tasks/administer-cluster/access-cluster-services/)。
+[访问集群服务](/zh/docs/tasks/access-application-cluster/access-cluster-services/)。
 
 <!--
 ## Requesting redirects
 
 The redirect capabilities have been deprecated and removed.  Please use a proxy (see below) instead.
 -->
-## 请求重定向
+## 请求重定向 {#requesting-redirects}
 
 重定向功能已弃用并被删除。请改用代理（见下文）。
 
@@ -367,7 +390,7 @@ There are several different proxies you may encounter when using Kubernetes:
     - adds authentication headers
 
 -->
-## 多种代理
+## 多种代理 {#so-many-proxies}
 
 使用 Kubernetes 时可能会遇到几种不同的代理：
 

static/_redirects

@@ -216,6 +216,7 @@
 /docs/reference/glossary/maintainer/    /docs/reference/glossary/approver/ 301
 
 /docs/reference/kubectl/overview/    /docs/reference/kubectl/ 301
+/zh/docs/reference/kubectl/overview/    /zh/docs/reference/kubectl/ 301
 /docs/reference/kubectl/kubectl-cmds/     /docs/reference/generated/kubectl/kubectl-commands/ 301!
 /docs/reference/kubectl/kubectl/kubectl_*    /docs/reference/generated/kubectl/kubectl-commands#:splat 301
 /docs/reference/scheduling/profiles/    /docs/reference/scheduling/config/#profiles 301