Merge pull request #33965 from Sea-n/zh-reviewer-ref-auth
[zh] Remove reviewer for auth and kubectlpull/33903/head
Kubernetes Prow Robot
GitHub
commit
4d95494b45
|
|
@ -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 访问限制的情况下拒绝。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
@ -58,14 +53,14 @@ reconciled by a controller to a different value.
|
|||
-->
|
||||
|
||||
* 你可以将 `--subresource` alpha 标志用于 kubectl 命令，例如 `get`、`patch`、`edit` 和 `replace`
|
||||
来获取和更新所有支持子资源的资源的子资源。 目前，仅支持 `status` 和 `scale` 子资源。
|
||||
* 针对子资源的 API 协定与完整资源相同。在更新`status` 子资源为一个新值时，请记住，
|
||||
来获取和更新所有支持子资源的资源的子资源。目前，仅支持 `status` 和 `scale` 子资源。
|
||||
* 针对子资源的 API 协定与完整资源相同。在更新 `status` 子资源为一个新值时，请记住，
|
||||
子资源可能是潜在的由控制器调和为不同的值。
|
||||
|
||||
<!--
|
||||
## 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` 参数来表示的功能特性，使用基于源码控制的配置文件，以记录要使用的功能特性。
|
||||
|
||||
|
|
|
|||
|
|
@ -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 子命令，
|
||||
|
|
@ -30,8 +25,12 @@ 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-)
|
||||
要运行 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) 获取更多信息。
|
||||
|
||||
|
|
@ -115,7 +117,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<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。
|
||||
|
||||
<!--
|
||||
|
|
@ -123,7 +125,7 @@ Because the kubectl run command starts a Deployment for the container, the Deplo
|
|||
To destroy the Deployment and its pods you need to run `kubectl delete deployment <name>`.
|
||||
-->
|
||||
因为我们使用 Deployment 启动了容器，如果你终止连接到的进程（例如 `ctrl-c`），容器将会重启，
|
||||
这跟 `docker run -it` 不同。 如果想销毁该 Deployment（和它的 Pod），
|
||||
这跟 `docker run -it` 不同。如果想销毁该 Deployment（和它的 Pod），
|
||||
你需要运行 `kubectl delete deployment <name>`。
|
||||
|
||||
## 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 >}}
|
||||
<!--
|
||||
When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
|
||||
When you use kubectl, you don't delete the pod directly. You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
|
||||
-->
|
||||
请注意，我们不直接删除 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
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue