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

Merge pull request #33965 from Sea-n/zh-reviewer-ref-auth

Browse Source 
[zh] Remove reviewer for auth and kubectl
This commit is contained in:
Kubernetes Prow Robot
2022-05-26 16:19:55 -07:00
committed by GitHub
parent 262db081ad 635fe65bc5
commit 4d95494b45
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 模式
content_type: concept
weight: 95
---
<!--
---
reviewers:
- erictune
- lavalamp
@@ -18,7 +12,6 @@ reviewers:
title: Webhook Mode
content_type: concept
weight: 95
---
-->
<!-- overview -->
@@ -38,7 +31,7 @@ service when determining user privileges.
<!--
## Configuration File Format
-->
## 配置文件格式
## 配置文件格式 {#configuration-file-format}
<!--
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
"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:
@@ -122,7 +116,7 @@ contexts:
<!--
## Request Payloads
-->
## 请求载荷
## 请求载荷 {#request-payloads}
<!--
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
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/)
@@ -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
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:
@@ -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:
-->
期待远程服务填充请求的 `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:
```
<!--
Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`,
`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and
Non-resource paths include: `/api`, `/apis`, `/metrics`,
`/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and
`/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`,
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
to the REST api.
-->
非资源类的路径包括：`/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 访问限制的情况下拒绝。
<!--
content/zh/docs/reference/kubectl/conventions.md
+4 -8
View File
@@ -1,17 +1,12 @@
---
title: kubectl 的用法约定
reviewers:
- janetkuo
content_type: concept
---
<!--
---
title: kubectl Usage Conventions
reviewers:
- janetkuo
content_type: concept
---
-->
<!-- overview -->
@@ -26,7 +21,7 @@ Recommended usage conventions for `kubectl`.
<!--
## Using `kubectl` in Reusable Scripts
-->
## 在可重用脚本中使用 `kubectl`
## 在可重用脚本中使用 `kubectl` {#using-kubectl-in-reusable-scripts}
<!--
For a stable output in a script:
@@ -65,7 +60,7 @@ reconciled by a controller to a different value.
<!--
## Best Practices
-->
## 最佳实践
## 最佳实践 {#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` 参数来表示的功能特性，使用基于源码控制的配置文件，以记录要使用的功能特性。
content/zh/docs/reference/kubectl/docker-cli-to-kubectl.md
+17 -15
View File
@@ -1,23 +1,18 @@
---
title: 适用于 Docker 用户的 kubectl
content_type: concept
reviewers:
- brendandburns
- thockin
---
<!--
---
title: kubectl for Docker Users
content_type: concept
reviewers:
- brendandburns
- thockin
---
-->
<!-- 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 命令行工具，
则使用 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-).
-->
要运行 nginx 部署并将其暴露，请参见 [kubectl create deployment](/docs/reference/generated/kubectl/kubectl-commands#-em-deployment-em-)
<!--
docker:
-->
使用 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 命令：
<!--
```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).
-->
在 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) 获取更多信息。
@@ -319,8 +321,8 @@ There is a slight difference between pods and containers; by default pods do not
-->
现在是时候提一下 Pod 和容器之间的细微差别了；默认情况下如果 Pod 中的进程退出 Pod 也不会终止，
相反它将会重启该进程。这类似于 docker run 时的 `--restart=always` 选项，这是主要差别。
在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 kubernetes，每个调用都是分开的。
要查看以前在 kubernetes 中执行的输出，请执行以下操作：
在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 Kubernetes，每个调用都是分开的。
要查看以前在 Kubernetes 中执行的输出，请执行以下操作：
```shell
kubectl logs --previous nginx-app-zibvs
@@ -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
```