From 635fe65bc56d9fab11bbf9f59e88f22bb5d38749 Mon Sep 17 00:00:00 2001 From: Sean Wei Date: Thu, 26 May 2022 22:42:00 +0800 Subject: [PATCH] [zh] Remove reviewer for auth and kubectl --- .../reference/access-authn-authz/webhook.md | 37 ++++++++-------- .../zh/docs/reference/kubectl/conventions.md | 16 +++---- .../kubectl/docker-cli-to-kubectl.md | 44 ++++++++++--------- 3 files changed, 47 insertions(+), 50 deletions(-) diff --git a/content/zh/docs/reference/access-authn-authz/webhook.md b/content/zh/docs/reference/access-authn-authz/webhook.md index 0ef1e6a18d..29032a7353 100644 --- a/content/zh/docs/reference/access-authn-authz/webhook.md +++ b/content/zh/docs/reference/access-authn-authz/webhook.md @@ -1,15 +1,9 @@ --- -reviewers: -- erictune -- lavalamp -- deads2k -- liggitt title: Webhook 模式 content_type: concept weight: 95 --- @@ -38,7 +31,7 @@ service when determining user privileges. -## 配置文件格式 +## 配置文件格式 {#configuration-file-format} -配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。 +配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。 +在该文件中，“users” 代表着 API 服务器的 webhook，而 “cluster” 代表着远程服务。 -## 请求载荷 +## 请求载荷 {#request-payloads} -在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` 对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。 +在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` +对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。 -需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。 +需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都遵从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。 +实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。 +此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。 期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回: + ```json { "apiVersion": "authorization.k8s.io/v1beta1", @@ -195,7 +193,8 @@ authorizers are configured, they are given a chance to allow the request. If there are no other authorizers, or none of them allow the request, the request is forbidden. The webhook would return: --> -在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求"无意见"，但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回: +在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求 “无意见”。 +但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回： ```json { @@ -214,7 +213,7 @@ configured authorizers. This should only be used by webhooks that have detailed knowledge of the full authorizer configuration of the cluster. The webhook would return: --> -第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回: +第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回： ```json { @@ -252,16 +251,16 @@ Access to non-resource paths are sent as: ``` -非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`, -`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, 和 -`/version`。客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便 +非资源类的路径包括：`/api`、`/apis`、`/metrics`、`/logs`、`/debug`、 +`/healthz`、`/livez`、`/openapi/v2`、`/readyz`、和 `/version`。 +客户端需要访问 `/api`、`/api/*`、`/apis`、`/apis/*` 和 `/version` 以便 能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。 @@ -26,7 +21,7 @@ Recommended usage conventions for `kubectl`. -## 在可重用脚本中使用 `kubectl` +## 在可重用脚本中使用 `kubectl` {#using-kubectl-in-reusable-scripts} * 你可以将 `--subresource` alpha 标志用于 kubectl 命令，例如 `get`、`patch`、`edit` 和 `replace` - 来获取和更新所有支持子资源的资源的子资源。 目前，仅支持 `status` 和 `scale` 子资源。 -* 针对子资源的 API 协定与完整资源相同。在更新`status` 子资源为一个新值时，请记住， + 来获取和更新所有支持子资源的资源的子资源。目前，仅支持 `status` 和 `scale` 子资源。 +* 针对子资源的 API 协定与完整资源相同。在更新 `status` 子资源为一个新值时，请记住， 子资源可能是潜在的由控制器调和为不同的值。 -## 最佳实践 +## 最佳实践 {#best-practices} ### `kubectl run` @@ -80,7 +75,8 @@ For `kubectl run` to satisfy infrastructure as code: * Switch to configuration files checked into source control for features that are needed, but not expressible via `kubectl run` flags. --> -* 使用特定版本的标签标记镜像，不要将该标签移动到新版本。例如，使用 `:v1234`、`v1.2.3`、`r03062016-1-4`，而不是 `:latest`（有关详细信息，请参阅[配置的最佳实践](/zh/docs/concepts/configuration/overview/#container-images))。 +* 使用特定版本的标签标记镜像，不要将该标签改为新版本。例如使用 `:v1234`、`v1.2.3`、`r03062016-1-4`， + 而不是 `:latest`（有关详细信息，请参阅[配置的最佳实践](/zh/docs/concepts/configuration/overview/#container-images))。 * 使用基于版本控制的脚本来运行包含大量参数的镜像。 * 对于无法通过 `kubectl run` 参数来表示的功能特性，使用基于源码控制的配置文件，以记录要使用的功能特性。 diff --git a/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md index 0b32ecafdc..a2e3b49848 100644 --- a/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -1,23 +1,18 @@ --- title: 适用于 Docker 用户的 kubectl content_type: concept -reviewers: -- brendandburns -- thockin --- 你可以使用 Kubernetes 命令行工具 `kubectl` 与 API 服务器进行交互。如果你熟悉 Docker 命令行工具， 则使用 kubectl 非常简单。但是，Docker 命令和 kubectl 命令之间有一些区别。以下显示了 Docker 子命令， @@ -30,8 +25,12 @@ You can use the Kubernetes command line tool `kubectl` to interact with the API -要运行 nginx 部署并将其暴露，请参见[kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-) +要运行 nginx 部署并将其暴露，请参见 [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-) + + +使用 docker 命令： ```shell docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx @@ -48,7 +47,10 @@ CONTAINER ID IMAGE COMMAND CREATED 55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app ``` + +使用 kubectl 命令： 在 kubectl 命令中，我们创建了一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)， -这将保证有 N 个运行 nginx 的 Pod(N 代表 spec 中声明的 replica 数，默认为 1)。 +这将保证有 N 个运行 nginx 的 Pod（N 代表 spec 中声明的 replica 数，默认为 1）。 我们还创建了一个 [service](/zh/docs/concepts/services-networking/service/)，其选择器与容器标签匹配。 查看[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。 @@ -115,7 +117,7 @@ kubectl run [-i] [--tty] --attach --image= Unlike `docker run ...`, if you specify `--attach`, then you attach `stdin`, `stdout` and `stderr`. You cannot control which streams are attached (`docker -a ...`). To detach from the container, you can type the escape sequence Ctrl+P followed by Ctrl+Q. --> -与 `docker run ...` 不同的是，如果指定了 `--attach` ，我们将连接到 `stdin`，`stdout` 和 `stderr`， +与 `docker run ...` 不同的是，如果指定了 `--attach`，我们将连接到 `stdin`，`stdout` 和 `stderr`， 而不能控制具体连接到哪个输出流（`docker -a ...`）。要从容器中退出，可以输入 Ctrl + P，然后按 Ctrl + Q。 因为我们使用 Deployment 启动了容器，如果你终止连接到的进程（例如 `ctrl-c`），容器将会重启， -这跟 `docker run -it` 不同。 如果想销毁该 Deployment（和它的 Pod）， +这跟 `docker run -it` 不同。如果想销毁该 Deployment（和它的 Pod）， 你需要运行 `kubectl delete deployment `。 ## docker ps @@ -271,7 +273,7 @@ docker exec -ti 55c103fa1296 /bin/sh kubectl: ```shell -kubectl exec -ti nginx-app-5jyvm -- /bin/sh +kubectl exec -ti nginx-app-5jyvm -- /bin/sh # exit ``` @@ -318,9 +320,9 @@ kubectl logs -f nginx-app-zibvs There is a slight difference between pods and containers; by default pods do not terminate if their processes exit. Instead the pods restart the process. This is similar to the docker run option `--restart=always` with one major difference. In docker, the output for each invocation of the process is concatenated, but for Kubernetes, each invocation is separate. To see the output from a previous run in Kubernetes, do this: --> 现在是时候提一下 Pod 和容器之间的细微差别了；默认情况下如果 Pod 中的进程退出 Pod 也不会终止， -相反它将会重启该进程。这类似于 docker run 时的 `--restart=always` 选项， 这是主要差别。 -在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 kubernetes，每个调用都是分开的。 -要查看以前在 kubernetes 中执行的输出，请执行以下操作： +相反它将会重启该进程。这类似于 docker run 时的 `--restart=always` 选项，这是主要差别。 +在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 Kubernetes，每个调用都是分开的。 +要查看以前在 Kubernetes 中执行的输出，请执行以下操作： ```shell kubectl logs --previous nginx-app-zibvs @@ -403,7 +405,7 @@ kubectl get po -l app=nginx-app {{< note >}} 请注意，我们不直接删除 Pod。使用 kubectl 命令，我们要删除拥有该 Pod 的 Deployment。 如果我们直接删除 Pod，Deployment 将会重新创建该 Pod。 @@ -501,10 +503,10 @@ kubectl: kubectl cluster-info ``` ``` -Kubernetes master is running at https://108.59.85.141 -KubeDNS is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kube-dns/proxy -kubernetes-dashboard is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy -Grafana is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy -Heapster is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy -InfluxDB is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy +Kubernetes master is running at https://203.0.113.141 +KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy +kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy +Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy ```