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

Merge pull request #23195 from tengqm/zh-links-tasks-4

Browse Source 
[zh] Tidy up and fix links in tasks section (4/10)
This commit is contained in:
Kubernetes Prow Robot
2020-08-22 20:47:40 -07:00
committed by GitHub
parent aa10585cda a3a745838b
commit 0355f57f05
13 changed files with 598 additions and 637 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
+48 -43
View File
@@ -1,21 +1,16 @@
---
reviewers:
- jpeeler
- pmorie
title: 配置 Pod 使用投射卷作存储
content_type: task
weight: 70
---
<!--
---
reviewers:
- jpeeler
- pmorie
title: Configure a Pod to Use a Projected Volume for Storage
content_type: task
weight: 70
---
-->
<!-- overview -->
@@ -25,22 +20,20 @@ several existing volume sources into the same directory. Currently, `secret`, `c
and `serviceAccountToken` volumes can be projected.
-->
本文介绍怎样通过[`投射`](/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
本文介绍怎样通过[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。
当前，`secret`、`configMap`、`downwardAPI` 和 `serviceAccountToken` 卷可以被投射。
{{< note >}}
<!--
`serviceAccountToken` is not a volume type.
-->
{{< note >}}
`serviceAccountToken` 不是一种卷类型
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@@ -51,62 +44,74 @@ In this exercise, you create username and password Secrets from local files. You
Here is the configuration file for the Pod:
-->
## 为 Pod 配置投射卷
## 为 Pod 配置 projected 卷
本练习中，您将从本地文件来创建包含有用户名和密码的 Secret。然后创建运行一个容器的 Pod，该 Pod 使用[`投射`](/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
本练习中，您将从本地文件来创建包含有用户名和密码的 Secret。然后创建运行一个容器的 Pod，
该 Pod 使用[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将 Secret 挂载到相同的路径下。
下面是 Pod 的配置文件：
{{< codenew file="pods/storage/projected.yaml" >}}
1. <!--Create the Secrets:-->创建 Secrets:
```shell
<!--# Create files containing the username and password:--># 创建包含用户名和密码的文件:
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt-->
1. <!--Create the Secrets:-->
创建 Secrets:
<!--# Package these files into secrets:--># 将上述文件引用到 Secret：
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt
```
```shell
# 创建包含用户名和密码的文件:
echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt-->
1. <!--Create the Pod:-->创建 Pod：
# 将上述文件引用到 Secret：
kubectl create secret generic user --from-file=./username.txt
kubectl create secret generic pass --from-file=./password.txt
```
```shell
kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml
```
2. <!--Create the Pod:-->
创建 Pod：
<!--Verify that the Pod's Container is running, and then watch for changes to
the Pod:-->确认 Pod 中的容器运行正常，然后监视 Pod 的变化：
```shell
kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml
```
```shell
kubectl get --watch pod test-projected-volume
```
<!--
Verify that the Pod's Container is running, and then watch for changes to
the Pod:
-->
确认 Pod 中的容器运行正常，然后监视 Pod 的变化：
<!--The output looks like this:-->输出结果和下面类似：
NAME READY STATUS RESTARTS AGE
test-projected-volume 1/1 Running 0 14s
```shell
kubectl get --watch pod test-projected-volume
```
1. <!--In another terminal, get a shell to the running Container:-->在另外一个终端中，打开容器的 shell：
```shell
kubectl exec -it test-projected-volume -- /bin/sh
```
<!--The output looks like this:-->
输出结果和下面类似：
1. <!--In your shell, verify that the `projected-volume` directory contains your projected sources:-->在 shell 中，确认 `projected-volume` 目录包含你的投射源：
```shell
ls /projected-volume/
```
```
NAME READY STATUS RESTARTS AGE
test-projected-volume 1/1 Running 0 14s
```
3. <!--In another terminal, get a shell to the running Container:-->
在另外一个终端中，打开容器的 shell：
```shell
kubectl exec -it test-projected-volume -- /bin/sh
```
4. <!--In your shell, verify that the `projected-volume` directory contains your projected sources:-->
在 shell 中，确认 `projected-volume` 目录包含你的投射源：
```shell
ls /projected-volume/
```
## {{% heading "whatsnext" %}}
<!--
* Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes.
* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document.
-->
* 进一步了解[`投射`](/docs/concepts/storage/volumes/#projected) 卷。
* 进一步了解[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷。
* 阅读[一体卷](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)设计文档。
content/zh/docs/tasks/configure-pod-container/configure-service-account.md
+248 -128
View File
@@ -1,15 +1,10 @@
---
reviewers:
- bprashanth
- liggitt
- thockin
title: 为 Pod 配置服务账户
content_type: task
weight: 90
---
<!--
---
reviewers:
- bprashanth
- liggitt
@@ -17,7 +12,6 @@ reviewers:
title: Configure Service Accounts for Pods
content_type: task
weight: 90
---
-->
<!-- overview -->
@@ -25,26 +19,16 @@ weight: 90
<!--
A service account provides an identity for processes that run in a Pod.
*This is a user introduction to Service Accounts. See also the
[Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/).*
-->
服务账户为 Pod 中运行的进程提供了一个标识。
*本文是服务账户的用户使用介绍。您也可以参考[集群管理指南之服务账户](/docs/reference/access-authn-authz/service-accounts-admin/)。*
{{< note >}}
<!--
This document describes how service accounts behave in a cluster set up
as recommended by the Kubernetes project. Your cluster administrator may have
This document is a user introduction to Service Accounts and describes how service accounts behave in a cluster set up
as recommended by the Kubernetes project. Your cluster administrator may have
customized the behavior in your cluster, in which case this documentation may
not apply.
-->
服务账户为 Pod 中运行的进程提供了一个标识。
本文档描述 Kubernetes 项目推荐的集群中服务帐户的行为。
集群管理员也可能已经定制了服务账户在集群中的属性，在这种情况下，本文档可能并不适用。
{{< note >}}
本文是服务账户的用户使用介绍，描述服务账号在集群中如何起作用。
你的集群管理员可能已经对你的集群做了定制，因此导致本文中所讲述的内容并不适用。
{{< /note >}}
<!--
@@ -55,20 +39,15 @@ cluster). Processes in containers inside pods can also contact the apiserver.
When they do, they are authenticated as a particular Service Account (for example,
`default`).
-->
当您（人类）访问集群时（例如，使用 `kubectl`），api 服务器将您的身份验证为特定的用户帐户（当前这通常是 `admin`，除非您的集群管理员已经定制了您的集群配置）。
当你（自然人）访问集群时（例如，使用 `kubectl`），API 服务器将你的身份验证为
特定的用户帐户（当前这通常是 `admin`，除非你的集群管理员已经定制了你的集群配置）。
Pod 内的容器中的进程也可以与 api 服务器接触。
当它们进行身份验证时，它们被验证为特定的服务帐户（例如，`default`）。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@@ -80,12 +59,11 @@ If you get the raw json or yaml for a pod you have created (for example, `kubect
you can see the `spec.serviceAccountName` field has been
[automatically set](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
-->
## 使用默认的服务账户访问 API 服务器
当您创建 Pod 时，如果没有指定服务账户，Pod 会被指定命名空间中的`default`服务账户。
如果您查看 Pod 的原始 json 或 yaml（例如：`kubectl get pods/podname -o yaml`），
您可以看到 `spec.serviceAccountName` 字段已经被[自动设置](/docs/user-guide/working-with-resources/#resources-are-automatically-modified)了。
当你创建 Pod 时，如果没有指定服务账户，Pod 会被指定给命名空间中的 `default` 服务账户。
如果你查看 Pod 的原始 JSON 或 YAML（例如：`kubectl get pods/podname -o yaml`），
你可以看到 `spec.serviceAccountName` 字段已经被自动设置了。
<!--
You can access the API from inside a pod using automatically mounted service account credentials,
@@ -95,11 +73,14 @@ The API permissions of the service account depend on the [authorization plugin a
In version 1.6+, you can opt out of automounting API credentials for a service account by setting
`automountServiceAccountToken: false` on the service account:
-->
你可以使用自动挂载给 Pod 的服务账户凭据访问 API，
[访问集群](/zh/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod)
中有相关描述。
服务账户的 API 许可取决于你所使用的
[鉴权插件和策略](/zh/docs/reference/access-authn-authz/authorization/#authorization-modules)。
您可以使用自动挂载给 Pod 的服务账户凭据访问 API，[访问集群](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) 中有相关描述。
服务账户的 API 许可取决于您所使用的[授权插件和策略](/docs/reference/access-authn-authz/authorization/#authorization-modules)。
在 1.6 以上版本中，您可以通过在服务账户上设置 `automountServiceAccountToken: false` 来实现不给服务账号自动挂载 API 凭据：
在 1.6 以上版本中，你可以通过在服务账户上设置 `automountServiceAccountToken: false`
来实现不给服务账号自动挂载 API 凭据：
```yaml
@@ -114,8 +95,7 @@ automountServiceAccountToken: false
<!--
In version 1.6+, you can also opt out of automounting API credentials for a particular pod:
-->
在 1.6 以上版本中，您也可以选择不给特定 Pod 自动挂载 API 凭据：
在 1.6 以上版本中，你也可以选择不给特定 Pod 自动挂载 API 凭据：
```yaml
apiVersion: v1
@@ -130,19 +110,19 @@ spec:
<!--
The pod spec takes precedence over the service account if both specify a `automountServiceAccountToken` value.
-->
如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。
<!--
## Use Multiple Service Accounts.
Every namespace has a default service account resource called `default`.
You can list this and any other serviceAccount resources in the namespace with this command:
-->
如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。
## 使用多个服务账户
## 使用多个服务账户 {#use-multiple-service-accounts}
每个命名空间都有一个名为 `default` 的服务账户资源。
您可以用下面的命令查询这个服务账户以及命名空间中的其他 serviceAccount 资源：
你可以用下面的命令查询这个服务账户以及命名空间中的其他 ServiceAccount 资源：
```shell
kubectl get serviceAccounts
@@ -153,8 +133,7 @@ default 1 1d
<!--
You can create additional ServiceAccount objects like this:
-->
您可以像这样来创建额外的 ServiceAccount 对象：
你可以像这样来创建额外的 ServiceAccount 对象：
```shell
kubectl create -f - <<EOF
@@ -169,8 +148,7 @@ serviceaccount/build-robot created
<!--
If you get a complete dump of the service account object, like this:
-->
如果您查询服务帐户对象的完整信息，如下所示：
如果你查询服务帐户对象的完整信息，如下所示：
```shell
kubectl get serviceaccounts/build-robot -o yaml
@@ -194,12 +172,12 @@ You may use authorization plugins to [set permissions on service accounts](/docs
To use a non-default service account, simply set the `spec.serviceAccountName`
field of a pod to the name of the service account you wish to use.
-->
那么你就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
那么您就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
你可以使用授权插件来
[设置服务账户的访问许可](/zh/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
您可以使用授权插件来 [设置服务账户的访问许可](/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
要使用非默认的服务账户，只需简单的将 Pod 的 `spec.serviceAccountName` 字段设置为您想用的服务账户名称。
要使用非默认的服务账户，只需简单的将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账户名称。
<!--
The service account has to exist at the time the pod is created, or it will be rejected.
@@ -208,12 +186,11 @@ You cannot update the service account of an already created pod.
You can clean up the service account from this example like this:
-->
Pod 被创建时服务账户必须存在，否则会被拒绝。
您不能更新已经创建好的 Pod 的服务账户。
你不能更新已经创建好的 Pod 的服务账户。
您可以清除服务账户，如下所示：
你可以清除服务账户，如下所示：
```shell
kubectl delete serviceaccount/build-robot
@@ -225,7 +202,6 @@ kubectl delete serviceaccount/build-robot
Suppose we have an existing service account named "build-robot" as mentioned above, and we create
a new secret manually.
-->
## 手动创建服务账户 API 令牌
假设我们有一个上面提到的名为 "build-robot" 的服务账户，然后我们手动创建一个新的 Secret。
@@ -248,8 +224,7 @@ Now you can confirm that the newly built secret is populated with an API token f
Any tokens for non-existent service accounts will be cleaned up by the token controller.
-->
现在，您可以确认新构建的 Secret 中填充了 "build-robot" 服务帐户的 API 令牌。
现在，你可以确认新构建的 Secret 中填充了 "build-robot" 服务帐户的 API 令牌。
令牌控制器将清理不存在的服务帐户的所有令牌。
@@ -270,50 +245,74 @@ namespace: 7 bytes
token: ...
```
{{< note >}}
<!--
The content of `token` is elided here.
-->
{{< note >}}
这里省略了 `token` 的内容。
{{< /note >}}
<!--
## Add ImagePullSecrets to a service account
First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
Next, verify it has been created. For example:
### Create an imagePullSecret
- Create an imagePullSecret, as described in [Specifying ImagePullSecret on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
-->
## 为服务账户添加 ImagePullSecrets {#add-imagepullsecrets-to-a-service-account}
## 为服务账户添加 ImagePullSecrets
### 创建 ImagePullSecret
首先，创建一个 ImagePullSecrets，可以参考[这里](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 的描述。
然后，确认创建是否成功。例如：
- 创建一个 ImagePullSecret，如同[为 Pod 设置 ImagePullSecret](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)所述。
```shell
kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \
--docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
--docker-email=DUMMY_DOCKER_EMAIL
```
```shell
kubectl get secrets myregistrykey
NAME TYPE DATA AGE
myregistrykey   kubernetes.io/.dockerconfigjson   1       1d
```
<!--
- Verify it has been created.
-->
- 确认创建成功：
```shell
kubectl get secrets myregistrykey
```
<!-- The output is similar to this: -->
输出类似于：
```
NAME TYPE DATA AGE
myregistrykey   kubernetes.io/.dockerconfigjson   1       1d
```
<!--
### Add image pull secret to service account
Next, modify the default service account for the namespace to use this secret as an imagePullSecret.
-->
### 将镜像拉取 Secret 添加到服务账号
接着修改命名空间的默认服务帐户，以将该 Secret 用作 imagePullSecret。
接着修改命名空间的 `default` 服务帐户，以将该 Secret 用作 imagePullSecret。
```shell
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
```
<!--
Interactive version requiring manual edit:
You can instead use `kubectl edit`, or manually edit the YAML manifests as shown below:
-->
需要手动编辑的交互式版本：
你也可以使用 `kubectl edit`，或者如下所示手动编辑 YAML 清单：
```shell
kubectl get serviceaccounts default -o yaml > ./sa.yaml
```
cat sa.yaml
`sa.yaml` 文件的内容类似于：
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
@@ -324,13 +323,19 @@ metadata:
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
secrets:
- name: default-token-uudge
```
vi sa.yaml
[editor session not shown]
[delete line with key "resourceVersion"]
[add lines with "imagePullSecrets:"]
<!--
Using your editor of choice (for example `vi`), open the `sa.yaml` file, delete line with key `resourceVersion`, add lines with `imagePullSecrets:` and save.
cat sa.yaml
The output of the `sa.yaml` file is similar to this:
-->
使用你常用的编辑器（例如 `vi`），打开 `sa.yaml` 文件，删除带有键名
`resourceVersion` 的行，添加带有 `imagePullSecrets:` 的行，最后保存文件。
所得到的 `sa.yaml` 文件类似于：
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
@@ -342,37 +347,46 @@ secrets:
- name: default-token-uudge
imagePullSecrets:
- name: myregistrykey
kubectl replace serviceaccount default -f ./sa.yaml
serviceaccounts/default
```
<!--
Now, any new pods created in the current namespace will have this added to their spec:
Finally replace the serviceaccount with the new updated `sa.yaml` file
-->
最后，用新的更新的 `sa.yaml` 文件替换服务账号。
现在，在当前命名空间中创建的每个新 Pod 的 spec 中都会添加下面的内容：
```yaml
spec:
imagePullSecrets:
- name: myregistrykey
```shell
kubectl replace serviceaccount default -f ./sa.yaml
```
<!--## Adding Secrets to a service account.
<!--
### Verify imagePullSecrets was added to pod spec
TODO: Test and explain how to use additional non-K8s secrets with an existing service account.
Now, when a new Pod is created in the current namespace and using the default ServiceAccount, the new Pod has its `spec.imagePullSecrets` field set automatically:
-->
### 验证镜像拉取 Secret 已经被添加到 Pod 规约
现在，在当前命名空间中创建的每个使用默认服务账号的新 Pod，新 Pod 都会自动
设置其 `.spec.imagePullSecrets` 字段：
```shell
kubectl run nginx --image=nginx --restart=Never
kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'
```
<!-- The output is: -->
输出为：
```
myregistrykey
```
<!--
## Service Account Token Volume Projection
-->
## 服务帐户令牌卷投影
## 服务帐户令牌卷投射 {#service-account-token-volume-projection}
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
{{< note >}}
<!--
This ServiceAccountTokenVolumeProjection is __beta__ in 1.12 and
enabled by passing all of the following flags to the API server:
@@ -381,13 +395,13 @@ enabled by passing all of the following flags to the API server:
* `--service-account-signing-key-file`
* `--service-account-api-audiences`
-->
ServiceAccountTokenVolumeProjection 在 1.12 版本中是 __beta__ 阶段，可以通过向 API 服务器传递以下所有参数来启用它：
{{< note >}}
ServiceAccountTokenVolumeProjection 在 1.12 版本中是 __beta__ 阶段，
可以通过向 API 服务器传递以下所有参数来启用它：
* `--service-account-issuer`
* `--service-account-signing-key-file`
* `--service-account-api-audiences`
{{< /note >}}
<!--
@@ -397,9 +411,8 @@ duration. These properties are not configurable on the default service account
token. The service account token will also become invalid against the API when
the Pod or the ServiceAccount is deleted.
-->
kubelet 还可以将服务帐户令牌投影到 Pod 中。
您可以指定令牌的所需属性，例如受众和有效持续时间。
你可以指定令牌的所需属性，例如受众和有效持续时间。
这些属性在默认服务帐户令牌上无法配置。
当删除 Pod 或 ServiceAccount 时，服务帐户令牌也将对 API 无效。
@@ -409,44 +422,151 @@ This behavior is configured on a PodSpec using a ProjectedVolume type called
pod with a token with an audience of "vault" and a validity duration of two
hours, you would configure the following in your PodSpec:
-->
使用名为 [ServiceAccountToken](/zh/docs/concepts/storage/volumes/#projected) 的
ProjectedVolume 类型在 PodSpec 上配置此功能。
要向 Pod 提供具有 "vault" 用户以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容：
使用名为 [ServiceAccountToken](/docs/concepts/storage/volumes/#projected) 的 ProjectedVolume 类型在 PodSpec 上配置此功能。
要向 Pod 提供具有 "vault" 观众以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容：
{{< codenew file="pods/pod-projected-svc-token.yaml" >}}
```yaml
kind: Pod
apiVersion: v1
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: vault-token
volumes:
- name: vault-token
projected:
sources:
- serviceAccountToken:
path: vault-token
expirationSeconds: 7200
audience: vault
<!--
Create the Pod:
-->
创建 Pod：
```shell
kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
```
<!--
The kubelet will request and store the token on behalf of the pod, make the
token available to the pod at a configurable file path, and refresh the token as
it approaches expiration. Kubelet proactively rotates the token if it is older
than 80% of its total TTL, or if the token is older than 24 hours.
token available to the pod at a configurable file path, and refresh the token as it approaches expiration. Kubelet proactively rotates the token if it is older than 80% of its total TTL, or if the token is older than 24 hours.
The application is responsible for reloading the token when it rotates. Periodic
reloading (e.g. once every 5 minutes) is sufficient for most usecases.
The application is responsible for reloading the token when it rotates. Periodic reloading (e.g. once every 5 minutes) is sufficient for most use cases.
-->
`kubelet` 组件会替 Pod 请求令牌并将其保存起来，通过将令牌存储到一个可配置的
路径使之在 Pod 内可用，并在令牌快要到期的时候刷新它。
`kubelet` 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 24 小时
的时候主动轮换它。
Kubelet 将代表 Pod 请求和存储令牌，使令牌在可配置的文件路径上对 Pod 可用，并在令牌接近到期时刷新令牌。
如果令牌存活时间大于其总 TTL 的 80% 或者大于 24 小时，Kubelet 则会主动旋转令牌。
应用程序负责在令牌被轮换时重新加载其内容。对于大多数使用场景而言，周期性地
（例如，每隔 5 分钟）重新加载就足够了。
应用程序负责在令牌旋转时重新加载令牌。
对于大多数情况，定期重新加载（例如，每 5 分钟一次）就足够了。
<!--
## Service Account Issuer Discovery
-->
## 发现服务账号分发者
{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
<!--
The Service Account Issuer Discovery feature is enabled by enabling the
`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates)
and then enabling the Service Account Token Projection feature as described
[above](#service-account-token-volume-projection).
-->
通过启用 `ServiceAccountIssuerDiscovery`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)，
并按[前文所述](#service-account-token-volume-projection)启用服务账号令牌投射，
可以启用发现服务账号分发者（Service Account Issuer Discovery）这一功能特性。
<!--
The issuer URL must comply with the
[OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html). In
practice, this means it must use the `https` scheme, and should serve an OpenID
provider configuration at `{service-account-issuer}/.well-known/openid-configuration`.
If the URL does not comply, the `ServiceAccountIssuerDiscovery` endpoints will
not be registered, even if the feature is enabled.
-->
{{< note >}}
分发者的 URL 必须遵从
[OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)。
这意味着 URL 必须使用 `https` 模式，并且必须在
`{service-account-issuer}/.well-known/openid-configuration`
路径提供 OpenID 提供者（Provider）配置。
如果 URL 没有遵从这一规范，`ServiceAccountIssuerDiscovery` 末端就不会被注册，
即使该特性已经被启用。
{{< /note >}}
<!--
The Service Account Issuer Discovery feature enables federation of Kubernetes
service account tokens issued by a cluster (the _identity provider_) with
external systems (_relying parties_).
When enabled, the Kubernetes API server provides an OpenID Provider
Configuration document at `/.well-known/openid-configuration` and the associated
JSON Web Key Set (JWKS) at `/openid/v1/jwks`. The OpenID Provider Configuration
is sometimes referred to as the _discovery document_.
-->
发现服务账号分发者这一功能使得用户能够用联邦的方式结合使用 Kubernetes
集群（_Identity Provider_，标识提供者）与外部系统（_relying parties_，
依赖方）所分发的服务账号令牌。
当此功能被启用时，Kubernetes API 服务器会在 `/.well-known/openid-configuration`
提供一个 OpenID 提供者配置文档，并在 `/openid/v1/jwks` 处提供与之关联的
JSON Web Key Set（JWKS）。
这里的 OpenID 提供者配置有时候也被称作 _发现文档（Discovery Document）_。
<!--
When enabled, the cluster is also configured with a default RBAC ClusterRole
called `system:service-account-issuer-discovery`. No role bindings are provided
by default. Administrators may, for example, choose whether to bind the role to
`system:authenticated` or `system:unauthenticated` depending on their security
requirements and which external systems they intend to federate with.
-->
特性被启用时，集群也会配置名为 `system:service-account-issuer-discovery`
的默认 RBAC ClusterRole，但默认情况下不提供角色绑定对象。
举例而言，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到
`system:authenticated` 或 `system:unauthenticated`。
<!--
The responses served at `/.well-known/openid-configuration` and
`/openid/v1/jwks` are designed to be OIDC compatible, but not strictly OIDC
compliant. Those documents contain only the parameters necessary to perform
validation of Kubernetes service account tokens.
-->
{{< note >}}
对 `/.well-known/openid-configuration` 和 `/openid/v1/jwks` 路径请求的响应
被设计为与 OIDC 兼容，但不是完全与其一致。
返回的文档仅包含对 Kubernetes 服务账号令牌进行验证所必须的参数。
{{< /note >}}
<!--
The JWKS response contains public keys that a relying party can use to validate
the Kubernetes service account tokens. Relying parties first query for the
OpenID Provider Configuration, and use the `jwks_uri` field in the response to
find the JWKS.
-->
JWKS 响应包含依赖方可以用来验证 Kubernetes 服务账号令牌的公钥数据。
依赖方先会查询 OpenID 提供者配置，之后使用返回响应中的 `jwks_uri` 来查找
JWKS。
<!--
In many cases, Kubernetes API servers are not available on the public internet,
but public endpoints that serve cached responses from the API server can be made
available by users or service providers. In these cases, it is possible to
override the `jwks_uri` in the OpenID Provider Configuration so that it points
to the public endpoint, rather than the API server's address, by passing the
`--service-account-jwks-uri` flag to the API server. Like the issuer URL, the
JWKS URI is required to use the `https` scheme.
-->
在很多场合，Kubernetes API 服务器都不会暴露在公网上，不过对于缓存并向外提供 API
服务器响应数据的公开末端而言，用户或者服务提供商可以选择将其暴露在公网上。
在这种环境中，可能会重载 OpenID 提供者配置中的
`jwks_uri`，使之指向公网上可用的末端地址，而不是 API 服务器的地址。
这时需要向 API 服务器传递 `--service-account-jwks-uri` 参数。
与分发者 URL 类似，此 JWKS URI 也需要使用 `https` 模式。
## {{% heading "whatsnext" %}}
<!--
- [Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/)
- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
- [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html)
-->
- [服务账号的集群管理员指南](/zh/docs/reference/access-authn-authz/service-accounts-admin/)
- [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md)
- [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)
content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md
+80 -88
View File
@@ -4,19 +4,12 @@ content_type: task
weight: 50
---
<!--
---
title: Configure a Pod to Use a Volume for Storage
content_type: task
weight: 50
---
-->
<!-- overview -->
此页面展示了如何配置 Pod 以使用卷进行存储。
只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。对于独立于容器的持久化存储，您可以使用[卷](/docs/concepts/storage/volumes/)。这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。
<!--
This page shows how to configure a Pod to use a Volume for storage.
@@ -26,21 +19,18 @@ consistent storage that is independent of the Container, you can use a
[Volume](/docs/concepts/storage/volumes/). This is especially important for stateful
applications, such as key-value stores (such as Redis) and databases.
-->
此页面展示了如何配置 Pod 以使用卷进行存储。
只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。
对于独立于容器的持久化存储，你可以使用[卷](/zh/docs/concepts/storage/volumes/)。
这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 为 Pod 配置卷
在本练习中，您将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为 [emptyDir](/docs/concepts/storage/volumes/#emptydir) 的卷，在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：
<!--
## Configure a volume for a Pod
@@ -51,145 +41,143 @@ Volume of type
that lasts for the life of the Pod, even if the Container terminates and
restarts. Here is the configuration file for the Pod:
-->
## 为 Pod 配置卷 {#configure-a-volume-for-a-pod}
在本练习中，你将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为
[emptyDir](/zh/docs/concepts/storage/volumes/#emptydir) 的卷，
在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置：
{{< codenew file="pods/storage/redis.yaml" >}}
1. 创建 Pod:
<!--
1.Create the Pod:
-->
1. 创建 Pod:
```shell
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
```
```shell
kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
```
1. 验证 Pod 中的容器是否正在运行，然后留意 Pod 的更改：
<!--
1.Verify that the Pod's Container is running, and then watch for changes to
the Pod:
1.Verify that the Pod's Container is running, and then watch for changes to the Pod:
-->
2. 验证 Pod 中的容器是否正在运行，然后留意 Pod 的更改：
```shell
kubectl get pod redis --watch
```
```shell
kubectl get pod redis --watch
```
输出如下：
输出如下：
```shell
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
```
```shell
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
```
1. 在另一个终端，用 shell 连接正在运行的容器：
<!--
1.In another terminal, get a shell to the running Container:
-->
3. 在另一个终端，用 shell 连接正在运行的容器：
```shell
kubectl exec -it redis -- /bin/bash
```
```shell
kubectl exec -it redis -- /bin/bash
```
1. 在您的 shell 终端中，切换到 `/data/redis` 目录下，然后创建一个文件：
<!--
1.In your shell, go to `/data/redis`, and then create a file:
-->
4. 在你的 Shell中，切换到 `/data/redis` 目录下，然后创建一个文件：
```shell
root@redis:/data# cd /data/redis/
root@redis:/data/redis# echo Hello > test-file
```
```shell
root@redis:/data# cd /data/redis/
root@redis:/data/redis# echo Hello > test-file
```
1. 在您的 shell 终端中，列出正在运行的进程：
<!--
1.In your shell, list the running processes:
-->
5. 在你的 Shell 中，列出正在运行的进程：
```shell
root@redis:/data/redis# apt-get update
root@redis:/data/redis# apt-get install procps
root@redis:/data/redis# ps aux
```
```shell
root@redis:/data/redis# apt-get update
root@redis:/data/redis# apt-get install procps
root@redis:/data/redis# ps aux
```
输出类似于：
输出类似于：
```shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
```
```shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
```
1. 在您的 shell 终端中，结束 Redis 进程：
<!--
1.In your shell, kill the Redis process:
-->
6. 在你的 Shell 中，结束 Redis 进程：
```shell
root@redis:/data/redis# kill <pid>
```
```shell
root@redis:/data/redis# kill <pid>
```
其中 `<pid>` 是 Redis 进程的 ID (PID)。
其中 `<pid>` 是 Redis 进程的 ID (PID)。
1. 在您原先终端中，留意 Redis Pod 的更改。最终您将会看到和下面类似的输出：
<!--
1. In your original terminal, watch for changes to the Redis Pod. Eventually,
you will see something like this:
-->
7. 在你原先终端中，留意 Redis Pod 的更改。最终你将会看到和下面类似的输出：
```shell
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
redis 0/1 Completed 0 6m
redis 1/1 Running 1 6m
```
```shell
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
redis 0/1 Completed 0 6m
redis 1/1 Running 1 6m
```
此时，容器已经终止并重新启动。这是因为 Redis Pod 的 [restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 为 `Always`。
<!--
At this point, the Container has terminated and restarted. This is because the
Redis Pod has a
[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
of `Always`.
-->
此时，容器已经终止并重新启动。这是因为 Redis Pod 的
[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
为 `Always`。
1. 用 shell 终端进入重新启动的容器中：
<!--
1.Get a shell into the restarted Container:
-->
1. 用 Shell 进入重新启动的容器中：
```shell
kubectl exec -it redis -- /bin/bash
```
```shell
kubectl exec -it redis -- /bin/bash
```
1. 在您的 shell 终端中，进入到 `/data/redis` 目录下，并确认 `test-file` 文件是否仍然存在。
<!--
1.In your shell, goto `/data/redis`, and verify that `test-file` is still there.
-->
2. 在你的 Shell 中，进入到 `/data/redis` 目录下，并确认 `test-file` 文件是否仍然存在。
```shell
root@redis:/data/redis# cd /data/redis/
root@redis:/data/redis# ls
test-file
```
```shell
root@redis:/data/redis# cd /data/redis/
root@redis:/data/redis# ls
test-file
```
1. 删除为此练习所创建的 Pod：
<!--
1.Delete the Pod that you created for this exercise:
-->
3. 删除为此练习所创建的 Pod：
```shell
kubectl delete pod redis
```
```shell
kubectl delete pod redis
```
## {{% heading "whatsnext" %}}
* 参阅[卷](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)。
* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
* 除了 `emptyDir` 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案，包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节，例如安装和卸载设备。了解更多详情请参阅[卷](/docs/concepts/storage/volumes/)。
<!--
* See [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core).
@@ -201,5 +189,9 @@ GCE and EBS on EC2, which are preferred for critical data and will handle
details such as mounting and unmounting the devices on the nodes. See
[Volumes](/docs/concepts/storage/volumes/) for more details.
-->
* 参阅 [Volume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)。
* 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。
* 除了 `emptyDir` 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案，
包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节，
例如安装和卸载设备。了解更多详情请参阅[卷](/zh/docs/concepts/storage/volumes/)。
content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
+29 -53
View File
@@ -5,11 +5,9 @@ weight: 100
---
<!--
---
title: Pull an Image from a Private Registry
content_type: task
weight: 100
---
-->
<!-- overview -->
@@ -18,24 +16,17 @@ weight: 100
This page shows how to create a Pod that uses a Secret to pull an image from a
private Docker registry or repository.
-->
本文介绍如何使用 Secret 从私有的 Docker 镜像仓库或代码仓库拉取镜像来创建 Pod。
## {{% heading "prerequisites" %}}
* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
* To do this exercise, you need a
[Docker ID](https://docs.docker.com/docker-id/) and password.
-->
您需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。
你需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。
<!-- steps -->
@@ -44,7 +35,6 @@ private Docker registry or repository.
On your laptop, you must authenticate with a registry in order to pull a private image:
-->
## 登录 Docker 镜像仓库
在个人电脑上，要想拉取私有镜像必须在镜像仓库上进行身份验证。
@@ -60,8 +50,7 @@ The login process creates or updates a `config.json` file that holds an authoriz
View the `config.json` file:
-->
当提示时，输入 Docker 用户名和密码。
当出现提示时，输入 Docker 用户名和密码。
登录过程会创建或更新保存有授权令牌的 `config.json` 文件。
@@ -74,7 +63,6 @@ cat ~/.docker/config.json
<!--
The output contains a section similar to this:
-->
输出结果包含类似于以下内容的部分：
```json
@@ -87,10 +75,10 @@ The output contains a section similar to this:
}
```
{{< note >}}
<!--
If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value.
-->
{{< note >}}
如果使用 Docker 凭证仓库，则不会看到 `auth` 条目，看到的将是以仓库名称作为值的 `credsStore` 条目。
{{< /note >}}
@@ -101,15 +89,21 @@ A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate w
Create this Secret, naming it `regcred`:
-->
## 在集群中创建保存授权令牌的 Secret
Kubernetes 集群使用 `docker-registry` 类型的 Secret 来通过容器仓库的身份验证，进而提取私有映像。
创建 Secret，命名为 `regcred`：
```shell
<!--
kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>
-->
```shell
kubectl create secret docker-registry regcred \
--docker-server=<你的镜像仓库服务器> \
--docker-username=<你的用户名> \
--docker-password=<你的密码> \
--docker-email=<你的邮箱地址>
```
<!--
@@ -122,22 +116,21 @@ where:
You have successfully set your Docker credentials in the cluster as a Secret called `regcred`.
-->
在这里：
* `<your-registry-server>` 是你的私有 Docker 仓库全限定域名（FQDN）。(参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分)
* `<your-registry-server>` 是你的私有 Docker 仓库全限定域名（FQDN）。
(参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分)
* `<your-name>` 是你的 Docker 用户名。
* `<your-pword>` 是你的 Docker 密码。
* `<your-email>` 是你的 Docker 邮箱。
这样您就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。
这样你就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。
<!--
## Inspecting the Secret `regcred`
To understand the contents of the `regcred` Secret you just created, start by viewing the Secret in YAML format:
-->
## 检查 Secret `regcred`
要了解你创建的 `regcred` Secret 的内容，可以用 YAML 格式进行查看：
@@ -146,10 +139,7 @@ To understand the contents of the `regcred` Secret you just created, start by vi
kubectl get secret regcred --output=yaml
```
<!--
The output is similar to this:
-->
<!-- The output is similar to this: -->
输出和下面类似：
```yaml
@@ -170,7 +160,6 @@ The value of the `.dockerconfigjson` field is a base64 representation of your Do
To understand what is in the `.dockerconfigjson` field, convert the secret data to a
readable format:
-->
`.dockerconfigjson` 字段的值是 Docker 凭据的 base64 表示。
要了解 `dockerconfigjson` 字段中的内容，请将 Secret 数据转换为可读格式：
@@ -179,10 +168,7 @@ readable format:
kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
```
<!--
The output is similar to this:
-->
<!-- The output is similar to this: -->
输出和下面类似：
```json
@@ -192,7 +178,6 @@ The output is similar to this:
<!--
To understand what is in the `auth` field, convert the base64-encoded data to a readable format:
-->
要了解 `auth` 字段中的内容，请将 base64 编码过的数据转换为可读格式：
```shell
@@ -202,7 +187,6 @@ echo "c3R...zE2" | base64 --decode
<!--
The output, username and password concatenated with a `:`, is similar to this:
-->
输出结果中，用户名和密码用 `:` 链接，类似下面这样：
```none
@@ -213,26 +197,23 @@ janedoe:xxxxxxxxxxx
Notice that the Secret data contains the authorization token similar to your local `~/.docker/config.json` file.
You have successfully set your Docker credentials as a Secret called `regcred` in the cluster.
-->
注意，Secret 数据包含与本地 `~/.docker/config.json` 文件类似的授权令牌。
这样你就已经成功地将 Docker 凭据设置为集群中的名为 `regcred` 的 Secret。
<!--
## Create a Pod that uses your Secret
Here is a configuration file for a Pod that needs access to your Docker credentials in `regcred`:
-->
注意，Secret 数据包含与本地 `~/.docker/config.json` 文件类似的授权令牌。
这样您就已经成功地将 Docker 凭据设置为集群中的名为 `regcred` 的 Secret。
## 创建一个使用您的 Secret 的 Pod
## 创建一个使用你的 Secret 的 Pod
下面是一个 Pod 配置文件，它需要访问 `regcred` 中的 Docker 凭据：
{{< codenew file="pods/private-reg-pod.yaml" >}}
<!--
Download the above file:
-->
<!-- Download the above file: -->
下载上述文件：
```shell
@@ -242,7 +223,6 @@ wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yam
<!--
In file `my-private-reg-pod.yaml`, replace `<your-private-image>` with the path to an image in a private registry such as:
-->
在`my-private-reg-pod.yaml` 文件中，使用私有仓库的镜像路径替换 `<your-private-image>`，例如：
```none
@@ -255,22 +235,18 @@ The `imagePullSecrets` field in the configuration file specifies that Kubernetes
Create a Pod that uses your Secret, and verify that the Pod is running:
-->
要从私有仓库拉取镜像，Kubernetes 需要凭证。
配置文件中的 `imagePullSecrets` 字段表明 Kubernetes 应该通过名为 `regcred` 的 Secret 获取凭证。
创建使用了你的 Secret 的 Pod，并检查它是否正常运行：
```shell
kubectl create -f my-private-reg-pod.yaml
kubectl apply -f my-private-reg-pod.yaml
kubectl get pod private-reg
```
## {{% heading "whatsnext" %}}
<!--
* Learn more about [Secrets](/docs/concepts/configuration/secret/).
* Learn more about [using a private registry](/docs/concepts/containers/images/#using-a-private-registry).
@@ -279,10 +255,10 @@ kubectl get pod private-reg
* See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
-->
* 进一步了解 [Secrets](/docs/concepts/configuration/secret/)。
* 进一步了解 [使用私有仓库](/docs/concepts/containers/images/#using-a-private-registry)。
* 参考 [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)。
* 参考 [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)。
* 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `imagePullSecrets` 字段 。
* 进一步了解 [Secret](/zh/docs/concepts/configuration/secret/)
* 进一步了解 [使用私有仓库](/zh/docs/concepts/containers/images/#using-a-private-registry)
* 参考 [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)
* 参考 [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
* 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `imagePullSecrets` 字段
content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
+13 -47
View File
@@ -5,11 +5,9 @@ weight: 30
---
<!--
---
title: Configure Quality of Service for Pods
content_type: task
weight: 30
---
-->
<!-- overview -->
@@ -19,20 +17,13 @@ This page shows how to configure Pods so that they will be assigned particular
Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about
scheduling and evicting Pods.
-->
本文介绍怎样配置 Pod 让其获得特定的服务质量（QoS）类。Kubernetes 使用 QoS 类来决定 Pod 的调度和驱逐策略。
本页介绍怎样配置 Pod 让其获得特定的服务质量（QoS）类。Kubernetes 使用 QoS 类来决定 Pod 的调度和驱逐策略。
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
@@ -40,8 +31,7 @@ scheduling and evicting Pods.
When Kubernetes creates a Pod it assigns one of these QoS classes to the Pod:
-->
## QoS 类
## QoS 类 {#qos-classes}
Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：
@@ -75,7 +65,6 @@ For a Pod to be given a QoS class of Guaranteed:
Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU:
-->
## 创建一个 QoS 类为 Guaranteed 的 Pod
对于 QoS 类为 Guaranteed 的 Pod：
@@ -134,14 +123,13 @@ status:
qosClass: Guaranteed
```
{{< note >}}
<!--
If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
CPU limit, but does not specify a CPU request, Kubernetes automatically assigns a CPU request that matches
the limit.
-->
{{< note >}}
如果容器指定了自己的内存限制，但没有指定内存请求，Kubernetes 会自动为它指定与内存限制匹配的内存请求。
同样，如果容器指定了自己的 CPU 限制，但没有指定 CPU 请求，Kubernetes 会自动为它指定与 CPU 限制匹配的 CPU 请求。
{{< /note >}}
@@ -167,7 +155,6 @@ A Pod is given a QoS class of Burstable if:
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
and a memory request of 100 MiB.
-->
## 创建一个 QoS 类为 Burstable 的 Pod
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
@@ -225,7 +212,6 @@ status:
<!--
Delete your Pod:
-->
删除 Pod：
```shell
@@ -241,7 +227,6 @@ have any memory or CPU limits or requests.
Here is the configuration file for a Pod that has one Container. The Container has no memory or CPU
limits or requests:
-->
## 创建一个 QoS 类为 BestEffort 的 Pod
对于 QoS 类为 BestEffort 的 Pod，Pod 中的容器必须没有设置内存和 CPU 限制或请求。
@@ -249,14 +234,11 @@ limits or requests:
下面是包含一个容器的 Pod 配置文件。
容器没有设置内存和 CPU 限制或请求。
{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod：
```shell
@@ -266,7 +248,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qo
<!--
View detailed information about the Pod:
-->
查看 Pod 详情：
```shell
@@ -276,7 +257,6 @@ kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml
<!--
The output shows that Kubernetes gave the Pod a QoS class of BestEffort.
-->
结果表明 Kubernetes 为 Pod 配置的 QoS 类为 BestEffort。
```yaml
@@ -292,7 +272,6 @@ status:
<!--
Delete your Pod:
-->
删除 Pod：
```shell
@@ -305,14 +284,12 @@ kubectl delete pod qos-demo-3 --namespace=qos-example
Here is the configuration file for a Pod that has two Containers. One container specifies a memory
request of 200 MiB. The other Container does not specify any requests or limits.
-->
## 创建包含两个容器的 Pod
下面是包含两个容器的 Pod 配置文件。
一个容器指定了内存请求 200 MiB。
另外一个容器没有指定任何请求和限制。
{{< codenew file="pods/qos/qos-pod-4.yaml" >}}
<!--
@@ -321,7 +298,6 @@ criteria for QoS class Guaranteed, and one of its Containers has a memory reques
Create the Pod:
-->
注意此 Pod 满足 Burstable QoS 类的标准。
也就是说它不满足 Guaranteed QoS 类标准，因为它的一个容器设有内存请求。
@@ -334,7 +310,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qo
<!--
View detailed information about the Pod:
-->
查看 Pod 详情：
```shell
@@ -344,7 +319,6 @@ kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml
<!--
The output shows that Kubernetes gave the Pod a QoS class of Burstable:
-->
结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable：
```yaml
@@ -366,7 +340,6 @@ status:
<!--
Delete your Pod:
-->
删除 Pod：
```shell
@@ -378,7 +351,6 @@ kubectl delete pod qos-demo-4 --namespace=qos-example
Delete your namespace:
-->
## 环境清理
删除命名空间：
@@ -387,12 +359,8 @@ Delete your namespace:
kubectl delete namespace qos-example
```
## {{% heading "whatsnext" %}}
<!--
### For app developers
@@ -400,12 +368,11 @@ kubectl delete namespace qos-example
* [Assign CPU Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/)
-->
### 应用开发者参考
* [为 Pod 和容器分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为 Pod 和容器分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)
* [为 Pod 和容器分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/)
* [为 Pod 和容器分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/)
<!--
### For cluster administrators
@@ -429,21 +396,20 @@ kubectl delete namespace qos-example
### 集群管理员参考
* [为命名空间配置默认的内存请求和限制](/docs/tasks/administer-cluster/memory-default-namespace/)
* [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
* [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace)
* [为命名空间配置默认的 CPU 请求和限制](/docs/tasks/administer-cluster/cpu-default-namespace/)
* [为命名空间配置最小和最大内存限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
* [为命名空间配置最小和最大内存限制](/docs/tasks/administer-cluster/memory-constraint-namespace/)
* [为命名空间配置最小和最大 CPU 限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
* [为命名空间配置最小和最大 CPU 限制](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
* [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)
* [为命名空间配置内存和 CPU 配额](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
* [为命名空间配置 Pod 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)
* [为命名空间配置 Pod 配额](/docs/tasks/administer-cluster/quota-pod-namespace/)
* [为 API 对象配置配额](/zh/docs/tasks/administer-cluster/quota-api-object/)
* [为 API 对象配置配额](/docs/tasks/administer-cluster/quota-api-object/)
* [控制节点上的拓扑管理策略](/docs/tasks/administer-cluster/topology-manager/)
* [控制节点上的拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)