From a3a745838b1a608a1607ac73f700dc0c847665e1 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 12 Aug 2020 11:25:19 +0800 Subject: [PATCH] [zh] Tidy up and fix links in tasks section (4/10) --- content/zh/docs/concepts/containers/images.md | 77 ++-- .../setup/learning-environment/minikube.md | 4 +- .../access-cluster.md | 2 +- .../configure-projected-volume-storage.md | 91 +++-- .../configure-service-account.md | 376 ++++++++++++------ .../configure-volume-storage.md | 168 ++++---- .../pull-image-private-registry.md | 82 ++-- .../quality-service-pod.md | 60 +-- .../imperative-config.md | 100 ++--- .../docs/tasks/network/validate-dual-stack.md | 53 ++- .../install-service-catalog-using-helm.md | 52 ++- .../install-service-catalog-using-sc.md | 37 +- .../zh/docs/tasks/tools/install-minikube.md | 133 +++---- 13 files changed, 598 insertions(+), 637 deletions(-) diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md index d47a9c21d6..946c74ce77 100644 --- a/content/zh/docs/concepts/containers/images.md +++ b/content/zh/docs/concepts/containers/images.md @@ -89,34 +89,34 @@ Instead, specify a meaningful tag such as `v1.42.0`. -## 更新镜像 {#updating-images} -默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，`kubelet` 将不再去拉取镜像。 -如果希望强制总是拉取镜像，你可以执行以下操作之一： - - +## 更新镜像 {#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）。 - 如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。 -## 使用私有仓库 {#using-a-private-registry} +## 使用私有仓库 {#using-a-private-registry} 从私有仓库读取镜像时可能需要密钥。 -凭据信息可以用以下方式提供: +凭证可以用以下方式提供: - 配置节点向私有仓库进行身份验证 - 所有 Pod 均可读取任何已配置的私有仓库 @@ -174,9 +174,9 @@ Credentials can be provided in several ways: 向容器仓库认证的机制 -下面将详细描述每一种方案。 +下面将详细描述每一项。 -如果一切正常，一段时间后，可以运行: - -```shell -kubectl logs private-image-test-1 -``` - -并看到命令输出为： - -``` -SUCCESS -``` - @@ -388,7 +373,7 @@ All pods will have read access to any pre-pulled images. -### 为 Pod 设置 ImagePullSecrets +### 在 Pod 上指定 ImagePullSecrets {#specifying-imagepullsecrets-on-a-pod} -#### 创建包含 Docker 配置的Secret +#### 使用 Docker Config 创建 Secret {#creating-a-secret-with-docker-config} -将大写字母代替为合适的值，运行以下命令： +运行以下命令，将大写字母代替为合适的值： ```shell kubectl create secret docker-registry <名称> \ diff --git a/content/zh/docs/setup/learning-environment/minikube.md b/content/zh/docs/setup/learning-environment/minikube.md index 5696f59519..bd828ec871 100644 --- a/content/zh/docs/setup/learning-environment/minikube.md +++ b/content/zh/docs/setup/learning-environment/minikube.md @@ -374,12 +374,10 @@ minikube start --kubernetes-version {{< param "fullversion" >}} ``` -#### 指定 VM 驱动程序 - +#### 指定 VM 驱动程序 {#specifying-the-vm-driver} 您可以通过将 `--vm-driver=` 参数添加到 `minikube start` 来更改 VM 驱动程序。 -### 从 Pod 中访问 API +### 从 Pod 中访问 API {#accessing-the-api-from-a-pod} 当你从 Pod 中访问 API 时，定位和验证 apiserver 会有些许不同。 diff --git a/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index ec91c53ec5..089ed655e8 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -1,21 +1,16 @@ --- -reviewers: -- jpeeler -- pmorie title: 配置 Pod 使用投射卷作存储 content_type: task weight: 70 --- @@ -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 >}} +{{< note >}} `serviceAccountToken` 不是一种卷类型 {{< /note >}} - ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - -## 为 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. 创建 Secrets: -```shell - # 创建包含用户名和密码的文件: - echo -n "admin" > ./username.txt - echo -n "1f2d1e2e67df" > ./password.txt--> +1. + 创建 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. 创建 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. + 创建 Pod： -确认 Pod 中的容器运行正常，然后监视 Pod 的变化： + ```shell + kubectl create -f https://k8s.io/examples/pods/storage/projected.yaml + ``` -```shell - kubectl get --watch pod test-projected-volume -``` + + 确认 Pod 中的容器运行正常，然后监视 Pod 的变化： - 输出结果和下面类似： - NAME READY STATUS RESTARTS AGE - test-projected-volume 1/1 Running 0 14s + ```shell + kubectl get --watch pod test-projected-volume + ``` -1. 在另外一个终端中，打开容器的 shell： -```shell - kubectl exec -it test-projected-volume -- /bin/sh -``` + + 输出结果和下面类似： -1. 在 shell 中，确认 `projected-volume` 目录包含你的投射源： -```shell - ls /projected-volume/ -``` + ``` + NAME READY STATUS RESTARTS AGE + test-projected-volume 1/1 Running 0 14s + ``` +3. + 在另外一个终端中，打开容器的 shell： + + ```shell + kubectl exec -it test-projected-volume -- /bin/sh + ``` + +4. + 在 shell 中，确认 `projected-volume` 目录包含你的投射源： + + ```shell + ls /projected-volume/ + ``` ## {{% heading "whatsnext" %}} - -* 进一步了解[`投射`](/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)设计文档。 - diff --git a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md index 5c53b1d259..bf9f9bf87e 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-service-account.md @@ -1,15 +1,10 @@ --- -reviewers: -- bprashanth -- liggitt -- thockin title: 为 Pod 配置服务账户 content_type: task weight: 90 --- @@ -25,26 +19,16 @@ weight: 90 - -服务账户为 Pod 中运行的进程提供了一个标识。 - -*本文是服务账户的用户使用介绍。您也可以参考[集群管理指南之服务账户](/docs/reference/access-authn-authz/service-accounts-admin/)。* - - -{{< note >}} - +服务账户为 Pod 中运行的进程提供了一个标识。 -本文档描述 Kubernetes 项目推荐的集群中服务帐户的行为。 -集群管理员也可能已经定制了服务账户在集群中的属性，在这种情况下，本文档可能并不适用。 - +{{< note >}} +本文是服务账户的用户使用介绍，描述服务账号在集群中如何起作用。 +你的集群管理员可能已经对你的集群做了定制，因此导致本文中所讲述的内容并不适用。 {{< /note >}} - -当您（人类）访问集群时（例如，使用 `kubectl`），api 服务器将您的身份验证为特定的用户帐户（当前这通常是 `admin`，除非您的集群管理员已经定制了您的集群配置）。 +当你（自然人）访问集群时（例如，使用 `kubectl`），API 服务器将你的身份验证为 +特定的用户帐户（当前这通常是 `admin`，除非你的集群管理员已经定制了你的集群配置）。 Pod 内的容器中的进程也可以与 api 服务器接触。 当它们进行身份验证时，它们被验证为特定的服务帐户（例如，`default`）。 - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - ## 使用默认的服务账户访问 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` 字段已经被自动设置了。 +你可以使用自动挂载给 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 - -在 1.6 以上版本中，您也可以选择不给特定 Pod 自动挂载 API 凭据： +在 1.6 以上版本中，你也可以选择不给特定 Pod 自动挂载 API 凭据： ```yaml apiVersion: v1 @@ -130,19 +110,19 @@ spec: +如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。 + - -如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。 - -## 使用多个服务账户 +## 使用多个服务账户 {#use-multiple-service-accounts} 每个命名空间都有一个名为 `default` 的服务账户资源。 -您可以用下面的命令查询这个服务账户以及命名空间中的其他 serviceAccount 资源： +你可以用下面的命令查询这个服务账户以及命名空间中的其他 ServiceAccount 资源： ```shell kubectl get serviceAccounts @@ -153,8 +133,7 @@ default 1 1d - -您可以像这样来创建额外的 ServiceAccount 对象： +你可以像这样来创建额外的 ServiceAccount 对象： ```shell kubectl create -f - < - -如果您查询服务帐户对象的完整信息，如下所示： +如果你查询服务帐户对象的完整信息，如下所示： ```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` 字段设置为你想用的服务账户名称。 - 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 >}} +{{< note >}} 这里省略了 `token` 的内容。 {{< /note >}} +## 为服务账户添加 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 -``` +- 确认创建成功： + + ```shell + kubectl get secrets myregistrykey + ``` + + + 输出类似于： + + ``` + NAME TYPE DATA AGE + myregistrykey   kubernetes.io/.dockerconfigjson   1       1d + ``` + + +### 将镜像拉取 Secret 添加到服务账号 -接着修改命名空间的默认服务帐户，以将该 Secret 用作 imagePullSecret。 +接着修改命名空间的 `default` 服务帐户，以将该 Secret 用作 imagePullSecret。 ```shell kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' ``` - -需要手动编辑的交互式版本： +你也可以使用 `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:"] + +使用你常用的编辑器（例如 `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 ``` +最后，用新的更新的 `sa.yaml` 文件替换服务账号。 -现在，在当前命名空间中创建的每个新 Pod 的 spec 中都会添加下面的内容： - -```yaml -spec: - imagePullSecrets: - - name: myregistrykey +```shell +kubectl replace serviceaccount default -f ./sa.yaml ``` - +### 验证镜像拉取 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"}' +``` + + +输出为： + +``` +myregistrykey +``` - -## 服务帐户令牌卷投影 +## 服务帐户令牌卷投射 {#service-account-token-volume-projection} {{< feature-state for_k8s_version="v1.12" state="beta" >}} -{{< note >}} - -ServiceAccountTokenVolumeProjection 在 1.12 版本中是 __beta__ 阶段，可以通过向 API 服务器传递以下所有参数来启用它： +{{< note >}} +ServiceAccountTokenVolumeProjection 在 1.12 版本中是 __beta__ 阶段， +可以通过向 API 服务器传递以下所有参数来启用它： * `--service-account-issuer` * `--service-account-signing-key-file` * `--service-account-api-audiences` - {{< /note >}} - 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 + +创建 Pod： + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml ``` +`kubelet` 组件会替 Pod 请求令牌并将其保存起来，通过将令牌存储到一个可配置的 +路径使之在 Pod 内可用，并在令牌快要到期的时候刷新它。 +`kubelet` 会在令牌存在期达到其 TTL 的 80% 的时候或者令牌生命期超过 24 小时 +的时候主动轮换它。 -Kubelet 将代表 Pod 请求和存储令牌，使令牌在可配置的文件路径上对 Pod 可用，并在令牌接近到期时刷新令牌。 -如果令牌存活时间大于其总 TTL 的 80% 或者大于 24 小时，Kubelet 则会主动旋转令牌。 +应用程序负责在令牌被轮换时重新加载其内容。对于大多数使用场景而言，周期性地 +（例如，每隔 5 分钟）重新加载就足够了。 -应用程序负责在令牌旋转时重新加载令牌。 -对于大多数情况，定期重新加载（例如，每 5 分钟一次）就足够了。 + +## 发现服务账号分发者 + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + + +通过启用 `ServiceAccountIssuerDiscovery` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates)， +并按[前文所述](#service-account-token-volume-projection)启用服务账号令牌投射， +可以启用发现服务账号分发者（Service Account Issuer Discovery）这一功能特性。 + + +{{< 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 >}} + + +发现服务账号分发者这一功能使得用户能够用联邦的方式结合使用 Kubernetes +集群（_Identity Provider_，标识提供者）与外部系统（_relying parties_， +依赖方）所分发的服务账号令牌。 + +当此功能被启用时，Kubernetes API 服务器会在 `/.well-known/openid-configuration` +提供一个 OpenID 提供者配置文档，并在 `/openid/v1/jwks` 处提供与之关联的 +JSON Web Key Set（JWKS）。 +这里的 OpenID 提供者配置有时候也被称作 _发现文档（Discovery Document）_。 + + +特性被启用时，集群也会配置名为 `system:service-account-issuer-discovery` +的默认 RBAC ClusterRole，但默认情况下不提供角色绑定对象。 +举例而言，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到 +`system:authenticated` 或 `system:unauthenticated`。 + + +{{< note >}} +对 `/.well-known/openid-configuration` 和 `/openid/v1/jwks` 路径请求的响应 +被设计为与 OIDC 兼容，但不是完全与其一致。 +返回的文档仅包含对 Kubernetes 服务账号令牌进行验证所必须的参数。 +{{< /note >}} + + +JWKS 响应包含依赖方可以用来验证 Kubernetes 服务账号令牌的公钥数据。 +依赖方先会查询 OpenID 提供者配置，之后使用返回响应中的 `jwks_uri` 来查找 +JWKS。 + + +在很多场合，Kubernetes API 服务器都不会暴露在公网上，不过对于缓存并向外提供 API +服务器响应数据的公开末端而言，用户或者服务提供商可以选择将其暴露在公网上。 +在这种环境中，可能会重载 OpenID 提供者配置中的 +`jwks_uri`，使之指向公网上可用的末端地址，而不是 API 服务器的地址。 +这时需要向 API 服务器传递 `--service-account-jwks-uri` 参数。 +与分发者 URL 类似，此 JWKS URI 也需要使用 `https` 模式。 +## {{% heading "whatsnext" %}} + + +- [服务账号的集群管理员指南](/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) + diff --git a/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md index 2f5b7a4e5c..5e5a9907e9 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -4,19 +4,12 @@ content_type: task weight: 50 --- - -此页面展示了如何配置 Pod 以使用卷进行存储。 - -只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。对于独立于容器的持久化存储，您可以使用[卷](/docs/concepts/storage/volumes/)。这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。 - +此页面展示了如何配置 Pod 以使用卷进行存储。 - +只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。 +对于独立于容器的持久化存储，你可以使用[卷](/zh/docs/concepts/storage/volumes/)。 +这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - -## 为 Pod 配置卷 - -在本练习中，您将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为 [emptyDir](/docs/concepts/storage/volumes/#emptydir) 的卷，在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 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. 创建 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 的更改： +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 连接正在运行的容器： +3. 在另一个终端，用 shell 连接正在运行的容器： - ```shell - kubectl exec -it redis -- /bin/bash - ``` + ```shell + kubectl exec -it redis -- /bin/bash + ``` -1. 在您的 shell 终端中，切换到 `/data/redis` 目录下，然后创建一个文件： +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 终端中，列出正在运行的进程： +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 进程： +6. 在你的 Shell 中，结束 Redis 进程： - ```shell - root@redis:/data/redis# kill - ``` + ```shell + root@redis:/data/redis# kill + ``` - 其中 `` 是 Redis 进程的 ID (PID)。 + 其中 `` 是 Redis 进程的 ID (PID)。 -1. 在您原先终端中，留意 Redis Pod 的更改。最终您将会看到和下面类似的输出： +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`。 +此时，容器已经终止并重新启动。这是因为 Redis Pod 的 +[restartPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +为 `Always`。 -1. 用 shell 终端进入重新启动的容器中： +1. 用 Shell 进入重新启动的容器中： - ```shell - kubectl exec -it redis -- /bin/bash - ``` + ```shell + kubectl exec -it redis -- /bin/bash + ``` -1. 在您的 shell 终端中，进入到 `/data/redis` 目录下，并确认 `test-file` 文件是否仍然存在。 +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： +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/)。 - - +* 参阅 [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/)。 diff --git a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md index b8228ac2ba..f9e4389762 100644 --- a/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/zh/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -5,11 +5,9 @@ weight: 100 --- @@ -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 >}} - -您需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。 - - +你需要 [Docker ID](https://docs.docker.com/docker-id/) 和密码来进行本练习。 @@ -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 - 输出结果包含类似于以下内容的部分： ```json @@ -87,10 +75,10 @@ The output contains a section similar to this: } ``` -{{< note >}} +{{< 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 + +```shell +kubectl create secret docker-registry regcred \ + --docker-server=<你的镜像仓库服务器> \ + --docker-username=<你的用户名> \ + --docker-password=<你的密码> \ + --docker-email=<你的邮箱地址> ``` - 在这里： -* `` 是你的私有 Docker 仓库全限定域名（FQDN）。(参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分) +* `` 是你的私有 Docker 仓库全限定域名（FQDN）。 + (参考 https://index.docker.io/v1/ 中关于 DockerHub 的部分) * `` 是你的 Docker 用户名。 * `` 是你的 Docker 密码。 * `` 是你的 Docker 邮箱。 -这样您就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。 +这样你就成功地将集群中的 Docker 凭据设置为名为 `regcred` 的 Secret。 - ## 检查 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 ``` - - + 输出和下面类似： ```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 ``` - - + 输出和下面类似： ```json @@ -192,7 +178,6 @@ The output is similar to this: - 要了解 `auth` 字段中的内容，请将 base64 编码过的数据转换为可读格式： ```shell @@ -202,7 +187,6 @@ echo "c3R...zE2" | base64 --decode - 输出结果中，用户名和密码用 `:` 链接，类似下面这样： ```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。 + + - -注意，Secret 数据包含与本地 `~/.docker/config.json` 文件类似的授权令牌。 - -这样您就已经成功地将 Docker 凭据设置为集群中的名为 `regcred` 的 Secret。 - -## 创建一个使用您的 Secret 的 Pod +## 创建一个使用你的 Secret 的 Pod 下面是一个 Pod 配置文件，它需要访问 `regcred` 中的 Docker 凭据： {{< codenew file="pods/private-reg-pod.yaml" >}} - - + 下载上述文件： ```shell @@ -242,7 +223,6 @@ wget -O my-private-reg-pod.yaml https://k8s.io/examples/pods/private-reg-pod.yam - 在`my-private-reg-pod.yaml` 文件中，使用私有仓库的镜像路径替换 ``，例如： ```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" %}} - -* 进一步了解 [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` 字段 diff --git a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md index 680d38b316..9d0635d43b 100644 --- a/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/zh/docs/tasks/configure-pod-container/quality-service-pod.md @@ -5,11 +5,9 @@ weight: 30 --- @@ -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 >}} - - - - -## 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 >}} - +{{< 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: - 删除 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" >}} - 创建 Pod： ```shell @@ -264,7 +246,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qo - 查看 Pod 详情： ```shell @@ -274,7 +255,6 @@ kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml - 结果表明 Kubernetes 为 Pod 配置的 QoS 类为 BestEffort。 ```yaml @@ -289,7 +269,6 @@ spec: - 删除 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" >}} - 注意此 Pod 满足 Burstable QoS 类的标准。 也就是说它不满足 Guaranteed QoS 类标准，因为它的一个容器设有内存请求。 @@ -331,7 +307,6 @@ kubectl create -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qo - 查看 Pod 详情： ```shell @@ -341,7 +316,6 @@ kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml - 结果表明 Kubernetes 为 Pod 配置的 QoS 类为 Burstable： ```yaml @@ -362,7 +336,6 @@ spec: - 删除 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" %}} - - - ### 应用开发者参考 -* [为 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/) @@ -20,29 +18,24 @@ This document explains how to define and manage objects using configuration file 可以使用 `kubectl` 命令行工具以及用 YAML 或 JSON 编写的对象配置文件来创建、更新和删除 Kubernetes 对象。 本文档说明了如何使用配置文件定义和管理对象。 - ## {{% heading "prerequisites" %}} - -安装 [`kubectl`](/docs/tasks/tools/install-kubectl/) 。 +安装 [`kubectl`](/zh/docs/tasks/tools/install-kubectl/) 。 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - ## 权衡 - `kubectl` 工具支持三种对象管理： -参看 [Kubernetes 对象管理](/docs/concepts/overview/working-with-objects/object-management/) 讨论每种对象管理的优缺点。 +参看 [Kubernetes 对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/) +中关于每种对象管理的优缺点的讨论。 -## 如何创建对象 - -您可以使用 `kubectl create -f` 从配置文件创建一个对象。 +## 如何创建对象 + +你可以使用 `kubectl create -f` 从配置文件创建一个对象。 请参考 [kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 有关详细信息。 * `kubectl create -f ` -## 如何更新对象 -{{< warning >}} - +## 如何更新对象 + +{{< 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 ` -## 如何删除对象 - -您可以使用 `kubectl delete -f` 删除配置文件中描述的对象。 +## 如何删除对象 + +你可以使用 `kubectl delete -f` 删除配置文件中描述的对象。 * `kubectl delete -f ` -## 如何查看对象 - -您可以使用 `kubectl get -f` 查看有关配置文件中描述的对象的信息。 +## 如何查看对象 + +你可以使用 `kubectl get -f` 查看有关配置文件中描述的对象的信息。 * `kubectl get -f -o yaml` @@ -138,10 +129,7 @@ Use `kubectl get -h` to see a list of options. -## 局限性 - +## 局限性 + 当完全定义每个对象的配置并将其记录在其配置文件中时，`create`、 `replace` 和`delete` 命令会很好的工作。 但是，当更新一个活动对象，并且更新没有合并到其配置文件中时，下一次执行 `replace` 时，更新将丢失。 如果控制器,例如 HorizontalPodAutoscaler ,直接对活动对象进行更新，则会发生这种情况。 @@ -173,17 +163,16 @@ If you need to support multiple writers to the same object, you can use -## 从 URL 创建和编辑对象而不保存配置 - -假设您具有对象配置文件的 URL。 -您可以在创建对象之前使用 `kubectl create --edit` 对配置进行更改。 +## 从 URL 创建和编辑对象而不保存配置 + +假设你具有对象配置文件的 URL。 +你可以在创建对象之前使用 `kubectl create --edit` 对配置进行更改。 这对于指向可以由读者修改的配置文件的教程和任务特别有用。 ```shell @@ -192,13 +181,12 @@ kubectl create -f --edit -## 从命令式命令迁移到命令式对象配置 - +## 从命令式命令迁移到命令式对象配置 + 从命令式命令迁移到命令式对象配置涉及几个手动步骤。 1. 将活动对象导出到本地对象配置文件： - ```shell - kubectl get / -o yaml > _.yaml - ``` + ```shell + kubectl get / -o yaml > _.yaml + ``` -1. 从对象配置文件中手动删除状态字段。 +2. 从对象配置文件中手动删除状态字段。 -1. 对于后续的对象管理，只能使用 `replace` 。 +3. 对于后续的对象管理，只能使用 `replace` 。 - ```shell - kubectl replace -f _.yaml - ``` + ```shell + kubectl replace -f _.yaml + ``` ## 定义控制器选择器和 PodTemplate 标签 -{{< warning >}} +{{< warning >}} 不建议在控制器上更新选择器。 {{< /warning >}} @@ -242,9 +230,7 @@ used only by the controller selector with no other semantic meaning. --> 推荐的方法是定义单个不变的 PodTemplate 标签，该标签仅由控制器选择器使用，而没有其他语义。 - + 标签示例： ```yaml @@ -257,21 +243,17 @@ template: controller-selector: "apps/v1/deployment/nginx" ``` - - ## {{% heading "whatsnext" %}} - -* [使用命令式命令管理 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" >}}/) - diff --git a/content/zh/docs/tasks/network/validate-dual-stack.md b/content/zh/docs/tasks/network/validate-dual-stack.md index c0d1363fcc..2f67abbf70 100644 --- a/content/zh/docs/tasks/network/validate-dual-stack.md +++ b/content/zh/docs/tasks/network/validate-dual-stack.md @@ -6,13 +6,11 @@ title: 验证 IPv4/IPv6 双协议栈 content_type: task --- @@ -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 或更高版本 * 提供程序对双协议栈网络的支持 (云供应商或其他方式必须能够为 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/) 集群 ## 验证寻址 - ### 验证节点寻址 - 每个双协议栈节点应分配一个 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 ``` + @@ -75,7 +70,9 @@ There should be one IPv4 block and one IPv6 block allocated. -验证节点是否检测到 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 ### 验证 Pod 寻址 - 验证 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 ## 验证服务 - 在不设置 `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 -通过查看该服务的 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 80/TCP 9s ### 创建双协议栈负载均衡服务 - 如果云提供商支持配置启用 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 ``` - - - - diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md index 91116c46f0..5e102f790c 100644 --- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -3,16 +3,14 @@ title: 使用 Helm 安装 Service Catalog content_type: task --- -{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} +{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}} -* 理解 [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。 - - ## 添加 service-catalog Helm 仓库 - 安装 Helm 后，通过执行以下命令将 *service-catalog* Helm 存储库添加到本地计算机： ```shell @@ -83,18 +77,16 @@ svc-cat/catalog 0.0.1 service-catalog API server and controller-manag... ## 启用 RBAC - -您的 Kubernetes 集群必须启用 RBAC，这需要您的 Tiller Pod 具有 `cluster-admin` 访问权限。 +你的 Kubernetes 集群必须启用 RBAC，这需要你的 Tiller Pod 具有 `cluster-admin` 访问权限。 - -如果您使用的是 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 -如果您使用 `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 >}} -如果在运行 `helm init` 时使用了 `--tiller-namespace` 或 `--service-account` 参数，则需要调整以下命令中的 `--serviceaccount` 参数以引用相应的 namespace 和 ServiceAccount 名称。 +{{< note >}} +如果在运行 `helm init` 时使用了 `--tiller-namespace` 或 `--service-account` 参数， +则需要调整以下命令中的 `--serviceaccount` 参数以引用相应的名字空间和服务账号名称。 {{< /note >}} ## 在 Kubernetes 集群中安装 Service Catalog - 使用以下命令从 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) 项目。 + diff --git a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md index dd179932c5..3139539017 100644 --- a/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md +++ b/content/zh/docs/tasks/service-catalog/install-service-catalog-using-sc.md @@ -6,26 +6,23 @@ content_type: task --- -{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} +{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}} -使用[服务目录安装程序](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)工具可以轻松地在 Kubernetes 集群上安装或卸载服务目录。 +使用[服务目录安装程序](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) +工具可以轻松地在 Kubernetes 集群上安装或卸载服务目录。 这个 CLI 工具以 `sc` 命令形式被安装在您的本地环境中。 - - ## {{% heading "prerequisites" %}} -* 了解[服务目录](/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= - - - + ``` + kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= + ``` ## 在本地环境中安装 `sc` - 使用 `go get` 命令安装 `sc` CLI 工具： ```Go @@ -72,12 +67,11 @@ After running the above command, `sc` should be installed in your `GOPATH/bin` d ## 在 Kubernetes 集群中安装服务目录 - 首先，检查是否已经安装了所有依赖项。运行： ```shell @@ -104,20 +98,17 @@ sc install --etcd-backup-storageclass "standard" ## 卸载服务目录 - 如果您想使用 `sc` 工具从 Kubernetes 集群卸载服务目录，请运行： ```shell sc uninstall ``` - - ## {{% heading "whatsnext" %}} @@ -23,14 +21,10 @@ card: - -本页面讲述如何安装 [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 - -若要检查您的 macOS 是否支持虚拟化技术，请运行下面的命令： +若要检查你的 macOS 是否支持虚拟化技术，请运行下面的命令： ``` sysctl -a | grep -E --color 'machdep.cpu.features|VMX' @@ -61,8 +54,7 @@ sysctl -a | grep -E --color 'machdep.cpu.features|VMX' - -如果你在输出结果中看到了 `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 - -若要检查您的 Windows8 及以上的系统是否支持虚拟化技术，请终端或者 cmd 中运行以下命令： +若要检查你的 Windows8 及以上的系统是否支持虚拟化技术，请终端或者 cmd 中运行以下命令： ``` systeminfo @@ -79,8 +70,7 @@ systeminfo - -如果您看到下面的输出，则表示该 Windows 支持虚拟化技术。 +如果你看到下面的输出，则表示该 Windows 支持虚拟化技术。 ``` Hyper-V Requirements: VM Monitor Mode Extensions: Yes @@ -92,24 +82,19 @@ Hyper-V Requirements: VM Monitor Mode Extensions: Yes - -如果您看到下面的输出，则表示您的操作系统已经安装了 Hypervisor，您可以跳过安装 Hypervisor 的步骤。 +如果你看到下面的输出，则表示你的操作系统已经安装了 Hypervisor，你可以跳过安装 Hypervisor 的步骤。 ``` Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. ``` - {{% /tab %}} {{< /tabs >}} - - - ## 安装 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。 -• [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 还支持使用一个 `--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 >}} - +{{< 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 还支持另外一个类似于 Docker 驱动的方式 `vm-driver=podman`。 -使用超级用户权限（root 用户）运行 Podman 可以最好的确保容器具有足够的权限使用你操作系统上的所有特性。 +使用超级用户权限（root 用户）运行 Podman 可以最好的确保容器具有足够的权限使用 +你的操作系统上的所有特性。 -{{< caution >}} -`Podman` 驱动方式需要以 root 用户身份运行容器，因为普通用户帐户没有足够的权限使用容器运行可能需要的操作系统上的所有特性。 +{{< caution >}} +`Podman` 驱动需要以 root 用户身份运行容器，因为普通用户帐户没有足够的权限 +使用容器运行可能需要的操作系统上的所有特性。 {{< /caution >}} - ### 使用包安装 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 发行版选择安装合适的包。 - ### 直接下载并安装 Minikube 如果你不想通过包安装，你也可以下载并使用一个单节点二进制文件。 @@ -218,7 +199,7 @@ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/miniku -将 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" %}} - ### 安装 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。 - ### 安装 Hypervisor 如果你还没有安装 hypervisor，请选择以下方式之一进行安装： • [HyperKit](https://github.com/moby/hyperkit) - • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - • [VMware Fusion](https://www.vmware.com/products/fusion) - ### 安装 Minikube macOS 安装 Minikube 最简单的方法是使用 [Homebrew](https://brew.sh)： @@ -284,8 +261,7 @@ brew install minikube - -你也可以通过下载单节点二进制文件进行安装： +你也可以通过下载独立的可执行文件进行安装： ```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 - -这是一个简单的将 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。 - ### 安装 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 >}} +{{< 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 - 完成 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 >}} - - - - ## 安装确认 要确认 hypervisor 和 Minikube 均已成功安装，可以运行以下命令来启动本地 Kubernetes 集群： @@ -396,10 +362,11 @@ To confirm successful installation of both a hypervisor and Minikube, you can ru - {{< note >}} -若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `` 的地方，用小写字母输入你安装的 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= -# Or when you need -minikube start --vm-driver= --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 ``` - 一旦 `minikube start` 完成，你可以运行下面的命令来检查集群的状态： ```shell @@ -425,7 +391,6 @@ minikube status - 如果你的集群正在运行，`minikube status` 的输出结果应该类似于这样： ``` @@ -438,8 +403,7 @@ kubeconfig: Configured - -在确认 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 ``` - - + 并且 `minikube start` 返回了一个错误： + ``` machine does not exist ``` - - + 那么，你需要清理 minikube 的本地状态： + ```shell minikube delete ``` - ## {{% heading "whatsnext" %}} - - -* [使用 Minikube 在本地运行 Kubernetes](/docs/setup/learning-environment/minikube/) +* [使用 Minikube 在本地运行 Kubernetes](/zh/docs/setup/learning-environment/minikube/) +