From aca3e081fe9e875abecba9a2548c1423ac0e774c Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 23 Nov 2020 10:24:40 +0800 Subject: [PATCH] [zh] Sync changes from English site (11) --- .../administer-cluster/cluster-management.md | 452 ------------------ .../declare-network-policy.md | 22 +- .../dns-horizontal-autoscaling.md | 8 +- .../namespaces-walkthrough.md | 4 +- .../assign-cpu-resource.md | 19 +- .../assign-memory-resource.md | 98 ++-- ...igure-liveness-readiness-startup-probes.md | 9 +- .../configure-pod-initialization.md | 15 +- .../zh/docs/tasks/tls/certificate-rotation.md | 34 +- 9 files changed, 114 insertions(+), 547 deletions(-) delete mode 100644 content/zh/docs/tasks/administer-cluster/cluster-management.md diff --git a/content/zh/docs/tasks/administer-cluster/cluster-management.md b/content/zh/docs/tasks/administer-cluster/cluster-management.md deleted file mode 100644 index c70475e6bf..0000000000 --- a/content/zh/docs/tasks/administer-cluster/cluster-management.md +++ /dev/null @@ -1,452 +0,0 @@ ---- -approvers: -- lavalamp -- thockin -title: 集群管理 -content_type: task ---- - - -本文描述了和集群生命周期相关的几个主题：创建新集群、更新集群的主控节点和工作节点、 -执行节点维护（例如升级内核）以及升级运行中集群的 Kubernetes API 版本。 - - - - -## 创建和配置集群 - -要在一组机器上安装 Kubernetes，请根据你的环境，查阅现有的[入门指南](/zh/docs/setup/) - - - -## 升级集群 - -集群升级当前是配套提供的，某些发布版本在升级时可能需要特殊处理。 -推荐管理员在升级他们的集群前，同时查阅 -[发行说明](https://git.k8s.io/kubernetes/CHANGELOG.md) 和版本具体升级说明。 - - -### 升级 Azure Kubernetes Service（AKS）集群 - -Azure Kubernetes Service 支持自服务式的控制面升级和集群节点升级。 -升级过程目前是由用户发起的，具体文档参见 -[Azure AKS 文档](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)。 - - -### 升级 Google Compute Engine 集群 - -Google Compute Engine Open Source（GCE-OSS）通过删除和重建主控节点来支持主控节点升级。 -通过维持相同的 Persistent Disk (PD) 以保证在升级过程中保留数据。 - - -GCE 的 节点升级采用[受控实例组](https://cloud.google.com/compute/docs/instance-groups/)， -每个节点将被顺序删除，然后使用新软件重建。 -任何运行在那个节点上的 Pod 需要用副本控制器控制，或者在扩容之后手动重建。 - - -开源 Google Compute Engine (GCE) 集群上的升级过程由 `cluster/gce/upgrade.sh` 脚本控制。 - -运行 `cluster/gce/upgrade.sh -h` 获取使用说明。 - -例如，只将主控节点升级到一个指定的版本（v1.0.2）： - -```shell -cluster/gce/upgrade.sh -M v1.0.2 -``` - - -或者，将整个集群升级到最新的稳定版本： - -```shell -cluster/gce/upgrade.sh release/stable -``` - - -### 升级 Google Kubernetes Engine 集群 - -Google Kubernetes Engine 自动升级主控节点组件（例如 `kube-apiserver`、`kube-scheduler`）至最新版本。 -它还负责主控节点运行的操作系统和其它组件的升级。 - - -节点升级过程由用户发起，[Google Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/clusters/upgrade)中有相关描述。 - - -### 升级 Amazon EKS 集群 - -Amazon EKS 集群的主控组件可以使用 eksctl、AWS 管理控制台或者 AWS CLI 来升级。 -升级过程由用户发起，具体参看 -[Amazon EKS 文档](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)。 - - -### 升级 Oracle Cloud Infrastructure 上的 Container Engine for Kubernetes (OKE) 集群 - -Oracle 在 Oracle 控制面替你创建和管理一组主控节点（及相关的 Kubernetes 基础设施， -如 etcd 节点）。你可以在不停机的情况下无缝升级这些主控节点到新的 Kubernetes 版本。 -相关的操作可参考 -[OKE 文档](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengupgradingk8smasternode.htm)。 - - -### 在其他平台上升级集群 - -不同的供应商和工具管理升级的过程各不相同。建议你查阅它们有关升级的主要文档。 - -* [kops](https://github.com/kubernetes/kops) -* [kubespray](https://github.com/kubernetes-incubator/kubespray) -* [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html) -* [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) -* ... - - -要在上面列表中没有提及的平台上升级集群时，请参阅 -[版本偏差](/zh/docs/setup/release/version-skew-policy/#supported-component-upgrade-order) -页面所讨论的组件升级顺序。 - - -## 调整集群大小 - -如果集群资源短缺，且集群正运行在 -[节点自注册模式](/zh/docs/concepts/architecture/nodes/#self-registration-of-nodes)， -你可以轻松地添加更多的机器。 -如果正在使用的是 GCE 或者 Google Kubernetes Engine，添加节点将通过调整管理节点的实例组的大小完成。 -在 [Google Cloud 控制台](https://console.developers.google.com) 页面 -的 `Compute > Compute Engine > Instance groups > your group > Edit group` -下修改实例数量或使用 gcloud CLI 都可以完成这个任务。 - -```shell -gcloud compute instance-groups managed resize kubernetes-minion-group --size 42 --zone $ZONE -``` - - -实例组将负责在新机器上放置恰当的镜像并启动它们。 -kubelet 将向 API 服务器注册它的节点以使其可以用于调度。 -如果你对实例组进行缩容，系统将会随机选取节点来终止。 - - -在其他环境中，你可能需要手动配置机器并告诉 kubelet API 服务器在哪台机器上运行。 - - -### 集群自动伸缩 - -如果正在使用 GCE 或者 Google Kubernetes Engine，你可以配置你的集群， -使其能够基于 Pod 需求自动重新调整大小。 - - -如[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)所述， -用户可以控制预留多少 CPU 和内存来分配给 Pod。 -这个信息被 Kubernetes 调度器用来寻找一个运行 Pod 的地方。 -如果没有一个节点有足够的空闲容量（或者不能满足 Pod 的其他需求）， -这个 Pod 就需要等待某些 Pod 结束，或者一个新的节点被添加。 - - -集群 Autoscaler 查找不能被调度的 Pod 并检查添加一个新节点（和集群中其它节点类似的） -是否有帮助。如果是的话，它将调整集群的大小以容纳等待调度的 Pod。 - - -如果发现在一段延时时间内（默认 10 分钟，将来有可能改变）某些节点不再需要， -集群 Autoscaler 也会缩小集群。 - - -集群 Autoscaler 基于每个实例组（GCE）或节点池（Google Kubernetes Engine）来配置。 - - -如果你使用 GCE，那么你可以在使用 kube-up.sh 脚本创建集群的时候启用集群自动扩缩。 -要想配置集群 Autoscaler，你需要设置三个环境变量： - - -* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - 如果设置为 true 将启用集群 Autoscaler。 -* `KUBE_AUTOSCALER_MIN_NODES` - 集群的最小节点数量。 -* `KUBE_AUTOSCALER_MAX_NODES` - 集群的最大节点数量。 - -示例： - -```shell -KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh -``` - - -在 Google Kubernetes Engine 上，你可以在创建、更新集群或创建一个特别的（你希望自动伸缩的） -节点池时，通过给对应的 `gcloud` 命令传递 `--enable-autoscaling`、`--min-nodes` 和 -`--max-nodes` 来配置集群 Autoscaler。 - -示例： - -```shell -gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5 -``` - -```shell -gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15 -``` - - - - -**集群 Autoscaler 期望节点未被手动修改过（例如通过 kubectl 添加标签），因自行指定的属性 -可能不能被传递到相同节点组中的新节点上。** - -关于集群 Autoscaler 如何决定是否、合适以及怎样对集群进行缩放的细节，请参考 autoscaler 项目的 -[FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) -文档。 - - - -## 维护节点 - -如果需要重启节点（例如内核升级、libc 升级、硬件维修等），且停机时间很短时， -kubelet 重启后，将尝试重启调度到节点上的 Pod。如果重启花费较长时间（默认时间为 5 分钟，由 -控制器管理器的 `--pod-eviction-timeout` 控制），节点控制器将会结束绑定到这个不可用节点上的 Pod。 -如果存在对应的 ReplicaSet（或者 ReplicationController），则将在另一个节点上启动 Pod 的新副本。 -所以，如果所有的 Pod 都是多副本的，那么在不是所有节点都同时停机的前提下，升级可以在不需要特殊 -调整情况下完成。 - - -如果你希望对升级过程有更多的控制，可以使用下面的工作流程： - -使用 `kubectl drain` 体面地结束节点上的所有 Pod 并同时标记节点为不可调度： - -```shell -kubectl drain $NODENAME -``` - - -在你试图使节点离线时，这样做将阻止新的 Pod 落到它们上面。 - -对于有 ReplicaSet 的 Pod 来说，它们将会被新的 Pod 替换并且将被调度到一个新的节点。 -此外，如果 Pod 是一个 Service 的一部分，则客户端将被自动重定向到新的 Pod。 - - -对于没有 ReplicaSet 的 Pod，你需要手动启动 Pod 的新副本，并且 -如果它不是 Service 的一部分，你需要手动将客户端重定向到这个 Pod。 - -在节点上执行维护工作。 - -重新使节点可调度： - -```shell -kubectl uncordon $NODENAME -``` - - -如果删除了节点的虚拟机实例并重新创建，那么一个新的可调度节点资源将被自动创建 -（只在你使用支持节点发现的云服务提供商时；当前只有 Google Compute Engine， -不包括在 Google Compute Engine 上使用 kube-register 的 CoreOS）。 -相关详细信息，请查阅[节点](/zh/docs/concepts/architecture/nodes/)。 - - -## 高级主题 - -### 升级到不同的 API 版本 - -当新的 API 版本发布时，你可能需要升级集群支持新的 API 版本 -（例如当 'v2' 发布时从 'v1' 切换到 'v2'）。 - - -这不是一个经常性的事件，但需要谨慎的处理。这里有一系列升级到新 API 版本的步骤。 - -1. 开启新 API 版本 -1. 升级集群存储来使用新版本 -1. 升级所有配置文件；识别使用旧 API 版本末端的用户 -1. 运行 `cluster/update-storage-objects.sh` 升级存储中的现有对象为新版本 -1. 关闭旧 API 版本 - - -### 打开或关闭集群的 API 版本 - -可以在启动 API 服务器时传递 `--runtime-config=api/` 标志来打开或关闭特定的 API 版本。 -例如：要关闭 v1 API，请传递 `--runtime-config=api/v1=false`。 -`runtime-config` 还支持两个特殊键值：`api/all` 和 `api/legacy`，分别控制全部和遗留 API。 -例如要关闭除 v1 外全部 API 版本，请传递 `--runtime-config=api/all=false,api/v1=true`。 -对于这些标志来说，_遗留（Legacy）_ API 指的是那些被显式废弃的 API（例如 `v1beta3`）。 - - -### 切换集群存储的 API 版本 - -存储于磁盘中、用于在集群内部代表 Kubernetes 活跃资源的对象使用特定的 API 版本表达。 -当所支持的 API 改变时，这些对象可能需要使用更新的 API 重写。 -重写失败将最终导致资源不再能够被 Kubernetes API server 解析或使用。 - - -### 切换配置文件到新 API 版本 - -你可以使用 `kubectl convert` 命令对不同 API 版本的配置文件进行转换。 - -```shell -kubectl convert -f pod.yaml --output-version v1 -``` - - -更多选项请参考 [`kubectl convert`](/docs/reference/generated/kubectl/kubectl-commands/#convert) 命令用法。 - diff --git a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md index efe1942339..69454747d2 100644 --- a/content/zh/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/declare-network-policy.md @@ -21,6 +21,8 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do [NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/) 声明网络策略去管理 Pod 之间的通信 +{{% thirdparty-content %}} + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} @@ -42,14 +44,6 @@ Make sure you've configured a network provider with network policy support. Ther * [Romana](/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/) * [Weave 网络](/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/) - -{{< note >}} -以上列表是根据产品名称按字母顺序排序，而不是按推荐或偏好排序。 -下面示例对于使用了上面任何提供商的 Kubernetes 集群都是有效的 -{{< /note >}} - 将此 Deployment 以名为 `nginx` 的 Service 暴露出来： -```console +```shell kubectl expose deployment nginx --port=80 ``` @@ -89,7 +83,7 @@ The above commands create a Deployment with an nginx Pod and expose the Deployme Service 暴露出来。名为 `nginx` 的 Pod 和 Deployment 都位于 `default` 名字空间内。 -```console +```shell kubectl get svc,pod ``` ```none @@ -111,7 +105,7 @@ You should be able to access the new `nginx` service from other Pods. To access 你应该可以从其它的 Pod 访问这个新的 `nginx` 服务。 要从 default 命名空间中的其它s Pod 来访问该服务。可以启动一个 busybox 容器： -```console +```shell kubectl run busybox --rm -ti --image=busybox /bin/sh ``` @@ -167,7 +161,7 @@ Use kubectl to create a NetworkPolicy from the above `nginx-policy.yaml` file: 使用 kubectl 根据上面的 `nginx-policy.yaml` 文件创建一个 NetworkPolicy： -```console +```shell kubectl apply -f https://k8s.io/examples/service/networking/nginx-policy.yaml ``` ```none @@ -183,7 +177,7 @@ When you attempt to access the `nginx` Service from a Pod without the correct la 如果你尝试从没有设定正确标签的 Pod 中去访问 `nginx` 服务，请求将会超时： -```console +```shell kubectl run busybox --rm -ti --image=busybox -- /bin/sh ``` @@ -210,7 +204,7 @@ You can create a Pod with the correct labels to see that the request is allowed: 创建一个拥有正确标签的 Pod，你将看到请求是被允许的： -```console +```shell kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh ``` 注意 `coresPerReplica` 和 `nodesPerReplica` 的值都是整数。 @@ -260,7 +260,7 @@ There are other supported scaling patterns. For details, see 当一个集群使用具有较少核心的节点时，由 `nodesPerReplica` 来控制。 其它的扩缩模式也是支持的，详情查看 -[cluster-proportional-autoscaler](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler)。 +[cluster-proportional-autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)。 * 阅读[为关键插件 Pod 提供的调度保障](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) -* 进一步了解 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-incubator/cluster-proportional-autoscaler) +* 进一步了解 [cluster-proportional-autoscaler 实现](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) diff --git a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md index db84fcae80..7fbf132dcf 100644 --- a/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/content/zh/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -397,9 +397,7 @@ Production likes to run cattle, so let's create some cattle pods. 生产环境需要以放牛的方式运维，让我们创建一些名为 `cattle` 的 Pod。 ```shell -kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -kubectl scale deployment cattle --replicas=5 - +kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname --replicas=5 kubectl get deployment ``` diff --git a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md index 19a48d27fb..1f41db117a 100644 --- a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -30,7 +30,7 @@ allocated as much CPU as it requests. Each node in your cluster must have at least 1 CPU. A few of the steps on this page require you to run the -[metrics-server](https://github.com/kubernetes-incubator/metrics-server) +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) service in your cluster. If you have the metrics-server running, you can skip those steps. @@ -39,7 +39,8 @@ following command to enable metrics-server: --> 集群中的每个节点必须至少有 1 个 CPU 可用才能运行本任务中的示例。 -本页的一些步骤要求你在集群中运行[metrics-server](https://github.com/kubernetes-incubator/metrics-server) +本页的一些步骤要求你在集群中运行 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 服务。如果你的集群中已经有正在运行的 metrics-server 服务，可以跳过这些步骤。 如果你正在运行{{< glossary_tooltip term_id="minikube" >}}，请运行以下命令启用 metrics-server： @@ -354,6 +355,20 @@ to specify a default value for the CPU limit. [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core/) 指定 CPU 限制的默认值。 + +## 如果你设置了 CPU 限制但未设置 CPU 请求 + +如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其 +设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置 +内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。 + @@ -19,34 +17,33 @@ This page shows how to assign a memory *request* and a memory *limit* to a Container. A Container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than its limit. --> -此页面显示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。 - - - +此页面展示如何将内存 *请求* （request）和内存 *限制* （limit）分配给一个容器。 +我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -您集群中的每个节点必须拥有至少 300 MiB 的内存。 +你集群中的每个节点必须拥有至少 300 MiB 的内存。 -该页面上的一些步骤要求您在集群中运行 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 服务。如果您已经有在运行中的 metrics-server，则可以跳过这些步骤。 +该页面上的一些步骤要求你在集群中运行 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 服务。 +如果你已经有在运行中的 metrics-server，则可以跳过这些步骤。 -如果您运行的是 Minikube，可以运行下面的命令启用 metrics-server： +如果你运行的是 Minikube，可以运行下面的命令启用 metrics-server： ```shell minikube addons enable metrics-server @@ -68,13 +65,11 @@ reference to `metrics.k8s.io`. --> 如果资源指标 API 可用，则输出结果将包含对 `metrics.k8s.io` 的引用信息。 -```shell +``` NAME v1beta1.metrics.k8s.io ``` - - ## 超过容器限制的内存 -当节点拥有足够的可用内存时，容器可以使用其请求的内存。但是，容器不允许使用超过其限制的内存。 -如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。如果容器继续消耗超出其限制的内存，则终止容器。 +当节点拥有足够的可用内存时，容器可以使用其请求的内存。 +但是，容器不允许使用超过其限制的内存。 +如果容器分配的内存超过其限制，该容器会成为被终止的候选容器。 +如果容器继续消耗超出其限制的内存，则终止容器。 如果终止的容器可以被重启，则 kubelet 会重新启动它，就像其他任何类型的运行时失败一样。 -在本练习中，您将创建一个 Pod，尝试分配超出其限制的内存。 +在本练习中，你将创建一个 Pod，尝试分配超出其限制的内存。 这是一个 Pod 的配置文件，其拥有一个容器，该容器的内存请求为 50 MiB，内存限制为 100 MiB： {{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} @@ -223,7 +220,7 @@ will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limi Create the Pod: --> -在配置文件的 `args` 部分中，您可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。 +在配置文件的 `args` 部分中，你可以看到容器会尝试分配 250 MiB 内存，这远高于 100 MiB 的限制。 创建 Pod： @@ -277,7 +274,8 @@ lastState: The Container in this exercise can be restarted, so the kubelet restarts it. Repeat this command several times to see that the Container is repeatedly killed and restarted: --> -本练习中的容器可以被重启，所以 kubelet 会重启它。多次运行下面的命令，可以看到容器在反复的被杀死和重启： +本练习中的容器可以被重启，所以 kubelet 会重启它。 +多次运行下面的命令，可以看到容器在反复的被杀死和重启： ```shell kubectl get pod memory-demo-2 --namespace=mem-example @@ -371,8 +369,8 @@ of any Node in your cluster. --> Pod 的调度基于请求。只有当节点拥有足够满足 Pod 内存请求的内存时，才会将 Pod 调度至节点上运行。 -在本练习中，你将创建一个 Pod，其内存请求超过了您集群中的任意一个节点所拥有的内存。 -这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了您集群中任何节点的容量。 +在本练习中，你将创建一个 Pod，其内存请求超过了你集群中的任意一个节点所拥有的内存。 +这是该 Pod 的配置文件，其拥有一个请求 1000 GiB 内存的容器，这应该超过了你集群中任何节点的容量。 {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} @@ -397,7 +395,8 @@ kubectl get pod memory-demo-3 --namespace=mem-example -输出结果显示：Pod 处于 PENDING 状态。这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态： +输出结果显示：Pod 处于 PENDING 状态。 +这意味着，该 Pod 没有被调度至任何节点上运行，并且它会无限期的保持该状态： ``` kubectl get pod memory-demo-3 --namespace=mem-example @@ -436,7 +435,9 @@ For example, the following represent approximately the same value: --> ## 内存单位 -内存资源的基本单位是字节（byte）。您可以使用这些后缀之一，将内存表示为纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。例如，下面是一些近似相同的值： +内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为 +纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 +例如，下面是一些近似相同的值： ```shell 128974848, 129e6, 129M , 123Mi @@ -469,12 +470,13 @@ Container is automatically assigned the default limit. Cluster administrators ca [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) to specify a default value for the memory limit. --> -* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存，进而可能导致该节点调用 OOM Killer。 -此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。 +* 容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存， + 进而可能导致该节点调用 OOM Killer。 + 此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。 * 运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。 -集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) -来指定默认的内存限制。 + 集群管理员可用使用 [LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) + 来指定默认的内存限制。 ## 内存请求和限制的目的 -通过为集群中运行的容器配置内存请求和限制，您可以有效利用集群节点上可用的内存资源。通过将 Pod 的内存请求保持在较低水平，您可以更好地安排 Pod 调度。通过让内存限制大于内存请求，您可以完成两件事： +通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。 +通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。 +通过让内存限制大于内存请求，你可以完成两件事： ### 应用开发者扩展阅读 * [为容器和 Pod 分配 CPU 资源](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) * [配置 Pod 的服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/) + + ### 集群管理员扩展阅读 * [为命名空间配置默认的内存请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) - * [为命名空间配置默认的 CPU 请求和限制](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) - * [配置命名空间的最小和最大内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) - * [配置命名空间的最小和最大 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) - * [为命名空间配置内存和 CPU 配额](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) - * [配置命名空间下 Pod 总数](/zh/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) - * [配置 API 对象配额](/zh/docs/tasks/administer-cluster/quota-api-object/) - - - - diff --git a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index f8ceb4f6d9..a2aa986464 100644 --- a/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -284,7 +284,7 @@ affect the HTTP liveness probe. 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. +can't it is considered a failure. --> ## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe} @@ -419,7 +419,7 @@ Sometimes, applications are temporarily unable to serve traffic. For example, an application might need to load large data or configuration files during startup, or depend on external services after startup. In such cases, you don't want to kill the application, -but you don’t want to send it requests either. Kubernetes provides +but you don't want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. A pod with containers reporting that they are not ready does not receive traffic through Kubernetes Services. @@ -534,7 +534,7 @@ in the range 1 to 65535. -* 进一步了解[容器探测器](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 +* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 本文展示如何在 kubelet 中启用并配置证书轮换。 -{{< feature-state for_k8s_version="v1.8" state="beta" >}} +{{< feature-state for_k8s_version="v1.19" state="stable" >}} ## {{% heading "prerequisites" %}} @@ -58,23 +58,21 @@ Kubernetes API 间的连接认证。 The `kubelet` process accepts an argument `--rotate-certificates` that controls if the kubelet will automatically request a new certificate as the expiration of -the certificate currently in use approaches. Since certificate rotation is a -beta feature, the feature flag must also be enabled with -`--feature-gates=RotateKubeletClientCertificate=true`. +the certificate currently in use approaches. --> ## 启用客户端证书轮换 - `kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的证书即将到期时， -是否会自动申请新的证书。 由于证书轮换是 beta 特性，必须通过参数 -`--feature-gates=RotateKubeletClientCertificate=true` 进行启用。 + `kubelet` 进程接收 `--rotate-certificates` 参数，该参数决定 kubelet 在当前使用的 +证书即将到期时，是否会自动申请新的证书。 -`kube-controller-manager` 进程接收 -`--experimental-cluster-signing-duration` 参数，该参数控制证书签发的有效期限。 +`kube-controller-manager` 进程接收 `--cluster-signing-duration` 参数 +（在 1.19 版本之前为 `--experimental-cluster-signing-duration`），用来 +控制签发证书的有效期限。 ## 理解证书轮换配置 -当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet 会使用其初始证书连接到 -Kubernetes API ，并发送证书签名的请求。 可以通过以下方式查看证书签名请求的状态： +当 kubelet 启动时，如被配置为自举（使用`--bootstrap-kubeconfig` 参数），kubelet +会使用其初始证书连接到 Kubernetes API ，并发送证书签名的请求。 +可以通过以下方式查看证书签名请求的状态： -```sh +```shell kubectl get csr ``` @@ -99,19 +98,20 @@ status of `Pending`. If the certificate signing requests meets specific criteria, it will be auto approved by the controller manager, then it will have a status of `Approved`. Next, the controller manager will sign a certificate, issued for the duration specified by the -`--experimental-cluster-signing-duration` parameter, and the signed certificate +`--cluster-signing-duration` parameter, and the signed certificate will be attached to the certificate signing requests. --> 最初，来自节点上 kubelet 的证书签名请求处于 `Pending` 状态。 如果证书签名请求满足特定条件， 控制器管理器会自动批准，此时请求会处于 `Approved` 状态。 接下来，控制器管理器会签署证书， -证书的有效期限由 `--experimental-cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。 +证书的有效期限由 `--cluster-signing-duration` 参数指定，签署的证书会被附加到证书签名请求中。 -Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir` 参数指定。 +Kubelet 会从 Kubernetes API 取回签署的证书，并将其写入磁盘，存储位置通过 `--cert-dir` +参数指定。 然后 kubelet 会使用新的证书连接到 Kubernetes API。