From 68abcb96388539c41caf98df42ab987ed90a92a4 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Thu, 13 Aug 2020 17:49:12 +0800 Subject: [PATCH] [zh] Tidy up and fix links in tasks section (5/10) --- .../administer-cluster/kubelet-config-file.md | 96 ++-- .../assign-pods-nodes.md | 113 ++-- .../attach-handler-lifecycle-event.md | 71 +-- ...igure-liveness-readiness-startup-probes.md | 137 +++-- .../configure-pod-initialization.md | 78 +-- .../configure-runasusername.md | 63 +- .../extended-resource.md | 40 +- .../configure-pod-container/static-pod.md | 198 ++++--- .../translate-compose-kubernetes.md | 537 ++++++++++-------- .../configure-multiple-schedulers.md | 254 +++++---- .../zh/examples/admin/sched/clusterrole.yaml | 37 ++ 11 files changed, 883 insertions(+), 741 deletions(-) rename content/zh/docs/tasks/{administer-cluster => extend-kubernetes}/configure-multiple-schedulers.md (51%) create mode 100644 content/zh/examples/admin/sched/clusterrole.yaml diff --git a/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md b/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md index 677bb4426c..e41eb9e3d9 100644 --- a/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md +++ b/content/zh/docs/tasks/administer-cluster/kubelet-config-file.md @@ -1,29 +1,26 @@ --- -reviewers: -- mtaufen -- dawnchen title: 通过配置文件设置 Kubelet 参数 content_type: task --- -{{< feature-state state="beta" >}} + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} -通过保存在硬盘的配置文件设置 Kubelet 的配置参数子集，可以作为命令行参数的替代。此功能在 v1.10 中为 beta 版。 +通过保存在硬盘的配置文件设置 kubelet 的部分配置参数，这可以作为命令行参数的替代。 +此功能在 v1.10 中为 beta 版。 建议通过配置文件的方式提供参数，因为这样可以简化节点部署和配置管理。 - - ## {{% heading "prerequisites" %}} - -- 需要安装 1.10 或更高版本的 Kubelet 二进制文件，才能实现 beta 功能。 - - +--> +- 需要安装 1.10 或更高版本的 kubelet 可执行文件，才能使用此 beta 功能。 + +The subset of the Kubelet's configuration that can be configured via a file +is defined by the `KubeletConfiguration` struct +[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go). +--> ## 创建配置文件 +`KubeletConfiguration` 结构体定义了可以通过文件配置的 Kubelet 配置子集， +该结构体在 [这里（v1beta1）](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go) +可以找到。 -`KubeletConfiguration` 结构体定义了可以通过文件配置的 Kubelet 配置子集，该结构体在 [这里（v1beta1）](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go) 可以找到, 配置文件必须是这个结构体中参数的 JSON 或 YAML 表现形式。 + +配置文件必须是这个结构体中参数的 JSON 或 YAML 表现形式。 +确保 kubelet 可以读取该文件。 -在单独的文件夹中创建一个名为 `kubelet` 的文件，并保证 Kubelet 可以读取该文件夹及文件。您应该在这个 `kubelet` 文件中编写 Kubelet 配置。 +下面是一个 Kubelet 配置文件示例： -这是一个 Kubelet 配置文件示例： - -``` +```yaml kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 evictionHard: memory.available: "200Mi" ``` -在这个示例中, 当可用内存低于200Mi 时, Kubelet 将会开始驱逐 Pods。 没有声明的其余配置项都将使用默认值, 命令行中的 flags 将会覆盖配置文件中的对应值。 - - -作为一个小技巧，您可以从活动节点生成配置文件，相关方法请查看 [重新配置活动集群节点的 Kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet)。 - - -## 启动通过配置文件配置的 Kubelet 进程 +在这个示例中, 当可用内存低于 200Mi 时, kubelet 将会开始驱逐 Pods。 +没有声明的其余配置项都将使用默认值，除非使用命令行参数来重载。 +命令行中的参数将会覆盖配置文件中的对应值。 + +作为一个小技巧，你可以从活动节点生成配置文件，相关方法请查看 +[重新配置活动集群节点的 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet)。 + + + +## 启动通过配置文件配置的 Kubelet 进程 + 启动 Kubelet 需要将 `--config` 参数设置为 Kubelet 配置文件的路径。Kubelet 将从此文件加载其配置。 -请注意，命令行参数与配置文件有相同的值时，就会覆盖配置文件中的该值。这有助于确保命令行 API 的向后兼容性。 +--> +请注意，命令行参数与配置文件有相同的值时，就会覆盖配置文件中的该值。 +这有助于确保命令行 API 的向后兼容性。 -请注意，Kubelet 配置文件中的相对文件路径是相对于 Kubelet 配置文件的位置解析的，而命令行参数中的相对路径是相对于 Kubelet 的当前工作目录解析的。 +--> +请注意，kubelet 配置文件中的相对文件路径是相对于 kubelet 配置文件的位置解析的， +而命令行参数中的相对路径是相对于 kubelet 的当前工作目录解析的。 -请注意，命令行参数和 Kubelet 配置文件的某些默认值不同。如果设置了 `--config`，并且没有通过命令行指定值，则 `KubeletConfiguration` 版本的默认值生效。在上面的例子中，version 是 `kubelet.config.k8s.io/v1beta1`。 - - +请注意，命令行参数和 Kubelet 配置文件的某些默认值不同。 +如果设置了 `--config`，并且没有通过命令行指定值，则 `KubeletConfiguration` +版本的默认值生效。在上面的例子中，version 是 `kubelet.config.k8s.io/v1beta1`。 -## 与动态 Kubelet 配置的关系 - -如果您正在使用 [动态 Kubelet 配置](/docs/tasks/administer-cluster/reconfigure-kubelet) 特性，那么自动回滚机制将认为是 "最后已知正常（last known good）" 的配置，通过 `--config` 提供的配置与覆盖这些值的任何参数的结合。 - +## 与动态 Kubelet 配置的关系 + +如果你正在使用[动态 kubelet 配置](/zh/docs/tasks/administer-cluster/reconfigure-kubelet)特性， +那么自动回滚机制将认为通过 `--config` 提供的配置与覆盖这些值的任何参数的组合是 + "最后已知正常（last known good）" 的配置。 diff --git a/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md index be2f8d030b..5ad4f62c28 100644 --- a/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/content/zh/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -4,11 +4,9 @@ content_type: task weight: 120 --- @@ -21,82 +19,84 @@ Kubernetes cluster. ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - ## 给节点添加标签 - 1. 列出集群中的节点 - kubectl get nodes + ```shell + kubectl get nodes + ``` - - 输出类似如下： + + 输出类似如下： - NAME STATUS AGE VERSION - worker0 Ready 1d v1.6.0+fff5156 - worker1 Ready 1d v1.6.0+fff5156 - worker2 Ready 1d v1.6.0+fff5156 + ``` + NAME STATUS AGE VERSION + worker0 Ready 1d v1.6.0+fff5156 + worker1 Ready 1d v1.6.0+fff5156 + worker2 Ready 1d v1.6.0+fff5156 + ``` -1. 选择其中一个节点，为它添加标签： +2. 选择其中一个节点，为它添加标签： - kubectl label nodes disktype=ssd + ```shell + kubectl label nodes disktype=ssd + ``` - - `` 是你选择的节点的名称。 + + `` 是你选择的节点的名称。 -1. 验证你选择的节点是否有 `disktype=ssd` 标签： +3. 验证你选择的节点是否有 `disktype=ssd` 标签： - kubectl get nodes --show-labels + ```shell + kubectl get nodes --show-labels + ``` + + 输出类似如下： - - 输出类似如下： - - NAME STATUS AGE VERSION LABELS - worker0 Ready 1d v1.6.0+fff5156 ...,disktype=ssd,kubernetes.io/hostname=worker0 - worker1 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker1 - worker2 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker2 - - - 在前面的输出中，你可以看到 `worker0` 节点有 `disktype=ssd` 标签。 + ``` + NAME STATUS AGE VERSION LABELS + worker0 Ready 1d v1.6.0+fff5156 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.6.0+fff5156 ...,kubernetes.io/hostname=worker2 + ``` + + 在前面的输出中，你可以看到 `worker0` 节点有 `disktype=ssd` 标签。 -## 创建一个调度到你选择的节点的 pod - -该 pod 配置文件描述了一个拥有节点选择器 `disktype: ssd` 的 pod。这表明该 pod 将被调度到 +## 创建一个调度到你选择的节点的 pod + +此 Pod 配置文件描述了一个拥有节点选择器 `disktype: ssd` 的 Pod。这表明该 Pod 将被调度到 有 `disktype=ssd` 标签的节点。 {{< codenew file="pods/pod-nginx.yaml" >}} @@ -107,24 +107,26 @@ a `disktype=ssd` label. --> 1. 使用该配置文件去创建一个 pod，该 pod 将被调度到你选择的节点上： - kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml + ```shell + kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml + ``` -1. 验证 pod 是不是运行在你选择的节点上： +2. 验证 pod 是不是运行在你选择的节点上： - kubectl get pods --output=wide - - - 输出类似如下： - - NAME READY STATUS RESTARTS AGE IP NODE - nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ```shell + kubectl get pods --output=wide + ``` + + 输出类似如下： + ``` + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` ## {{% heading "whatsnext" %}} @@ -132,6 +134,5 @@ a `disktype=ssd` label. Learn more about [labels and selectors](/docs/concepts/overview/working-with-objects/labels/). --> -了解更多关于 -[标签和选择器](/docs/concepts/overview/working-with-objects/labels/)。 +进一步了解[标签和选择器](/zh/docs/concepts/overview/working-with-objects/labels/) diff --git a/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 8c0cc202d6..a4ead7966a 100644 --- a/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -4,11 +4,9 @@ content_type: task weight: 140 --- @@ -23,33 +21,26 @@ Container is terminated. 当一个容器启动后，Kubernetes 将立即发送 postStart 事件；在容器被终结之前， Kubernetes 将发送一个 preStop 事件。 - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - -## 定义 postStart 和 preStop 处理函数 - +## 定义 postStart 和 preStop 处理函数 + 在本练习中，你将创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。 -下面是对应 Pod 的配置文件 +下面是对应 Pod 的配置文件： {{< codenew file="pods/lifecycle-events.yaml" >}} @@ -59,55 +50,58 @@ file to the Container's `/usr/share` directory. The preStop command shuts down nginx gracefully. This is helpful if the Container is being terminated because of a failure. --> 在上述配置文件中，你可以看到 postStart 命令在容器的 `/usr/share` 目录下写入文件 `message`。 -命令 preStop 负责优雅地终止 nginx 服务。当因为失效而导致容器终止时，这一处理方式很有用。``` +命令 preStop 负责优雅地终止 nginx 服务。当因为失效而导致容器终止时，这一处理方式很有用。 创建 Pod： - kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml +```shell +kubectl apply -f https://k8s.io/examples/pods/lifecycle-events.yaml +``` 验证 Pod 中的容器已经运行： - kubectl get pod lifecycle-demo +```shell +kubectl get pod lifecycle-demo +``` 使用 shell 连接到你的 Pod 里的容器： - kubectl exec -it lifecycle-demo -- /bin/bash +``` +kubectl exec -it lifecycle-demo -- /bin/bash +``` 在 shell 中，验证 `postStart` 处理函数创建了 `message` 文件： - root@lifecycle-demo:/# cat /usr/share/message +``` +root@lifecycle-demo:/# cat /usr/share/message +``` 命令行输出的是 `postStart` 处理函数所写入的文本 - Hello from the postStart handler - - - - +``` +Hello from the postStart handler +``` -## 讨论 - -Kubernetes 在容器创建后立即发送 postStart 事件。然而，postStart 处理函数的调用不保证早于容器的入口点（entrypoint） +## 讨论 + +Kubernetes 在容器创建后立即发送 postStart 事件。 +然而，postStart 处理函数的调用不保证早于容器的入口点（entrypoint） 的执行。postStart 处理函数与容器的代码是异步执行的，但 Kubernetes -的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。只有 postStart 处理函数执行完毕，容器的状态才会变成 +的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。 +只有 postStart 处理函数执行完毕，容器的状态才会变成 RUNNING。 Kubernetes 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期限超时，Kubernetes 的容器管理逻辑 会一直阻塞等待 preStop 处理函数执行完毕。更多的相关细节，可以参阅 -[Pods 的结束](/docs/user-guide/pods/#termination-of-pods)。 +[Pods 的结束](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 {{< note >}} -Kubernetes 只有在 Pod *结束（Terminated）* 的时候才会发送 preStop 事件，这意味着在 Pod *完成（Completed）* 时 +Kubernetes 只有在 Pod *结束（Terminated）* 的时候才会发送 preStop 事件， +这意味着在 Pod *完成（Completed）* 时 preStop 的事件处理逻辑不会被触发。这个限制在 [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807) 中被追踪。 {{< /note >}} - - - ## {{% heading "whatsnext" %}} - -* 进一步了解[容器生命周期回调](/docs/concepts/containers/container-lifecycle-hooks/)。 -* 进一步了解[Pod 的生命周期](/docs/concepts/workloads/pods/pod-lifecycle/)。 - +* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。 +* 进一步了解[Pod 的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。 这篇文章介绍如何给容器配置存活、就绪和启动探测器。 -[kubelet](/zh/docs/admin/kubelet/) 使用存活探测器来知道什么时候要重启容器。例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。 +[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +使用存活探测器来知道什么时候要重启容器。 +例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。 +这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。 -kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。 - -kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查，确保这些存活、就绪探测器不会影响应用程序的启动。这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 - +kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod +内的所有容器都准备好了，才能把这个 Pod 看作就绪了。 +这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 +在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。 +kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。 +如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查， +确保这些存活、就绪探测器不会影响应用程序的启动。 +这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - ## 定义存活命令 {#define-a-liveness-command} -许多长时间运行的应用程序最终会过渡到断开的状态，除非重新启动，否则无法恢复。Kubernetes 提供了存活探测器来发现并补救这种情况。 +许多长时间运行的应用程序最终会过渡到断开的状态，除非重新启动，否则无法恢复。 +Kubernetes 提供了存活探测器来发现并补救这种情况。 -在这篇练习中，会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。下面是这个 Pod 的配置文件。 +在这篇练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。 +下面是这个 Pod 的配置文件。 {{< codenew file="pods/probe/exec-liveness.yaml" >}} @@ -75,7 +81,12 @@ and restarts it. When the Container starts, it executes this command: --> -在这个配置文件中，可以看到 Pod 中只有一个容器。`periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。 +在这个配置文件中，可以看到 Pod 中只有一个容器。 +`periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 +`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 +kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。 +如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 +如果这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。 当容器启动时，执行如下的命令： @@ -90,7 +101,9 @@ code. After 30 seconds, `cat /tmp/healthy` returns a failure code. Create the Pod: --> -这个容器生命的前 30 秒， `/tmp/healthy` 文件是存在的。所以在这最开始的 30 秒内，执行命令 `cat /tmp/healthy` 会返回成功码。30 秒之后，执行命令 `cat /tmp/healthy` 就会返回失败码。 +这个容器生命的前 30 秒， `/tmp/healthy` 文件是存在的。 +所以在这最开始的 30 秒内，执行命令 `cat /tmp/healthy` 会返回成功代码。 +30 秒之后，执行命令 `cat /tmp/healthy` 就会返回失败代码。 创建 Pod： @@ -110,9 +123,9 @@ kubectl describe pod liveness-exec -输出结果显示还没有存活探测器失败： +输出结果表明还没有存活探测器失败： -```shell +``` FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 @@ -137,7 +150,7 @@ probes have failed, and the containers have been killed and recreated. --> 在输出结果的最下面，有信息显示存活探测器失败了，这个容器被杀死并且被重建了。 -```shell +``` FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 @@ -162,7 +175,7 @@ The output shows that `RESTARTS` has been incremented: --> 输出结果显示 `RESTARTS` 的值增加了 1。 -```shell +``` NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 1 1m ``` @@ -176,7 +189,8 @@ image. --> ## 定义一个存活态 HTTP 请求接口 {#define-a-liveness-HTTP-request} -另外一种类型的存活探测方式是使用 HTTP GET 请求。下面是一个 Pod 的配置文件，其中运行一个基于 `k8s.gcr.io/liveness` 镜像的容器。 +另外一种类型的存活探测方式是使用 HTTP GET 请求。 +下面是一个 Pod 的配置文件，其中运行一个基于 `k8s.gcr.io/liveness` 镜像的容器。 {{< codenew file="pods/probe/http-liveness.yaml" >}} @@ -191,7 +205,12 @@ returns a success code, the kubelet considers the Container to be alive and healthy. If the handler returns a failure code, the kubelet kills the Container and restarts it. --> -在这个配置文件中，可以看到 Pod 也只有一个容器。`periodSeconds` 字段指定了 kubelet 每隔 3 秒执行一次存活探测。`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。如果服务上 `/healthz` 路径下的处理程序返回成功码，则 kubelet 认为容器是健康存活的。如果处理程序返回失败码，则 kubelet 会杀死这个容器并且重新启动它。 +在这个配置文件中，可以看到 Pod 也只有一个容器。 +`periodSeconds` 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 +`initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 +kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。 +如果服务器上 `/healthz` 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。 +如果处理程序返回失败代码，则 kubelet 会杀死这个容器并且重新启动它。 -任何大于或等于 200 并且小于 400 的返回码标示成功，其它返回码都标示失败。 +任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。 可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。 @@ -229,7 +248,8 @@ checks will fail, and the kubelet will kill and restart the Container. To try the HTTP liveness check, create a Pod: --> -kubelet 在容器启动之后 3 秒开始执行健康检测。所以前几次健康检查都是成功的。但是 10 秒之后，健康检查会失败，并且 kubelet 会杀死容器再重新启动容器。 +kubelet 在容器启动之后 3 秒开始执行健康检测。所以前几次健康检查都是成功的。 +但是 10 秒之后，健康检查会失败，并且 kubelet 会杀死容器再重新启动容器。 创建一个 Pod 来测试 HTTP 的存活检测： @@ -254,7 +274,9 @@ the HTTP liveness probe uses that proxy. In releases after v1.13, local HTTP proxy environment variable settings do not affect the HTTP liveness probe. --> -在 1.13（包括 1.13版本）之前的版本中，如果在 Pod 运行的节点上设置了环境变量 `http_proxy`（或者 `HTTP_PROXY`），HTTP 的存活探测会使用这个代理。在 1.13 之后的版本中，设置本地的 HTTP 代理环境变量不会影响 HTTP 的存活探测。 +在 1.13（包括 1.13版本）之前的版本中，如果在 Pod 运行的节点上设置了环境变量 +`http_proxy`（或者 `HTTP_PROXY`），HTTP 的存活探测会使用这个代理。 +在 1.13 之后的版本中，设置本地的 HTTP 代理环境变量不会影响 HTTP 的存活探测。 ## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe} -第三种类型的存活探测是使用 TCP 套接字。通过配置，kubelet 会尝试在指定端口和容器建立套接字链接。如果能建立链接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。 +第三种类型的存活探测是使用 TCP 套接字。 +通过配置，kubelet 会尝试在指定端口和容器建立套接字链接。 +如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。 {{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} @@ -286,9 +310,15 @@ will be restarted. To try the TCP liveness check, create a Pod: --> -如你所见，TCP 检测的配置和 HTTP 检测非常相似。下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。这会尝试连接 `goproxy` 容器的 8080 端口。如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。 +如你所见，TCP 检测的配置和 HTTP 检测非常相似。 +下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。 +这会尝试连接 `goproxy` 容器的 8080 端口。 +如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。 -除了就绪探测，这个配置包括了一个存活探测。kubelet 会在容器启动 15 秒后进行第一次存活探测。就像就绪探测一样，会尝试连接 `goproxy` 容器的 8080 端口。如果存活探测失败，这个容器会被重新启动。 +除了就绪探测，这个配置包括了一个存活探测。 +kubelet 会在容器启动 15 秒后进行第一次存活探测。 +就像就绪探测一样，会尝试连接 `goproxy` 容器的 8080 端口。 +如果存活探测失败，这个容器会被重新启动。 ```shell kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml @@ -312,7 +342,8 @@ for HTTP or TCP liveness checks: --> ## 使用命名端口 {#use-a-named-port} -对于 HTTP 或者 TCP 存活检测可以使用命名的[容器端口](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core)。 +对于 HTTP 或者 TCP 存活检测可以使用命名的 +[ContainerPort](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerport-v1-core)。 ```yaml ports: @@ -341,7 +372,10 @@ So, the previous example would become: --> ## 使用启动探测器保护慢启动容器 {#define-startup-probes} -有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置 `failureThreshold * periodSeconds` 参数来保证有足够长的时间应对糟糕情况下的启动时间。 +有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。 +要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。 +技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置 +`failureThreshold * periodSeconds` 参数来保证有足够长的时间应对糟糕情况下的启动时间。 所以，前面的例子就变成了： @@ -392,12 +426,16 @@ Services. --> ## 定义就绪探测器 {#define-readiness-probes} -有时候，应用程序会暂时性的不能提供通信服务。例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。在这种情况下，既不想杀死应用程序，也不想给它发送请求。Kubernetes 提供了就绪探测器来发现并缓解这些情况。容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。 +有时候，应用程序会暂时性的不能提供通信服务。 +例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。 +在这种情况下，既不想杀死应用程序，也不想给它发送请求。 +Kubernetes 提供了就绪探测器来发现并缓解这些情况。 +容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。 -{{< note >}} +{{< note >}} 就绪探测器在容器的整个生命周期中保持运行状态。 {{< /note >}} @@ -405,7 +443,8 @@ Readiness probes runs on the container during its whole lifecycle. Readiness probes are configured similarly to liveness probes. The only difference is that you use the `readinessProbe` field instead of the `livenessProbe` field. --> -就绪探测器的配置和存活探测器的配置相似。唯一区别就是要使用 `readinessProbe` 字段，而不是 `livenessProbe` 字段。 +就绪探测器的配置和存活探测器的配置相似。 +唯一区别就是要使用 `readinessProbe` 字段，而不是 `livenessProbe` 字段。 ```yaml readinessProbe: @@ -426,17 +465,18 @@ for it, and that containers are restarted when they fail. --> HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置一样的。 -就绪和存活探测可以在同一个容器上并行使用。两者都用可以确保流量不会发给还没有准备好的容器，并且容器会在它们失败的时候被重新启动。 +就绪和存活探测可以在同一个容器上并行使用。 +两者都用可以确保流量不会发给还没有准备好的容器，并且容器会在它们失败的时候被重新启动。 ## 配置探测器 {#configure-probes} -{{< comment >}} +{{< comment >}} 最后，本节的一些内容可以放到某个概念主题里。 {{< /comment >}} @@ -445,7 +485,8 @@ Eventually, some of this section could be moved to a concept topic. you can use to more precisely control the behavior of liveness and readiness checks: --> -[探测器](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为： +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) +有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为： -[HTTP 探测器](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core)可以在 `httpGet` 上配置额外的字段： +[HTTP Probes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) +可以在 `httpGet` 上配置额外的字段： * `host`：连接使用的主机名，默认是 Pod 的 IP。也可以在 HTTP 头中设置 “Host” 来代替。 * `scheme` ：用于设置连接主机的方式（HTTP 还是 HTTPS）。默认是 HTTP。 @@ -502,20 +547,25 @@ For a TCP probe, the kubelet makes the probe connection at the node, not in the means that you can not use a service name in the `host` parameter since the kubelet is unable to resolve it. --> -对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。除非 `httpGet` 中的 `host` 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。如果 `scheme` 字段设置为了 `HTTPS`，kubelet 会跳过证书验证发送 HTTPS 请求。大多数情况下，不需要设置`host` 字段。这里有个需要设置 `host` 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 `hostNetwork` 字段设置为了 `true`。那么 `httpGet` 中的 `host` 字段应该设置为 127.0.0.1。可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 `host` 字段，而是应该在 `httpHeaders` 中设置 `Host`。 - -对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，这意味着你不能在 `host` 参数上配置 service name，因为 kubelet 不能解析 service name。 - +对于 HTTP 探测，kubelet 发送一个 HTTP 请求到指定的路径和端口来执行检测。 +除非 `httpGet` 中的 `host` 字段设置了，否则 kubelet 默认是给 Pod 的 IP 地址发送探测。 +如果 `scheme` 字段设置为了 `HTTPS`，kubelet 会跳过证书验证发送 HTTPS 请求。 +大多数情况下，不需要设置`host` 字段。 +这里有个需要设置 `host` 字段的场景，假设容器监听 127.0.0.1，并且 Pod 的 `hostNetwork` +字段设置为了 `true`。那么 `httpGet` 中的 `host` 字段应该设置为 127.0.0.1。 +可能更常见的情况是如果 Pod 依赖虚拟主机，你不应该设置 `host` 字段，而是应该在 +`httpHeaders` 中设置 `Host`。 +对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接， +这意味着你不能在 `host` 参数上配置服务名称，因为 kubelet 不能解析服务名称。 ## {{% heading "whatsnext" %}} - -* 进一步了解[容器探测器](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 +* 进一步了解[容器探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 ### 参考 {#reference} + * [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) -* [容器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) -* [探测器](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) +* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) diff --git a/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md index 56e8e560bf..1807a22fee 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -5,11 +5,9 @@ weight: 130 --- @@ -36,7 +34,7 @@ Here is the configuration file for the Pod: --> ## 创建一个包含 Init 容器的 Pod {#creating-a-pod-that-has-an-init-container} -本例中您将创建一个包含一个应用容器和一个 Init 容器的 Pod。Init 容器在应用容器启动前运行完成。 +本例中你将创建一个包含一个应用容器和一个 Init 容器的 Pod。Init 容器在应用容器启动前运行完成。 下面是 Pod 的配置文件： @@ -51,13 +49,14 @@ shared Volume at `/work-dir`, and the application container mounts the shared Volume at `/usr/share/nginx/html`. The init container runs the following command and then terminates: --> - -配置文件中，您可以看到应用容器和 Init 容器共享了一个卷。 +配置文件中，你可以看到应用容器和 Init 容器共享了一个卷。 Init 容器将共享卷挂载到了 `/work-dir` 目录，应用容器将共享卷挂载到了 `/usr/share/nginx/html` 目录。 Init 容器执行完下面的命令就终止： - wget -O /work-dir/index.html http://kubernetes.io +```shell +wget -O /work-dir/index.html http://kubernetes.io +``` - 请注意 Init 容器在 nginx 服务器的根目录写入 `index.html`。 创建 Pod： - kubectl create -f https://k8s.io/examples/pods/init-containers.yaml +```shell +kubectl create -f https://k8s.io/examples/pods/init-containers.yaml +``` - 检查 nginx 容器运行正常： - kubectl get pod init-demo +```shell +kubectl get pod init-demo +``` - 结果表明 nginx 容器运行正常： - NAME READY STATUS RESTARTS AGE - init-demo 1/1 Running 0 1m +``` +NAME READY STATUS RESTARTS AGE +init-demo 1/1 Running 0 1m +``` - 通过 shell 进入 init-demo Pod 中的 nginx 容器： - kubectl exec -it init-demo -- /bin/bash +```shell +kubectl exec -it init-demo -- /bin/bash +``` - 结果表明 nginx 正在为 Init 容器编写的 web 页面服务： - - - - - ... - "url": "http://kubernetes.io/"} - - - ... -

Kubernetes is open source giving you the freedom to take advantage ...

- ... - +``` + + + +... +"url": "http://kubernetes.io/"} + + + ... +

Kubernetes is open source giving you the freedom to take advantage ...

+ ... +``` ## {{% heading "whatsnext" %}} - -* 进一步了解 [相同 Pod 中的容器间的通信](/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。 -* 进一步了解 [Init 容器](/docs/concepts/workloads/pods/init-containers/)。 -* 进一步了解 [卷](/docs/concepts/storage/volumes/)。 -* 进一步了解 [Init 容器排错](/docs/tasks/debug-application-cluster/debug-init-containers/)。 - - - +* 进一步了解[同一 Pod 中的容器间的通信](/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。 +* 进一步了解 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。 +* 进一步了解[卷](/zh/docs/concepts/storage/volumes/)。 +* 进一步了解 [Init 容器排错](/zh/docs/tasks/debug-application-cluster/debug-init-containers/)。 diff --git a/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md b/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md index d6a2476c6f..b64a51b2ab 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-runasusername.md @@ -1,15 +1,13 @@ --- -title: 为 Windows 的 pod 和容器配置 RunAsUserName +title: 为 Windows 的 Pod 和容器配置 RunAsUserName content_type: task weight: 20 --- @@ -19,36 +17,38 @@ weight: 20 +本页展示如何为运行在 Windows 节点上的 pod 和容器启用并使用 `RunAsUserName` 功能。 +此功能旨在成为 Windows 版的 `runAsUser`（Linux），允许用户使用与默认用户名不同的 +用户名运行容器 entrypoint。 -本页展示如何为运行在 Windows 节点上的 pod 和容器启用并使用 `RunAsUserName` 功能。此功能旨在成为 Windows 版的 `runAsUser`（Linux），允许用户使用与默认用户名不同的用户名运行容器 entrypoint。 - -{{< note >}} -该功能目前处于 beta 状态。 `RunAsUserName` 的整体功能不会出现变更，但是关于用户名验证的部分可能会有所更改。 +{{< note >}} +此功能目前处于 Beta 状态。`RunAsUserName` 的整体功能不会出现变更， +但是关于用户名验证的部分可能会有所更改。 {{< /note >}} - - ## {{% heading "prerequisites" %}} - - -你必须有一个 Kubernetes 集群，并且 kubectl 必须能和集群通信。集群应该要有 Windows 工作节点，将在其中调度运行 Windows 工作负载的 pod 和容器。 +你必须有一个 Kubernetes 集群，并且 kubectl 必须能和集群通信。 +集群应该要有 Windows 工作节点，将在其中调度运行 Windows 工作负载的 pod 和容器。 - ## 为 Pod 设置 Username -要指定运行 Pod 容器时所使用的用户名，请在 Pod 声明中包含 `securityContext` （[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)）字段，并在其内部包含 `windowsOptions` （[WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)）字段的 `runAsUserName` 字段。 +要指定运行 Pod 容器时所使用的用户名，请在 Pod 声明中包含 `securityContext` +（[PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)）字段， +并在其内部包含 `windowsOptions` +（[WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)） +字段的 `runAsUserName` 字段。 -您为 Pod 指定的 Windows SecurityContext 选项适用于该 Pod 中（包括 init 容器）的所有容器。 +你为 Pod 指定的 Windows SecurityContext 选项适用于该 Pod 中（包括 init 容器）的所有容器。 这儿有一个已经设置了 `runAsUserName` 字段的 Windows Pod 的配置文件： @@ -127,17 +127,15 @@ The Windows security context options that you specify for a Container apply only Here is the configuration file for a Pod that has one Container, and the `runAsUserName` field is set at the Pod level and the Container level: --> +你为容器指定的 Windows SecurityContext 选项仅适用于该容器，并且它会覆盖 Pod 级别设置。 -您为容器指定的 Windows SecurityContext 选项仅适用于该容器，并且它会覆盖 Pod 级别设置。 - -这儿有一个 Pod 的配置文件，其只有一个容器，并且在 Pod 级别和容器级别都设置了 `runAsUserName`： +这里有一个 Pod 的配置文件，其中只有一个容器，并且在 Pod 级别和容器级别都设置了 `runAsUserName`： {{< codenew file="windows/run-as-username-container.yaml" >}} - 创建 Pod： ```shell @@ -147,7 +145,6 @@ kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml - 验证 Pod 容器是否在运行： ```shell @@ -157,7 +154,6 @@ kubectl get pod run-as-username-container-demo - 获取该容器的 shell： ```shell @@ -167,7 +163,6 @@ kubectl exec -it run-as-username-container-demo -- powershell - 检查运行 shell 的用户的用户名是否正确（应该是容器级别设置的那个）： ```powershell @@ -177,10 +172,9 @@ echo $env:USERNAME - 输出结果应该是这样： -```shell +``` ContainerAdministrator ``` @@ -189,10 +183,11 @@ ContainerAdministrator In order to use this feature, the value set in the `runAsUserName` field must be a valid username. It must have the following format: `DOMAIN\USER`, where `DOMAIN\` is optional. Windows user names are case insensitive. Additionally, there are some restrictions regarding the `DOMAIN` and `USER`: --> - ## Windows Username 的局限性 -想要使用此功能，在 `runAsUserName` 字段中设置的值必须是有效的用户名。它必须是 `DOMAIN\USER` 这种格式，其中 `DOMAIN\` 是可选的。Windows 用户名不区分大小写。此外，关于 `DOMAIN` 和 `USER` 还有一些限制： +想要使用此功能，在 `runAsUserName` 字段中设置的值必须是有效的用户名。 +它必须是 `DOMAIN\USER` 这种格式，其中 `DOMAIN\` 是可选的。 +Windows 用户名不区分大小写。此外，关于 `DOMAIN` 和 `USER` 还有一些限制： - - `runAsUserName` 字段不能为空，并且不能包含控制字符（ASCII 值：`0x00-0x1F`、`0x7F`） - `DOMAIN` 必须是 NetBios 名称或 DNS 名称，每种名称都有各自的局限性： - NetBios 名称：最多 15 个字符，不能以 `.`（点）开头，并且不能包含以下字符：`\ / : * ? " < > |` @@ -213,24 +207,19 @@ Examples of acceptable values for the `runAsUserName` field: `ContainerAdministr For more information about these limtations, check [here](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and) and [here](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1). --> - -`runAsUserName` 字段接受的值的一些示例：`ContainerAdministrator`、`ContainerUser`、`NT AUTHORITY\NETWORK SERVICE`、`NT AUTHORITY\LOCAL SERVICE`。 +`runAsUserName` 字段接受的值的一些示例：`ContainerAdministrator`、`ContainerUser`、 +`NT AUTHORITY\NETWORK SERVICE`、`NT AUTHORITY\LOCAL SERVICE`。 关于这些限制的更多信息，可以查看[这里](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and)和[这里](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1)。 - - ## {{% heading "whatsnext" %}} - - -* [Kubernetes 中调度 Windows 容器的指南](/docs/setup/production-environment/windows/user-guide-windows-containers/) -* [使用组托管服务帐户（GMSA）管理工作负载身份](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts) -* [Windows 下 pod 和容器的 GMSA 配置](/docs/tasks/configure-pod-container/configure-gmsa/) - +* [Kubernetes 中调度 Windows 容器的指南](/zh/docs/setup/production-environment/windows/user-guide-windows-containers/) +* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts) +* [Windows 下 pod 和容器的 GMSA 配置](/zh/docs/tasks/configure-pod-container/configure-gmsa/) diff --git a/content/zh/docs/tasks/configure-pod-container/extended-resource.md b/content/zh/docs/tasks/configure-pod-container/extended-resource.md index 005152b9e9..e34a5e4eb1 100644 --- a/content/zh/docs/tasks/configure-pod-container/extended-resource.md +++ b/content/zh/docs/tasks/configure-pod-container/extended-resource.md @@ -5,11 +5,9 @@ weight: 40 --- @@ -21,14 +19,8 @@ This page shows how to assign extended resources to a Container. --> 本文介绍如何为容器指定扩展资源。 -{{< feature-state state="stable" >}} - - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -在您开始此练习前，请先练习[为节点广播扩展资源](/docs/tasks/administer-cluster/extended-resource-node/)。 -在那个练习中将配置您的一个节点来广播 dongle 资源。 - - - +在你开始此练习前，请先练习 +[为节点广播扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/)。 +在那个练习中将配置你的一个节点来广播 dongle 资源。 @@ -57,9 +47,10 @@ Here is the configuration file for a Pod that has one Container: --> ## 给 Pod 分派扩展资源 -要请求扩展资源，需要在您的容器清单中包括 `resources:requests` 字段。 +要请求扩展资源，需要在你的容器清单中包括 `resources:requests` 字段。 扩展资源可以使用任何完全限定名称，只是不能使用 `*.kubernetes.io/`。 -有效的扩展资源名的格式为 `example.com/foo`，其中 `example.com` 应被替换为您的组织的域名，而 `foo` 则是描述性的资源名称。 +有效的扩展资源名的格式为 `example.com/foo`，其中 `example.com` 应被替换为 +你的组织的域名，而 `foo` 则是描述性的资源名称。 下面是包含一个容器的 Pod 配置文件： @@ -70,7 +61,7 @@ In the configuration file, you can see that the Container requests 3 dongles. Create a Pod: --> -在配置文件中，您可以看到容器请求了 3 个 dongles。 +在配置文件中，你可以看到容器请求了 3 个 dongles。 创建 Pod： @@ -137,7 +128,7 @@ kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.y -描述 Pod +描述 Pod： ```shell kubectl describe pod extended-resource-demo-2 @@ -175,7 +166,7 @@ It has a status of Pending: --> 输出结果表明 Pod 虽然被创建了，但没有被调度到节点上正常运行。Pod 的状态为 Pending： -```yaml +``` NAME READY STATUS RESTARTS AGE extended-resource-demo-2 0/1 Pending 0 6m ``` @@ -185,7 +176,7 @@ extended-resource-demo-2 0/1 Pending 0 6m Delete the Pods that you created for this exercise: --> -## 环境清理 +## 清理 删除本练习中创建的 Pod： @@ -194,11 +185,8 @@ kubectl delete pod extended-resource-demo kubectl delete pod extended-resource-demo-2 ``` - - ## {{% heading "whatsnext" %}} - ## 应用开发者参考 -* [为容器和 Pod 分配内存资源](/docs/tasks/configure-pod-container/assign-memory-resource/) -* [为容器和 Pod 分配 CPU 资源](/docs/tasks/configure-pod-container/assign-cpu-resource/) +* [为容器和 Pod 分配内存资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) +* [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) ### 集群管理员参考 -* [为节点广播扩展资源](/docs/tasks/administer-cluster/extended-resource-node/) - - +* [为节点广播扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/) diff --git a/content/zh/docs/tasks/configure-pod-container/static-pod.md b/content/zh/docs/tasks/configure-pod-container/static-pod.md index eef7ea7f2b..573bdd8d2d 100644 --- a/content/zh/docs/tasks/configure-pod-container/static-pod.md +++ b/content/zh/docs/tasks/configure-pod-container/static-pod.md @@ -1,6 +1,4 @@ --- -reviewers: -- jsafrane title: 创建静态 Pod weight: 170 content_type: task @@ -17,8 +15,10 @@ Unlike Pods that are managed by the control plane (for example, a instead, the kubelet watches each static Pod (and restarts it if it crashes). --> -*静态 Pod* 在指定的节点上由 kubelet 守护进程直接管理，不需要 {{< glossary_tooltip text="API 服务" term_id="kube-apiserver" >}} 监管。 -不像 Pod 是由控制面管理的（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}）；相反 kubelet 监视每个静态 Pod（在它崩溃之后重新启动）。 +*静态 Pod* 在指定的节点上由 kubelet 守护进程直接管理，不需要 +{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} 监管。 +与由控制面管理的 Pod（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}） +不同；kubelet 监视每个静态 Pod（在它崩溃之后重新启动）。 - 静态 Pod 永远都会绑定到一个指定节点上的 {{< glossary_tooltip term_id="kubelet" >}}。 -kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个 {{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。 +kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个 +{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。 这意味着节点上运行的静态 Pod 对 API 服务来说是不可见的，但是不能通过 API 服务器来控制。 {{< note >}} -如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod，就可能需要考虑使用 {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} 替代这种方式。 +如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod， +就可能需要考虑使用 {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} 替代这种方式。 {{< /note >}} - - ## {{% heading "prerequisites" %}} @@ -57,12 +56,10 @@ This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run and that your nodes are running the Fedora operating system. Instructions for other distributions or Kubernetes installations may vary. --> - -本文假定你在使用 {{< glossary_tooltip term_id="docker" >}} 来运行 Pod，并且你的节点是运行着 Fedora 操作系统。 +本文假定你在使用 {{< glossary_tooltip term_id="docker" >}} 来运行 Pod， +并且你的节点是运行着 Fedora 操作系统。 其它发行版或者 Kubernetes 部署版本上操作方式可能不一样。 - - - ## 创建静态 Pod {#static-pod-creation} -可以通过[文件系统上的配置文件](/docs/tasks/configure-pod-container/static-pod/#configuration-files)或者 [web 网络上的配置文件](/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)来配置静态 Pod。 +可以通过[文件系统上的配置文件](/zh/docs/tasks/configure-pod-container/static-pod/#configuration-files) +或者 [web 网络上的配置文件](/zh/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http) +来配置静态 Pod。 - ### 文件系统上的静态 Pod 声明文件 {#configuration-files} -声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在 [Kubelet 配置文件](/docs/tasks/administer-cluster/kubelet-config-file)的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON 文件来创建/删除静态 Pod。 +声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在 +[Kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) +的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON +文件来创建/删除静态 Pod。 注意 kubelet 扫描目录的时候会忽略以点开头的文件。 例如：下面是如何以静态 Pod 的方式启动一个简单 web 服务： @@ -97,9 +97,9 @@ For example, this is how to start a simple web server as a static Pod: 1. 选择一个要运行静态 Pod 的节点。在这个例子中选择 `my-node1`。 - ```shell - ssh my-node1 - ``` + ```shell + ssh my-node1 + ``` +2. 选择一个目录，比如在 `/etc/kubelet.d` 目录来保存 web 服务 Pod 的定义文件， + `/etc/kubelet.d/static-web.yaml`： -1. 选择一个目录，比如在 `/etc/kubelet.d` 目录来保存 web 服务 Pod 的定义文件， `/etc/kubelet.d/static-web.yaml`： + ```shell + # 在 kubelet 运行的节点上执行以下命令 + mkdir /etc/kubelet.d/ + cat </etc/kubelet.d/static-web.yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + EOF + ``` - ```shell - # 在 kubelet 运行的节点上执行以下命令 - mkdir /etc/kubelet.d/ - cat </etc/kubelet.d/static-web.yaml - apiVersion: v1 - kind: Pod - metadata: - name: static-web - labels: - role: myrole - spec: - containers: - - name: web - image: nginx - ports: - - name: web - containerPort: 80 - protocol: TCP - EOF - ``` - 3. 配置这个节点上的 kubelet，使用这个参数执行 `--pod-manifest-path=/etc/kubelet.d/`： - ``` - KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" - ``` - 或者在 [Kubelet配置文件](/docs/tasks/administer-cluster/kubelet-config-file)中添加 `staticPodPath: <目录>`字段。 + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + 或者在 [Kubelet配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) + 中添加 `staticPodPath: <目录>`字段。 +4. 重启 kubelet。Fedora 上使用下面的命令： -1. 重启 kubelet。Fedora 上使用下面的命令： + ```shell + # 在 kubelet 运行的节点上执行以下命令 + systemctl restart kubelet + ``` - ```shell - # 在 kubelet 运行的节点上执行以下命令 - systemctl restart kubelet - ``` - ### Web 网上的静态 Pod 声明文件 {#pods-created-via-http} -Kubelet 根据 `--manifest-url=` 参数的配置定期的下载指定文件，并且转换成 JSON/YAML 格式的 Pod 容器定义文件。 -与[文件系统上的声明文件](#configuration-files)使用方式类似，kubelet 调度获取声明文件。如果静态 Pod 的声明文件有改变，kubelet会应用这些改变。 +Kubelet 根据 `--manifest-url=` 参数的配置定期的下载指定文件，并且转换成 +JSON/YAML 格式的 Pod 定义文件。 +与[文件系统上的清单文件](#configuration-files)使用方式类似，kubelet 调度获取清单文件。 +如果静态 Pod 的清单文件有改变，kubelet 会应用这些改变。 按照下面的方式来： - 1. 创建一个 YAML 文件，并保存在保存在 web 服务上，为 kubelet 生成一个 URL。 - ```yaml - apiVersion: v1 - kind: Pod - metadata: - name: static-web - labels: - role: myrole - spec: - containers: - - name: web - image: nginx - ports: - - name: web - containerPort: 80 - protocol: TCP - ``` + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + ``` +2. 通过在选择的节点上使用 `--manifest-url=` 配置运行 kubelet。 + 在 Fedora 添加下面这行到 `/etc/kubernetes/kubelet` ： -1. 通过在选择的节点上使用 `--manifest-url=` 配置运行 kubelet。在 Fedora 添加下面这行到 `/etc/kubernetes/kubelet` ： - - ``` - KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=" - ``` + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=" + ``` +3. 重启 kubelet。在 Fedora 上运行如下命令： -1. 重启 kubelet。在 Fedora 上运行如下命令： + ```shell + # 在 kubelet 运行的节点上执行以下命令 + systemctl restart kubelet + ``` - ```shell - # 在 kubelet 运行的节点上执行以下命令 - systemctl restart kubelet - ``` - ## 观察静态 pod 的行为 {#behavior-of-static-pods} -当 kubelet 启动时，会自动启动所有定义的静态 Pod。当定义了一个静态 Pod 并重新启动 kubelet 时，新的静态 Pod 就应该已经在运行了。 +当 kubelet 启动时，会自动启动所有定义的静态 Pod。 +当定义了一个静态 Pod 并重新启动 kubelet 时，新的静态 Pod 就应该已经在运行了。 可以在节点上运行下面的命令来查看正在运行的容器（包括静态 Pod）： + ```shell # 在 kubelet 运行的节点上执行以下命令 docker ps ``` + - 输出可能会像这样： ``` CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c ``` + - 可以在 API 服务上看到镜像 Pod： ```shell kubectl get pods ``` + ``` NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 2m ``` + - {{< note >}} -要确保 kubelet 在 API 服务上有创建镜像 Pod 的权限。如果没有，创建请求会被 API 服务拒绝。可以看[Pod安全策略](/docs/concepts/policy/pod-security-policy/)。 +要确保 kubelet 在 API 服务上有创建镜像 Pod 的权限。如果没有，创建请求会被 API 服务拒绝。 +可以看[Pod安全策略](/zh/docs/concepts/policy/pod-security-policy/)。 {{< /note >}} -静态 Pod 上的{{< glossary_tooltip term_id="label" text="标签" >}} 被传到镜像 Pod。 你可以通过 {{< glossary_tooltip term_id="selector" text="选择算符" >}} 使用这些标签，比如。 +静态 Pod 上的{{< glossary_tooltip term_id="label" text="标签" >}} 被传到镜像 Pod。 +你可以通过 {{< glossary_tooltip term_id="selector" text="选择算符" >}} 使用这些标签。 可以看到 Pod 还在运行： + ```shell kubectl get pods ``` + ``` NAME READY STATUS RESTARTS AGE static-web-my-node1 1/1 Running 0 12s ``` + - 回到 kubelet 运行的节点上，可以手工停止 Docker 容器。 可以看到过了一段时间后 kubelet 会发现容器停止了并且会自动重启 Pod： ```shell # 在 kubelet 运行的节点上执行以下命令 -docker stop f6d05272b57e # 把 ID 换为你的容器的 ID +# 把 ID 换为你的容器的 ID +docker stop f6d05272b57e sleep 20 docker ps ``` + ``` CONTAINER ID IMAGE COMMAND CREATED ... 5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... ``` + ## 动态增加和删除静态 pod -运行中的 kubelet 会定期扫描配置的目录(比如例子中的 `/etc/kubelet.d` 目录)中的变化，并且根据文件中出现/消失的 Pod 来添加/删除 Pod。 +运行中的 kubelet 会定期扫描配置的目录(比如例子中的 `/etc/kubelet.d` 目录)中的变化， +并且根据文件中出现/消失的 Pod 来添加/删除 Pod。 ```shell # 前提是你在用主机文件系统上的静态 Pod 配置文件 # 在 kubelet 运行的节点上执行以下命令 -# mv /etc/kubelet.d/static-web.yaml /tmp sleep 20 docker ps @@ -393,6 +402,7 @@ mv /tmp/static-web.yaml /etc/kubelet.d/ sleep 20 docker ps ``` + ``` CONTAINER ID IMAGE COMMAND CREATED ... e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago diff --git a/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md index 9ecc6c22f2..175bdac0da 100644 --- a/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md +++ b/content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -7,13 +7,9 @@ weight: 200 --- @@ -21,52 +17,41 @@ weight: 170 - -Kompose 是什么？它是个转换工具，可将 compose（即 Docker Compose）所组装的所有内容转换成容器编排器（Kubernetes 或 OpenShift）可识别的形式。 +Kompose 是什么？它是个转换工具，可将 compose（即 Docker Compose）所组装的所有内容 +转换成容器编排器（Kubernetes 或 OpenShift）可识别的形式。 - 更多信息请参考 Kompose 官网 [http://kompose.io](http://kompose.io)。 - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - -## 安装 Kompose - - +## 安装 Kompose 我们有很多种方式安装 Kompose。首选方式是从最新的 GitHub 发布页面下载二进制文件。 -## GitHub 发布版本 - - +## GitHub 发布版本 -Kompose 通过 GitHub 发布版本，发布周期为三星期。您可以在[GitHub 发布页面](https://github.com/kubernetes/kompose/releases)上看到所有当前版本。 +Kompose 通过 GitHub 发布版本，发布周期为三星期。 +你可以在 [GitHub 发布页面](https://github.com/kubernetes/kompose/releases) +上看到所有当前版本。 -```sh +```shell # Linux curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose @@ -83,18 +68,16 @@ sudo mv ./kompose /usr/local/bin/kompose -或者，您可以下载 [tarball](https://github.com/kubernetes/kompose/releases)。 +或者，你可以下载 [tarball](https://github.com/kubernetes/kompose/releases)。 ## Go - 用 `go get` 命令从主分支拉取最新的开发变更的方法安装 Kompose。 - -```sh +```shell go get -u github.com/kubernetes/kompose ``` @@ -104,17 +87,17 @@ go get -u github.com/kubernetes/kompose Kompose is in [EPEL](https://fedoraproject.org/wiki/EPEL) CentOS repository. If you don't have [EPEL](https://fedoraproject.org/wiki/EPEL) repository already installed and enabled you can do it by running `sudo yum install epel-release` --> - Kompose 位于 [EPEL](https://fedoraproject.org/wiki/EPEL) CentOS 代码仓库。 -如果您还没有安装启用 [EPEL](https://fedoraproject.org/wiki/EPEL) 代码仓库，请运行命令 `sudo yum install epel-release`。 +如果你还没有安装启用 [EPEL](https://fedoraproject.org/wiki/EPEL) 代码仓库， +请运行命令 `sudo yum install epel-release`。 +如果你的系统中已经启用了 [EPEL](https://fedoraproject.org/wiki/EPEL)， +你就可以像安装其他软件包一样安装 Kompose。 -如果您的系统中已经启用了 [EPEL](https://fedoraproject.org/wiki/EPEL)，您就可以像安装其他软件包一样安装 Kompose。 - -```bash +```shell sudo yum -y install kompose ``` @@ -123,10 +106,9 @@ sudo yum -y install kompose +Kompose 位于 Fedora 24、25 和 26 的代码仓库。你可以像安装其他软件包一样安装 Kompose。 -Kompose 位于 Fedora 24、25 和 26 的代码仓库。您可以像安装其他软件包一样安装 Kompose。 - -```bash +```shell sudo dnf -y install kompose ``` @@ -135,152 +117,154 @@ sudo dnf -y install kompose +在 macOS 上你可以通过 [Homebrew](https://brew.sh) 安装 Kompose 的最新版本： -在 macOS 上您可以通过 [Homebrew](https://brew.sh) 安装 Kompose 的最新版本： - -```bash +```shell brew install kompose - ``` + - ## 使用 Kompose - 再需几步，我们就把你从 Docker Compose 带到 Kubernetes。 -您只需要一个现有的 `docker-compose.yml` 文件。 +你只需要一个现有的 `docker-compose.yml` 文件。 1. 进入 `docker-compose.yml` 文件所在的目录。如果没有，请使用下面这个进行测试。 - ```yaml - version: "2" + ```yaml + version: "2" - services: + services: - redis-master: - image: k8s.gcr.io/redis:e2e - ports: - - "6379" + redis-master: + image: k8s.gcr.io/redis:e2e + ports: + - "6379" - redis-slave: - image: gcr.io/google_samples/gb-redisslave:v3 - ports: - - "6379" - environment: - - GET_HOSTS_FROM=dns - - frontend: - image: gcr.io/google-samples/gb-frontend:v4 - ports: - - "80:80" - environment: - - GET_HOSTS_FROM=dns - labels: - kompose.service.type: LoadBalancer - ``` + redis-slave: + image: gcr.io/google_samples/gb-redisslave:v3 + ports: + - "6379" + environment: + - GET_HOSTS_FROM=dns + frontend: + image: gcr.io/google-samples/gb-frontend:v4 + ports: + - "80:80" + environment: + - GET_HOSTS_FROM=dns + labels: + kompose.service.type: LoadBalancer + ``` 2. 运行 `kompose up` 命令直接部署到 Kubernetes，或者跳到下一步，生成 `kubectl` 使用的文件。 - ```bash - $ kompose up - We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. - If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. + ```bash + $ kompose up + We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. + If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. - INFO Successfully created Service: redis - INFO Successfully created Service: web - INFO Successfully created Deployment: redis - INFO Successfully created Deployment: web - - Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details. - ``` + INFO Successfully created Service: redis + INFO Successfully created Service: web + INFO Successfully created Deployment: redis + INFO Successfully created Deployment: web + Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details. + ``` 3. - 要将 `docker-compose.yml` 转换为 `kubectl` 可用的文件，请运行 `kompose convert` 命令进行转换，然后运行 `kubectl create -f ` 进行创建。 + 要将 `docker-compose.yml` 转换为 `kubectl` 可用的文件，请运行 `kompose convert` 命令进行转换， + 然后运行 `kubectl create -f ` 进行创建。 - ```bash - $ kompose convert - INFO Kubernetes file "frontend-service.yaml" created - INFO Kubernetes file "redis-master-service.yaml" created - INFO Kubernetes file "redis-slave-service.yaml" created - INFO Kubernetes file "frontend-deployment.yaml" created - INFO Kubernetes file "redis-master-deployment.yaml" created - INFO Kubernetes file "redis-slave-deployment.yaml" created - ``` + ```shell + kompose convert + ``` - ```bash - $ kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml - service/frontend created - service/redis-master created - service/redis-slave created - deployment.apps/frontend created - deployment.apps/redis-master created - deployment.apps/redis-slave created - ``` - - 您部署的应用在 Kubernetes 中运行起来了。 + ``` + INFO Kubernetes file "frontend-service.yaml" created + INFO Kubernetes file "redis-master-service.yaml" created + INFO Kubernetes file "redis-slave-service.yaml" created + INFO Kubernetes file "frontend-deployment.yaml" created + INFO Kubernetes file "redis-master-deployment.yaml" created + INFO Kubernetes file "redis-slave-deployment.yaml" created + ``` + ```shell + kubectl create -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml + ``` -4. 访问您的应用。 + ``` + service/frontend created + service/redis-master created + service/redis-slave created + deployment.apps/frontend created + deployment.apps/redis-master created + deployment.apps/redis-slave created + ``` - + + 你部署的应用在 Kubernetes 中运行起来了。 - 如果您在开发过程中使用 `minikube`，请执行： +4. + 访问你的应用 - ```bash - $ minikube service frontend - ``` + - - 否则，我们要查看一下您的服务使用了什么 IP！ + 如果你在开发过程中使用 `minikube`，请执行： - ```sh - $ kubectl describe svc frontend - Name: frontend - Namespace: default - Labels: service=frontend - Selector: service=frontend - Type: LoadBalancer - IP: 10.0.0.183 - LoadBalancer Ingress: 192.0.2.89 - Port: 80 80/TCP - NodePort: 80 31144/TCP - Endpoints: 172.17.0.4:80 - Session Affinity: None - No events. + ```shell + minikube service frontend + ``` - ``` + + 否则，我们要查看一下你的服务使用了什么 IP！ - - 如果您使用的是云提供商，您的 IP 将在 `LoadBalancer Ingress` 字段给出。 + ```shell + kubectl describe svc frontend + ``` - ```sh - $ curl http://192.0.2.89 - ``` + ``` + Name: frontend + Namespace: default + Labels: service=frontend + Selector: service=frontend + Type: LoadBalancer + IP: 10.0.0.183 + LoadBalancer Ingress: 192.0.2.89 + Port: 80 80/TCP + NodePort: 80 31144/TCP + Endpoints: 172.17.0.4:80 + Session Affinity: None + No events. + ``` + + 如果你使用的是云提供商，你的 IP 将在 `LoadBalancer Ingress` 字段给出。 + ```shell + curl http://192.0.2.89 + ``` - -## 用户指南 +## 用户指南 {#user-guide} - - CLI - [`kompose convert`](#kompose-convert) - [`kompose up`](#kompose-up) - [`kompose down`](#kompose-down) + - 文档 - [构建和推送 Docker 镜像](#构建和推送-docker-镜像) - [其他转换方式](#其他转换方式) @@ -310,9 +294,8 @@ you need is an existing `docker-compose.yml` file. Kompose has support for two providers: OpenShift and Kubernetes. You can choose a targeted provider using global option `--provider`. If no provider is specified, Kubernetes is set by default. --> - Kompose 支持两种驱动：OpenShift 和 Kubernetes。 -您可以通过全局选项 `--provider` 选择驱动方式。如果没有指定，会将 Kubernetes 作为默认驱动。 +你可以通过全局选项 `--provider` 选择驱动方式。如果没有指定，会将 Kubernetes 作为默认驱动。 ## `kompose convert` @@ -320,8 +303,10 @@ Kompose 支持将 V1、V2 和 V3 版本的 Docker Compose 文件转换为 Kubern ### Kubernetes -```sh -$ kompose --file docker-voting.yml convert +```shell +kompose --file docker-voting.yml convert +``` +``` WARN Unsupported key networks - ignoring WARN Unsupported key build - ignoring INFO Kubernetes file "worker-svc.yaml" created @@ -334,8 +319,13 @@ INFO Kubernetes file "result-deployment.yaml" created INFO Kubernetes file "vote-deployment.yaml" created INFO Kubernetes file "worker-deployment.yaml" created INFO Kubernetes file "db-deployment.yaml" created +``` -$ ls +```shell +ls +``` + +``` db-deployment.yaml docker-compose.yml docker-gitlab.yml redis-deployment.yaml result-deployment.yaml vote-deployment.yaml worker-deployment.yaml db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yaml vote-svc.yaml worker-svc.yaml ``` @@ -343,11 +333,12 @@ db-svc.yaml docker-voting.yml redis-svc.yaml result-svc.yam +你也可以同时提供多个 docker-compose 文件进行转换： -您也可以同时提供多个 docker-compose 文件进行转换： - -```sh -$ kompose -f docker-compose.yml -f docker-guestbook.yml convert +```shell +kompose -f docker-compose.yml -f docker-guestbook.yml convert +``` +``` INFO Kubernetes file "frontend-service.yaml" created INFO Kubernetes file "mlbparks-service.yaml" created INFO Kubernetes file "mongodb-service.yaml" created @@ -359,8 +350,13 @@ INFO Kubernetes file "mongodb-deployment.yaml" created INFO Kubernetes file "mongodb-claim0-persistentvolumeclaim.yaml" created INFO Kubernetes file "redis-master-deployment.yaml" created INFO Kubernetes file "redis-slave-deployment.yaml" created +``` -$ ls +```shell +ls +``` + +``` mlbparks-deployment.yaml mongodb-service.yaml redis-slave-service.jsonmlbparks-service.yaml frontend-deployment.yaml mongodb-claim0-persistentvolumeclaim.yaml redis-master-service.yaml frontend-service.yaml mongodb-deployment.yaml redis-slave-deployment.yaml @@ -370,13 +366,15 @@ redis-master-deployment.yaml - 当提供多个 docker-compose 文件时，配置将会合并。任何通用的配置都将被后续文件覆盖。 ### OpenShift -```sh -$ kompose --provider openshift --file docker-voting.yml convert +```shell +kompose --provider openshift --file docker-voting.yml convert +``` + +``` WARN [worker] Service cannot be created because of missing port. INFO OpenShift file "vote-service.yaml" created INFO OpenShift file "db-service.yaml" created @@ -397,13 +395,15 @@ INFO OpenShift file "result-imagestream.yaml" created - kompose 还支持为服务中的构建指令创建 buildconfig。 默认情况下，它使用当前 git 分支的 remote 仓库作为源仓库，使用当前分支作为构建的源分支。 -您可以分别使用 ``--build-repo`` 和 ``--build-branch`` 选项指定不同的源仓库和分支。 +你可以分别使用 ``--build-repo`` 和 ``--build-branch`` 选项指定不同的源仓库和分支。 -```sh -$ kompose --provider openshift --file buildconfig/docker-compose.yml convert +```shell +kompose --provider openshift --file buildconfig/docker-compose.yml convert +``` + +``` WARN [foo] Service cannot be created because of missing port. INFO OpenShift Buildconfig using git@github.com:rtnpro/kompose.git::master as source. INFO OpenShift file "foo-deploymentconfig.yaml" created @@ -411,12 +411,12 @@ INFO OpenShift file "foo-imagestream.yaml" created INFO OpenShift file "foo-buildconfig.yaml" created ``` -{{< note >}} - -如果使用 ``oc create -f`` 手动推送 Openshift 工件，则需要确保在构建配置工件之前推送 imagestream 工件，以解决 Openshift 的这个问题：https://github.com/openshift/origin/issues/4518 。 +{{< note >}} +如果使用 ``oc create -f`` 手动推送 Openshift 工件，则需要确保在构建配置工件之前推送 +imagestream 工件，以解决 Openshift 的这个问题：https://github.com/openshift/origin/issues/4518 。 {{< /note >}} ## `kompose up` @@ -424,13 +424,15 @@ If you are manually pushing the Openshift artifacts using ``oc create -f``, you - -Kompose 支持通过 `kompose up` 直接将您的"复合的（composed）" 应用程序部署到 Kubernetes 或 OpenShift。 +Kompose 支持通过 `kompose up` 直接将你的"复合的（composed）" 应用程序部署到 Kubernetes 或 OpenShift。 ### Kubernetes -```sh -$ kompose --file ./examples/docker-guestbook.yml up +```shell +kompose --file ./examples/docker-guestbook.yml up +``` + +``` We are going to create Kubernetes deployments and services for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. @@ -442,8 +444,13 @@ INFO Successfully created deployment: redis-slave INFO Successfully created deployment: frontend Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details. +``` -$ kubectl get deployment,svc,pods +```shell +kubectl get deployment,svc,pods +``` + +``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.extensions/frontend 1 1 1 1 4m deployment.extensions/redis-master 1 1 1 1 4m @@ -469,13 +476,18 @@ pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m **注意**： -- 您必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。 -- 此操作仅生成 Deployment 和 Service 对象并将其部署到 Kubernetes。如果需要部署其他不同类型的资源，请使用 `kompose convert` 和 `kubectl create -f` 命令。 +- 你必须有一个运行正常的 Kubernetes 集群，该集群具有预先配置的 kubectl 上下文。 +- 此操作仅生成 Deployment 和 Service 对象并将其部署到 Kubernetes。 + 如果需要部署其他不同类型的资源，请使用 `kompose convert` 和 `kubectl create -f` 命令。 ### OpenShift -```sh -$ kompose --file ./examples/docker-guestbook.yml --provider openshift up + +```shell +kompose --file ./examples/docker-guestbook.yml --provider openshift up +``` + +``` We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead. @@ -490,8 +502,13 @@ INFO Successfully created deployment: redis-master INFO Successfully created ImageStream: redis-master Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' for details. +``` -$ oc get dc,svc,is +```shell +oc get dc,svc,is +``` + +``` NAME REVISION DESIRED CURRENT TRIGGERED BY dc/frontend 0 1 0 config,image(frontend:v4) dc/redis-master 0 1 0 config,image(redis-master:e2e) @@ -510,10 +527,9 @@ is/redis-slave 172.30.12.200:5000/fff/redis-slave v1 **Note**: - You must have a running OpenShift cluster with a pre-configured `oc` context (`oc login`) --> - **注意**： -- 您必须有一个运行正常的 OpenShift 集群，该集群具有预先配置的 `oc` 上下文 (`oc login`)。 +- 你必须有一个运行正常的 OpenShift 集群，该集群具有预先配置的 `oc` 上下文 (`oc login`)。 ## `kompose down` @@ -521,10 +537,15 @@ is/redis-slave 172.30.12.200:5000/fff/redis-slave v1 Once you have deployed "composed" application to Kubernetes, `$ kompose down` will help you to take the application out by deleting its deployments and services. If you need to remove other resources, use the 'kubectl' command. --> -您一旦将"复合(composed)" 应用部署到 Kubernetes，`$ kompose down` 命令将能帮您通过删除 Deployment 和 Service 对象来删除应用。如果需要删除其他资源，请使用 'kubectl' 命令。 +你一旦将"复合(composed)" 应用部署到 Kubernetes，`kompose down` +命令将能帮你通过删除 Deployment 和 Service 对象来删除应用。 +如果需要删除其他资源，请使用 'kubectl' 命令。 -```sh -$ kompose --file docker-guestbook.yml down +```shell +kompose --file docker-guestbook.yml down +``` + +``` INFO Successfully deleted service: redis-master INFO Successfully deleted deployment: redis-master INFO Successfully deleted service: redis-slave @@ -535,8 +556,11 @@ INFO Successfully deleted deployment: frontend - 使用带有 `build` 键的 `kompose up` 命令： -```none -$ kompose up +```shell +kompose up +``` + +``` INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar' INFO Building image 'docker.io/foo/bar' from directory 'build' INFO Image 'docker.io/foo/bar' from directory 'build' built successfully @@ -591,30 +617,36 @@ Your application has been deployed to Kubernetes. You can run 'kubectl get deplo +要想禁用该功能，或者使用 BuildConfig 中的版本（在 OpenShift 中）， +可以通过传递 `--build (local|build-config|none)` 参数来实现。 -要想禁用该功能，或者使用 BuildConfig 中的版本（在 OpenShift 中），可以通过传递 `--build (local|build-config|none)` 参数来实现。 - -```sh +```shell # Disable building/pushing Docker images -$ kompose up --build none +kompose up --build none # Generate Build Config artifacts for OpenShift -$ kompose up --provider openshift --build build-config +kompose up --provider openshift --build build-config ``` - ## 其他转换方式 -默认的 `kompose` 转换会生成 yaml 格式的 Kubernetes [Deployment](/docs/concepts/workloads/controllers/deployment/) 和 [Service](/docs/concepts/services-networking/service/) 对象。 -您可以选择通过 `-j` 参数生成 json 格式的对象。 -您也可以替换生成 [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/) 对象、[Daemon Sets](/docs/concepts/workloads/controllers/daemonset/) 或 [Helm](https://github.com/helm/helm) charts。 +默认的 `kompose` 转换会生成 yaml 格式的 Kubernetes +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和 +[Service](/zh/docs/concepts/services-networking/service/) 对象。 +你可以选择通过 `-j` 参数生成 json 格式的对象。 +你也可以替换生成 [Replication Controllers](/zh/docs/concepts/workloads/controllers/replicationcontroller/) 对象、 +[Daemon Sets](/zh/docs/concepts/workloads/controllers/daemonset/) 或 +[Helm](https://github.com/helm/helm) charts。 -```sh -$ kompose convert -j +```shell +kompose convert -j +``` +``` INFO Kubernetes file "redis-svc.json" created INFO Kubernetes file "web-svc.json" created INFO Kubernetes file "redis-deployment.json" created @@ -624,11 +656,12 @@ INFO Kubernetes file "web-deployment.json" created - `*-deployment.json` 文件中包含 Deployment 对象。 -```sh -$ kompose convert --replication-controller +```shell +kompose convert --replication-controller +``` +``` INFO Kubernetes file "redis-svc.yaml" created INFO Kubernetes file "web-svc.yaml" created INFO Kubernetes file "redis-replicationcontroller.yaml" created @@ -639,10 +672,15 @@ INFO Kubernetes file "web-replicationcontroller.yaml" created The `*-replicationcontroller.yaml` files contain the Replication Controller objects. If you want to specify replicas (default is 1), use `--replicas` flag: `$ kompose convert --replication-controller --replicas 3` --> -`*-replicationcontroller.yaml` 文件包含 Replication Controller 对象。如果您想指定副本数（默认为 1），可以使用 `--replicas` 参数：`$ kompose convert --replication-controller --replicas 3` +`*-replicationcontroller.yaml` 文件包含 Replication Controller 对象。 +如果你想指定副本数（默认为 1），可以使用 `--replicas` 参数： +`kompose convert --replication-controller --replicas 3` -```sh -$ kompose convert --daemon-set +```shell +kompose convert --daemon-set +``` + +``` INFO Kubernetes file "redis-svc.yaml" created INFO Kubernetes file "web-svc.yaml" created INFO Kubernetes file "redis-daemonset.yaml" created @@ -653,20 +691,26 @@ INFO Kubernetes file "web-daemonset.yaml" created The `*-daemonset.yaml` files contain the Daemon Set objects If you want to generate a Chart to be used with [Helm](https://github.com/kubernetes/helm) simply do: --> - `*-daemonset.yaml` 文件包含 Daemon Set 对象。 -如果您想生成 [Helm](https://github.com/kubernetes/helm) 可用的 Chart，只需简单的执行下面的命令： +如果你想生成 [Helm](https://github.com/kubernetes/helm) 可用的 Chart，只需简单的执行下面的命令： -```sh -$ kompose convert -c +```shell +kompose convert -c +``` +``` INFO Kubernetes file "web-svc.yaml" created INFO Kubernetes file "redis-svc.yaml" created INFO Kubernetes file "web-deployment.yaml" created INFO Kubernetes file "redis-deployment.yaml" created chart created in "./docker-compose/" +``` -$ tree docker-compose/ +```shell +tree docker-compose/ +``` + +``` docker-compose ├── Chart.yaml ├── README.md @@ -679,35 +723,36 @@ docker-compose +这个 Chart 结构旨在为构建 Helm Chart 提供框架。 + + - -这个图标结构旨在为构建 Helm Chart 提供框架。 - ## 标签 `kompose` 支持 `docker-compose.yml` 文件中用于 Kompose 的标签，以便在转换时明确定义 Service 的行为。 -- `kompose.service.type` 定义要创建的 Service 类型。 +- `kompose.service.type` 定义要创建的 Service 类型。例如： - - -```yaml -version: "2" -services: - nginx: - image: nginx - dockerfile: foobar - build: ./foobar - cap_add: - - ALL - container_name: foobar - labels: - kompose.service.type: nodeport -``` + ```yaml + version: "2" + services: + nginx: + image: nginx + dockerfile: foobar + build: ./foobar + cap_add: + - ALL + container_name: foobar + labels: + kompose.service.type: nodeport + ``` +- `kompose.service.expose` 定义是否允许从集群外部访问 Service。 + 如果该值被设置为 "true"，提供程序将自动设置端点，对于任何其他值，该值将被设置为主机名。 + 如果在 Service 中定义了多个端口，则选择第一个端口作为公开端口。 -- `kompose.service.expose` 定义 是否允许从集群外部访问 Service。如果该值被设置为 "true"，提供程序将自动设置端点，对于任何其他值，该值将被设置为主机名。如果在 Service 中定义了多个端口，则选择第一个端口作为公开端口。 - 对于 Kubernetes 驱动程序，创建了一个 Ingress 资源，并且假定已经配置了相应的 Ingress 控制器。 - 对于 OpenShift 驱动程序, 创建一个 route。 -例如： + 例如： -```yaml -version: "2" -services: - web: - image: tuna/docker-counter23 - ports: - - "5000:5000" - links: - - redis - labels: - kompose.service.expose: "counter.example.com" - redis: - image: redis:3.0 - ports: - - "6379" -``` + ```yaml + version: "2" + services: + web: + image: tuna/docker-counter23 + ports: + - "5000:5000" + links: + - redis + labels: + kompose.service.expose: "counter.example.com" + redis: + image: redis:3.0 + ports: + - "6379" + ``` +{{< note >}} `kompose.service.type` 标签应该只用`ports`来定义，否则 `kompose` 会失败。 {{< /note >}} - ## 重启 -如果你想创建没有控制器的普通 Pod，可以使用 docker-compose 的 `restart` 结构来定义它。请参考下表了解 `restart` 的不同参数。 +如果你想创建没有控制器的普通 Pod，可以使用 docker-compose 的 `restart` 结构来定义它。 +请参考下表了解 `restart` 的不同参数。 +{{< note >}} 控制器对象可以是 `deployment` 或 `replicationcontroller` 等。 {{< /note >}} - 例如，`pival` Service 将在这里变成 Pod。这个容器的计算值为 `pi`。 ```yaml @@ -814,32 +859,36 @@ services: ### 关于 Deployment Config 的提醒 -如果 Docker Compose 文件中为服务声明了卷，Deployment (Kubernetes) 或 DeploymentConfig (OpenShift) 的策略会从 "RollingUpdate" (默认) 变为 "Recreate"。 +如果 Docker Compose 文件中为服务声明了卷，Deployment (Kubernetes) 或 DeploymentConfig (OpenShift) +的策略会从 "RollingUpdate" (默认) 变为 "Recreate"。 这样做的目的是为了避免服务的多个实例同时访问卷。 - -如果 Docker Compose 文件中的服务名包含 `_` (例如 `web_service`)，那么将会被替换为 `-`，服务也相应的会重命名(例如 `web-service`)。 +如果 Docker Compose 文件中的服务名包含 `_` (例如 `web_service`)， +那么将会被替换为 `-`，服务也相应的会重命名(例如 `web-service`)。 Kompose 这样做的原因是 "Kubernetes" 不允许对象名称中包含 `_`。 - ## Docker Compose 版本 Kompose 支持的 Docker Compose 版本包括：1、2 和 3。有限支持 2.1 和 3.2 版本，因为它们还在实验阶段。 -所有三个版本的兼容性列表请查看我们的 [转换文档](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md)，文档中列出了所有不兼容的 Docker Compose 关键字。 +所有三个版本的兼容性列表请查看我们的 +[转换文档](https://github.com/kubernetes/kompose/blob/master/docs/conversion.md)， +文档中列出了所有不兼容的 Docker Compose 关键字。 diff --git a/content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md similarity index 51% rename from content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md rename to content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index 7f2b41da33..8c4a150ffd 100644 --- a/content/zh/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -1,64 +1,65 @@ --- title: 配置多个调度器 content_type: task +weight: 20 --- -Kubernetes 自带了一个默认调度器，其详细描述请查阅[这里](/docs/reference/command-line-tools-reference/kube-scheduler/)。 - -如果默认调度器不适合您的需求，您可以实现自己的调度器。 - -不仅如此，您甚至可以伴随着默认调度器同时运行多个调度器，并告诉 Kubernetes 为每个 pod 使用什么调度器。 +Kubernetes 自带了一个默认调度器，其详细描述请查阅 +[这里](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)。 +如果默认调度器不适合你的需求，你可以实现自己的调度器。 +不仅如此，你甚至可以和默认调度器一起同时运行多个调度器，并告诉 Kubernetes 为每个 +Pod 使用哪个调度器。 让我们通过一个例子讲述如何在 Kubernetes 中运行多个调度器。 关于实现调度器的具体细节描述超出了本文范围。 -请参考 kube-scheduler 的实现，规范示例代码位于 [pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)。 - - - +请参考 kube-scheduler 的实现，规范示例代码位于 +[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - ## 打包调度器 - -将调度器二进制文件打包到容器镜像中。出于示例目的，我们就使用默认调度器（kube-scheduler）作为我们的第二个调度器。 - -从 Github 克隆 [Kubernetes 源代码](https://github.com/kubernetes/kubernetes)，并编译构建源代码。 +将调度器可执行文件打包到容器镜像中。出于示例目的，我们就使用默认调度器 +（kube-scheduler）作为我们的第二个调度器。 +克隆 [Github 上 Kubernetes 源代码](https://github.com/kubernetes/kubernetes)， +并编译构建源代码。 ```shell git clone https://github.com/kubernetes/kubernetes.git @@ -77,13 +78,14 @@ ADD ./_output/dockerized/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-sche ``` 将文件保存为 `Dockerfile`，构建镜像并将其推送到镜像仓库。 此示例将镜像推送到 [Google 容器镜像仓库（GCR）](https://cloud.google.com/container-registry/)。 - 有关详细信息，请阅读 GCR [文档](https://cloud.google.com/container-registry/docs/)。 ```shell @@ -93,29 +95,43 @@ gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0 ## 为调度器定义 Kubernetes Deployment - -现在我们将调度器放在容器镜像中，我们可以为它创建一个 pod 配置，并在我们的 Kubernetes 集群中运行它。 -但是与其在集群中直接创建一个 pod，不如使用 [Deployment](/docs/concepts/workloads/controllers/deployment/)。 -[Deployment](/docs/concepts/workloads/controllers/deployment/) 管理一个 [Replica Set](/docs/concepts/workloads/controllers/replicaset/)，Replica Set 再管理 pod，从而使调度器能够适应故障。 -以下是 Deployment 配置，被保存为 `my-scheduler.yaml`： +现在我们将调度器放在容器镜像中，我们可以为它创建一个 Pod 配置，并在我们的 Kubernetes 集群中 +运行它。但是与其在集群中直接创建一个 Pod，不如使用 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 +Deployment 管理一个 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)， +ReplicaSet 再管理 Pod，从而使调度器能够免受一些故障的影响。 +以下是 Deployment 配置，将其保存为 `my-scheduler.yaml`： {{< codenew file="admin/sched/my-scheduler.yaml" >}} -这里需要注意的是，在该部署文件中 Container 的 spec 配置的调度器启动命令参数（--scheduler-name）指定的调度器名称应该是惟一的。 -这个名称应该与 pods 上的可选参数 `spec.schedulerName` 的值相匹配，也就是说调度器名称的匹配关系决定了 pods 的调度任务由哪个调度器负责。 +这里需要注意的是，在容器规约中配置的调度器启动命令参数（--scheduler-name）所指定的 +调度器名称应该是唯一的。 +这个名称应该与 Pod 上的可选参数 `spec.schedulerName` 的值相匹配，也就是说调度器名称的匹配 +关系决定了 Pods 的调度任务由哪个调度器负责。 -还要注意，我们创建了一个专用服务帐户 `my-scheduler` 并将集群角色 `system:kube-scheduler` 绑定到它，以便它可以获得与 `kube-scheduler` 相同的权限。 +还要注意，我们创建了一个专用服务账号 `my-scheduler` 并将集群角色 `system:kube-scheduler` +绑定到它，以便它可以获得与 `kube-scheduler` 相同的权限。 ## 在集群中运行第二个调度器 - 为了在 Kubernetes 集群中运行我们的第二个调度器，只需在 Kubernetes 集群中创建上面配置中指定的 Deployment： ```shell @@ -139,10 +154,15 @@ kubectl create -f my-scheduler.yaml -验证调度器 pod 正在运行： +验证调度器 Pod 正在运行： ```shell -$ kubectl get pods --namespace=kube-system +kubectl get pods --namespace=kube-system +``` + +输出类似于： + +``` NAME READY STATUS RESTARTS AGE .... my-scheduler-lnf4s-4744f 1/1 Running 0 2m @@ -152,16 +172,21 @@ my-scheduler-lnf4s-4744f 1/1 Running 0 2m -此列表中，除了默认的 kube-scheduler pod 之外，您应该还能看到处于 “Running” 状态的 my-scheduler pod。 +此列表中，除了默认的 `kube-scheduler` Pod 之外，你应该还能看到处于 “Running” 状态的 +`my-scheduler` Pod。 + -要在启用了 leader 选举的情况下运行多调度器，您必须执行以下操作： - +### 启用领导者选举 + +要在启用了 leader 选举的情况下运行多调度器，你必须执行以下操作： + 首先，更新上述 Deployment YAML（my-scheduler.yaml）文件中的以下字段： * `--leader-elect=true` @@ -171,110 +196,98 @@ First, update the following fields in your YAML file: -如果在集群上启用了 RBAC，则必须更新 `system：kube-scheduler` 集群角色。将调度器名称添加到应用于端点资源的规则的 resourceNames，如以下示例所示： -``` -$ kubectl edit clusterrole system:kube-scheduler -- apiVersion: rbac.authorization.k8s.io/v1 - kind: ClusterRole - metadata: - annotations: - rbac.authorization.kubernetes.io/autoupdate: "true" - labels: - kubernetes.io/bootstrapping: rbac-defaults - name: system:kube-scheduler - rules: - - apiGroups: - - "" - resourceNames: - - kube-scheduler - - my-scheduler - resources: - - endpoints - verbs: - - delete - - get - - patch - - update +如果在集群上启用了 RBAC，则必须更新 `system：kube-scheduler` 集群角色。 +将调度器名称添加到应用于端点资源的规则的 resourceNames，如以下示例所示： + +```shell +kubectl edit clusterrole system:kube-scheduler ``` +{{< codenew file="admin/sched/clusterrole.yaml" >}} + -## 指定 pod 的调度器 +## 为 Pod 指定调度器 -现在我们的第二个调度器正在运行，让我们创建一些 pod，并指定它们由默认调度器或我们刚部署的调度器进行调度。 -为了使用特定的调度器调度给定的 pod，我们在那个 pod 的 spec 中指定调度器的名称。让我们看看三个例子。 - +现在我们的第二个调度器正在运行，让我们创建一些 Pod，并指定它们由默认调度器或我们刚部署的 +调度器进行调度。 +为了使用特定的调度器调度给定的 Pod，我们在那个 Pod 的规约中指定调度器的名称。让我们看看三个例子。 - - Pod spec 没有任何调度器名称 +- Pod spec 没有任何调度器名称 {{< codenew file="admin/sched/pod1.yaml" >}} - -如果未提供调度器名称，则会使用 default-scheduler 自动调度 pod。 + --> + 如果未提供调度器名称，则会使用 default-scheduler 自动调度 pod。 - -将此文件另存为 `pod1.yaml`，并将其提交给 Kubernetes 集群。 + --> + 将此文件另存为 `pod1.yaml`，并将其提交给 Kubernetes 集群。 -```shell -kubectl create -f pod1.yaml -``` + ```shell + kubectl create -f pod1.yaml + ``` - - Pod spec 设置为 `default-scheduler` +- Pod spec 设置为 `default-scheduler` {{< codenew file="admin/sched/pod2.yaml" >}} - -通过将调度器名称作为 `spec.schedulerName` 参数的值来指定调度器。在这种情况下，我们提供默认调度器的名称，即 `default-scheduler`。 + --> + 通过将调度器名称作为 `spec.schedulerName` 参数的值来指定调度器。 + 在这种情况下，我们提供默认调度器的名称，即 `default-scheduler`。 - -将此文件另存为 `pod2.yaml`，并将其提交给 Kubernetes 集群。 + --> + 将此文件另存为 `pod2.yaml`，并将其提交给 Kubernetes 集群。 -```shell -kubectl create -f pod2.yaml -``` + ```shell + kubectl create -f pod2.yaml + ``` - - Pod spec 设置为 `my-scheduler` +- Pod spec 设置为 `my-scheduler` {{< codenew file="admin/sched/pod3.yaml" >}} - -在这种情况下，我们指定此 pod 使用我们部署的 `my-scheduler` 来调度。 -请注意，`spec.schedulerName` 参数的值应该与 Deployment 中配置的提供给 scheduler 命令的参数名称匹配。 + + 在这种情况下，我们指定此 pod 使用我们部署的 `my-scheduler` 来调度。 + 请注意，`spec.schedulerName` 参数的值应该与 Deployment 中配置的提供给 + scheduler 命令的参数名称匹配。 - -将此文件另存为 `pod3.yaml`，并将其提交给 Kubernetes 集群。 + --> + 将此文件另存为 `pod3.yaml`，并将其提交给 Kubernetes 集群。 -```shell -kubectl create -f pod3.yaml -``` + ```shell + kubectl create -f pod3.yaml + ``` 确认所有三个 pod 都在运行。 @@ -282,8 +295,6 @@ kubectl create -f pod3.yaml kubectl get pods ``` - - -为了更容易地完成这些示例，我们没有验证 pod 实际上是使用所需的调度程序调度的。 -我们可以通过更改 pod 的顺序和上面的部署配置提交来验证这一点。 -如果我们在提交调度器部署配置之前将所有 pod 配置提交给 Kubernetes 集群，我们将看到注解了 `annotation-second-scheduler` 的 pod 始终处于 “Pending” 状态，而其他两个 pod 被调度。 -一旦我们提交调度器部署配置并且我们的新调度器开始运行，注解了 `annotation-second-scheduler` 的 pod 就能被调度。 - +为了更容易地完成这些示例，我们没有验证 Pod 实际上是使用所需的调度程序调度的。 +我们可以通过更改 Pod 的顺序和上面的部署配置提交来验证这一点。 +如果我们在提交调度器部署配置之前将所有 Pod 配置提交给 Kubernetes 集群， +我们将看到注解了 `annotation-second-scheduler` 的 Pod 始终处于 “Pending” 状态， +而其他两个 Pod 被调度。 +一旦我们提交调度器部署配置并且我们的新调度器开始运行，注解了 +`annotation-second-scheduler` 的 pod 就能被调度。 -或者，可以查看事件日志中的 “Scheduled” 条目，以验证是否由所需的调度器调度了 pod。 +或者，可以查看事件日志中的 “Scheduled” 条目，以验证是否由所需的调度器调度了 Pod。 ```shell kubectl get events ``` - diff --git a/content/zh/examples/admin/sched/clusterrole.yaml b/content/zh/examples/admin/sched/clusterrole.yaml new file mode 100644 index 0000000000..554b8659db --- /dev/null +++ b/content/zh/examples/admin/sched/clusterrole.yaml @@ -0,0 +1,37 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: system:kube-scheduler +rules: + - apiGroups: + - coordination.k8s.io + resources: + - leases + verbs: + - create + - apiGroups: + - coordination.k8s.io + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - leases + verbs: + - get + - update + - apiGroups: + - "" + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - endpoints + verbs: + - delete + - get + - patch + - update