[zh]Resync tasks files[8]
caodonghui
parent
a63b896950
commit
a7e39ecdb0
|
|
@ -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
|
||||
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)
|
||||
|
|
|
|||
|
|
@ -8,10 +8,10 @@ weight: 110
|
|||
<!--
|
||||
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
|
||||
restart a Container. For example, liveness probes could catch a deadlock,
|
||||
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,
|
||||
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.
|
||||
-->
|
||||
这篇文章介绍如何给容器配置存活、就绪和启动探测器。
|
||||
|
|
@ -22,12 +22,12 @@ despite bugs.
|
|||
这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
|
||||
|
||||
<!--
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
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
|
||||
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
|
||||
|
|
@ -45,7 +45,7 @@ kubelet 使用启动探测器可以知道应用程序容器什么时候启动了
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- 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
|
||||
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:
|
||||
-->
|
||||
## 定义存活命令 {#define-a-liveness-command}
|
||||
|
|
@ -70,16 +70,16 @@ Kubernetes 提供了存活探测器来发现并补救这种情况。
|
|||
{{< 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
|
||||
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
|
||||
kubelet executes the command `cat /tmp/healthy` in the Container. If the
|
||||
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
|
||||
should wait 5 seconds before performing the first probe. To perform a probe, 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
|
||||
healthy. If the command returns a non-zero value, the kubelet kills the container
|
||||
and restarts it.
|
||||
|
||||
When the Container starts, it executes this command:
|
||||
When the container starts, it executes this command:
|
||||
-->
|
||||
在这个配置文件中，可以看到 Pod 中只有一个容器。
|
||||
`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
|
||||
code. After 30 seconds, `cat /tmp/healthy` returns a failure code.
|
||||
|
||||
|
|
@ -195,14 +195,14 @@ image.
|
|||
{{< 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
|
||||
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
|
||||
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
|
||||
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
|
||||
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 也只有一个容器。
|
||||
|
|
@ -217,14 +217,14 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
|
|||
other code indicates failure.
|
||||
|
||||
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.
|
||||
-->
|
||||
任何大于或等于 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 的状态码。
|
||||
|
||||
|
|
@ -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
|
||||
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:
|
||||
-->
|
||||
|
|
@ -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
|
||||
the Container has been restarted:
|
||||
the container has been restarted:
|
||||
-->
|
||||
10 秒之后，通过看 Pod 事件来检测存活探测器已经失败了并且容器被重新启动了。
|
||||
|
||||
|
|
@ -269,7 +269,7 @@ kubectl describe pod liveness-http
|
|||
|
||||
<!--
|
||||
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.
|
||||
In releases after v1.13, local HTTP proxy environment variable settings do not
|
||||
affect the HTTP liveness probe.
|
||||
|
|
@ -281,7 +281,7 @@ affect the HTTP 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.
|
||||
If it can establish a connection, the container is considered healthy, if it
|
||||
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.
|
||||
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
|
||||
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
|
||||
seconds.
|
||||
|
||||
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
|
||||
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
|
||||
will be restarted.
|
||||
|
||||
|
|
@ -317,7 +317,7 @@ To try the TCP liveness check, create a Pod:
|
|||
|
||||
除了就绪探测，这个配置包括了一个存活探测。
|
||||
kubelet 会在容器启动 15 秒后进行第一次存活探测。
|
||||
就像就绪探测一样，会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
与就绪探测类似，会尝试连接 `goproxy` 容器的 8080 端口。
|
||||
如果存活探测失败，这个容器会被重新启动。
|
||||
|
||||
```shell
|
||||
|
|
@ -439,6 +439,14 @@ Readiness probes runs on the container during its whole lifecycle.
|
|||
就绪探测器在容器的整个生命周期中保持运行状态。
|
||||
{{< /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
|
||||
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
|
||||
to 1 second. Minimum value is 1.
|
||||
* `successThreshold`: Minimum consecutive successes for the probe to be
|
||||
considered successful after having failed. Defaults to 1. Must be 1 for
|
||||
liveness and startup Probes. Minimum value is 1.
|
||||
considered successful after having failed. Defaults to 1. Must be 1 for liveness
|
||||
and startup Probes. Minimum value is 1.
|
||||
* `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.
|
||||
Defaults to 3. Minimum value is 1.
|
||||
|
|
@ -511,6 +519,7 @@ Defaults to 3. Minimum value is 1.
|
|||
存活探测情况下的放弃就意味着重新启动容器。
|
||||
就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Before Kubernetes 1.20, the field `timeoutSeconds` was not respected for exec probes:
|
||||
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+`
|
||||
版本中，对于 exec 探针而言，容器中的进程可能会因为超时值的设置保持持续运行，
|
||||
即使探针返回了失败状态。
|
||||
|
||||
{{< /note >}}
|
||||
{{< caution >}}
|
||||
<!--
|
||||
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
|
||||
`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.
|
||||
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
|
||||
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`.
|
||||
|
|
@ -658,6 +667,70 @@ to resolve it.
|
|||
对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，
|
||||
这意味着你不能在 `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" %}}
|
||||
|
||||
<!--
|
||||
|
|
@ -667,13 +740,13 @@ to resolve it.
|
|||
* 进一步了解[容器探针](/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)
|
||||
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-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)
|
||||
* [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
This means that the Pods running on a node are visible on the API server,
|
||||
but cannot be controlled from there.
|
||||
The Pod names will suffixed with the node hostname with a leading hyphen
|
||||
|
||||
{{< note >}}
|
||||
If you are running clustered Kubernetes and are using static
|
||||
|
|
@ -40,6 +41,7 @@ instead.
|
|||
kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建一个
|
||||
{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
|
||||
这意味着节点上运行的静态 Pod 对 API 服务来说是可见的，但是不能通过 API 服务器来控制。
|
||||
Pod 名称将把以连字符开头的节点主机名作为后缀。
|
||||
|
||||
{{< note >}}
|
||||
如果你在运行一个 Kubernetes 集群，并且在每个节点上都运行一个静态 Pod，
|
||||
|
|
@ -48,7 +50,6 @@ kubelet 会尝试通过 Kubernetes API 服务器为每个静态 Pod 自动创建
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< 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}
|
||||
|
||||
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.
|
||||
|
||||
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 定义文件，以 JSON 或者 YAML 格式存储在指定目录。路径设置在
|
||||
[Kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
[Kubelet 配置文件](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
的 `staticPodPath: <目录>` 字段，kubelet 会定期的扫描这个文件夹下的 YAML/JSON
|
||||
文件来创建/删除静态 Pod。
|
||||
注意 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/"
|
||||
```
|
||||
or add the `staticPodPath: <the directory>` field in the [KubeletConfiguration file](/docs/tasks/administer-cluster/kubelet-config-file).
|
||||
```
|
||||
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
|
||||
[kubelet configuration file](/docs/reference/config-api/kubelet-config.v1beta1/).
|
||||
-->
|
||||
3. 配置这个节点上的 kubelet，使用这个参数执行 `--pod-manifest-path=/etc/kubelet.d/`。
|
||||
在 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配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
或者在 [Kubelet 配置文件](/zh/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
中添加 `staticPodPath: <目录>`字段。
|
||||
|
||||
<!--
|
||||
1. Restart the kubelet. On Fedora, you would run:
|
||||
4. Restart the kubelet. On Fedora, you would run:
|
||||
|
||||
```shell
|
||||
# Run this command on the node where the kubelet is running
|
||||
systemctl restart kubelet
|
||||
```
|
||||
```shell
|
||||
# Run this command on the node where the kubelet is running
|
||||
systemctl restart kubelet
|
||||
```
|
||||
-->
|
||||
4. 重启 kubelet。Fedora 上使用下面的命令：
|
||||
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ sudo yum -y install kompose
|
|||
{{% 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。
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ brew install 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.
|
||||
-->
|
||||
再需几步，我们就把你从 Docker Compose 带到 Kubernetes。
|
||||
|
|
|
|||
Loading…
Reference in New Issue