[zh] Fix some 404 links
Sean Wei
parent
5a1ade2551
commit
34563abc4f
|
|
@ -45,9 +45,9 @@ Most stateless systems, web servers for example, are created without the need to
|
|||
One of Kubernetes' responsibilities is to place "resources" (e.g, a disk or container) into the cluster and satisfy the constraints they request. For example: "I must be in availability zone _A_" (see [Running in multiple zones](/docs/setup/best-practices/multiple-zones/#nodes-are-labeled)), or "I can't be placed onto the same node as this other Pod" (see [Affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)).
|
||||
-->
|
||||
Kubernetes 的职责之一是将 "资源"（如磁盘或容器）放入集群中，并满足其请求的约束。
|
||||
例如。"我必须在可用性区域 _A_"（见[在多个区域运行](/zh-cn/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)），
|
||||
例如。"我必须在可用性区域 _A_"（见[在多个区域运行](/zh-cn/docs/setup/best-practices/multiple-zones/#nodes-are-labeled)），
|
||||
或者 "我不能被放置到与某个 Pod 相同的节点上"
|
||||
（见[亲和与反亲和](/zh-cn/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)）。
|
||||
（见[亲和与反亲和](/zh-cn/docs/setup/best-practices/multiple-zones/#nodes-are-labeled)）。
|
||||
|
||||
<!--
|
||||
As an addition to those constraints, Kubernetes offers [Statefulsets](/docs/concepts/workloads/controllers/statefulset/) that provide identity to Pods as well as persistent storage that "follows" these identified pods. Identity in a StatefulSet is handled by an increasing integer at the end of a pod's name. It's important to note that this integer must always be contiguous: in a StatefulSet, if pods 1 and 3 exist then pod 2 must also exist.
|
||||
|
|
@ -91,7 +91,7 @@ When adding additional resources to the cluster we also distribute them across z
|
|||
Note that anti-affinities are satisfied no matter the order in which pods are assigned to Kubernetes nodes. In the example, pods 0, 1 and 2 were assigned to zones A, B, and C respectively, but pods 3 and 4 were assigned in a different order, to zones B and A respectively. The anti-affinity is still satisfied because the pods are still placed in different zones.
|
||||
-->
|
||||
请注意，无论 Pod 被分配到 Kubernetes 节点的顺序如何，都会满足反亲和性。
|
||||
在这个例子中，Pod 0、1 、2 分别被分配到 A、B 、C 区，但 Pod 3 和 4 以不同的顺序被分配到 B 和 A 区。
|
||||
在这个例子中，Pod 0、1、2 分别被分配到 A、B、C 区，但 Pod 3 和 4 以不同的顺序被分配到 B 和 A 区。
|
||||
反亲和性仍然得到满足，因为 Pod 仍然被放置在不同的区域。
|
||||
|
||||
<!--
|
||||
|
|
@ -144,7 +144,7 @@ Our combined knowledge of the following is what lead to this misconception.
|
|||
* The behavior that a StatefulSet with _n_ replicas, when Pods are being deployed, they are created sequentially, in order from `{0..n-1}`. See [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees) for more details.
|
||||
-->
|
||||
我们对以下内容的综合认识是导致这种误解的原因。
|
||||
* Kubernetes [自动跨区分配 Pod](/zh-cn/docs/setup/best-practices/multiple-zone/#pods-are-spread-across-zone) 的能力
|
||||
* Kubernetes [自动跨区分配 Pod](/zh-cn/docs/setup/best-practices/multiple-zones/#pods-are-spread-across-zones) 的能力
|
||||
* 一个有 _n_ 个副本的 StatefulSet，当 Pod 被部署时，它们会按照 `{0...n-1}` 的顺序依次创建。
|
||||
更多细节见 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。
|
||||
|
||||
|
|
|
|||
|
|
@ -194,6 +194,6 @@ dockershim removal makes up for the migration effort you'll have. Start planning
|
|||
now to avoid surprises. We'll have more updates and guides before Kubernetes
|
||||
1.24 is released.
|
||||
-->
|
||||
在这一点上，我们相信你（和 Kubernetes）从移除 dockershim 中获得的价值可以弥补你将要进行的迁移工作。
|
||||
在这一点上，我们相信你（和 Kubernetes）从移除 dockershim 中获得的价值可以弥补你将要进行的迁移工作。
|
||||
现在就开始计划以避免出现意外。在 Kubernetes 1.24 发布之前，我们将提供更多更新信息和指南。
|
||||
|
||||
|
|
|
|||
|
|
@ -1351,7 +1351,7 @@ A set of <code><resource name>=<resource quantity></code> (e.g. <cod
|
|||
kubernetes 系统预留的资源配置，以一组 <code><资源名称>=<资源数量></code> 格式表示。
|
||||
（例如：<code>cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'</code>）。
|
||||
当前支持 <code>cpu</code>、<code>memory</code> 和用于根文件系统的 <code>ephemeral-storage</code>。
|
||||
请参阅<a href="http://kubernetes.io/zh-cn/docs/user-guide/compute-resources">这里</a>获取更多信息。
|
||||
请参阅<a href="https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/">这里</a>获取更多信息。
|
||||
（已弃用：应在 <code>--config</code> 所给的配置文件中进行设置。
|
||||
请参阅 <a href="https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> 了解更多信息。）
|
||||
</td>
|
||||
|
|
|
|||
|
|
@ -2,7 +2,6 @@
|
|||
title: Kubelet 配置 (v1beta1)
|
||||
content_type: tool-reference
|
||||
package: kubelet.config.k8s.io/v1beta1
|
||||
auto_generated: true
|
||||
---
|
||||
|
||||
<!--
|
||||
|
|
@ -683,7 +682,7 @@ The cgroupRoot must be specified if this field is not empty.
|
|||
Default: "&qout;
|
||||
-->
|
||||
<p><code>systemCgroups</code>是用来放置那些未被容器化的、非内核的进程的控制组
|
||||
(CGroup）的绝对名称。设置为空字符串表示没有这类容器。回滚此字段设置需要重启节点。
|
||||
（CGroup）的绝对名称。设置为空字符串表示没有这类容器。回滚此字段设置需要重启节点。
|
||||
当此字段非空时，必须设置<code>cgroupRoot</code>字段。</p>
|
||||
<p>默认值：""</p>
|
||||
</td>
|
||||
|
|
@ -696,7 +695,7 @@ Default: "&qout;
|
|||
<!--cgroupRoot is the root cgroup to use for pods. This is handled by the
|
||||
container runtime on a best effort basis.
|
||||
-->
|
||||
<p><code>cgroupRoot</code>是用来运行 Pod 的控制组 (CGroup）。
|
||||
<p><code>cgroupRoot</code>是用来运行 Pod 的控制组（CGroup）。
|
||||
容器运行时会尽可能处理此字段的设置值。</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
@ -725,7 +724,7 @@ Default: true
|
|||
or systemd).
|
||||
Default: "cgroupfs"
|
||||
-->
|
||||
<p><code>cgroupDriver</code>是 kubelet 用来操控宿主系统上控制组 (CGroup）
|
||||
<p><code>cgroupDriver</code>是 kubelet 用来操控宿主系统上控制组（CGroup）
|
||||
的驱动程序（cgroupfs 或 systemd）。</p>
|
||||
<p>默认值："cgroupfs"</p>
|
||||
</td>
|
||||
|
|
@ -1399,7 +1398,8 @@ Default: nil
|
|||
-->
|
||||
<p><code>systemReserved</code>是一组<code>资源名称=资源数量</code>对，
|
||||
用来描述为非 Kubernetes 组件预留的资源（例如：'cpu=200m,memory=150G'）。</p>
|
||||
<p>目前仅支持 CPU 和内存。更多细节可参见 http://kubernetes.io/zh/docs/user-guide/compute-resources。</p>
|
||||
<p>目前仅支持 CPU 和内存。更多细节可参见
|
||||
https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/ 。</p>
|
||||
<p>默认值：Nil</p>
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ kubectl 管理控制 Kubernetes 集群。
|
|||
|
||||
|
||||
<!--
|
||||
Find more information at: https://kubernetes.io/docs/reference/kubectl/overview/
|
||||
Find more information at: https://kubernetes.io/docs/reference/kubectl/
|
||||
-->
|
||||
获取更多信息，请访问 [kubectl 概述](/zh-cn/docs/reference/kubectl/overview/)。
|
||||
获取更多信息，请访问 [kubectl 概述](/zh-cn/docs/reference/kubectl/)。
|
||||
|
||||
```
|
||||
kubectl [flags]
|
||||
|
|
@ -625,4 +625,4 @@ When set to false, turns off extra HTTP headers detailing invoked kubectl comman
|
|||
* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top) - 显示资源（CPU /内存/存储）使用率
|
||||
* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - 标记节点为可调度的
|
||||
* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - 打印客户端和服务器的版本信息
|
||||
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - 实验性：等待一个或多个资源达到某种状态
|
||||
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - 实验性：等待一个或多个资源达到某种状态
|
||||
|
|
@ -17,6 +17,7 @@ content_type: "api_reference"
|
|||
description: "Volume represents a named volume in a pod that may be accessed by any container in the pod."
|
||||
title: "Volume"
|
||||
weight: 3
|
||||
auto_generated: true
|
||||
-->
|
||||
|
||||
`import "k8s.io/api/core/v1"`
|
||||
|
|
@ -444,7 +445,7 @@ Volume 表示 Pod 中一个有名字的卷，可以由 Pod 中的任意容器进
|
|||
sizeLimit 是这个 EmptyDir 卷所需的本地存储总量。这个大小限制也适用于内存介质。
|
||||
EmptyDir 的内存介质最大使用量将是此处指定的 sizeLimit 与 Pod 中所有容器内存限制总和这两个值之间的最小值。
|
||||
默认为 nil，这意味着限制未被定义。更多信息：
|
||||
http://kubernetes.io/zh-cn/docs/user-guide/volumes#emptydir
|
||||
https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#emptydir
|
||||
|
||||
<!--
|
||||
- **hostPath** (HostPathVolumeSource)
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ The Kubelet populates this with `runtime.GOARCH` as defined by Go. This can be h
|
|||
|
||||
用于：Node
|
||||
|
||||
Kubelet 使用 Go 定义的 `runtime.GOARCH` 填充它。 如果你混合使用 ARM 和 X86 节点，这会很方便。
|
||||
Kubelet 使用 Go 定义的 `runtime.GOARCH` 填充它。如果你混合使用 ARM 和 X86 节点，这会很方便。
|
||||
<!--
|
||||
### kubernetes.io/os
|
||||
|
||||
|
|
@ -230,11 +230,11 @@ This label has been deprecated. Please use `kubernetes.io/os` instead.
|
|||
-->
|
||||
### beta.kubernetes.io/arch (已弃用) {#beta-kubernetes-io-arch}
|
||||
|
||||
此标签已被弃用。请改用`kubernetes.io/arch`。
|
||||
此标签已被弃用。请改用 `kubernetes.io/arch`。
|
||||
|
||||
### beta.kubernetes.io/os (已弃用) {#beta-kubernetes-io-os}
|
||||
|
||||
此标签已被弃用。请改用`kubernetes.io/os`。
|
||||
此标签已被弃用。请改用 `kubernetes.io/os`。
|
||||
|
||||
<!--
|
||||
### kubernetes.io/hostname {#kubernetesiohostname}
|
||||
|
|
@ -255,7 +255,7 @@ This label is also used as part of the topology hierarchy. See [topology.kubern
|
|||
|
||||
Kubelet 使用主机名填充此标签。请注意，可以通过将 `--hostname-override` 标志传递给 `kubelet` 来替代“实际”主机名。
|
||||
|
||||
此标签也用作拓扑层次结构的一部分。 有关详细信息，请参阅 [topology.kubernetes.io/zone](#topologykubernetesiozone)。
|
||||
此标签也用作拓扑层次结构的一部分。有关详细信息，请参阅 [topology.kubernetes.io/zone](#topologykubernetesiozone)。
|
||||
|
||||
<!--
|
||||
### kubernetes.io/change-cause {#change-cause}
|
||||
|
|
@ -328,7 +328,7 @@ which allows users to influence ReplicaSet downscaling order. The annotation par
|
|||
|
||||
用于：Pod
|
||||
|
||||
该注解用于设置 [Pod 删除成本](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)允许用户影响 ReplicaSet 缩减顺序。注解解析为 `int32` 类型。
|
||||
该注解用于设置 [Pod 删除成本](/zh-cn/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)允许用户影响 ReplicaSet 缩减顺序。注解解析为 `int32` 类型。
|
||||
|
||||
<!--
|
||||
### kubernetes.io/ingress-bandwidth
|
||||
|
|
@ -353,7 +353,7 @@ For example, `10M` means 10 megabits per second.
|
|||
|
||||
{{< note >}}
|
||||
入站流量控制注解是一项实验性功能。
|
||||
如果要启用流量控制支持，必须将`bandwidth`插件添加到 CNI 配置文件（默认为`/etc/cni/net.d`）
|
||||
如果要启用流量控制支持，必须将 `bandwidth` 插件添加到 CNI 配置文件（默认为`/etc/cni/net.d`）
|
||||
并确保二进制文件包含在你的 CNI bin 目录中（默认为`/opt/cni/bin`）。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -364,9 +364,9 @@ For example, `10M` means 10 megabits per second.
|
|||
你可以对 Pod 应用服务质量流量控制并有效限制其可用带宽。
|
||||
入站流量（到 Pod）通过控制排队的数据包来处理，以有效地处理数据。
|
||||
要限制 Pod 的带宽，请编写对象定义 JSON 文件并使用 `kubernetes.io/ingress-bandwidth`
|
||||
注解指定数据流量速度。 用于指定入站的速率单位是每秒，
|
||||
注解指定数据流量速度。用于指定入站的速率单位是每秒，
|
||||
作为[量纲（Quantity）](/zh-cn/docs/reference/kubernetes-api/common-definitions/quantity/)。
|
||||
例如，`10M`表示每秒 10 兆比特。
|
||||
例如，`10M` 表示每秒 10 兆比特。
|
||||
|
||||
<!--
|
||||
### kubernetes.io/egress-bandwidth
|
||||
|
|
@ -391,7 +391,7 @@ For example, `10M` means 10 megabits per second.
|
|||
|
||||
{{< note >}}
|
||||
出站流量控制注解是一项实验性功能。
|
||||
如果要启用流量控制支持，必须将`bandwidth`插件添加到 CNI 配置文件（默认为`/etc/cni/net.d`）
|
||||
如果要启用流量控制支持，必须将 `bandwidth` 插件添加到 CNI 配置文件（默认为`/etc/cni/net.d`）
|
||||
并确保二进制文件包含在你的 CNI bin 目录中（默认为`/opt/cni/bin`）。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -483,7 +483,7 @@ StatefulSet topic for more details.
|
|||
|
||||
当 StatefulSet 控制器为 StatefulSet 创建 Pod 时，控制平面会在该 Pod 上设置此标签。标签的值是正在创建的 Pod 的名称。
|
||||
|
||||
有关详细信息，请参阅 StatefulSet 主题中的 [Pod 名称标签](/docs/concepts/workloads/controllers/statefulset/#pod-name-label)。
|
||||
有关详细信息，请参阅 StatefulSet 主题中的 [Pod 名称标签](/zh-cn/docs/concepts/workloads/controllers/statefulset/#pod-name-label)。
|
||||
|
||||
<!--
|
||||
### topology.kubernetes.io/region {#topologykubernetesioregion}
|
||||
|
|
@ -529,8 +529,8 @@ A region represents a larger domain, made up of one or more zones. It is uncomm
|
|||
|
||||
在 PersistentVolume 上：拓扑感知卷配置器将自动在 `PersistentVolume` 上设置 Node 亲和性约束。
|
||||
|
||||
一个 Zone 代表一个逻辑故障域。 Kubernetes 集群通常跨越多个 Zone 以提高可用性。虽然 Zone 的确切定义留给基础设施实现，
|
||||
但 Zone 的常见属性包括 Zone 内非常低的网络延迟、 Zone 内的免费网络流量以及与其他 Zone 的故障独立性。
|
||||
一个 Zone 代表一个逻辑故障域。Kubernetes 集群通常跨越多个 Zone 以提高可用性。虽然 Zone 的确切定义留给基础设施实现，
|
||||
但 Zone 的常见属性包括 Zone 内非常低的网络延迟、Zone 内的免费网络流量以及与其他 Zone 的故障独立性。
|
||||
例如，一个 Zone 内的 Node 可能共享一个网络交换机，但不同 Zone 中的 Node 无法共享交换机。
|
||||
|
||||
一个 Region 代表一个更大的域，由一个或多个 Zone 组成。Kubernetes 集群跨多个 Region 并不常见，虽然 Zone 或 Region 的确切定义留给基础设施实现，
|
||||
|
|
@ -544,9 +544,9 @@ Kubernetes makes a few assumptions about the structure of zones and regions:
|
|||
-->
|
||||
Kubernetes 对 Zone 和 Region 的结构做了一些假设：
|
||||
|
||||
1. Zone 和 Region 是分层的： Zone 是 Region 的严格子集，没有 Zone 可以在两个 Region 中；
|
||||
1. Zone 和 Region 是分层的：Zone 是 Region 的严格子集，没有 Zone 可以在两个 Region 中；
|
||||
|
||||
2. Zone 名称跨 Region 是唯一的；例如， Region “africa-east-1” 可能由 Zone “africa-east-1a” 和 “africa-east-1b” 组成。
|
||||
2. Zone 名称跨 Region 是唯一的；例如，Region “africa-east-1” 可能由 Zone “africa-east-1a” 和 “africa-east-1b” 组成。
|
||||
|
||||
<!--
|
||||
It should be safe to assume that topology labels do not change. Even though labels are strictly mutable, consumers of them can assume that a given node is not going to be moved between zones without being destroyed and recreated.
|
||||
|
|
@ -581,7 +581,7 @@ If `PersistentVolumeLabel` does not support automatic labeling of your Persisten
|
|||
adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all.
|
||||
-->
|
||||
你应该考虑手动添加标签（或添加对 `PersistentVolumeLabel` 的支持）。
|
||||
基于 `PersistentVolumeLabel` ，调度程序可以防止 Pod 挂载来自其他 Zone 的卷。如果你的基础架构没有此限制，则不需要将 Zone 标签添加到卷上。
|
||||
基于 `PersistentVolumeLabel`，调度程序可以防止 Pod 挂载来自其他 Zone 的卷。如果你的基础架构没有此限制，则不需要将 Zone 标签添加到卷上。
|
||||
|
||||
<!--
|
||||
### volume.beta.kubernetes.io/storage-provisioner (deprecated)
|
||||
|
|
@ -1336,7 +1336,7 @@ See more details on the [Audit Annotations](/docs/reference/labels-annotations-t
|
|||
- [`insecure-sha1.invalid-cert.kubernetes.io/$hostname`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#insecure-sha1-invalid-cert-kubernetes-io-hostname)
|
||||
- [`missing-san.invalid-cert.kubernetes.io/$hostname`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#missing-san-invalid-cert-kubernetes-io-hostname)
|
||||
- [`pod-security.kubernetes.io/audit-violations`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/zh-cn/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`pod-security.kubernetes.io/enforce-policy`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
|
||||
- [`pod-security.kubernetes.io/exempt`](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
|
||||
|
||||
在[审计注解](/zh-cn/docs/reference/labels-annotations-taints/audit-annotations/)页面上查看更多详细信息。
|
||||
|
|
|
|||
|
|
@ -251,7 +251,7 @@ extension points:
|
|||
-->
|
||||
- `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。
|
||||
得分可以使用以下三种策略之一：`LeastAllocated`（默认）、`MostAllocated`
|
||||
和`RequestedToCapacityRatio`。
|
||||
和 `RequestedToCapacityRatio`。
|
||||
|
||||
实现的扩展点：`preFilter`，`filter`，`score`。
|
||||
<!--
|
||||
|
|
@ -501,7 +501,7 @@ This would equate to manually enabling `MyPlugin` for all of its extension
|
|||
points, like so:
|
||||
-->
|
||||
|
||||
这相当于为所有扩展点手动启用`MyPlugin`，如下所示：
|
||||
这相当于为所有扩展点手动启用 `MyPlugin`，如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
|
|
@ -732,7 +732,7 @@ as well as its seamless integration with the existing methods for configuring ex
|
|||
## Scheduler configuration migrations
|
||||
-->
|
||||
|
||||
## 调度程序配置迁移
|
||||
## 调度程序配置迁移 {#scheduler-configuration-migrations}
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="v1beta1 → v1beta2" %}}
|
||||
<!--
|
||||
|
|
@ -774,7 +774,7 @@ as well as its seamless integration with the existing methods for configuring ex
|
|||
* The scheduler plugin `ServiceAffinity` is deprecated; instead, use the [`InterPodAffinity`](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) plugin (enabled by default) to achieve similar behavior.
|
||||
-->
|
||||
* 调度程序插件 `ServiceAffinity` 已弃用；
|
||||
相反，使用 [`InterPodAffinity`](/zh-cn/doc/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
|
||||
相反，使用 [`InterPodAffinity`](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
|
||||
插件（默认启用）来实现类似的行为。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ by managing [policies](/docs/concepts/policy/) and
|
|||
你可以使用基于角色的访问控制（[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)）
|
||||
和其他安全机制来确保用户和负载能够访问到所需要的资源，同时确保工作负载及集群
|
||||
自身仍然是安全的。
|
||||
你可以通过管理[策略](/zh-cn/docs/concets/policy/)和
|
||||
你可以通过管理[策略](/zh-cn/docs/concepts/policy/)和
|
||||
[容器资源](/zh-cn/docs/concepts/configuration/manage-resources-containers)来
|
||||
针对用户和工作负载所可访问的资源设置约束，
|
||||
|
||||
|
|
@ -215,7 +215,7 @@ for details.
|
|||
-->
|
||||
- *为 API 服务器配置负载均衡*：配置负载均衡器来将外部的 API 请求散布给运行在
|
||||
不同节点上的 API 服务实例。参阅
|
||||
[创建外部负载均衡器](/zh-cn/docs/access-application-cluster/create-external-load-balancer/)
|
||||
[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/)
|
||||
了解细节。
|
||||
<!--
|
||||
- *Separate and backup etcd service*: The etcd services can either run on the
|
||||
|
|
@ -318,7 +318,7 @@ control plane or have a cloud provider do it for you, you still need to
|
|||
consider how you want to manage your worker nodes (also referred to
|
||||
simply as *nodes*).
|
||||
-->
|
||||
### 生产用工作节点
|
||||
### 生产用工作节点 {#production-worker-nodes}
|
||||
|
||||
生产质量的工作负载需要是弹性的；它们所依赖的其他组件（例如 CoreDNS）也需要是弹性的。
|
||||
无论你是自行管理控制面还是让云供应商来管理，你都需要考虑如何管理工作节点
|
||||
|
|
@ -418,7 +418,7 @@ hundreds of people. In a learning environment or platform prototype, you might h
|
|||
administrative account for everything you do. In production, you will want
|
||||
more accounts with different levels of access to different namespaces.
|
||||
-->
|
||||
### 生产级用户环境
|
||||
### 生产级用户环境 {#production-user-management}
|
||||
|
||||
在生产环境中，情况可能不再是你或者一小组人在访问集群，而是几十
|
||||
上百人需要访问集群。在学习环境或者平台原型环境中，你可能具有一个
|
||||
|
|
@ -635,4 +635,3 @@ and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin
|
|||
[DNS 自动扩缩](/zh-cn/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
|
||||
和[服务账号](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/)
|
||||
来为应用负载作准备。
|
||||
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ applies to `kubeadm` as well as to Kubernetes overall.
|
|||
Check that policy to learn about what versions of Kubernetes and `kubeadm`
|
||||
are supported. This page is written for Kubernetes {{< param "version" >}}.
|
||||
-->
|
||||
[Kubernetes 版本及版本偏差策略](/zh-cn/docs/setup/release/version-skew-policy/#supported-versions)适用于 `kubeadm` 以及整个 Kubernetes。
|
||||
[Kubernetes 版本及版本偏差策略](/zh-cn/releases/version-skew-policy/#supported-versions)适用于 `kubeadm` 以及整个 Kubernetes。
|
||||
查阅该策略以了解支持哪些版本的 Kubernetes 和 `kubeadm`。
|
||||
该页面是为 Kubernetes {{< param "version" >}} 编写的。
|
||||
|
||||
|
|
@ -544,7 +544,7 @@ The `node-role.kubernetes.io/control-plane` label is such a restricted label and
|
|||
a privileged client after a node has been created. To do that manually you can do the same by using `kubectl label`
|
||||
and ensure it is using a privileged kubeconfig such as the kubeadm managed `/etc/kubernetes/admin.conf`.
|
||||
-->
|
||||
默认情况下，kubeadm 启用 [NodeRestriction](/zh-cn/docs/reference/access-authn-authz/admissiontrollers/#noderestriction)
|
||||
默认情况下，kubeadm 启用 [NodeRestriction](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
|
||||
准入控制器来限制 kubelets 在节点注册时可以应用哪些标签。准入控制器文档描述 kubelet `--node-labels` 选项允许使用哪些标签。
|
||||
其中 `node-role.kubernetes.io/control-plane` 标签就是这样一个受限制的标签，
|
||||
kubeadm 在节点创建后使用特权客户端手动应用此标签。
|
||||
|
|
@ -889,7 +889,7 @@ options.
|
|||
* Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy)
|
||||
* <a id="lifecycle" />See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)
|
||||
for details about upgrading your cluster using `kubeadm`.
|
||||
* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm)
|
||||
* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/)
|
||||
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/).
|
||||
* See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list
|
||||
of Pod network add-ons.
|
||||
|
|
@ -903,7 +903,7 @@ options.
|
|||
-->
|
||||
* 使用 [Sonobuoy](https://github.com/heptio/sonobuoy) 验证集群是否正常运行。
|
||||
* <a id="lifecycle"/>有关使用 kubeadm 升级集群的详细信息，请参阅[升级 kubeadm 集群](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)。
|
||||
* 在 [kubeadm 参考文档](/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm)中了解有关 `kubeadm` 进阶用法的信息。
|
||||
* 在 [kubeadm 参考文档](/zh-cn/docs/reference/setup-tools/kubeadm/)中了解有关 `kubeadm` 进阶用法的信息。
|
||||
* 了解有关 Kubernetes [概念](/zh-cn/docs/concepts/)和 [`kubectl`](/zh-cn/docs/reference/kubectl/)的更多信息。
|
||||
* 有关 Pod 网络附加组件的更多列表，请参见[集群网络](/zh-cn/docs/concepts/cluster-administration/networking/)页面。
|
||||
* <a id="other-addons" />请参阅[附加组件列表](/zh-cn/docs/concepts/cluster-administration/addons/)以探索其他附加组件，
|
||||
|
|
@ -1051,7 +1051,7 @@ To learn more about the version skew between the different Kubernetes component
|
|||
the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
|
||||
-->
|
||||
要了解更多关于不同 Kubernetes 组件之间的版本偏差，请参见
|
||||
[版本偏差策略](https://kubernetes.io/releases/version-skew-policy/)。
|
||||
[版本偏差策略](/zh-cn/releases/version-skew-policy/)。
|
||||
|
||||
<!--
|
||||
## Limitations {#limitations}
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ For information on how to create a cluster with kubeadm once you have performed
|
|||
-->
|
||||
* 一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux
|
||||
发行版以及一些不提供包管理器的发行版提供通用的指令
|
||||
* 每台机器 2 GB 或更多的 RAM （如果少于这个数字将会影响你应用的运行内存)
|
||||
* 每台机器 2 GB 或更多的 RAM （如果少于这个数字将会影响你应用的运行内存）
|
||||
* 2 CPU 核或更多
|
||||
* 集群中的所有机器的网络彼此均能相互连接(公网和内网都可以)
|
||||
* 节点之中不可以有重复的主机名、MAC 地址或 product_uuid。请参见[这里](#verify-mac-address)了解更多详细信息。
|
||||
|
|
@ -293,7 +293,7 @@ For more information on version skews, see:
|
|||
-->
|
||||
关于版本偏差的更多信息，请参阅以下文档：
|
||||
|
||||
* Kubernetes [版本与版本间的偏差策略](/zh-cn/docs/setup/release/version-skew-policy/)
|
||||
* Kubernetes [版本与版本间的偏差策略](/zh-cn/releases/version-skew-policy/)
|
||||
* Kubeadm 特定的[版本偏差策略](/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy)
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
|
|
|
|||
|
|
@ -312,7 +312,7 @@ section.
|
|||
-->
|
||||
{{< note >}}
|
||||
下面的内容只是一个例子。如果你不想使用包管理器，
|
||||
请遵循[没有包管理器](/zh-cn/docs/setup/productionenvironment/tools/kubeadm/install-kubeadm/#k8s-install-2))
|
||||
请遵循[没有包管理器](/zh-cn/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#k8s-install-2))
|
||||
章节的指南。
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -213,7 +213,7 @@ _Running_ (see [Pod Phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phas
|
|||
and _Ready_ (see `type` in [Pod Conditions](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)).
|
||||
-->
|
||||
请注意，直到 `web-0` Pod 处于 _Running_（请参阅
|
||||
[Pod 阶段]((/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase))）
|
||||
[Pod 阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)）
|
||||
并 _Ready_（请参阅 [Pod 状况](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)中的
|
||||
`type`）状态后，`web-1` Pod 才会被启动。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue