kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[zh] Tidy up and fix links in tasks section (4/10)

pull/23195/head
Qiming Teng 2020-08-12 11:25:19 +08:00
parent fb6364da0a
commit a3a745838b
13 changed files with 598 additions and 637 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
content/zh/docs/concepts/containers/images.md
View File

@ -89,34 +89,34 @@ Instead, specify a meaningful tag such as `v1.42.0`.
<!--
## Updating Images
The default pull policy is `IfNotPresent` which causes the Kubelet to skip
The default pull policy is `IfNotPresent` which causes the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
pulling an image if it already exists. If you would like to always force a pull,
you can do one of the following:
-->
## 更新镜像 {#updating-images}
默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，`kubelet` 将不再去拉取镜像。
如果希望强制总是拉取镜像，你可以执行以下操作之一：
<!--
- set the `imagePullPolicy` of the container to `Always`.
- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
- omit the `imagePullPolicy` and the tag for the image to use.
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
-->
## 更新镜像 {#updating-images}
默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 将不再去拉取镜像。
如果希望强制总是拉取镜像，你可以执行以下操作之一：
- 设置容器的 `imagePullPolicy` 为 `Always`。
- 省略 `imagePullPolicy`，并使用 `:latest` 作为要使用的镜像的标签。
- 省略 `imagePullPolicy` 和要使用的镜像标签。
- 启用 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)
准入控制器（Admission Controller）。
<!--
When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
-->
如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。
<!--
## Building Multi-architecture Images with Manifests
## Multi-architecture Images with Manifests
As well as providing binary images, a container registry can also serve a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
@ -139,27 +139,27 @@ YAML 文件也能兼容。
<!--
## Using a Private Registry
Private registries may require keys to read images from them.
Private registries may require keys to read images from them.
Credentials can be provided in several ways:
-->
## 使用私有仓库 {#using-a-private-registry}
## 使用私有仓库 {#using-a-private-registry}
从私有仓库读取镜像时可能需要密钥。
凭据信息可以用以下方式提供:
凭证可以用以下方式提供:
<!--
- Configuring Nodes to Authenticate to a Private Registry
- all pods can read any configured private registries
- requires node configuration by cluster administrator
- Pre-pulled Images
- all pods can use any images cached on a node
- requires root access to all nodes to setup
- Specifying ImagePullSecrets on a Pod
- only pods which provide own keys can access the private registry
- Vendor-specific or local extensions
- if you're using a custom node configuration, you (or your cloud
provider) can implement your mechanism for authenticating the node
to the container registry.
- Configuring Nodes to Authenticate to a Private Registry
- all pods can read any configured private registries
- requires node configuration by cluster administrator
- Pre-pulled Images
- all pods can use any images cached on a node
- requires root access to all nodes to setup
- Specifying ImagePullSecrets on a Pod
- only pods which provide own keys can access the private registry
- Vendor-specific or local extensions
- if you're using a custom node configuration, you (or your cloud
provider) can implement your mechanism for authenticating the node
to the container registry.
-->
- 配置节点向私有仓库进行身份验证
- 所有 Pod 均可读取任何已配置的私有仓库
@ -174,9 +174,9 @@ Credentials can be provided in several ways:
向容器仓库认证的机制
<!--
These options are explained in more detail below.
These options are explaind in more detail below.
-->
下面将详细描述每一种方案。
下面将详细描述每一项。
<!--
### Configuring Nodes to authenticate to a Private Registry
@ -299,21 +299,6 @@ EOF
pod/private-image-test-1 created
```
<!--
If everything is working, then, after a few moments, you can run:
-->
如果一切正常，一段时间后，可以运行:
```shell
kubectl logs private-image-test-1
```
并看到命令输出为：
```
SUCCESS
```
<!--
If you suspect that the command failed, you can run:
-->
@ -388,7 +373,7 @@ All pods will have read access to any pre-pulled images.
<!--
### Specifying ImagePullSecrets on a Pod
-->
### 为 Pod 设置 ImagePullSecrets
### 在 Pod 上指定 ImagePullSecrets {#specifying-imagepullsecrets-on-a-pod}
<!--
This is the recommended approach to run containers based on images
@ -408,9 +393,9 @@ Kubernetes 支持在 Pod 中设置容器镜像仓库的密钥。
Run the following command, substituting the appropriate uppercase values:
-->
#### 创建包含 Docker 配置的Secret
#### 使用 Docker Config 创建 Secret {#creating-a-secret-with-docker-config}
将大写字母代替为合适的值，运行以下命令：
运行以下命令，将大写字母代替为合适的值：
```shell
kubectl create secret docker-registry <名称> \

4
content/zh/docs/setup/learning-environment/minikube.md
View File

@ -374,12 +374,10 @@ minikube start --kubernetes-version {{< param "fullversion" >}}
```
<!--
#### Specifying the VM driver
-->
#### 指定 VM 驱动程序
<!--
You can change the VM driver by adding the `--vm-driver=<enter_driver_name>` flag to `minikube start`.
-->
#### 指定 VM 驱动程序 {#specifying-the-vm-driver}
您可以通过将 `--vm-driver=<enter_driver_name>` 参数添加到 `minikube start` 来更改 VM 驱动程序。
<!--

2
content/zh/docs/tasks/access-application-cluster/access-cluster.md
View File

@ -268,7 +268,7 @@ is associated with a service account, and a credential (token) for that
service account is placed into the filesystem tree of each container in that pod,
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
-->
### 从 Pod 中访问 API
### 从 Pod 中访问 API {#accessing-the-api-from-a-pod}
当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。

91
content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md
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)设计文档。

376
content/zh/docs/tasks/configure-pod-container/configure-service-account.md
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)

168
content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md
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/)。

82
content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md
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` 字段

60
content/zh/docs/tasks/configure-pod-container/quality-service-pod.md
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：
@ -133,14 +122,13 @@ spec:
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 >}}
@ -166,7 +154,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：
@ -223,7 +210,6 @@ spec:
<!--
Delete your Pod:
-->
删除 Pod：
```shell
@ -239,7 +225,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 限制或请求。
@ -247,14 +232,11 @@ limits or requests:
下面是包含一个容器的 Pod 配置文件。
容器没有设置内存和 CPU 限制或请求。
{{< codenew file="pods/qos/qos-pod-3.yaml" >}}
<!--
Create the Pod:
-->
创建 Pod：
```shell
@ -264,7 +246,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qo
<!--
View detailed information about the Pod:
-->
查看 Pod 详情：
```shell
@ -274,7 +255,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
@ -289,7 +269,6 @@ spec:
<!--
Delete your Pod:
-->
删除 Pod：
```shell
@ -302,14 +281,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" >}}
<!--
@ -318,7 +295,6 @@ criteria for QoS class Guaranteed, and one of its Containers has a memory reques
Create the Pod:
-->
注意此 Pod 满足 Burstable QoS 类的标准。
也就是说它不满足 Guaranteed QoS 类标准，因为它的一个容器设有内存请求。
@ -331,7 +307,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qo
<!--
View detailed information about the Pod:
-->
查看 Pod 详情：
```shell
@ -341,7 +316,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
@ -362,7 +336,6 @@ spec:
<!--
Delete your Pod:
-->
删除 Pod：
```shell
@ -374,7 +347,6 @@ kubectl delete pod qos-demo-4 --namespace=qos-example
Delete your namespace:
-->
## 环境清理
删除命名空间：
@ -383,12 +355,8 @@ Delete your namespace:
kubectl delete namespace qos-example
```
## {{% heading "whatsnext" %}}
<!--
### For app developers
@ -396,12 +364,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
@ -425,21 +392,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/)

100
content/zh/docs/tasks/manage-kubernetes-objects/imperative-config.md
View File

@ -4,11 +4,9 @@ content_type: task
weight: 40
---
<!--
---
title: Imperative Management of Kubernetes Objects Using Configuration Files
content_type: task
weight: 40
---
-->
<!-- overview -->
@ -20,29 +18,24 @@ This document explains how to define and manage objects using configuration file
可以使用 `kubectl` 命令行工具以及用 YAML 或 JSON 编写的对象配置文件来创建、更新和删除 Kubernetes 对象。
本文档说明了如何使用配置文件定义和管理对象。
## {{% heading "prerequisites" %}}
<!--
Install [`kubectl`](/docs/tasks/tools/install-kubectl/).
-->
安装 [`kubectl`](/docs/tasks/tools/install-kubectl/) 。
安装 [`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 。
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!--
## Trade-offs
The `kubectl` tool supports three kinds of object management:
-->
## 权衡
<!--
The `kubectl` tool supports three kinds of object management:
-->
`kubectl` 工具支持三种对象管理：
<!--
@ -58,30 +51,26 @@ The `kubectl` tool supports three kinds of object management:
See [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/)
for a discussion of the advantages and disadvantage of each kind of object management.
-->
参看 [Kubernetes 对象管理](/docs/concepts/overview/working-with-objects/object-management/) 讨论每种对象管理的优缺点。
参看 [Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)
中关于每种对象管理的优缺点的讨论。
<!--
## How to create objects
-->
## 如何创建对象
<!--
You can use `kubectl create -f` to create an object from a configuration file.
Refer to the [kubernetes API reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
for details.
-->
您可以使用 `kubectl create -f` 从配置文件创建一个对象。
## 如何创建对象
你可以使用 `kubectl create -f` 从配置文件创建一个对象。
请参考 [kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 有关详细信息。
* `kubectl create -f <filename|url>`
<!--
## How to update objects
-->
## 如何更新对象
{{< warning >}}
<!--
Updating objects with the `replace` command drops all
parts of the spec not specified in the configuration file. This
should not be used with objects whose specs are partially managed
@ -90,8 +79,12 @@ the `externalIPs` field is managed independently from the configuration
file. Independently managed fields must be copied to the configuration
file to prevent `replace` from dropping them.
-->
## 如何更新对象
{{< warning >}}
使用 `replace` 命令更新对象会删除所有未在配置文件中指定的规范的某些部分。
不应将其规范由集群部分管理的对象使用，比如类型为 `LoadBalancer` 的服务，其中 `externalIPs` 字段独立于配置文件进行管理。
不应将其规范由集群部分管理的对象使用，比如类型为 `LoadBalancer` 的服务，
其中 `externalIPs` 字段独立于配置文件进行管理。
必须将独立管理的字段复制到配置文件中，以防止 `replace` 删除它们。
{{< /warning >}}
@ -99,33 +92,31 @@ file to prevent `replace` from dropping them.
You can use `kubectl replace -f` to update a live object according to a
configuration file.
-->
您可以使用 `kubectl replace -f` 根据配置文件更新活动对象。
你可以使用 `kubectl replace -f` 根据配置文件更新活动对象。
* `kubectl replace -f <filename|url>`
<!--
## How to delete objects
-->
## 如何删除对象
<!--
You can use `kubectl delete -f` to delete an object that is described in a
configuration file.
-->
您可以使用 `kubectl delete -f` 删除配置文件中描述的对象。
## 如何删除对象
你可以使用 `kubectl delete -f` 删除配置文件中描述的对象。
* `kubectl delete -f <filename|url>`
<!--
## How to view an object
-->
## 如何查看对象
<!--
You can use `kubectl get -f` to view information about an object that is
described in a configuration file.
-->
您可以使用 `kubectl get -f` 查看有关配置文件中描述的对象的信息。
## 如何查看对象
你可以使用 `kubectl get -f` 查看有关配置文件中描述的对象的信息。
* `kubectl get -f <filename|url> -o yaml`
@ -138,10 +129,7 @@ Use `kubectl get -h` to see a list of options.
<!--
## Limitations
-->
## 局限性
<!--
The `create`, `replace`, and `delete` commands work well when each object's
configuration is fully defined and recorded in its configuration
file. However when a live object is updated, and the updates are not merged
@ -150,6 +138,8 @@ is executed. This can happen if a controller, such as
a HorizontalPodAutoscaler, makes updates directly to a live object. Here's
an example:
-->
## 局限性
当完全定义每个对象的配置并将其记录在其配置文件中时，`create`、 `replace` 和`delete` 命令会很好的工作。
但是，当更新一个活动对象，并且更新没有合并到其配置文件中时，下一次执行 `replace` 时，更新将丢失。
如果控制器,例如 HorizontalPodAutoscaler ,直接对活动对象进行更新，则会发生这种情况。
@ -173,17 +163,16 @@ If you need to support multiple writers to the same object, you can use
<!--
## Creating and editing an object from a URL without saving the configuration
-->
## 从 URL 创建和编辑对象而不保存配置
<!--
Suppose you have the URL of an object configuration file. You can use
`kubectl create --edit` to make changes to the configuration before the
object is created. This is particularly useful for tutorials and tasks
that point to a configuration file that could be modified by the reader.
-->
假设您具有对象配置文件的 URL。
您可以在创建对象之前使用 `kubectl create --edit` 对配置进行更改。
## 从 URL 创建和编辑对象而不保存配置
假设你具有对象配置文件的 URL。
你可以在创建对象之前使用 `kubectl create --edit` 对配置进行更改。
这对于指向可以由读者修改的配置文件的教程和任务特别有用。
```shell
@ -192,13 +181,12 @@ kubectl create -f <url> --edit
<!--
## Migrating from imperative commands to imperative object configuration
-->
## 从命令式命令迁移到命令式对象配置
<!--
Migrating from imperative commands to imperative object configuration involves
several manual steps.
-->
## 从命令式命令迁移到命令式对象配置
从命令式命令迁移到命令式对象配置涉及几个手动步骤。
<!--
@ -206,33 +194,33 @@ several manual steps.
-->
1. 将活动对象导出到本地对象配置文件：
```shell
kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
```
```shell
kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
```
<!--
1. Manually remove the status field from the object configuration file.
-->
1. 从对象配置文件中手动删除状态字段。
2. 从对象配置文件中手动删除状态字段。
<!--
1. For subsequent object management, use `replace` exclusively.
-->
1. 对于后续的对象管理，只能使用 `replace` 。
3. 对于后续的对象管理，只能使用 `replace` 。
```shell
kubectl replace -f <kind>_<name>.yaml
```
```shell
kubectl replace -f <kind>_<name>.yaml
```
<!--
## Defining controller selectors and PodTemplate labels
-->
## 定义控制器选择器和 PodTemplate 标签
{{< warning >}}
<!--
Updating selectors on controllers is strongly discouraged.
-->
{{< warning >}}
不建议在控制器上更新选择器。
{{< /warning >}}
@ -242,9 +230,7 @@ used only by the controller selector with no other semantic meaning.
-->
推荐的方法是定义单个不变的 PodTemplate 标签，该标签仅由控制器选择器使用，而没有其他语义。
<!--
Example label:
-->
<!-- Example label: -->
标签示例：
```yaml
@ -257,21 +243,17 @@ template:
controller-selector: "apps/v1/deployment/nginx"
```
## {{% heading "whatsnext" %}}
<!--
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-->
* [使用命令式命令管理 Kubernetes 对象](/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [使用对象配置管理 Kubernetes 对象 (声明式)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl/)
* [使用命令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/)
* [使用对象配置管理 Kubernetes 对象 (声明式)](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/)
* [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
* [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)

53
content/zh/docs/tasks/network/validate-dual-stack.md
View File

@ -6,13 +6,11 @@ title: 验证 IPv4/IPv6 双协议栈
content_type: task
---
<!--
---
reviewers:
- lachie83
- khenidak
title: Validate IPv4/IPv6 dual-stack
content_type: task
---
-->
<!-- overview -->
@ -21,10 +19,8 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
-->
这篇文章分享了如何验证 IPv4/IPv6 双协议栈的 Kubernetes 集群。
## {{% heading "prerequisites" %}}
<!--
* Kubernetes 1.16 or later
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces)
@ -34,27 +30,24 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu
-->
* Kubernetes 1.16 或更高版本
* 提供程序对双协议栈网络的支持 (云供应商或其他方式必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口)
* Kubenet 网络插件
* 一个能够支持双协议栈的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，
（如 kubenet 或 Calico）。
* Kube-proxy 在 IPVS 模式下运行
* [启用双协议栈](/docs/concepts/services-networking/dual-stack/) 集群
* [启用双协议栈](/zh/docs/concepts/services-networking/dual-stack/) 集群
<!-- steps -->
<!--
## Validate addressing
### Validate node addressing
Each dual-stack Node should have a single IPv4 block and a single IPv6 block allocated. Validate that IPv4/IPv6 Pod address ranges are configured by running the following command. Replace the sample node name with a valid dual-stack Node from your cluster. In this example, the Node's name is `k8s-linuxpool1-34450317-0`:
-->
## 验证寻址
<!--
### Validate node addressing
-->
### 验证节点寻址
<!--
Each dual-stack Node should have a single IPv4 block and a single IPv6 block allocated. Validate that IPv4/IPv6 Pod address ranges are configured by running the following command. Replace the sample node name with a valid dual-stack Node from your cluster. In this example, the Node's name is `k8s-linuxpool1-34450317-0`:
-->
每个双协议栈节点应分配一个 IPv4 块和一个 IPv6 块。
通过运行以下命令来验证是否配置了 IPv4/IPv6 Pod 地址范围。
将示例节点名称替换为集群中的有效双协议栈节点。
@ -63,10 +56,12 @@ Each dual-stack Node should have a single IPv4 block and a single IPv6 block all
```shell
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}'
```
```
10.244.1.0/24
a00:100::/24
```
<!--
There should be one IPv4 block and one IPv6 block allocated.
-->
@ -75,7 +70,9 @@ There should be one IPv4 block and one IPv6 block allocated.
<!--
Validate that the node has an IPv4 and IPv6 interface detected (replace node name with a valid node from the cluster. In this example the node name is k8s-linuxpool1-34450317-0):
-->
验证节点是否检测到 IPv4 和 IPv6 接口（用集群中的有效节点替换节点名称。在此示例中，节点名称为 k8s-linuxpool1-34450317-0）：
验证节点是否检测到 IPv4 和 IPv6 接口（用集群中的有效节点替换节点名称。
在此示例中，节点名称为 `k8s-linuxpool1-34450317-0`）：
```shell
kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s \n" .type .address}}{{end}}'
```
@ -87,16 +84,17 @@ InternalIP: 2001:1234:5678:9abc::5
<!--
### Validate Pod addressing
Validate that a Pod has an IPv4 and IPv6 address assigned. (replace the Pod name with a valid Pod in your cluster. In this example the Pod name is pod01)
-->
### 验证 Pod 寻址
<!--
Validate that a Pod has an IPv4 and IPv6 address assigned. (replace the Pod name with a valid Pod in your cluster. In this example the Pod name is pod01)
-->
验证 Pod 已分配了 IPv4 和 IPv6 地址。（用集群中的有效 Pod 替换 Pod 名称。在此示例中， Pod 名称为 pod01）
```shell
kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s \n" .ip}}{{end}}'
```
```
10.244.1.4
a00:100::4
@ -123,6 +121,7 @@ The following command prints the value of the `MY_POD_IPS` environment variable
```shell
kubectl exec -it pod01 -- set | grep MY_POD_IPS
```
```
MY_POD_IPS=10.244.1.4,a00:100::4
```
@ -135,6 +134,7 @@ Pod 的 IP 地址也将被写入容器内的 `/etc/hosts` 文件中。在双栈
```shell
kubectl exec -it pod01 -- cat /etc/hosts
```
```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
@ -149,12 +149,11 @@ a00:100::4 pod01
<!--
## Validate Services
Create the following Service without the `ipFamily` field set. When this field is not set, the Service gets an IP from the first configured range via `--service-cluster-ip-range` flag on the kube-controller-manager.
-->
## 验证服务
<!--
Create the following Service without the `ipFamily` field set. When this field is not set, the Service gets an IP from the first configured range via `--service-cluster-ip-range` flag on the kube-controller-manager.
-->
在不设置 `ipFamily` 字段的情况下创建以下服务。
如果未设置此字段，则服务会通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志从第一个配置的范围中获取 IP。
@ -163,7 +162,8 @@ Create the following Service without the `ipFamily` field set. When this field i
<!--
By viewing the YAML for the Service you can observe that the Service has the `ipFamily` field has set to reflect the address family of the first configured range set via `--service-cluster-ip-range` flag on kube-controller-manager.
-->
通过查看该服务的 YAML ，您可以观察到该服务的 `ipFamily` 字段已设置为反映通过 kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置的第一个配置范围的地址族。
通过查看该服务的 YAML ，您可以观察到该服务的 `ipFamily` 字段已设置为反映通过
kube-controller-manager 上的 `--service-cluster-ip-range` 标志设置的第一个配置范围的地址族。
```shell
kubectl get svc my-service -o yaml
@ -216,12 +216,11 @@ my-service ClusterIP fe80:20d::d06b <none> 80/TCP 9s
<!--
### Create a dual-stack load balanced Service
If the cloud provider supports the provisioning of IPv6 enabled external load balancer, create the following Service with both the `ipFamily` field set to `IPv6` and the `type` field set to `LoadBalancer`
-->
### 创建双协议栈负载均衡服务
<!--
If the cloud provider supports the provisioning of IPv6 enabled external load balancer, create the following Service with both the `ipFamily` field set to `IPv6` and the `type` field set to `LoadBalancer`
-->
如果云提供商支持配置启用 IPv6 的外部负载均衡器，则将 `ipFamily` 字段设置为 `IPv6` 并将 `type` 字段设置为 `LoadBalancer`的方式创建以下服务
{{< codenew file="service/networking/dual-stack-ipv6-lb-svc.yaml" >}}
@ -237,7 +236,3 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S
my-service ClusterIP fe80:20d::d06b 2001:db8:f100:4002::9d37:c0d7 80:31868/TCP 30s
```

52
content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md
View File

@ -3,16 +3,14 @@ title: 使用 Helm 安装 Service Catalog
content_type: task
---
<!--
---
title: Install Service Catalog using Helm
reviewers:
- chenopis
content_type: task
---
-->
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}}
<!--
Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) repo.
@ -21,7 +19,6 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
要获取有关此过程的最新信息，请浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) 仓库。
## {{% heading "prerequisites" %}}
<!--
@ -35,27 +32,24 @@ Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes clust
* Follow the [Helm install instructions](https://github.com/kubernetes/helm/blob/master/docs/install.md).
* If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
-->
* 理解 [Service Catalog](/docs/concepts/service-catalog/) 的关键概念。
* 理解[服务目录](/zh/docs/concepts/service-catalog/) 的关键概念。
* Service Catalog 需要 Kubernetes 集群版本在 1.7 或更高版本。
* 您必须启用 Kubernetes 集群的 DNS 功能。
* 你必须启用 Kubernetes 集群的 DNS 功能。
* 如果使用基于云的 Kubernetes 集群或 {{< glossary_tooltip text="Minikube" term_id="minikube" >}}，则可能已经启用了集群 DNS。
* 如果您正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。
* 如果你正在使用 `hack/local-up-cluster.sh`，请确保设置了 `KUBE_ENABLE_CLUSTER_DNS` 环境变量，然后运行安装脚本。
* [安装和设置 v1.7 或更高版本的 kubectl](/zh/docs/tasks/tools/install-kubectl/)，确保将其配置为连接到 Kubernetes 集群。
* 安装 v2.7.0 或更高版本的 [Helm](http://helm.sh/)。
* 安装 v2.7.0 或更高版本的 [Helm](https://helm.sh/)。
* 遵照 [Helm 安装说明](https://github.com/kubernetes/helm/blob/master/docs/install.md)。
* 如果已经安装了适当版本的 Helm，请执行 `helm init` 来安装 Helm 的服务器端组件 Tiller。
<!-- steps -->
<!--
## Add the service-catalog Helm repository
Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
-->
## 添加 service-catalog Helm 仓库
<!--
Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
-->
安装 Helm 后，通过执行以下命令将 *service-catalog* Helm 存储库添加到本地计算机：
```shell
@ -83,18 +77,16 @@ svc-cat/catalog 0.0.1 service-catalog API server and controller-manag...
<!--
## Enable RBAC
Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access.
If you are using Minikube, run the `minikube start` command with the following flag:
-->
## 启用 RBAC
<!--
Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access.
-->
您的 Kubernetes 集群必须启用 RBAC，这需要您的 Tiller Pod 具有 `cluster-admin` 访问权限。
你的 Kubernetes 集群必须启用 RBAC，这需要你的 Tiller Pod 具有 `cluster-admin` 访问权限。
<!--
If you are using Minikube, run the `minikube start` command with the following flag:
-->
如果您使用的是 Minikube，请使用以下参数运行 `minikube start` 命令：
如果你使用的是 Minikube，请使用以下参数运行 `minikube start` 命令：
```shell
minikube start --extra-config=apiserver.Authorization.Mode=RBAC
@ -103,7 +95,7 @@ minikube start --extra-config=apiserver.Authorization.Mode=RBAC
<!--
If you are using `hack/local-up-cluster.sh`, set the `AUTHORIZATION_MODE` environment variable with the following values:
-->
如果您使用 `hack/local-up-cluster.sh`，请使用以下值设置 `AUTHORIZATION_MODE` 环境变量：
如果你使用 `hack/local-up-cluster.sh`，请使用以下值设置 `AUTHORIZATION_MODE` 环境变量：
```
AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
@ -114,11 +106,12 @@ By default, `helm init` installs the Tiller Pod into the `kube-system` namespace
-->
默认情况下，`helm init` 将 Tiller Pod 安装到 `kube-system` 命名空间，Tiller 配置为使用 `default` 服务帐户。
{{< note >}}
<!--
If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
-->
如果在运行 `helm init` 时使用了 `--tiller-namespace` 或 `--service-account` 参数，则需要调整以下命令中的 `--serviceaccount` 参数以引用相应的 namespace 和 ServiceAccount 名称。
{{< note >}}
如果在运行 `helm init` 时使用了 `--tiller-namespace` 或 `--service-account` 参数，
则需要调整以下命令中的 `--serviceaccount` 参数以引用相应的名字空间和服务账号名称。
{{< /note >}}
<!--
@ -134,12 +127,11 @@ kubectl create clusterrolebinding tiller-cluster-admin \
<!--
## Install Service Catalog in your Kubernetes cluster
Install Service Catalog from the root of the Helm repository using the following command:
-->
## 在 Kubernetes 集群中安装 Service Catalog
<!--
Install Service Catalog from the root of the Helm repository using the following command:
-->
使用以下命令从 Helm 存储库的根目录安装 Service Catalog：
{{< tabs name="helm-versions" >}}
@ -149,11 +141,12 @@ helm install catalog svc-cat/catalog --namespace catalog
```
{{% /tab %}}
{{% tab name="Helm version 2" %}}
```shell
helm install svc-cat/catalog --name catalog --namespace catalog
```
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
@ -163,3 +156,4 @@ helm install svc-cat/catalog --name catalog --namespace catalog
-->
* 查看[示例服务代理](https://github.com/openservicebrokerapi/servicebroker/blob/mastergettingStarted.md#sample-service-brokers)。
* 探索 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。

37
content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md
View File

@ -6,26 +6,23 @@ content_type: task
---
<!--
---
title: Install Service Catalog using SC
reviewers:
- chenopis
content_type: task
---
-->
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}}
<!--
Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) tool to easily install or uninstall Service Catalog on your Kubernetes cluster. This CLI tool is installed as `sc` in your local environment.
-->
使用[服务目录安装程序](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)工具可以轻松地在 Kubernetes 集群上安装或卸载服务目录。
使用[服务目录安装程序](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
工具可以轻松地在 Kubernetes 集群上安装或卸载服务目录。
这个 CLI 工具以 `sc` 命令形式被安装在您的本地环境中。
## {{% heading "prerequisites" %}}
<!--
@ -38,27 +35,25 @@ Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-s
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
-->
* 了解[服务目录](/docs/concepts/service-catalog/)的主要概念。
* 了解[服务目录](/zh/docs/concepts/service-catalog/)的主要概念。
* 安装 [Go 1.6+](https://golang.org/dl/) 以及设置 `GOPATH`。
* 安装生成 SSL 工件所需的 [cfssl](https://github.com/cloudflare/cfssl) 工具。
* 服务目录需要 Kubernetes 1.7+ 版本。
* [安装和设置 kubectl](/docs/tasks/tools/install-kubectl/)，以便将其配置为连接到 Kubernetes v1.7+ 集群。
* [安装和设置 kubectl](/zh/docs/tasks/tools/install-kubectl/)，以便将其配置为连接到 Kubernetes v1.7+ 集群。
* 要安装服务目录，kubectl 用户必须绑定到 *cluster-admin* 角色。为了确保这是正确的，请运行以下命令：
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
```
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
```
<!-- steps -->
<!--
## Install `sc` in your local environment
Install the `sc` CLI tool using the `go get` command:
-->
## 在本地环境中安装 `sc`
<!--
Install the `sc` CLI tool using the `go get` command:
-->
使用 `go get` 命令安装 `sc` CLI 工具：
```Go
@ -72,12 +67,11 @@ After running the above command, `sc` should be installed in your `GOPATH/bin` d
<!--
## Install Service Catalog in your Kubernetes cluster
First, verify that all dependencies have been installed. Run:
-->
## 在 Kubernetes 集群中安装服务目录
<!--
First, verify that all dependencies have been installed. Run:
-->
首先，检查是否已经安装了所有依赖项。运行：
```shell
@ -104,20 +98,17 @@ sc install --etcd-backup-storageclass "standard"
<!--
## Uninstall Service Catalog
If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run:
-->
## 卸载服务目录
<!--
If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run:
-->
如果您想使用 `sc` 工具从 Kubernetes 集群卸载服务目录，请运行：
```shell
sc uninstall
```
## {{% heading "whatsnext" %}}
<!--

133
content/zh/docs/tasks/tools/install-minikube.md
View File

@ -8,14 +8,12 @@ card:
---
<!--
---
title: Install Minikube
content_type: task
weight: 20
card:
name: tasks
weight: 10
---
-->
<!-- overview -->
@ -23,14 +21,10 @@ card:
<!--
This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a tool that runs a single-node Kubernetes cluster in a virtual machine on your personal computer.
-->
本页面讲述如何安装 [Minikube](/docs/tutorials/hello-minikube)，该工具用于在您电脑中的虚拟机上运行一个单节点的 Kubernetes 集群。
本页面讲述如何安装 [Minikube](/zh/docs/tutorials/hello-minikube)，该工具用于在你电脑中的虚拟机上运行一个单节点的 Kubernetes 集群。
## {{% heading "prerequisites" %}}
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="Linux" %}}
@ -38,7 +32,7 @@ This page shows you how to install [Minikube](/docs/tutorials/hello-minikube), a
To check if virtualization is supported on Linux, run the following command and verify that the output is non-empty:
-->
若要检查您的 Linux 是否支持虚拟化技术，请运行下面的命令并验证输出结果是否不为空：
若要检查你的 Linux 是否支持虚拟化技术，请运行下面的命令并验证输出结果是否不为空：
```
grep -E --color 'vmx|svm' /proc/cpuinfo
@ -51,8 +45,7 @@ grep -E --color 'vmx|svm' /proc/cpuinfo
<!--
To check if virtualization is supported on macOS, run the following command on your terminal.
-->
若要检查您的 macOS 是否支持虚拟化技术，请运行下面的命令：
若要检查你的 macOS 是否支持虚拟化技术，请运行下面的命令：
```
sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
@ -61,8 +54,7 @@ sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
<!--
If you see `VMX` in the output (should be colored), the VT-x feature is enabled in your machine.
-->
如果你在输出结果中看到了 `VMX` （应该会高亮显示）的字眼，说明您的电脑已启用 VT-x 特性。
如果你在输出结果中看到了 `VMX` （应该会高亮显示）的字眼，说明你的电脑已启用 VT-x 特性。
{{% /tab %}}
@ -70,8 +62,7 @@ If you see `VMX` in the output (should be colored), the VT-x feature is enabled
<!--
To check if virtualization is supported on Windows 8 and above, run the following command on your Windows terminal or command prompt.
-->
若要检查您的 Windows8 及以上的系统是否支持虚拟化技术，请终端或者 cmd 中运行以下命令：
若要检查你的 Windows8 及以上的系统是否支持虚拟化技术，请终端或者 cmd 中运行以下命令：
```
systeminfo
@ -79,8 +70,7 @@ systeminfo
<!--
If you see the following output, virtualization is supported on Windows.
-->
如果您看到下面的输出，则表示该 Windows 支持虚拟化技术。
如果你看到下面的输出，则表示该 Windows 支持虚拟化技术。
```
Hyper-V Requirements: VM Monitor Mode Extensions: Yes
@ -92,24 +82,19 @@ Hyper-V Requirements: VM Monitor Mode Extensions: Yes
<!--
If you see the following output, your system already has a Hypervisor installed and you can skip the next step.
-->
如果您看到下面的输出，则表示您的操作系统已经安装了 Hypervisor，您可以跳过安装 Hypervisor 的步骤。
如果你看到下面的输出，则表示你的操作系统已经安装了 Hypervisor，你可以跳过安装 Hypervisor 的步骤。
```
Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed.
```
{{% /tab %}}
{{< /tabs >}}
<!-- steps -->
<!--
# Installing minikube
-->
## 安装 minikube
{{< tabs name="tab_with_md" >}}
@ -120,10 +105,10 @@ Hyper-V Requirements: A hypervisor has been detected. Features required for
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux).
-->
### 安装 kubectl
请确保你已正确安装 kubectl。您可以根据[安装并设置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux) 的说明来安装 kubectl。
请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)
的说明来安装 kubectl。
<!--
### Install a Hypervisor
@ -141,9 +126,8 @@ If you do not already have a hypervisor installed, install one of these now:
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
-->
• [KVM](https://www.linux-kvm.org/)，也使用了 QEMU
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
- [KVM](https://www.linux-kvm.org/)，KVM 也使用了 QEMU
- [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
<!--
Minikube also supports a `--vm-driver=none` option that runs the Kubernetes components on the host and not in a VM.
@ -153,19 +137,17 @@ If you're using the `none` driver in Debian or a derivative, use the `.deb` pack
Docker rather than the snap package, which does not work with Minikube.
You can download `.deb` packages from [Docker](https://www.docker.com/products/docker-desktop).
-->
Minikube 还支持使用一个 `--vm-driver=none` 选项，让 Kubernetes 组件运行在主机中，而不是在 VM 中。
Minikube 还支持使用一个 `--vm-driver=none` 选项，让 Kubernetes 组件运行在主机上，而不是在 VM 中。
使用这种驱动方式需要 [Docker](https://www.docker.com/products/docker-desktop) 和 Linux 环境，但不需要 hypervisor。
如果你在 Debian 系的 OS 中使用了 `none` 这种驱动方式，请使用 `.deb` 包安装 Docker，不要使用 snap 包的方式，Minikube 不支持这种方式。
你可以从 [Docker](https://www.docker.com/products/docker-desktop) 下载 `.deb` 包。
{{< caution >}}
<!--
The `none` VM driver can result in security and data loss issues.
Before using `--vm-driver=none`, consult [this documentation](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) for more information.
-->
{{< caution >}}
`none` VM 驱动方式存在导致安全和数据丢失的问题。
使用 `--vm-driver=none` 之前，请参考[这个文档](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)获取详细信息。
{{< /caution >}}
@ -173,15 +155,16 @@ Before using `--vm-driver=none`, consult [this documentation](https://minikube.s
<!--
Minikube also supports a `vm-driver=podman` similar to the Docker driver. Podman run as superuser privilege (root user) is the best way to ensure that your containers have full access to any feature available on your system.
-->
Minikube 还支持另外一个类似于 Docker 驱动的方式 `vm-driver=podman`。
使用超级用户权限（root 用户）运行 Podman 可以最好的确保容器具有足够的权限使用你操作系统上的所有特性。
使用超级用户权限（root 用户）运行 Podman 可以最好的确保容器具有足够的权限使用
你的操作系统上的所有特性。
{{< caution >}}
<!--
The `podman` driver requires running the containers as root because regular user accounts don’t have full access to all operating system features that their containers might need to run.
-->
`Podman` 驱动方式需要以 root 用户身份运行容器，因为普通用户帐户没有足够的权限使用容器运行可能需要的操作系统上的所有特性。
{{< caution >}}
`Podman` 驱动需要以 root 用户身份运行容器，因为普通用户帐户没有足够的权限
使用容器运行可能需要的操作系统上的所有特性。
{{< /caution >}}
<!--
@ -192,12 +175,11 @@ from Minikube's [releases](https://github.com/kubernetes/minikube/releases) page
Use your Linux's distribution's package tool to install a suitable package.
-->
### 使用包安装 Minikube
Minikube 有 *实验性* 的安装包。你可以在 Minikube 在 GitHub 上的 [releases](https://github.com/kubernetes/minikube/releases) 找到 Linux (AMD64) 的包。
Minikube 有 *实验性* 的安装包。你可以在 Minikube 在 GitHub 上的[发行版本](https://github.com/kubernetes/minikube/releases) 找到 Linux (AMD64) 的包。
根据您的 Linux 发行版选择安装合适的包。
根据你的 Linux 发行版选择安装合适的包。
<!--
### Install Minikube via direct download
@ -205,7 +187,6 @@ Minikube 有 *实验性* 的安装包。你可以在 Minikube 在 GitHub 上的
If you're not installing via a package, you can download a stand-alone
binary and use that.
-->
### 直接下载并安装 Minikube
如果你不想通过包安装，你也可以下载并使用一个单节点二进制文件。
@ -218,7 +199,7 @@ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/miniku
<!--
Here's an easy way to add the Minikube executable to your path:
-->
将 Minikube 可执行文件添加至 path：
将 Minikube 可执行文件添加至 PATH：
```shell
sudo mkdir -p /usr/local/bin/
@ -230,7 +211,6 @@ sudo install minikube /usr/local/bin/
As yet another alternative, you can install Minikube using Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux):
-->
### 使用 Homebrew 安装 Minikube
你还可以使用 Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux) 安装 Minikube：
@ -240,6 +220,7 @@ brew install minikube
```
{{% /tab %}}
{{% tab name="macOS" %}}
<!--
@ -247,32 +228,28 @@ brew install minikube
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos).
-->
### 安装 kubectl
请确保你已正确安装 kubectl。您可以根据[安装并设置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux) 的说明来安装 kubectl。
请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)
的说明来安装 kubectl。
<!--
### Install a Hypervisor
If you do not already have a hypervisor installed, install one of these now:
-->
### 安装 Hypervisor
如果你还没有安装 hypervisor，请选择以下方式之一进行安装：
• [HyperKit](https://github.com/moby/hyperkit)
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
• [VMware Fusion](https://www.vmware.com/products/fusion)
<!--
### Install Minikube
The easiest way to install Minikube on macOS is using [Homebrew](https://brew.sh):
-->
### 安装 Minikube
macOS 安装 Minikube 最简单的方法是使用 [Homebrew](https://brew.sh)：
@ -284,8 +261,7 @@ brew install minikube
<!--
You can also install it on macOS by downloading a stand-alone binary:
-->
你也可以通过下载单节点二进制文件进行安装：
你也可以通过下载独立的可执行文件进行安装：
```shell
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \
@ -295,8 +271,7 @@ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/miniku
<!--
Here's an easy way to add the Minikube executable to your path:
-->
这是一个简单的将 Minikube 可执行文件添加至 path 的方法：
下面是一个简单的将 Minikube 可执行文件添加至 PATH 的方法：
```shell
sudo mv minikube /usr/local/bin
@ -310,29 +285,27 @@ sudo mv minikube /usr/local/bin
Make sure you have kubectl installed. You can install kubectl according to the instructions in [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows).
-->
### 安装 kubectl
请确保你已正确安装 kubectl。您可以根据[安装并设置 kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows) 的说明来安装 kubectl。
请确保你已正确安装 kubectl。你可以根据[安装并设置 kubectl](/zh/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)
的说明来安装 kubectl。
<!--
### Install a Hypervisor
If you do not already have a hypervisor installed, install one of these now:
-->
### 安装 Hypervisor
如果你还没有安装 hypervisor，请选择以下方式之一进行安装：
• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install)
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
<!--
Hyper-V can run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education.
-->
{{< note >}}
Hyper-V 可以运行在三个版本的 Windows 10 上：企业版、专业版和教育版（Enterprise, Professional, Education）。
{{< /note >}}
@ -341,7 +314,6 @@ Hyper-V 可以运行在三个版本的 Windows 10 上：企业版、专业版和
The easiest way to install Minikube on Windows is using [Chocolatey](https://chocolatey.org/) (run as an administrator):
-->
### 使用 Chocolatey 安装 Minikube
Windows 安装 Minikube 最简单的方法是使用 [Chocolatey](https://chocolatey.org/) （以管理员身份运行）：
@ -353,7 +325,6 @@ choco install minikube
<!--
After Minikube has finished installing, close the current CLI session and restart. Minikube should have been added to your path automatically.
-->
完成 Minikube 的安装后，关闭当前 CLI 界面再重新打开。
Minikube 应该已经自动添加至 path 中。
@ -372,7 +343,6 @@ To install Minikube manually on Windows using [Windows Installer](https://docs.m
To install Minikube manually on Windows, download [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), rename it to `minikube.exe`, and add it to your path.
-->
### 直接下载并安装 Minikube
想在 Windows 上手动安装 Minikube，下载 [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest) 并将其重命名为 `minikube.exe`，然后将其添加至 path 即可。
@ -380,15 +350,11 @@ To install Minikube manually on Windows, download [`minikube-windows-amd64`](htt
{{% /tab %}}
{{< /tabs >}}
<!--
## Confirm Installation
To confirm successful installation of both a hypervisor and Minikube, you can run the following command to start up a local Kubernetes cluster:
-->
## 安装确认
要确认 hypervisor 和 Minikube 均已成功安装，可以运行以下命令来启动本地 Kubernetes 集群：
@ -396,10 +362,11 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru
<!--
For setting the `--vm-driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--vm-driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver).
-->
{{< note >}}
若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `<driver_name>` 的地方，用小写字母输入你安装的 hypervisor 的名称。
[指定 VM 驱动程序](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表。
若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `<驱动名称>` 的地方，
用小写字母输入你安装的 hypervisor 的名称。
[指定 VM 驱动程序](/zh/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)
列举了 `--vm-driver` 值的完整列表。
{{< /note >}}
{{< note >}}
@ -407,15 +374,14 @@ For setting the `--vm-driver` with `minikube start`, enter the name of the hyper
{{< /note >}}
```shell
minikube start --vm-driver=<driver_name>
# Or when you need
minikube start --vm-driver=<driver_name> --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
minikube start --vm-driver=<驱动名称>
# 或者在需要时
minikube start --vm-driver=<驱动名称> --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers
```
<!--
Once `minikube start` finishes, run the command below to check the status of the cluster:
-->
一旦 `minikube start` 完成，你可以运行下面的命令来检查集群的状态：
```shell
@ -425,7 +391,6 @@ minikube status
<!--
If your cluster is running, the output from `minikube status` should be similar to:
-->
如果你的集群正在运行，`minikube status` 的输出结果应该类似于这样：
```
@ -438,8 +403,7 @@ kubeconfig: Configured
<!--
After you have confirmed whether Minikube is working with your chosen hypervisor, you can continue to use Minikube or you can stop your cluster. To stop your cluster, run:
-->
在确认 Minikube 与 hypervisor 均正常工作后，您可以继续使用 Minikube 或停止集群。要停止集群，请运行：
在确认 Minikube 与 hypervisor 均正常工作后，你可以继续使用 Minikube 或停止集群。要停止集群，请运行：
```shell
minikube stop
@ -450,40 +414,33 @@ minikube stop
If you have previously installed Minikube, and run:
-->
## 清理本地状态 {#cleanup-local-state}
## 清理本地状态{#cleanup-local-state}
如果您之前安装过 Minikube，并运行了：
如果你之前安装过 Minikube，并运行了：
```shell
minikube start
```
<!--
and `minikube start` returned an error:
-->
<!-- and `minikube start` returned an error: -->
并且 `minikube start` 返回了一个错误：
```
machine does not exist
```
<!--
then you need to clear minikube's local state:
-->
<!-- then you need to clear minikube's local state: -->
那么，你需要清理 minikube 的本地状态：
```shell
minikube delete
```
## {{% heading "whatsnext" %}}
<!--
* [Running Kubernetes Locally via Minikube](/docs/setup/learning-environment/minikube/)
-->
* [使用 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/)
* [使用 Minikube 在本地运行 Kubernetes](/zh/docs/setup/learning-environment/minikube/)