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

Merge pull request #28020 from CaoDonghui123/fix1 

[zh]Resync tasks files[8]
This commit is contained in:
Kubernetes Prow Robot 2021-05-19 06:24:52 -07:00 committed by GitHub
parent 96c83e7ec5 a7e39ecdb0
commit 43de76853a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 131 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md
View File

@ -166,9 +166,9 @@ kubectl top pod cpu-demo --namespace=cpu-example
<!-- <!--
This example output shows that the Pod is using 974 milliCPU, which is This example output shows that the Pod is using 974 milliCPU, which is
just a bit less than the limit of 1 CPU specified in the Pod configuration. slightly less than the limit of 1 CPU specified in the Pod configuration.
--> -->
此示例输出显示 Pod 使用的是 974 milliCPU，即仅略低于 Pod 配置中指定的 1 个 CPU 的限制。 此示例输出显示 Pod 使用的是 974 milliCPU，即略低于 Pod 配置中指定的 1 个 CPU 的限制。
``` ```
NAME CPU(cores) MEMORY(bytes) NAME CPU(cores) MEMORY(bytes)

145
content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -8,10 +8,10 @@ weight: 110
<!-- <!--
This page shows how to configure liveness, readiness and startup probes for Containers. This page shows how to configure liveness, readiness and startup probes for Containers.
The [kubelet](/docs/admin/kubelet/) uses liveness probes to know when to The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses liveness probes to know when to
restart a Container. For example, liveness probes could catch a deadlock, restart a container. For example, liveness probes could catch a deadlock,
where an application is running, but unable to make progress. Restarting a where an application is running, but unable to make progress. Restarting a
Container in such a state can help to make the application more available container in such a state can help to make the application more available
despite bugs. despite bugs.
--> -->
这篇文章介绍如何给容器配置存活、就绪和启动探测器。 这篇文章介绍如何给容器配置存活、就绪和启动探测器。
@ -22,12 +22,12 @@ despite bugs.
这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。 这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
<!-- <!--
The kubelet uses readiness probes to know when a Container is ready to start The kubelet uses readiness probes to know when a container is ready to start
accepting traffic. A Pod is considered ready when all of its Containers are ready. accepting traffic. A Pod is considered ready when all of its containers are ready.
One use of this signal is to control which Pods are used as backends for Services. One use of this signal is to control which Pods are used as backends for Services.
When a Pod is not ready, it is removed from Service load balancers. When a Pod is not ready, it is removed from Service load balancers.
The kubelet uses startup probes to know when a Container application has started. The kubelet uses startup probes to know when a container application has started.
If such a probe is configured, it disables liveness and readiness checks until If such a probe is configured, it disables liveness and readiness checks until
it succeeds, making sure those probes don't interfere with the application startup. it succeeds, making sure those probes don't interfere with the application startup.
This can be used to adopt liveness checks on slow starting containers, avoiding them This can be used to adopt liveness checks on slow starting containers, avoiding them
@ -45,7 +45,7 @@ kubelet 使用启动探测器可以知道应用程序容器什么时候启动了
## {{% heading "prerequisites" %}} ## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< include "task-tutorial-prereqs.md" >}}
<!-- steps --> <!-- steps -->
@ -56,7 +56,7 @@ Many applications running for long periods of time eventually transition to
broken states, and cannot recover except by being restarted. Kubernetes provides broken states, and cannot recover except by being restarted. Kubernetes provides
liveness probes to detect and remedy such situations. liveness probes to detect and remedy such situations.
In this exercise, you create a Pod that runs a Container based on the In this exercise, you create a Pod that runs a container based on the
`k8s.gcr.io/busybox` image. Here is the configuration file for the Pod: `k8s.gcr.io/busybox` image. Here is the configuration file for the Pod:
--> -->
## 定义存活命令 {#define-a-liveness-command} ## 定义存活命令 {#define-a-liveness-command}
@ -70,16 +70,16 @@ Kubernetes 提供了存活探测器来发现并补救这种情况。
{{< codenew file="pods/probe/exec-liveness.yaml" >}} {{< codenew file="pods/probe/exec-liveness.yaml" >}}
<!-- <!--
In the configuration file, you can see that the Pod has a single Container. In the configuration file, you can see that the Pod has a single `Container`.
The `periodSeconds` field specifies that the kubelet should perform a liveness The `periodSeconds` field specifies that the kubelet should perform a liveness
probe every 5 seconds. The `initialDelaySeconds` field tells the kubelet that it probe every 5 seconds. The `initialDelaySeconds` field tells the kubelet that it
should wait 5 second before performing the first probe. To perform a probe, the should wait 5 seconds before performing the first probe. To perform a probe, the
kubelet executes the command `cat /tmp/healthy` in the Container. If the kubelet executes the command `cat /tmp/healthy` in the target container. If the
command succeeds, it returns 0, and the kubelet considers the Container to be alive and command succeeds, it returns 0, and the kubelet considers the container to be alive and
healthy. If the command returns a non-zero value, the kubelet kills the Container healthy. If the command returns a non-zero value, the kubelet kills the container
and restarts it. and restarts it.
When the Container starts, it executes this command: When the container starts, it executes this command:
--> -->
在这个配置文件中，可以看到 Pod 中只有一个容器。 在这个配置文件中，可以看到 Pod 中只有一个容器。
`periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 `periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。
@ -95,7 +95,7 @@ kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。
``` ```
<!-- <!--
For the first 30 seconds of the Container's life, there is a `/tmp/healthy` file. For the first 30 seconds of the container's life, there is a `/tmp/healthy` file.
So during the first 30 seconds, the command `cat /tmp/healthy` returns a success So during the first 30 seconds, the command `cat /tmp/healthy` returns a success
code. After 30 seconds, `cat /tmp/healthy` returns a failure code. code. After 30 seconds, `cat /tmp/healthy` returns a failure code.
@ -195,14 +195,14 @@ image.
{{< codenew file="pods/probe/http-liveness.yaml" >}} {{< codenew file="pods/probe/http-liveness.yaml" >}}
<!-- <!--
In the configuration file, you can see that the Pod has a single Container. In the configuration file, you can see that the Pod has a single container.
The `periodSeconds` field specifies that the kubelet should perform a liveness The `periodSeconds` field specifies that the kubelet should perform a liveness
probe every 3 seconds. The `initialDelaySeconds` field tells the kubelet that it probe every 3 seconds. The `initialDelaySeconds` field tells the kubelet that it
should wait 3 seconds before performing the first probe. To perform a probe, the should wait 3 seconds before performing the first probe. To perform a probe, the
kubelet sends an HTTP GET request to the server that is running in the Container kubelet sends an HTTP GET request to the server that is running in the container
and listening on port 8080. If the handler for the server's `/healthz` path and listening on port 8080. If the handler for the server's `/healthz` path
returns a success code, the kubelet considers the Container to be alive and 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 healthy. If the handler returns a failure code, the kubelet kills the container
and restarts it. and restarts it.
--> -->
在这个配置文件中，可以看到 Pod 也只有一个容器。 在这个配置文件中，可以看到 Pod 也只有一个容器。
@ -217,14 +217,14 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
other code indicates failure. other code indicates failure.
You can see the source code for the server in You can see the source code for the server in
[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go). [server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go).
For the first 10 seconds that the Container is alive, the `/healthz` handler For the first 10 seconds that the container is alive, the `/healthz` handler
returns a status of 200. After that, the handler returns a status of 500. returns a status of 200. After that, the handler returns a status of 500.
--> -->
任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。 任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。
可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。 可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go)。
容器存活的最开始 10 秒中，`/healthz` 处理程序返回一个 200 的状态码。之后处理程序返回 500 的状态码。 容器存活的最开始 10 秒中，`/healthz` 处理程序返回一个 200 的状态码。之后处理程序返回 500 的状态码。
@ -242,9 +242,9 @@ http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
``` ```
<!-- <!--
The kubelet starts performing health checks 3 seconds after the Container starts. The kubelet starts performing health checks 3 seconds after the container starts.
So the first couple of health checks will succeed. But after 10 seconds, the health So the first couple of health checks will succeed. But after 10 seconds, the health
checks will fail, and the kubelet will kill and restart the Container. checks will fail, and the kubelet will kill and restart the container.
To try the HTTP liveness check, create a Pod: To try the HTTP liveness check, create a Pod:
--> -->
@ -259,7 +259,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
<!-- <!--
After 10 seconds, view Pod events to verify that liveness probes have failed and After 10 seconds, view Pod events to verify that liveness probes have failed and
the Container has been restarted: the container has been restarted:
--> -->
10 秒之后，通过看 Pod 事件来检测存活探测器已经失败了并且容器被重新启动了。 10 秒之后，通过看 Pod 事件来检测存活探测器已经失败了并且容器被重新启动了。
@ -269,7 +269,7 @@ kubectl describe pod liveness-http
<!-- <!--
In releases prior to v1.13 (including v1.13), if the environment variable In releases prior to v1.13 (including v1.13), if the environment variable
`http_proxy` (or `HTTP_PROXY`) is set on the node where a pod is running, `http_proxy` (or `HTTP_PROXY`) is set on the node where a Pod is running,
the HTTP liveness probe uses that proxy. the HTTP liveness probe uses that proxy.
In releases after v1.13, local HTTP proxy environment variable settings do not In releases after v1.13, local HTTP proxy environment variable settings do not
affect the HTTP liveness probe. affect the HTTP liveness probe.
@ -281,7 +281,7 @@ affect the HTTP liveness probe.
<!-- <!--
## Define a TCP liveness probe ## Define a TCP liveness probe
A third type of liveness probe uses a TCP Socket. With this configuration, the A third type of liveness probe uses a TCP socket. With this configuration, the
kubelet will attempt to open a socket to your container on the specified port. kubelet will attempt to open a socket to your container on the specified port.
If it can establish a connection, the container is considered healthy, if it If it can establish a connection, the container is considered healthy, if it
can't it is considered a failure. can't it is considered a failure.
@ -298,13 +298,13 @@ can't it is considered a failure.
As you can see, configuration for a TCP check is quite similar to an HTTP check. As you can see, configuration for a TCP check is quite similar to an HTTP check.
This example uses both readiness and liveness probes. The kubelet will send the This example uses both readiness and liveness probes. The kubelet will send the
first readiness probe 5 seconds after the container starts. This will attempt to first readiness probe 5 seconds after the container starts. This will attempt to
connect to the `goproxy` container on port 8080. If the probe succeeds, the pod connect to the `goproxy` container on port 8080. If the probe succeeds, the Pod
will be marked as ready. The kubelet will continue to run this check every 10 will be marked as ready. The kubelet will continue to run this check every 10
seconds. seconds.
In addition to the readiness probe, this configuration includes a liveness probe. In addition to the readiness probe, this configuration includes a liveness probe.
The kubelet will run the first liveness probe 15 seconds after the container The kubelet will run the first liveness probe 15 seconds after the container
starts. Just like the readiness probe, this will attempt to connect to the starts. Similar to the readiness probe, this will attempt to connect to the
`goproxy` container on port 8080. If the liveness probe fails, the container `goproxy` container on port 8080. If the liveness probe fails, the container
will be restarted. will be restarted.
@ -317,7 +317,7 @@ To try the TCP liveness check, create a Pod:
除了就绪探测，这个配置包括了一个存活探测。 除了就绪探测，这个配置包括了一个存活探测。
kubelet 会在容器启动 15 秒后进行第一次存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。
就像就绪探测一样，会尝试连接 `goproxy` 容器的 8080 端口。 与就绪探测类似，会尝试连接 `goproxy` 容器的 8080 端口。
如果存活探测失败，这个容器会被重新启动。 如果存活探测失败，这个容器会被重新启动。
```shell ```shell
@ -439,6 +439,14 @@ Readiness probes runs on the container during its whole lifecycle.
就绪探测器在容器的整个生命周期中保持运行状态。 就绪探测器在容器的整个生命周期中保持运行状态。
{{< /note >}} {{< /note >}}
<!--
Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.
-->
{{< caution >}}
活跃性探测器 *不等待* 就绪性探测器成功。
如果要在执行活跃性探测器之前等待，应该使用 initialDelaySeconds 或 startupProbe。
{{< /caution >}}
<!-- <!--
Readiness probes are configured similarly to liveness probes. The only difference Readiness probes are configured similarly to liveness probes. The only difference
is that you use the `readinessProbe` field instead of the `livenessProbe` field. is that you use the `readinessProbe` field instead of the `livenessProbe` field.
@ -496,8 +504,8 @@ seconds. Minimum value is 1.
* `timeoutSeconds`: Number of seconds after which the probe times out. Defaults * `timeoutSeconds`: Number of seconds after which the probe times out. Defaults
to 1 second. Minimum value is 1. to 1 second. Minimum value is 1.
* `successThreshold`: Minimum consecutive successes for the probe to be * `successThreshold`: Minimum consecutive successes for the probe to be
considered successful after having failed. Defaults to 1. Must be 1 for considered successful after having failed. Defaults to 1. Must be 1 for liveness
liveness and startup Probes. Minimum value is 1. and startup Probes. Minimum value is 1.
* `failureThreshold`: When a probe fails, Kubernetes will * `failureThreshold`: When a probe fails, Kubernetes will
try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready. try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
Defaults to 3. Minimum value is 1. Defaults to 3. Minimum value is 1.
@ -511,6 +519,7 @@ Defaults to 3. Minimum value is 1.
存活探测情况下的放弃就意味着重新启动容器。 存活探测情况下的放弃就意味着重新启动容器。
就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
{{< note >}}
<!-- <!--
Before Kubernetes 1.20, the field `timeoutSeconds` was not respected for exec probes: Before Kubernetes 1.20, the field `timeoutSeconds` was not respected for exec probes:
probes continued running indefinitely, even past their configured deadline, probes continued running indefinitely, even past their configured deadline,
@ -545,7 +554,7 @@ the process inside the container may keep running even after probe returned fail
当此缺陷被修复之后，在使用 `dockershim` 容器运行时的 Kubernetes `1.20+` 当此缺陷被修复之后，在使用 `dockershim` 容器运行时的 Kubernetes `1.20+`
版本中，对于 exec 探针而言，容器中的进程可能会因为超时值的设置保持持续运行， 版本中，对于 exec 探针而言，容器中的进程可能会因为超时值的设置保持持续运行，
即使探针返回了失败状态。 即使探针返回了失败状态。
{{< /note >}}
{{< caution >}} {{< caution >}}
<!-- <!--
Incorrect implementation of readiness probes may result in an ever growing number Incorrect implementation of readiness probes may result in an ever growing number
@ -586,7 +595,7 @@ port to perform the check. The kubelet sends the probe to the pod's IP address,
unless the address is overridden by the optional `host` field in `httpGet`. If unless the address is overridden by the optional `host` field in `httpGet`. If
`scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the `scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the
certificate verification. In most scenarios, you do not want to set the `host` field. certificate verification. In most scenarios, you do not want to set the `host` field.
Here's one scenario where you would set it. Suppose the Container listens on 127.0.0.1 Here's one scenario where you would set it. Suppose the container listens on 127.0.0.1
and the Pod's `hostNetwork` field is true. Then `host`, under `httpGet`, should be set and the Pod's `hostNetwork` field is true. Then `host`, under `httpGet`, should be set
to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common
case, you should not use `host`, but rather set the `Host` header in `httpHeaders`. case, you should not use `host`, but rather set the `Host` header in `httpHeaders`.
@ -658,6 +667,70 @@ to resolve it.
对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接， 对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，
这意味着你不能在 `host` 参数上配置服务名称，因为 kubelet 不能解析服务名称。 这意味着你不能在 `host` 参数上配置服务名称，因为 kubelet 不能解析服务名称。
<!--
### Probe-level `terminationGracePeriodSeconds`
-->
### 探测器级别 `terminationGracePeriodSeconds`
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
<!--
Prior to release 1.21, the pod-level `terminationGracePeriodSeconds` was used
for terminating a container that failed its liveness or startup probe. This
coupling was unintended and may have resulted in failed containers taking an
unusually long time to restart when a pod-level `terminationGracePeriodSeconds`
was set.
-->
在 1.21 版之前，pod 级别的 `terminationGracePeriodSeconds` 被用来终止
未能成功处理活跃性探测或启动探测的容器。
这种耦合是意料之外的，可能会导致在设置了 pod 级别的 `terminationGracePeriodSeconds` 后，
需要很长的时间来重新启动失败的容器。
<!--
In 1.21, when the feature flag `ProbeTerminationGracePeriod` is enabled, users
can specify a probe-level `terminationGracePeriodSeconds` as part of the probe
specification. When the feature flag is enabled, and both a pod- and
probe-level `terminationGracePeriodSeconds` are set, the kubelet will use the
probe-level value.
For example,
-->
在1.21中，启用特性标志 `ProbeTerminationGracePeriod` 后，
用户可以指定一个探测器级别的 `terminationGracePeriodSeconds` 作为探测器规格的一部分。
当该特性标志被启用时，若同时设置了 Pod 级别和探测器级别的 `terminationGracePeriodSeconds`，
kubelet 将使用探测器级的值。
例如，
```yaml
spec:
terminationGracePeriodSeconds: 3600 # pod-level
containers:
- name: test
image: ...
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 60
# Override pod-level terminationGracePeriodSeconds #
terminationGracePeriodSeconds: 60
```
<!--
Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes.
It will be rejected by the API server.
-->
探测器级别的 `terminationGracePeriodSeconds` 不能用于设置就绪态探针。
它将被 API 服务器拒绝。
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
<!-- <!--
@ -667,13 +740,13 @@ to resolve it.
* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 * 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!-- <!--
### Reference You can also read the API references for:
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) * [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) * [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
--> -->
### 参考 {#reference} 你也可以阅读以下的 API 参考资料：
* [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) * [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)

32
content/zh/docs/tasks/configure-pod-container/static-pod.md
View File

@ -27,6 +27,7 @@ The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Po
on the Kubernetes API server for each static Pod. on the Kubernetes API server for each static Pod.
This means that the Pods running on a node are visible on the API server, This means that the Pods running on a node are visible on the API server,
but cannot be controlled from there. but cannot be controlled from there.
The Pod names will suffixed with the node hostname with a leading hyphen
{{< note >}} {{< note >}}
If you are running clustered Kubernetes and are using static If you are running clustered Kubernetes and are using static
@ -40,6 +41,7 @@ instead.
kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个 kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个
{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。 {{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
这意味着节点上运行的静态 Pod 对 API 服务来说是可见的，但是不能通过 API 服务器来控制。 这意味着节点上运行的静态 Pod 对 API 服务来说是可见的，但是不能通过 API 服务器来控制。
Pod 名称将把以连字符开头的节点主机名作为后缀。
{{< note >}} {{< note >}}
如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod， 如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod，
@ -48,7 +50,6 @@ kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建
## {{% heading "prerequisites" %}} ## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- <!--
@ -76,7 +77,9 @@ You can configure a static Pod with either a [file system hosted configuration f
<!-- <!--
### Filesystem-hosted static Pod manifest {#configuration-files} ### Filesystem-hosted static Pod manifest {#configuration-files}
Manifests are standard Pod definitions in JSON or YAML format in a specific directory. Use the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there. Manifests are standard Pod definitions in JSON or YAML format in a specific directory. Use the `staticPodPath: <the directory>` field in the
[kubelet configuration file](/docs/reference/config-api/kubelet-config.v1beta1/),
which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there.
Note that the kubelet will ignore files starting with dots when scanning the specified directory. Note that the kubelet will ignore files starting with dots when scanning the specified directory.
For example, this is how to start a simple web server as a static Pod: For example, this is how to start a simple web server as a static Pod:
@ -84,7 +87,7 @@ For example, this is how to start a simple web server as a static Pod:
### 文件系统上的静态 Pod 声明文件 {#configuration-files} ### 文件系统上的静态 Pod 声明文件 {#configuration-files}
声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在 声明文件是标准的 Pod 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在
[Kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) [Kubelet 配置文件](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON 的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON
文件来创建/删除静态 Pod。 文件来创建/删除静态 Pod。
注意 kubelet 扫描目录的时候会忽略以点开头的文件。 注意 kubelet 扫描目录的时候会忽略以点开头的文件。
@ -148,12 +151,13 @@ For example, this is how to start a simple web server as a static Pod:
``` ```
<!-- <!--
1. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line: 3. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line:
``` ```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
``` ```
or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file). or add the `staticPodPath: <the directory>` field in the
[kubelet configuration file](/docs/reference/config-api/kubelet-config.v1beta1/).
--> -->
3. 配置这个节点上的 kubelet，使用这个参数执行 `--pod-manifest-path=/etc/kubelet.d/`。 3. 配置这个节点上的 kubelet，使用这个参数执行 `--pod-manifest-path=/etc/kubelet.d/`。
在 Fedora 上编辑 `/etc/kubernetes/kubelet` 以包含下行： 在 Fedora 上编辑 `/etc/kubernetes/kubelet` 以包含下行：
@ -161,16 +165,16 @@ For example, this is how to start a simple web server as a static Pod:
``` ```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --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配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 或者在 [Kubelet 配置文件](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
中添加 `staticPodPath: <目录>`字段。 中添加 `staticPodPath: <目录>`字段。
<!-- <!--
1. Restart the kubelet. On Fedora, you would run: 4. Restart the kubelet. On Fedora, you would run:
```shell ```shell
# Run this command on the node where the kubelet is running # Run this command on the node where the kubelet is running
systemctl restart kubelet systemctl restart kubelet
``` ```
--> -->
4. 重启 kubelet。Fedora 上使用下面的命令： 4. 重启 kubelet。Fedora 上使用下面的命令：

4
content/zh/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
View File

@ -106,7 +106,7 @@ sudo yum -y install kompose
{{% tab name="Fedora package" %}} {{% tab name="Fedora package" %}}
<!-- <!--
Kompose is in Fedora 24, 25 and 26 repositories. You can install it just like any other package. Kompose is in Fedora 24, 25 and 26 repositories. You can install it like any other package.
--> -->
Kompose 位于 Fedora 24、25 和 26 的代码仓库。你可以像安装其他软件包一样安装 Kompose。 Kompose 位于 Fedora 24、25 和 26 的代码仓库。你可以像安装其他软件包一样安装 Kompose。
@ -135,7 +135,7 @@ brew install kompose
## 使用 Kompose ## 使用 Kompose
<!-- <!--
In just a few steps, we'll take you from Docker Compose to Kubernetes. All In a few steps, we'll take you from Docker Compose to Kubernetes. All
you need is an existing `docker-compose.yml` file. you need is an existing `docker-compose.yml` file.
--> -->
再需几步，我们就把你从 Docker Compose 带到 Kubernetes。 再需几步，我们就把你从 Docker Compose 带到 Kubernetes。