whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Remove reviewer for auth and kubectl

Browse Source
This commit is contained in:
Sean Wei
2022-05-26 22:42:00 +08:00
parent 6a89b98cc0
commit 635fe65bc5
3 changed files with 47 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/reference/access-authn-authz/webhook.md
+18 -19
View File
@@ -1,15 +1,9 @@
--- ---
reviewers:
- erictune
- lavalamp
- deads2k
- liggitt
title: Webhook 模式 title: Webhook 模式
content_type: concept content_type: concept
weight: 95 weight: 95
--- ---
<!-- <!--
---
reviewers: reviewers:
- erictune - erictune
- lavalamp - lavalamp
@@ -18,7 +12,6 @@ reviewers:
title: Webhook Mode title: Webhook Mode
content_type: concept content_type: concept
weight: 95 weight: 95
---
--> -->
<!-- overview --> <!-- overview -->
@@ -38,7 +31,7 @@ service when determining user privileges.
<!-- <!--
## Configuration File Format ## Configuration File Format
--> -->
## 配置文件格式 ## 配置文件格式 {#configuration-file-format}
<!-- <!--
Mode `Webhook` requires a file for HTTP configuration, specify by the Mode `Webhook` requires a file for HTTP configuration, specify by the
@@ -51,7 +44,8 @@ The configuration file uses the [kubeconfig](/docs/tasks/access-application-clus
file format. Within the file "users" refers to the API Server webhook and file format. Within the file "users" refers to the API Server webhook and
"clusters" refers to the remote service. "clusters" refers to the remote service.
--> -->
配置文件的格式使用 [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” 代表着远程服务。
<!-- <!--
A configuration example which uses HTTPS client auth: A configuration example which uses HTTPS client auth:
@@ -122,7 +116,7 @@ contexts:
<!-- <!--
## Request Payloads ## Request Payloads
--> -->
## 请求载荷 ## 请求载荷 {#request-payloads}
<!-- <!--
When faced with an authorization decision, the API Server POSTs a JSON- When faced with an authorization decision, the API Server POSTs a JSON-
@@ -131,7 +125,8 @@ action. This object contains fields describing the user attempting to make the
request, and either details about the resource being accessed or requests request, and either details about the resource being accessed or requests
attributes. attributes.
--> -->
在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` 对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。 在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview`
对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。
<!-- <!--
Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/) Note that webhook API objects are subject to the same [versioning compatibility rules](/docs/concepts/overview/kubernetes-api/)
@@ -140,7 +135,9 @@ compatibility promises for beta objects and check the "apiVersion" field of the
request to ensure correct deserialization. Additionally, the API Server must request to ensure correct deserialization. Additionally, the API Server must
enable the `authorization.k8s.io/v1beta1` API extensions group (`--runtime-config=authorization.k8s.io/v1beta1=true`). enable the `authorization.k8s.io/v1beta1` API extensions group (`--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`)。 需要注意的是 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`)。
<!-- <!--
An example request body: An example request body:
@@ -173,6 +170,7 @@ the request and respond to either allow or disallow access. The response body's
`spec` field is ignored and may be omitted. A permissive response would return: `spec` field is ignored and may be omitted. A permissive response would return:
--> -->
期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回: 期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回:
```json ```json
{ {
"apiVersion": "authorization.k8s.io/v1beta1", "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 If there are no other authorizers, or none of them allow the request, the
request is forbidden. The webhook would return: request is forbidden. The webhook would return:
--> -->
在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求"无意见"，但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回: 在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求 “无意见”。
但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回：
```json ```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. detailed knowledge of the full authorizer configuration of the cluster.
The webhook would return: The webhook would return:
--> -->
第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回: 第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回：
```json ```json
{ {
@@ -252,16 +251,16 @@ Access to non-resource paths are sent as:
``` ```
<!-- <!--
Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`, Non-resource paths include: `/api`, `/apis`, `/metrics`,
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and `/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and
`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`, `/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
and `/version` to discover what resources and versions are present on the server. and `/version` to discover what resources and versions are present on the server.
Access to other non-resource paths can be disallowed without restricting access Access to other non-resource paths can be disallowed without restricting access
to the REST api. to the REST api.
--> -->
非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`, 非资源类的路径包括：`/api`、`/apis`、`/metrics`、`/logs`、`/debug`、
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, 和 `/healthz`、`/livez`、`/openapi/v2`、`/readyz`、和 `/version`。
`/version`。客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便 客户端需要访问 `/api`、`/api/*`、`/apis`、`/apis/*` 和 `/version` 以便
能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。 能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。
<!-- <!--
content/zh/docs/reference/kubectl/conventions.md
+4 -8
View File
@@ -1,17 +1,12 @@
--- ---
title: kubectl 的用法约定 title: kubectl 的用法约定
reviewers:
- janetkuo
content_type: concept content_type: concept
--- ---
<!-- <!--
---
title: kubectl Usage Conventions title: kubectl Usage Conventions
reviewers: reviewers:
- janetkuo - janetkuo
content_type: concept content_type: concept
---
--> -->
<!-- overview --> <!-- overview -->
@@ -26,7 +21,7 @@ Recommended usage conventions for `kubectl`.
<!-- <!--
## Using `kubectl` in Reusable Scripts ## Using `kubectl` in Reusable Scripts
--> -->
## 在可重用脚本中使用 `kubectl` ## 在可重用脚本中使用 `kubectl` {#using-kubectl-in-reusable-scripts}
<!-- <!--
For a stable output in a script: For a stable output in a script:
@@ -65,7 +60,7 @@ reconciled by a controller to a different value.
<!-- <!--
## Best Practices ## Best Practices
--> -->
## 最佳实践 ## 最佳实践 {#best-practices}
### `kubectl run` ### `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. * 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` 参数来表示的功能特性，使用基于源码控制的配置文件，以记录要使用的功能特性。 * 对于无法通过 `kubectl run` 参数来表示的功能特性，使用基于源码控制的配置文件，以记录要使用的功能特性。
content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md
+17 -15
View File
@@ -1,23 +1,18 @@
--- ---
title: 适用于 Docker 用户的 kubectl title: 适用于 Docker 用户的 kubectl
content_type: concept content_type: concept
reviewers:
- brendandburns
- thockin
--- ---
<!-- <!--
---
title: kubectl for Docker Users title: kubectl for Docker Users
content_type: concept content_type: concept
reviewers: reviewers:
- brendandburns - brendandburns
- thockin - thockin
---
--> -->
<!-- overview --> <!-- overview -->
<!-- <!--
You can use the Kubernetes command line tool `kubectl` to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the docker commands and the kubectl commands. The following sections show a Docker sub-command and describe the equivalent `kubectl` command. You can use the Kubernetes command line tool `kubectl` to interact with the API Server. Using kubectl is straightforward if you are familiar with the Docker command line tool. However, there are a few differences between the Docker commands and the kubectl commands. The following sections show a Docker sub-command and describe the equivalent `kubectl` command.
--> -->
你可以使用 Kubernetes 命令行工具 `kubectl` 与 API 服务器进行交互。如果你熟悉 Docker 命令行工具， 你可以使用 Kubernetes 命令行工具 `kubectl` 与 API 服务器进行交互。如果你熟悉 Docker 命令行工具，
则使用 kubectl 非常简单。但是，Docker 命令和 kubectl 命令之间有一些区别。以下显示了 Docker 子命令， 则使用 kubectl 非常简单。但是，Docker 命令和 kubectl 命令之间有一些区别。以下显示了 Docker 子命令，
@@ -31,7 +26,11 @@ You can use the Kubernetes command line tool `kubectl` to interact with the API
To run an nginx Deployment and expose the Deployment, see [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-). To run an nginx Deployment and expose the Deployment, see [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-) 要运行 nginx 部署并将其暴露，请参见 [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-)
<!--
docker: docker:
-->
使用 docker 命令：
```shell ```shell
docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx 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 55c103fa1296 nginx "nginx -g 'daemon of…" 9 seconds ago Up 9 seconds 0.0.0.0:80->80/tcp nginx-app
``` ```
<!--
kubectl: kubectl:
-->
使用 kubectl 命令：
<!-- <!--
```shell ```shell
@@ -97,7 +99,7 @@ service "nginx-http" exposed
By using kubectl, you can create a [Deployment](/docs/concepts/workloads/controllers/deployment/) to ensure that N pods are running nginx, where N is the number of replicas stated in the spec and defaults to 1. You can also create a [service](/docs/concepts/services-networking/service/) with a selector that matches the pod labels. For more information, see [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster). By using kubectl, you can create a [Deployment](/docs/concepts/workloads/controllers/deployment/) to ensure that N pods are running nginx, where N is the number of replicas stated in the spec and defaults to 1. You can also create a [service](/docs/concepts/services-networking/service/) with a selector that matches the pod labels. For more information, see [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster).
--> -->
在 kubectl 命令中，我们创建了一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)， 在 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/)，其选择器与容器标签匹配。 我们还创建了一个 [service](/zh/docs/concepts/services-networking/service/)，其选择器与容器标签匹配。
查看[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。 查看[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。
@@ -319,8 +321,8 @@ There is a slight difference between pods and containers; by default pods do not
--> -->
现在是时候提一下 Pod 和容器之间的细微差别了；默认情况下如果 Pod 中的进程退出 Pod 也不会终止， 现在是时候提一下 Pod 和容器之间的细微差别了；默认情况下如果 Pod 中的进程退出 Pod 也不会终止，
相反它将会重启该进程。这类似于 docker run 时的 `--restart=always` 选项，这是主要差别。 相反它将会重启该进程。这类似于 docker run 时的 `--restart=always` 选项，这是主要差别。
在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 kubernetes，每个调用都是分开的。 在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 Kubernetes，每个调用都是分开的。
要查看以前在 kubernetes 中执行的输出，请执行以下操作： 要查看以前在 Kubernetes 中执行的输出，请执行以下操作：
```shell ```shell
kubectl logs --previous nginx-app-zibvs kubectl logs --previous nginx-app-zibvs
@@ -501,10 +503,10 @@ kubectl:
kubectl cluster-info kubectl cluster-info
``` ```
``` ```
Kubernetes master is running at https://108.59.85.141 Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://108.59.85.141/api/v1/namespaces/kube-system/services/kube-dns/proxy KubeDNS is running at https://203.0.113.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 kubernetes-dashboard is running at https://203.0.113.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 Grafana is running at https://203.0.113.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 Heapster is running at https://203.0.113.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 InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy
``` ```