diff --git a/cn/docs/concepts/configuration/manage-compute-resources-container.md b/cn/docs/concepts/configuration/manage-compute-resources-container.md index b49ae3ed70..6e092706bf 100644 --- a/cn/docs/concepts/configuration/manage-compute-resources-container.md +++ b/cn/docs/concepts/configuration/manage-compute-resources-container.md @@ -8,18 +8,6 @@ cn-reviewers: {% capture overview %} - - 当您定义 [Pod](/docs/user-guide/pods) 的时候可以选择为每个容器指定需要的 CPU 和内存（RAM）大小。当为容器指定了资源请求后，调度器就能够更好的判断出将容器调度到哪个节点上。如果您还为容器指定了资源限制，节点上的资源就可以按照指定的方式做竞争。关于资源请求和限制的不同点和更多资料请参考 [Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md)。 {% endcapture %} @@ -27,47 +15,12 @@ the difference between requests and limits, see {% capture body %} - - ## 资源类型 *CPU* 和 *内存* 都是 *资源类型*。资源类型具有基本单位。CPU 的单位是 core，内存的单位是 byte。 CPU和内存统称为*计算资源*，也可以称为*资源*。计算资源的数量是可以被请求、分配和消耗的可测量的。它们与 [API 资源](/docs/api/) 不同。 API 资源（如 Pod 和 [Service](/docs/user-guide/services)）是可通过 Kubernetes API server 读取和修改的对象。 - - ## Pod 和 容器的资源请求和限制 Pod 中的每个容器都可以指定以下的一个或者多个值： @@ -79,32 +32,6 @@ Pod 中的每个容器都可以指定以下的一个或者多个值： 尽管只能在个别容器上指定请求和限制，但是我们可以方便地计算出 Pod 资源请求和限制。特定资源类型的Pod 资源请求/限制是 Pod 中每个容器的该类型的资源请求/限制的总和。 - - ## CPU 的含义 CPU 资源的限制和请求以 *cpu* 为单位。 @@ -120,17 +47,6 @@ Kubernetes 中的一个 cpu 等于： CPU 总是要用绝对数量，不可以使用相对数量；0.1 的 CPU 在单核、双核、48核的机器中的意义是一样的。 - - ## 内存的含义 内存的限制和请求以字节为单位。您可以使用以下后缀之一作为平均整数或定点整数表示内存：E，P，T，G，M，K。您还可以使用两个字母的等效的幂数：Ei，Pi，Ti ，Gi，Mi，Ki。例如，以下代表大致相同的值： @@ -139,16 +55,6 @@ Mi, Ki. For example, the following represent roughly the same value: 128974848, 129e6, 129M, 123Mi ``` - - 下面是个例子。 以下 Pod 有两个容器。每个容器的请求为 0.25 cpu 和 64MiB（226 字节）内存，每个容器的限制为 0.5 cpu 和 128MiB 内存。您可以说该 Pod 请求 0.5 cpu 和 128 MiB 的内存，限制为 1 cpu 和 256MiB 的内存。 @@ -180,71 +86,10 @@ spec: cpu: "500m" ``` - - ## 具有资源请求的 Pod 如何调度 当您创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pod 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。请注意，尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在该节点上放置 Pod。当资源使用量稍后增加时，例如在请求率的每日峰值期间，这可以防止节点上的资源短缺。 - - ## 具有资源限制的 Pod 如何运行 当 kubelet 启动一个 Pod 的容器时，它会将 CPU 和内存限制传递到容器运行时。 @@ -263,42 +108,18 @@ resource limits, see the 要确定容器是否由于资源限制而无法安排或被杀死，请参阅 [疑难解答](#troubleshooting) 部分。 - - ## 监控计算资源使用 Pod 的资源使用情况被报告为 Pod 状态的一部分。 如果为集群配置了 [可选监控](http://releases.k8s.io/{{page.githubbranch}}/cluster/addons/cluster-monitoring/README.md)，则可以从监控系统检索 Pod 资源的使用情况。 - - ```shell $ kubectl describe pod frontend | grep -A 3 Events Events: @@ -306,24 +127,6 @@ Events: 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others ``` - - 在上述示例中，由于节点上的 CPU 资源不足，名为 “frontend” 的 Pod 将无法调度。由于内存不足（PodExceedsFreeMemory），类似的错误消息也可能会导致失败。一般来说，如果有这种类型的消息而处于 pending 状态，您可以尝试如下几件事情： ```shell @@ -356,26 +159,6 @@ Allocated resources: 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) ``` - - 在上面的输出中，您可以看到如果 Pod 请求超过 1120m CPU 或者 6.23Gi 内存，节点将无法满足。 通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。 @@ -384,16 +167,6 @@ Pod 可用的资源量小于节点容量，因为系统守护程序使用一部 可以将 [资源配额](/docs/concepts/policy/resource-quotas/) 功能配置为限制可以使用的资源总量。如果与 namespace 配合一起使用，就可以防止一个团队占用所有资源。 - - ## 我的容器被终止了 您的容器可能因为资源枯竭而被终止了。要查看容器是否因为遇到资源限制而被杀死，请在相关的 Pod 上调用 `kubectl describe pod`： @@ -436,16 +209,6 @@ Events: Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a ``` - - 在上面的例子中，`Restart Count: 5` 意味着 Pod 中的 `simmemleak` 容器被终止并重启了五次。 您可以使用 `kubectl get pod` 命令加上 `-o go-template=...` 选项来获取之前终止容器的状态。 @@ -456,57 +219,8 @@ Container Name: simmemleak LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]{% endraw %} ``` - - 您可以看到容器因为 `reason:OOM killed` 被终止，`OOM` 表示 Out Of Memory。 - - ## 不透明整型资源（Alpha功能） Kubernetes 1.5 版本中引入不透明整型资源。不透明的整数资源允许集群运维人员发布新的节点级资源，否则系统将不了解这些资源。 @@ -547,27 +261,6 @@ curl --header "Content-Type: application/json-patch+json" \ http://k8s-master:8080/api/v1/nodes/k8s-node-1/status ``` - - **注意：** 在前面的请求中，`~1` 是 patch 路径中 `/` 字符的编码。JSON-Patch 中的操作路径值被解释为 JSON-Pointer。更多详细信息请参阅 [IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3)。 ```yaml @@ -585,32 +278,6 @@ spec: pod.alpha.kubernetes.io/opaque-int-resource-foo: 1 ``` - - ## 计划改进 在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量，如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。 @@ -625,15 +292,6 @@ Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168 {% capture whatsnext %} - - - 获取将 [CPU 和内存资源分配给容器](/docs/tasks/configure-pod-container/assign-cpu-ram-container/) 的实践经验 - [容器](/docs/api-reference/{{page.version}}/#container-v1-core) - [ResourceRequirements](/docs/resources-reference/{{page.version}}/#resourcerequirements-v1-core) diff --git a/cn/docs/concepts/configuration/secret.md b/cn/docs/concepts/configuration/secret.md index fc5a328ec0..5b86b9cbb6 100644 --- a/cn/docs/concepts/configuration/secret.md +++ b/cn/docs/concepts/configuration/secret.md @@ -9,28 +9,10 @@ cn-reviewers: title: Secret --- - - `Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 ssh key。将这些信息放在 `secret` 中比放在 `pod` 的定义或者 docker 镜像中来说更加安全和灵活。参阅 [Secret 设计文档](https://git.k8s.io/community/contributors/design-proposals/secrets.md) 获取更多详细信息。 * TOC {:toc} - - ## Secret 概览 Secret 是一种包含少量敏感信息例如密码、token 或 key 的对象。这样的信息可能会被放在 Pod spec 中或者镜像中；将其放在一个 secret 对象中可以更好地控制它的用途，并降低意外暴露的风险。 @@ -39,20 +21,6 @@ Secret 是一种包含少量敏感信息例如密码、token 或 key 的对象 要使用 secret，pod 需要引用 secret。Pod 可以用两种方式使用 secret：作为 [volume](/docs/concepts/storage/volumes/) 中的文件被挂载到 pod 中的一个或者多个容器里，或者当 kubelet 为 pod 拉取镜像时使用。 - - ### 内置 secret #### Service Account 使用 API 凭证自动创建和附加 secret @@ -63,16 +31,6 @@ Kubernetes 自动创建包含访问 API 凭据的 secret，并自动修改您的 参阅 [Service Account](/docs/user-guide/service-accounts) 文档获取关于 Service Account 如何工作的更多信息。 - - ### 创建您自己的 Secret #### 使用 kubectl 创建 Secret @@ -85,12 +43,6 @@ $ echo -n "admin" > ./username.txt $ echo -n "1f2d1e2e67df" > ./password.txt ``` - - `kubectl create secret` 命令将这些文件打包到一个 Secret 中并在 API server 中创建了一个对象。 ```shell @@ -98,12 +50,6 @@ $ kubectl create secret generic db-user-pass --from-file=./username.txt --from-f secret "db-user-pass" created ``` - - 您可以这样检查刚创建的 secret： ```shell @@ -125,20 +71,6 @@ password.txt: 12 bytes username.txt: 5 bytes ``` - - 请注意，默认情况下，`get` 和 `describe` 命令都不会显示文件的内容。这是为了防止将 secret 中的内容被意外暴露给从终端日志记录中刻意寻找它们的人。 请参阅 [解码 secret](#decoding-a-secret) 了解如何查看它们的内容。 @@ -156,12 +88,6 @@ $ echo -n "1f2d1e2e67df" | base64 MWYyZDFlMmU2N2Rm ``` - - 现在可以像这样写一个 secret 对象： ```yaml @@ -175,14 +101,6 @@ data: password: MWYyZDFlMmU2N2Rm ``` - - 数据字段是一个映射。它的键必须匹配 [`DNS_SUBDOMAIN`](https://git.k8s.io/community/contributors/design-proposals/identifiers.md)，前导点也是可以的。这些值可以是任意数据，使用 base64 进行编码。 使用 [`kubectl create`](/docs/user-guide/kubectl/v1.7/#create) 创建 secret： @@ -192,16 +110,6 @@ $ kubectl create -f ./secret.yaml secret "mysecret" created ``` - - **编码注意：** secret 数据的序列化 JSON 和 YAML 值使用 base64 编码成字符串。换行符在这些字符串中无效，必须省略。当在 Darwin/OS X 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来拆分长行。另外，对于 Linux 用户如果 `-w` 选项不可用的话，应该添加选项 `-w 0` 到 `base64` 命令或管道 `base64 | tr -d '\n' ` 。 #### 解码 Secret @@ -225,12 +133,6 @@ metadata: type: Opaque ``` - - 解码密码字段： ```shell @@ -238,25 +140,6 @@ $ echo "MWYyZDFlMmU2N2Rm" | base64 --decode 1f2d1e2e67df ``` - - ### 使用 Secret Secret 可以作为数据卷被挂载，或作为环境变量暴露出来以供 pod 中的容器使用。它们也可以被系统的其他部分使用，而不直接暴露在 pod 内。例如，它们可以保存凭据，系统的其他部分应该用它来代表您与外部系统进行交互。 @@ -291,20 +174,6 @@ spec: secretName: mysecret ``` - - 您想要用的每个 secret 都需要在 `spec.volumes` 中指明。 如果 pod 中有多个容器，每个容器都需要自己的 `volumeMounts` 配置块，但是每个 secret 只需要一个 `spec.volumes`。 @@ -337,23 +206,6 @@ spec: path: my-group/my-username ``` - - 将会发生什么呢： - `username` secret 存储在 `/etc/foo/my-group/my-username` 文件中而不是 `/etc/foo/username` 中。 @@ -384,16 +236,6 @@ spec: defaultMode: 256 ``` - - 然后，secret 将被挂载到 `/etc/foo` 目录，所有通过该 secret volume 挂载创建的文件的权限都是 `0400`。 请注意，JSON 规范不支持八进制符号，因此使用 256 值作为 0400 权限。如果您使用 yaml 而不是 json 作为 pod，则可以使用八进制符号以更自然的方式指定权限。 @@ -422,18 +264,6 @@ spec: mode: 511 ``` - - 在这种情况下，导致 `/etc/foo/my-group/my-username` 的文件的权限值为 `0777`。由于 JSON 限制，必须以十进制格式指定模式。 请注意，如果稍后阅读此权限值可能会以十进制格式显示。 @@ -452,27 +282,6 @@ $ cat /etc/foo/password 1f2d1e2e67df ``` - - 容器中的程序负责从文件中读取 secret。 **挂载的 secret 被自动更新** @@ -512,14 +321,6 @@ spec: restartPolicy: Never ``` - - **消费环境变量里的 Secret 值** 在一个消耗环境变量 secret 的容器中，secret key 作为包含 secret 数据的 base-64 解码值的常规环境变量。这是从上面的示例在容器内执行的命令的结果： @@ -531,18 +332,6 @@ $ echo $SECRET_PASSWORD 1f2d1e2e67df ``` - - #### 使用 imagePullSecret imagePullSecret 是将包含 Docker（或其他）镜像注册表密码的 secret 传递给 Kubelet 的一种方式，因此可以代表您的 pod 拉取私有镜像。 @@ -551,18 +340,6 @@ imagePullSecret 是将包含 Docker（或其他）镜像注册表密码的 secre imagePullSecret 的使用在 [镜像文档](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 中说明。 - - ### 安排 imagePullSecrets 自动附加 您可以手动创建 imagePullSecret，并从 serviceAccount 引用它。使用该 serviceAccount 创建的任何 pod 和默认使用该 serviceAccount 的 pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 字段。有关该过程的详细说明，请参阅 [将 ImagePullSecrets 添加到服务帐户](/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)。 @@ -571,17 +348,6 @@ Manually created secrets (e.g. one containing a token for accessing a github acc 手动创建的 secret（例如包含用于访问 github 帐户的令牌）可以根据其服务帐户自动附加到 pod。请参阅 [使用 PodPreset 向 Pod 中注入信息](/docs/tasks/run-application/podpreset/) 以获取该进程的详细说明。 - - ## 详细 ### 限制 @@ -590,20 +356,6 @@ Secret API objects reside in a namespace. They can only be referenced by pods Secret API 对象驻留在命名空间中。它们只能由同一命名空间中的 pod 引用。 - - 每个 secret 的大小限制为1MB。这是为了防止创建非常大的 secret 会耗尽 apiserver 和 kubelet 的内存。然而，创建许多较小的 secret 也可能耗尽内存。更全面得限制 secret 对内存使用的功能还在计划中。 Kubelet 仅支持从 API server 获取的 Pod 使用 secret。这包括使用 kubectl 创建的任何 pod，或间接通过 replication controller 创建的 pod。它不包括通过 kubelet `--manifest-url` 标志，其 `--config` 标志或其 REST API 创建的pod（这些不是创建 pod 的常用方法）。 @@ -620,20 +372,6 @@ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. ``` - - ### Secret 与 Pod 生命周期的联系 通过 API 创建 Pod 时，不会检查应用的 secret 是否存在。一旦 Pod 被调度，kubelet 就会尝试获取该 secret 的值。如果获取不到该 secret，或者暂时无法与 API server 建立连接，kubelet 将会定期重试。Kubelet 将会报告关于 pod 的事件，并解释它无法启动的原因。一旦获取到 secret，kubelet将创建并装载一个包含它的卷。在所有 pod 的卷被挂载之前，都不会启动 pod 的容器。 @@ -648,14 +386,6 @@ Create a secret containing some ssh keys: $ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub ``` - - **安全性注意事项**：发送自己的 ssh 密钥之前要仔细思考：集群的其他用户可能有权访问该密钥。使用您想要共享 Kubernetes 群集的所有用户可以访问的服务帐户，如果它们遭到入侵，可以撤销。 现在我们可以创建一个使用 ssh 密钥引用 secret 的pod，并在一个卷中使用它： @@ -681,12 +411,6 @@ spec: mountPath: "/etc/secret-volume" ``` - - 当容器中的命令运行时，密钥的片段将可在以下目录： ```shell @@ -694,24 +418,8 @@ When the container's command runs, the pieces of the key will be available in: /etc/secret-volume/ssh-privatekey ``` - - 然后容器可以自由使用密钥数据建立一个 ssh 连接。 - - ### 使用案例：包含 prod/test 凭据的 pod 下面的例子说明一个 pod 消费一个包含 prod 凭据的 secret，另一个 pod 使用测试环境凭据消费 secret。 @@ -725,12 +433,6 @@ $ kubectl create secret generic test-db-secret --from-literal=username=testuser secret "test-db-secret" created ``` - - 创建 pod ： ```yaml @@ -775,12 +477,6 @@ items: mountPath: "/etc/secret-volume" ``` - - 这两个容器将在其文件系统上显示以下文件，其中包含每个容器环境的值： ```shell @@ -788,12 +484,6 @@ Both containers will have the following files present on their filesystems with /etc/secret-volume/password ``` - - 请注意，两个 pod 的 spec 配置中仅有一个字段有所不同；这有助于使用普通的 pod 配置模板创建具有不同功能的 pod。您可以使用两个 service account 进一步简化基本 pod spec：一个名为 `prod-user` 拥有 `prod-db-secret` ，另一个称为 `test-user` 拥有 `test-db-secret` 。然后，pod spec 可以缩短为，例如： ```yaml @@ -810,15 +500,6 @@ spec: image: myClientImage ``` - - ### 使用案例：secret 卷中以点号开头的文件 为了将数据“隐藏”起来（即文件名以点号开头的文件），简单地说让该键以一个点开始。例如，当如下 secret 被挂载到卷中： @@ -853,35 +534,12 @@ spec: mountPath: "/etc/secret-volume" ``` - - `Secret-volume` 将包含一个单独的文件，叫做 `.secret-file`，`dotfile-test-container` 的 `/etc/secret-volume/.secret-file` 路径下将有该文件。 **注意** 以点号开头的文件在 `ls -l` 的输出中被隐藏起来了；列出目录内容时，必须使用 `ls -la` 才能查看它们。 - - ### 使用案例：Secret 仅对 pod 中的一个容器可见 考虑以下一个需要处理 HTTP 请求的程序，执行一些复杂的业务逻辑，然后使用 HMAC 签署一些消息。因为它具有复杂的应用程序逻辑，所以在服务器中可能会出现一个未被注意的远程文件读取漏洞，这可能会将私钥暴露给攻击者。 @@ -892,24 +550,6 @@ With this partitioned approach, an attacker now has to trick the application ser - - ## 最佳实践 ### 客户端使用 secret API @@ -924,26 +564,6 @@ Secret 中的值对于不同的环境来说重要性可能不同，例如对于 为了提高循环获取的性能，客户端可以设计引用 secret 的资源，然后 `watch` 资源，在引用更改时重新请求 secret。此外，还提出了一种 [”批量监控“ API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/bulk_watch.md) 来让客户端 `watch` 每个资源，该功能可能会在将来的 Kubernetes 版本中提供。 - - ## 安全属性 ### 保护 @@ -960,22 +580,6 @@ There may be several containers in a pod. However, each container in a pod has Pod 中有多个容器。但是，pod 中的每个容器必须请求其挂载卷中的 secret 卷才能在容器内可见。这可以用于 [在 Pod 级别构建安全分区](#use-case-secret-visible-to-one-container-in-a-pod)。 - - - ### 风险 - API server 的 secret 数据以纯文本的方式存储在 etcd 中；因此： diff --git a/cn/docs/concepts/workloads/pods/pod-lifecycle.md b/cn/docs/concepts/workloads/pods/pod-lifecycle.md index a92436513f..1fd690b97a 100644 --- a/cn/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/cn/docs/concepts/workloads/pods/pod-lifecycle.md @@ -14,53 +14,12 @@ cn-reviewers: {% comment %}Updated: 4/14/2015{% endcomment %} {% comment %}Edited and moved to Concepts section: 2/2/17{% endcomment %} - - 该页面将描述 Pod 的生命周期。 {% endcapture %} {% capture body %} - - ## Pod phase Pod 的 `status` 定义在 [PodStatus](/docs/resources-reference/v1.7/#podstatus-v1-core) 对象中，其中有一个 `phase` 字段。 @@ -77,68 +36,10 @@ Pod 相位的数量和含义是严格指定的。除了本文档中列举的内 - 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。 - 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。 - - ## Pod 状态 Pod 有一个 PodStatus 对象，其中包含一个 [PodCondition](/docs/resources-reference/v1.7/#podcondition-v1-core) 数组。 PodCondition 数组的每个元素都有一个 `type` 字段和一个 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。`status` 字段是一个字符串，可能的值有 True、False 和 Unknown。 - - ## 容器探针 [探针](/docs/resources-reference/v1.7/#probe-v1-core) 是由 [kubelet](/docs/admin/kubelet/) 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)。有三种类型的处理程序： @@ -158,36 +59,6 @@ Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出 - `livenessProbe`：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 [重启策略](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 的影响。如果容器不提供存活探针，则默认状态为 `Success`。 - `readinessProbe`：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 `Failure`。如果容器不提供就绪探针，则默认状态为 `Success`。 - - ### 该什么时候使用存活（liveness）和就绪（readiness）探针? 如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的`restartPolicy` 自动执行正确的操作。 @@ -200,78 +71,14 @@ to stop. 请注意，如果您只想在 Pod 被删除时能够排除请求，则不一定需要使用就绪探针；在删除 Pod 时，Pod 会自动将自身置于未完成状态，无论就绪探针是否存在。当等待 Pod 中的容器停止时，Pod 仍处于未完成状态。 - - ## Pod 和容器状态 有关 Pod 容器状态的详细信息，请参阅 [PodStatus](/docs/resources-reference/v1.7/#podstatus-v1-core) 和 [ContainerStatus](/docs/resources-reference/v1.7/#containerstatus-v1-core)。请注意，报告的 Pod 状态信息取决于当前的 [ContainerState](/docs/resources-reference/v1.7/#containerstatus-v1-core)。 - - ## 重启策略 PodSpec 中有一个 `restartPolicy` 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。 `restartPolicy` 适用于 Pod 中的所有容器。`restartPolicy` 仅指通过同一节点上的 kubelet 重新启动容器。失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒...）重新启动，并在成功执行十分钟后重置。如 [Pod 文档](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof) 中所述，一旦绑定到一个节点，Pod 将永远不会重新绑定到另一个节点。 - - ## Pod 的生命 一般来说，Pod 不会消失，直到人为销毁他们。这可能是一个人或控制器。这个规则的唯一例外是成功或失败的 `phase` 超过一段时间（由 master 确定）的Pod将过期并被自动销毁。 @@ -288,17 +95,6 @@ applies a policy for setting the `phase` of all Pods on the lost node to Failed. 如果节点死亡或与集群的其余部分断开连接，则 Kubernetes 将应用一个策略将丢失节点上的所有 Pod 的 `phase` 设置为 Failed。 - - ## 示例 ### 高级 liveness 探针示例 @@ -333,69 +129,6 @@ spec: name: liveness ``` - - ### 状态示例 - Pod 中只有一个容器并且正在运行。容器成功退出。 diff --git a/cn/docs/user-guide/docker-cli-to-kubectl.md b/cn/docs/user-guide/docker-cli-to-kubectl.md index 1a5b2e4da8..1580401f8b 100644 --- a/cn/docs/user-guide/docker-cli-to-kubectl.md +++ b/cn/docs/user-guide/docker-cli-to-kubectl.md @@ -10,12 +10,6 @@ cn-reviewers: title: Docker 用户使用 kubectl 命令指南 --- - - 在本文中，我们将向 docker-cli 用户介绍 Kubernetes 命令行如何与 api 进行交互。该命令行工具——kubectl，被设计成 docker-cli 用户所熟悉的样子，但是它们之间又存在一些必要的差异。该文档将向您展示每个 docker 子命令和 kubectl 与其等效的命令。 * TOC @@ -23,14 +17,6 @@ In this doc, we introduce the Kubernetes command line for interacting with the a #### docker run - - 如何运行一个 nginx Deployment 并将其暴露出来？ 查看 [kubectl run](/docs/user-guide/kubectl/{{page.version}}/#run) 。 使用 docker 命令： @@ -43,12 +29,6 @@ CONTAINER ID IMAGE COMMAND CREATED a9ec34d98787 nginx "nginx -g 'daemon of 2 seconds ago Up 2 seconds 0.0.0.0:80->80/tcp, 443/tcp nginx-app ``` - - 使用 kubectl 命令： ```shell @@ -57,14 +37,6 @@ $ kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster" deployment "nginx-app" created ``` - - 在大于等于 1.2 版本 Kubernetes 集群中，使用`kubectl run` 命令将创建一个名为 "nginx-app" 的 Deployment。如果您运行的是老版本，将会创建一个 replication controller。 如果您想沿用旧的行为，使用 `--generation=run/v1` 参数，这样就会创建 replication controller。查看 [`kubectl run`](/docs/user-guide/kubectl/{{page.version}}/#run) 获取更多详细信息。 @@ -74,14 +46,6 @@ $ kubectl expose deployment nginx-app --port=80 --name=nginx-http service "nginx-http" exposed ``` - - 在 kubectl 命令中，我们创建了一个 [Deployment](/docs/concepts/workloads/controllers/deployment/)，这将保证有 N 个运行 nginx 的 pod（N 代表 spec 中声明的 replica 数，默认为 1）。我们还创建了一个 [service](/docs/user-guide/services)，使用 selector 匹配具有相应的 selector 的 Deployment。查看 [快速开始](/docs/user-guide/quick-start) 获取更多信息。 默认情况下镜像会在后台运行，与`docker run -d ...` 类似，如果您想在前台运行，使用： @@ -90,15 +54,6 @@ By default images are run in the background, similar to `docker run -d ...`, if kubectl run [-i] [--tty] --attach --image= ``` - - 与 `docker run ...` 不同的是，如果指定了 `--attach` ，我们将连接到 `stdin`，`stdout` 和 `stderr`，而不能控制具体连接到哪个输出流（`docker -a ...`）。 因为我们使用 Deployment 启动了容器，如果您终止了连接到的进程（例如 `ctrl-c`），容器将会重启，这跟 `docker run -it` 不同。 @@ -106,14 +61,6 @@ To destroy the Deployment (and its pods) you need to run `kubectl delete deploym #### docker ps - - 如何列出哪些正在运行？查看 [kubectl get](/docs/user-guide/kubectl/{{page.version}}/#get)。 使用 docker 命令： @@ -124,12 +71,6 @@ CONTAINER ID IMAGE COMMAND CREATED a9ec34d98787 nginx "nginx -g 'daemon of About an hour ago Up About an hour 0.0.0.0:80->80/tcp, 443/tcp nginx-app ``` - - 使用 kubectl 命令： ```shell @@ -140,14 +81,6 @@ nginx-app-5jyvm 1/1 Running 0 1h #### docker attach - - 如何连接到已经运行在容器中的进程？查看 [kubectl attach](/docs/user-guide/kubectl/{{page.version}}/#attach)。 使用 docker 命令： @@ -160,12 +93,6 @@ $ docker attach a9ec34d98787 ... ``` - - 使用 kubectl 命令： ```shell @@ -178,14 +105,6 @@ $ kubectl attach -it nginx-app-5jyvm #### docker exec - - 如何在容器中执行命令？查看 [kubectl exec](/docs/user-guide/kubectl/{{page.version}}/#exec)。 使用 docker 命令： @@ -198,12 +117,6 @@ $ docker exec a9ec34d98787 cat /etc/hostname a9ec34d98787 ``` - - 使用 kubectl 命令： ```shell @@ -214,14 +127,6 @@ $ kubectl exec nginx-app-5jyvm -- cat /etc/hostname nginx-app-5jyvm ``` - - 执行交互式命令怎么办？ 使用 docker 命令： @@ -231,12 +136,6 @@ $ docker exec -ti a9ec34d98787 /bin/sh # exit ``` - - 使用 kubectl 命令： ```shell @@ -244,24 +143,10 @@ $ kubectl exec -ti nginx-app-5jyvm -- /bin/sh # exit ``` - - 更多信息请查看 [获取运行中容器的 Shell 环境](/docs/tasks/kubectl/get-shell-running-container/)。 #### docker logs - - 如何查看运行中进程的 stdout/stderr？查看 [kubectl logs](/docs/user-guide/kubectl/{{page.version}}/#logs)。 使用 docker 命令： @@ -272,12 +157,6 @@ $ docker logs -f a9e 192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-" ``` - - 使用 kubectl 命令： ```shell @@ -286,12 +165,6 @@ $ kubectl logs -f nginx-app-zibvs 10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-" ``` - - 现在是时候提一下 pod 和容器之间的细微差别了；默认情况下如果 pod 中的进程退出 pod 也不会终止，相反它将会重启该进程。这类似于 docker run 时的 `--restart=always` 选项， 这是主要差别。在 docker 中，进程的每个调用的输出都是被连接起来的，但是对于 kubernetes，每个调用都是分开的。要查看以前在 kubernetes 中执行的输出，请执行以下操作： ```shell @@ -300,24 +173,8 @@ $ kubectl logs --previous nginx-app-zibvs 10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-" ``` - - 查看 [记录和监控集群活动](/docs/concepts/cluster-administration/logging/) 获取更多信息。 - - #### docker stop 和 docker rm 如何停止和删除运行中的进程？查看 [kubectl delete](/docs/user-guide/kubectl/{{page.version}}/#delete)。 @@ -334,12 +191,6 @@ $ docker rm a9ec34d98787 a9ec34d98787 ``` - - 使用 kubectl 命令： ```shell @@ -355,34 +206,14 @@ $ kubectl get po -l run=nginx-app # Return nothing ``` - - 请注意，我们不直接删除 pod。使用 kubectl 命令，我们要删除拥有该 pod 的 Deployment。如果我们直接删除pod，Deployment 将会重新创建该 pod。 #### docker login - - 在 kubectl 中没有对 `docker login` 的直接模拟。如果您有兴趣在私有镜像仓库中使用 Kubernetes，请参阅 [使用私有镜像仓库](/docs/concepts/containers/images/#using-a-private-registry)。 #### docker version - - 如何查看客户端和服务端的版本？查看 [kubectl version](/docs/user-guide/kubectl/{{page.version}}/#version)。 使用 docker 命令： @@ -401,12 +232,6 @@ Git commit (server): 0baf609 OS/Arch (server): linux/amd64 ``` - - 使用 kubectl 命令： ```shell @@ -417,14 +242,6 @@ Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4 #### docker info - - 如何获取有关环境和配置的各种信息？查看 [kubectl cluster-info](/docs/user-guide/kubectl/{{page.version}}/#cluster-info)。 使用 docker 命令： @@ -449,12 +266,6 @@ ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO WARNING: No swap limit support ``` - - 使用 kubectl 命令： ```shell diff --git a/cn/docs/user-guide/jsonpath.md b/cn/docs/user-guide/jsonpath.md index 965792da5f..51cdc2d49f 100644 --- a/cn/docs/user-guide/jsonpath.md +++ b/cn/docs/user-guide/jsonpath.md @@ -6,28 +6,9 @@ cn-reviewers: - rootsongjc --- - - JSONPath 模板由 {} 包起来的 JSONPath 表达式组成。 除了原始的 JSONPath 语法之外，我们还添加了三个函数： - - 1. `$` 运算符是可选的，因为表达式默认情况下始终从根对象开始。 2. 我们可以使用 `""` 来引用 JSONPath 表达式中的文本。 3. 我们可以使用 `range` 运算符来迭代列表。 @@ -72,20 +53,6 @@ Given the input: ] } ``` - | 函数 | 描述 | 示例 | 结果 | | ----------------- | ---------- | ---------------------------------------- | ---------------------------------------- | | text | 纯文本 | kind is {.kind} | kind is List |