whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Switch language name 'zh' to 'zh-cn'

Browse Source 
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.

- The upstream docsy theme changed the language name, leading to many warnings during site build;
  The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.

There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.

We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.

This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
2022-06-10 20:25:27 +08:00
parent 3d345b1816
commit c52818c03d
1347 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/setup/best-practices/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: 最佳实践
weight: 40
---
content/zh-cn/docs/setup/best-practices/certificates.md
+393
View File
@@ -0,0 +1,393 @@
---
title: PKI 证书和要求
content_type: concept
weight: 40
---
<!--
title: PKI certificates and requirements
reviewers:
- sig-cluster-lifecycle
content_type: concept
weight: 40
-->
<!-- overview -->
<!--
Kubernetes requires PKI certificates for authentication over TLS.
If you install Kubernetes with [kubeadm](/docs/reference/setup-tools/kubeadm/), the certificates that your cluster requires are automatically generated.
You can also generate your own certificates -- for example, to keep your private keys more secure by not storing them on the API server.
This page explains the certificates that your cluster requires.
-->
Kubernetes 需要 PKI 证书才能进行基于 TLS 的身份验证。如果你是使用
[kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 安装的 Kubernetes，
则会自动生成集群所需的证书。你还可以生成自己的证书。
例如，不将私钥存储在 API 服务器上，可以让私钥更加安全。此页面说明了集群必需的证书。
<!-- body -->
<!--
## How certificates are used by your cluster
Kubernetes requires PKI for the following operations:
-->
## 集群是如何使用证书的 {#how-certificates-are-used-by-your-cluster}
Kubernetes 需要 PKI 才能执行以下操作：
<!--
* Client certificates for the kubelet to authenticate to the API server
* Kubelet [server certificates](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)
for the API server to talk to the kubelets
* Server certificate for the API server endpoint
* Client certificates for administrators of the cluster to authenticate to the API server
* Client certificates for the API server to talk to the kubelets
* Client certificate for the API server to talk to etcd
* Client certificate/kubeconfig for the controller manager to talk to the API server
* Client certificate/kubeconfig for the scheduler to talk to the API server.
* Client and server certificates for the [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
-->
* Kubelet 的客户端证书，用于 API 服务器身份验证
* Kubelet [服务端证书](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates)，
用于 API 服务器与 Kubelet 的会话
* API 服务器端点的证书
* 集群管理员的客户端证书，用于 API 服务器身份认证
* API 服务器的客户端证书，用于和 Kubelet 的会话
* API 服务器的客户端证书，用于和 etcd 的会话
* 控制器管理器的客户端证书/kubeconfig，用于和 API 服务器的会话
* 调度器的客户端证书/kubeconfig，用于和 API 服务器的会话
* [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 的客户端及服务端证书
<!--
`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/).
-->
{{< note >}}
只有当你运行 kube-proxy 并要支持
[扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)
时，才需要 `front-proxy` 证书
{{< /note >}}
<!--
etcd also implements mutual TLS to authenticate clients and peers.
-->
etcd 还实现了双向 TLS 来对客户端和对其他对等节点进行身份验证。
<!--
## Where certificates are stored
If you install Kubernetes with kubeadm, most certificates are stored in `/etc/kubernetes/pki`. All paths in this documentation are relative to that directory, with the exception of user account certificates which kubeadm places in `/etc/kubernetes`.
-->
## 证书存放的位置 {#where-certificates-are-stored}
假如通过 kubeadm 安装 Kubernetes，大多数证书都存储在 `/etc/kubernetes/pki`。
本文档中的所有路径都是相对于该目录的，但用户账户证书除外，kubeadm 将其放在 `/etc/kubernetes` 中。
<!--
## Configure certificates manually
If you don't want kubeadm to generate the required certificates, you can create them using a single root CA or by providing all certificates. See [Certificates](/docs/tasks/administer-cluster/certificates/) for details on creating your own certificate authority.
See [Certificate Management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) for more on managing certificates.
-->
## 手动配置证书 {#configure-certificates-manually}
如果你不想通过 kubeadm 生成这些必需的证书，你可以使用一个单一的根 CA
来创建这些证书或者直接提供所有证书。
参见[证书](/zh/docs/tasks/administer-cluster/certificates/)以进一步了解创建自己的证书机构。
关于管理证书的更多信息，请参见[使用 kubeadm 进行证书管理](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)。
<!--
### Single root CA
You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.
-->
### 单根 CA {#single-root-ca}
你可以创建一个单根 CA，由管理员控制器它。该根 CA 可以创建多个中间 CA，并将所有进一步的创建委托给 Kubernetes。
<!--
Required CAs:
| path | Default CN | description |
|------------------------|---------------------------|----------------------------------|
| ca.crt,key | kubernetes-ca | Kubernetes general CA |
| etcd/ca.crt,key | etcd-ca | For all etcd-related functions |
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) |
On top of the above CAs, it is also necessary to get a public/private key pair for service account management, `sa.key` and `sa.pub`.
-->
需要这些 CA：
| 路径 | 默认 CN | 描述 |
|------------------------|---------------------------|----------------------------------|
| ca.crt,key | kubernetes-ca | Kubernetes 通用 CA |
| etcd/ca.crt,key | etcd-ca | 与 etcd 相关的所有功能 |
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | 用于 [前端代理](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) |
上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 `sa.key` 和 `sa.pub`。
<!--
The following example illustrates the CA key and certificate files shown in the previous table:
-->
下面的例子说明了上表中所示的 CA 密钥和证书文件。
```console
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key
```
<!--
### All certificates
If you don't wish to copy the CA private keys to your cluster, you can generate all certificates yourself.
Required certificates:
-->
### 所有的证书 {#all-certificates}
如果你不想将 CA 的私钥拷贝至你的集群中，你也可以自己生成全部的证书。
需要这些证书：
<!--
| Default CN | Parent CA | O (in Subject) | kind | hosts (SAN) |
|-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------|
| kube-etcd | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
| kube-etcd-healthcheck-client | etcd-ca | | client | |
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |
| kube-apiserver | kubernetes-ca | | server | `<hostname>`, `<Host_IP>`, `<advertise_IP>`, `[1]` |
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
-->
| 默认 CN | 父级 CA | O (位于 Subject 中) | 类型 | 主机 (SAN) |
|-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------|
| kube-etcd | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
| kube-etcd-peer | etcd-ca | | server, client | `<hostname>`, `<Host_IP>`, `localhost`, `127.0.0.1` |
| kube-etcd-healthcheck-client | etcd-ca | | client | |
| kube-apiserver-etcd-client | etcd-ca | system:masters | client | |
| kube-apiserver | kubernetes-ca | | server | `<hostname>`, `<Host_IP>`, `<advertise_IP>`, `[1]` |
| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | |
| front-proxy-client | kubernetes-front-proxy-ca | | client | |
<!--
[1]: any other IP or DNS name you contact your cluster on (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)
the load balancer stable IP and/or DNS name, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`,
`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`)
where `kind` maps to one or more of the [x509 key usage](https://pkg.go.dev/k8s.io/api/certificates/v1beta1#KeyUsage) types:
-->
[1]: 用来连接到集群的不同 IP 或 DNS 名
（就像 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 为负载均衡所使用的固定
IP 或 DNS 名，`kubernetes`、`kubernetes.default`、`kubernetes.default.svc`、
`kubernetes.default.svc.cluster`、`kubernetes.default.svc.cluster.local`）。
其中，`kind` 对应一种或多种类型的 [x509 密钥用途](https://pkg.go.dev/k8s.io/api/certificates/v1beta1#KeyUsage)：
<!--
| kind | Key usage |
|--------|---------------------------------------------------------------------------------|
| server | digital signature, key encipherment, server auth |
| client | digital signature, key encipherment, client auth |
-->
| kind | 密钥用途 |
|--------|---------------------------------------------------------------------------------|
| server | 数字签名、密钥加密、服务端认证 |
| client | 数字签名、密钥加密、客户端认证 |
{{< note >}}
<!--
Hosts/SAN listed above are the recommended ones for getting a working cluster; if required by a specific setup, it is possible to add additional SANs on all the server certificates.
-->
上面列出的 Hosts/SAN 是推荐的配置方式；如果需要特殊安装，则可以在所有服务器证书上添加其他 SAN。
{{< /note >}}
{{< note >}}
<!--
For kubeadm users only:
* The scenario where you are copying to your cluster CA certificates without private keys is referred as external CA in the kubeadm documentation.
* If you are comparing the above list with a kubeadm generated PKI, please be aware that `kube-etcd`, `kube-etcd-peer` and `kube-etcd-healthcheck-client` certificates
are not generated in case of external etcd.
-->
对于 kubeadm 用户：
* 不使用私钥，将证书复制到集群 CA 的方案，在 kubeadm 文档中将这种方案称为外部 CA。
* 如果将以上列表与 kubeadm 生成的 PKI 进行比较，你会注意到，如果使用外部 etcd，则不会生成 `kube-etcd`、`kube-etcd-peer` 和 `kube-etcd-healthcheck-client` 证书。
{{< /note >}}
<!--
### Certificate paths
Certificates should be placed in a recommended path (as used by [kubeadm](/docs/reference/setup-tools/kubeadm/)).
Paths should be specified using the given argument regardless of location.
-->
### 证书路径 {#certificate-paths}
证书应放置在建议的路径中（以便 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/)
使用）。无论使用什么位置，都应使用给定的参数指定路径。
<!--
| Default CN | recommended key path | recommended cert path | command | key argument | cert argument |
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
| kube-apiserver-kubelet-client| apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file |
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
| etcd-ca | | etcd/ca.crt | etcdctl | | --cacert |
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
-->
| 默认 CN | 建议的密钥路径 | 建议的证书路径 | 命令 | 密钥参数 | 证书参数 |
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
| kube-apiserver-kubelet-client| apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file |
| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file |
| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file |
| etcd-ca | | etcd/ca.crt | etcdctl | | --cacert |
| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert |
<!--
Same considerations apply for the service account key pair:
-->
注意事项同样适用于服务帐户密钥对：
<!--
| private key path | public key path | command | argument |
|------------------------------|-----------------------------|-------------------------|--------------------------------------|
| sa.key | | kube-controller-manager | --service-account-private-key-file |
| | sa.pub | kube-apiserver | --service-account-key-file |
-->
| 私钥路径 | 公钥路径 | 命令 | 参数 |
|------------------------------|-----------------------------|-------------------------|--------------------------------------|
| sa.key | | kube-controller-manager | --service-account-private-key-file |
| | sa.pub | kube-apiserver | --service-account-key-file |
<!--
The following example illustrates the file paths [from the previous tables](/docs/setup/best-practices/certificates/#certificate-paths) you need to provide if you are generating all of your own keys and certificates:
-->
下面的例子展示了自行生成所有密钥和证书时所需要提供的文件路径。
这些路径基于[前面的表格](/zh/docs/setup/best-practices/certificates/#certificate-paths)。
```console
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub
```
<!--
## Configure certificates for user accounts
You must manually configure these administrator account and service accounts:
-->
## 为用户帐户配置证书 {#configure-certificates-for-user-accounts}
你必须手动配置以下管理员帐户和服务帐户：
<!--
| filename | credential name | Default CN | O (in Subject) |
|-------------------------|----------------------------|--------------------------------|----------------|
| admin.conf | default-admin | kubernetes-admin | system:masters |
| kubelet.conf | default-auth | system:node:`<nodeName>` (see note) | system:nodes |
| controller-manager.conf | default-controller-manager | system:kube-controller-manager | |
| scheduler.conf | default-scheduler | system:kube-scheduler | |
-->
| 文件名 | 凭据名称 | 默认 CN | O (位于 Subject 中) |
|-------------------------|----------------------------|--------------------------------|---------------------|
| admin.conf | default-admin | kubernetes-admin | system:masters |
| kubelet.conf | default-auth | system:node:`<nodeName>` （参阅注释） | system:nodes |
| controller-manager.conf | default-controller-manager | system:kube-controller-manager | |
| scheduler.conf | default-scheduler | system:kube-scheduler | |
<!--
The value of `<nodeName>` for `kubelet.conf` **must** match precisely the value of the node name provided by the kubelet as it registers with the apiserver. For further details, read the [Node Authorization](/docs/reference/access-authn-authz/node/).
-->
{{< note >}}
`kubelet.conf` 中 `<nodeName>` 的值 **必须** 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。
有关更多详细信息，请阅读[节点授权](/zh/docs/reference/access-authn-authz/node/)。
{{< /note >}}
<!--
1. For each config, generate an x509 cert/key pair with the given CN and O.
1. Run `kubectl` as follows for each config:
-->
1. 对于每个配置，请都使用给定的 CN 和 O 生成 x509 证书/密钥偶对。
1. 为每个配置运行下面的 `kubectl` 命令：
```shell
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system
```
<!--
These files are used as follows:
| filename | command | comment |
|-------------------------|-------------------------|-----------------------------------------------------------------------|
| admin.conf | kubectl | Configures administrator user for the cluster |
| kubelet.conf | kubelet | One required for each node in the cluster. |
| controller-manager.conf | kube-controller-manager | Must be added to manifest in `manifests/kube-controller-manager.yaml` |
| scheduler.conf | kube-scheduler | Must be added to manifest in `manifests/kube-scheduler.yaml` |
-->
这些文件用途如下：
| 文件名 | 命令 | 说明 |
|-------------------------|-------------------------|-----------------------------------------------------------------------|
| admin.conf | kubectl | 配置集群的管理员 |
| kubelet.conf | kubelet | 集群中的每个节点都需要一份 |
| controller-manager.conf | kube-controller-manager | 必需添加到 `manifests/kube-controller-manager.yaml` 清单中 |
| scheduler.conf | kube-scheduler | 必需添加到 `manifests/kube-scheduler.yaml` 清单中 |
<!--
The following files illustrate full paths to the files listed in the previous table:
-->
下面是前表中所列文件的完整路径。
```console
/etc/kubernetes/admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf
```
content/zh-cn/docs/setup/best-practices/cluster-large.md
+246
View File
@@ -0,0 +1,246 @@
---
title: 大规模集群的注意事项
weight: 20
---
<!--
reviewers:
- davidopp
- lavalamp
title: Considerations for large clusters
weight: 20
-->
<!--
A cluster is a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (physical
or virtual machines) running Kubernetes agents, managed by the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
Kubernetes {{< param "version" >}} supports clusters with up to 5000 nodes. More specifically,
Kubernetes is designed to accommodate configurations that meet *all* of the following criteria:
-->
集群是运行 Kubernetes 代理的、
由{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}管理的一组
{{< glossary_tooltip text="节点" term_id="node" >}}（物理机或虚拟机）。
Kubernetes {{< param "version" >}} 支持的最大节点数为 5000。
更具体地说，Kubernetes旨在适应满足以下*所有*标准的配置：
<!--
* No more than 110 pods per node
* No more than 5000 nodes
* No more than 150000 total pods
* No more than 300000 total containers
-->
* 每个节点的 Pod 数量不超过 110
* 节点数不超过 5000
* Pod 总数不超过 150000
* 容器总数不超过 300000
<!--
You can scale your cluster by adding or removing nodes. The way you do this depends
on how your cluster is deployed.
-->
你可以通过添加或删除节点来扩展集群。集群扩缩的方式取决于集群的部署方式。
<!--
## Cloud provider resource quotas {#quota-issues}
To avoid running into cloud provider quota issues, when creating a cluster with many nodes,
consider:
* Requesting a quota increase for cloud resources such as:
* Computer instances
* CPUs
* Storage volumes
* In-use IP addresses
* Packet filtering rule sets
* Number of load balancers
* Network subnets
* Log streams
* Gating the cluster scaling actions to brings up new nodes in batches, with a pause
between batches, because some cloud providers rate limit the creation of new instances.
-->
## 云供应商资源配额 {#quota-issues}
为避免遇到云供应商配额问题，在创建具有大规模节点的集群时，请考虑以下事项：
* 请求增加云资源的配额，例如：
* 计算实例
* CPUs
* 存储卷
* 使用中的 IP 地址
* 数据包过滤规则集
* 负载均衡数量
* 网络子网
* 日志流
* 由于某些云供应商限制了创建新实例的速度，因此通过分批启动新节点来控制集群扩展操作，并在各批之间有一个暂停。
<!--
## Control plane components
For a large cluster, you need a control plane with sufficient compute and other
resources.
Typically you would run one or two control plane instances per failure zone,
scaling those instances vertically first and then scaling horizontally after reaching
the point of falling returns to (vertical) scale.
-->
## 控制面组件
对于大型集群，你需要一个具有足够计算能力和其他资源的控制平面。
通常，你将在每个故障区域运行一个或两个控制平面实例，
先垂直缩放这些实例，然后在到达下降点（垂直）后再水平缩放。
<!--
You should run at least one instance per failure zone to provide fault-tolerance. Kubernetes
nodes do not automatically steer traffic towards control-plane endpoints that are in the
same failure zone; however, your cloud provider might have its own mechanisms to do this.
For example, using a managed load balancer, you configure the load balancer to send traffic
that originates from the kubelet and Pods in failure zone _A_, and direct that traffic only
to the control plane hosts that are also in zone _A_. If a single control-plane host or
endpoint failure zone _A_ goes offline, that means that all the control-plane traffic for
nodes in zone _A_ is now being sent between zones. Running multiple control plane hosts in
each zone makes that outcome less likely.
-->
你应该在每个故障区域至少应运行一个实例，以提供容错能力。
Kubernetes 节点不会自动将流量引向相同故障区域中的控制平面端点。
但是，你的云供应商可能有自己的机制来执行此操作。
例如，使用托管的负载均衡器时，你可以配置负载均衡器发送源自故障区域 _A_ 中的 kubelet 和 Pod 的流量，
并将该流量仅定向到也位于区域 _A_ 中的控制平面主机。
如果单个控制平面主机或端点故障区域 _A_ 脱机，则意味着区域 _A_ 中的节点的所有控制平面流量现在都在区域之间发送。
在每个区域中运行多个控制平面主机能降低出现这种结果的可能性。
<!--
### etcd storage
-->
### etcd 存储
<!--
To improve performance of large clusters, you can store Event objects in a separate
dedicated etcd instance.
-->
为了提高大规模集群的性能，你可以将事件对象存储在单独的专用 etcd 实例中。
<!--
When creating a cluster, you can (using custom tooling):
* start and configure additional etcd instance
* configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events
-->
在创建集群时，你可以（使用自定义工具）：
* 启动并配置额外的 etcd 实例
* 配置 {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}}，将它用于存储事件
<!--
See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) and
[Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
for details on configuring and managing etcd for a large cluster.
-->
有关为大型集群配置和管理 etcd 的详细信息，请参阅
[为 Kubernetes 运行 etcd 集群](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/)
和使用 [kubeadm 创建一个高可用 etcd 集群](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)。
<!--
### Addon Resources
-->
### 插件资源 {#addon-resources}
<!--
Kubernetes [resource limits](/docs/concepts/configuration/manage-resources-containers/)
help to minimize the impact of memory leaks and other ways that pods and containers can
impact on other components. These resource limits apply to
{{< glossary_tooltip text="addon" term_id="addons" >}} resources just as they apply to application workloads.
For example, you can set CPU and memory limits for a logging component:
-->
Kubernetes [资源限制](/zh/docs/concepts/configuration/manage-resources-containers/)
有助于最大程度地减少内存泄漏的影响以及 Pod 和容器可能对其他组件的其他方式的影响。
这些资源限制适用于{{< glossary_tooltip text="插件" term_id="addons" >}}资源，
就像它们适用于应用程序工作负载一样。
例如，你可以对日志组件设置 CPU 和内存限制
```yaml
...
containers:
- name: fluentd-cloud-logging
image: fluent/fluentd-kubernetes-daemonset:v1
resources:
limits:
cpu: 100m
memory: 200Mi
```
<!--
Addons' default limits are typically based on data collected from experience running
each addon on small or medium Kubernetes clusters. When running on large
clusters, addons often consume more of some resources than their default limits.
If a large cluster is deployed without adjusting these values, the addon(s)
may continuously get killed because they keep hitting the memory limit.
Alternatively, the addon may run but with poor performance due to CPU time
slice restrictions.
-->
插件的默认限制通常基于从中小规模 Kubernetes 集群上运行每个插件的经验收集的数据。
插件在大规模集群上运行时，某些资源消耗常常比其默认限制更多。
如果在不调整这些值的情况下部署了大规模集群，则插件可能会不断被杀死，因为它们不断达到内存限制。
或者，插件可能会运行，但由于 CPU 时间片的限制而导致性能不佳。
<!--
To avoid running into cluster addon resource issues, when creating a cluster with
many nodes, consider the following:
* Some addons scale vertically - there is one replica of the addon for the cluster
or serving a whole failure zone. For these addons, increase requests and limits
as you scale out your cluster.
* Many addons scale horizontally - you add capacity by running more pods - but with
a very large cluster you may also need to raise CPU or memory limits slightly.
The VerticalPodAutoscaler can run in _recommender_ mode to provide suggested
figures for requests and limits.
* Some addons run as one copy per node, controlled by a {{< glossary_tooltip text="DaemonSet"
term_id="daemonset" >}}: for example, a node-level log aggregator. Similar to
the case with horizontally-scaled addons, you may also need to raise CPU or memory
limits slightly.
-->
为避免遇到集群插件资源问题，在创建大规模集群时，请考虑以下事项：
* 部分垂直扩展插件 —— 总有一个插件副本服务于整个集群或服务于整个故障区域。
对于这些附加组件，请在扩大集群时加大资源请求和资源限制。
* 许多水平扩展插件 —— 你可以通过运行更多的 Pod 来增加容量——但是在大规模集群下，
可能还需要稍微提高 CPU 或内存限制。
VerticalPodAutoscaler 可以在 _recommender_ 模式下运行，
以提供有关请求和限制的建议数字。
* 一些插件在每个节点上运行一个副本，并由 DaemonSet 控制：
例如，节点级日志聚合器。与水平扩展插件的情况类似，
你可能还需要稍微提高 CPU 或内存限制。
<!--
## {{% heading "whatsnext" %}}
`VerticalPodAutoscaler` is a custom resource that you can deploy into your cluster
to help you manage resource requests and limits for pods.
Visit [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)
to learn more about `VerticalPodAutoscaler` and how you can use it to scale cluster
components, including cluster-critical addons.
The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
integrates with a number of cloud providers to help you run the right number of
nodes for the level of resource demand in your cluster.
-->
## {{% heading "whatsnext" %}}
`VerticalPodAutoscaler` 是一种自定义资源，你可以将其部署到集群中，帮助你管理资源请求和 Pod 的限制。
访问 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme)
以了解有关 `VerticalPodAutoscaler` 的更多信息，
以及如何使用它来扩展集群组件（包括对集群至关重要的插件）的信息。
[集群自动扩缩器](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
与许多云供应商集成在一起，帮助你在你的集群中，按照资源需求级别运行正确数量的节点。
<!--
The [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)
helps you in resizing the addons automatically as your cluster's scale changes.
-->
[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)
可帮助你在集群规模变化时自动调整插件的大小。
content/zh-cn/docs/setup/best-practices/enforcing-pod-security-standards.md
+154
View File
@@ -0,0 +1,154 @@
---
title: 强制实施 Pod 安全性标准
weight: 40
---
<!--
reviewers:
- tallclair
- liggitt
title: Enforcing Pod Security Standards
weight: 40
-->
<!-- overview -->
<!--
This page provides an overview of best practices when it comes to enforcing
[Pod Security Standards](/docs/concepts/security/pod-security-standards).
-->
本页提供实施 [Pod 安全标准（Pod Security Standards）](/zh/docs/concepts/security/pod-security-standards)
时的一些最佳实践。
<!-- body -->
<!--
## Using the built-in Pod Security Admission Controller
-->
## 使用内置的 Pod 安全性准入控制器
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
<!--
The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
intends to replace the deprecated PodSecurityPolicies.
-->
[Pod 安全性准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecurity)
尝试替换已被废弃的 PodSecurityPolicies。
<!--
### Configure all cluster namespaces
-->
### 配置所有集群名字空间 {#configure-all-cluster-namespaces}
<!--
Namespaces that lack any configuration at all should be considered significant gaps in your cluster
security model. We recommend taking the time to analyze the types of workloads occurring in each
namespace, and by referencing the Pod Security Standards, decide on an appropriate level for
each of them. Unlabeled namespaces should only indicate that they've yet to be evaluated.
-->
完全未经配置的名字空间应该被视为集群安全模型中的重大缺陷。
我们建议花一些时间来分析在每个名字空间中执行的负载的类型，
并通过引用 Pod 安全性标准来确定每个负载的合适级别。
未设置标签的名字空间应该视为尚未被评估。
<!--
In the scenario that all workloads in all namespaces have the same security requirements,
we provide an [example](/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)
that illustrates how the PodSecurity labels can be applied in bulk.
-->
针对所有名字空间中的所有负载都具有相同的安全性需求的场景，
我们提供了一个[示例](/zh/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)
用来展示如何批量应用 Pod 安全性标签。
<!--
### Embrace the principle of least privilege
In an ideal world, every pod in every namespace would meet the requirements of the `restricted`
policy. However, this is not possible nor practical, as some workloads will require elevated
privileges for legitimate reasons.
-->
### 拥抱最小特权原则
在一个理想环境中，每个名字空间中的每个 Pod 都会满足 `restricted` 策略的需求。
不过，这既不可能也不现实，某些负载会因为合理的原因而需要特权上的提升。
<!--
- Namespaces allowing `privileged` workloads should establish and enforce appropriate access controls.
- For workloads running in those permissive namespaces, maintain documentation about their unique
security requirements. If at all possible, consider how those requirements could be further
constrained.
-->
- 允许 `privileged` 负载的名字空间需要建立并实施适当的访问控制机制。
- 对于运行在特权宽松的名字空间中的负载，需要维护其独特安全性需求的文档。
如果可能的话，要考虑如何进一步约束这些需求。
<!--
### Adopt a multi-mode strategy
The `audit` and `warn` modes of the Pod Security Standards admission controller make it easy to
collect important security insights about your pods without breaking existing workloads.
-->
### 采用多种模式的策略
Pod 安全性标准准入控制器的 `audit` 和 `warn` 模式（mode）
能够在不影响现有负载的前提下，让该控制器更方便地收集关于 Pod 的重要的安全信息。
<!--
It is good practice to enable these modes for all namespaces, setting them to the _desired_ level
and version you would eventually like to `enforce`. The warnings and audit annotations generated in
this phase can guide you toward that state. If you expect workload authors to make changes to fit
within the desired level, enable the `warn` mode. If you expect to use audit logs to monitor/drive
changes to fit within the desired level, enable the `audit` mode.
-->
针对所有名字空间启用这些模式是一种好的实践，将它们设置为你最终打算 `enforce` 的
_期望的_ 级别和版本。这一阶段中所生成的警告和审计注解信息可以帮助你到达这一状态。
如果你期望负载的作者能够作出变更以便适应期望的级别，可以启用 `warn` 模式。
如果你希望使用审计日志了监控和驱动变更，以便负载能够适应期望的级别，可以启用 `audit` 模式。
<!--
When you have the `enforce` mode set to your desired value, these modes can still be useful in a
few different ways:
- By setting `warn` to the same level as `enforce`, clients will receive warnings when attempting
to create Pods (or resources that have Pod templates) that do not pass validation. This will help
them update those resources to become compliant.
- In Namespaces that pin `enforce` to a specific non-latest version, setting the `audit` and `warn`
modes to the same level as `enforce`, but to the `latest` version, gives visibility into settings
that were allowed by previous versions but are not allowed per current best practices.
-->
当你将 `enforce` 模式设置为期望的取值时，这些模式在不同的场合下仍然是有用的：
- 通过将 `warn` 设置为 `enforce` 相同的级别，客户可以在尝试创建无法通过合法检查的 Pod
（或者包含 Pod 模板的资源）时收到警告信息。这些信息会帮助于更新资源使其合规。
- 在将 `enforce` 锁定到特定的非最新版本的名字空间中，将 `audit` 和 `warn`
模式设置为 `enforce` 一样的级别而非 `latest` 版本，
这样可以方便看到之前版本所允许但当前最佳实践中被禁止的设置。
<!--
## Third-party alternatives
-->
## 第三方替代方案 {#third-party-alternatives}
{{% thirdparty-content %}}
<!--
Other alternatives for enforcing security profiles are being developed in the Kubernetes
ecosystem:
-->
Kubernetes 生态系统中也有一些其他强制实施安全设置的替代方案处于开发状态中：
- [Kubewarden](https://github.com/kubewarden).
- [Kyverno](https://kyverno.io/policies/).
- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
<!--
The decision to go with a _built-in_ solution (e.g. PodSecurity admission controller) versus a
third-party tool is entirely dependent on your own situation. When evaluating any solution,
trust of your supply chain is crucial. Ultimately, using _any_ of the aforementioned approaches
will be better than doing nothing.
-->
采用 _内置的_ 方案（例如 PodSecurity 准入控制器）还是第三方工具，
这一决策完全取决于你自己的情况。在评估任何解决方案时，对供应链的信任都是至关重要的。
最终，使用前述方案中的 _任何_ 一种都好过放任自流。
content/zh-cn/docs/setup/best-practices/multiple-zones.md
+282
View File
@@ -0,0 +1,282 @@
---
title: 运行于多可用区环境
weight: 10
content_type: concept
---
<!--
reviewers:
- jlowdermilk
- justinsb
- quinton-hoole
title: Running in multiple zones
weight: 10
content_type: concept
-->
<!-- overview -->
<!--
This page describes running a cluster across multiple zones.
-->
本页描述如何跨多个区（Zone）中运行集群。
<!-- body -->
<!--
## Background
Kubernetes is designed so that a single Kubernetes cluster can run
across multiple failure zones, typically where these zones fit within
a logical grouping called a _region_. Major cloud providers define a region
as a set of failure zones (also called _availability zones_) that provide
a consistent set of features: within a region, each zone offers the same
APIs and services.
Typical cloud architectures aim to minimize the chance that a failure in
one zone also impairs services in another zone.
-->
## 背景
Kubernetes 从设计上允许同一个 Kubernetes 集群跨多个失效区来运行，
通常这些区位于某个称作 _区域（region）_ 逻辑分组中。
主要的云提供商都将区域定义为一组失效区的集合（也称作 _可用区（Availability Zones）_），
能够提供一组一致的功能特性：每个区域内，各个可用区提供相同的 API 和服务。
典型的云体系结构都会尝试降低某个区中的失效影响到其他区中服务的概率。
<!--
## Control plane behavior
All [control plane components](/docs/concepts/overview/components/#control-plane-components)
support running as a pool of interchangeable resources, replicated per
component.
-->
## 控制面行为 {#control-plane-behavior}
所有的[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)
都支持以一组可相互替换的资源池的形式来运行，每个组件都有多个副本。
<!--
When you deploy a cluster control plane, place replicas of
control plane components across multiple failure zones. If availability is
an important concern, select at least three failure zones and replicate
each individual control plane component (API server, scheduler, etcd,
cluster controller manager) across at least three failure zones.
If you are running a cloud controller manager then you should
also replicate this across all the failure zones you selected.
-->
当你部署集群控制面时，应将控制面组件的副本跨多个失效区来部署。
如果可用性是一个很重要的指标，应该选择至少三个失效区，并将每个
控制面组件（API 服务器、调度器、etcd、控制器管理器）复制多个副本，
跨至少三个失效区来部署。如果你在运行云控制器管理器，则也应该将
该组件跨所选的三个失效区来部署。
{{< note >}}
<!--
Kubernetes does not provide cross-zone resilience for the API server
endpoints. You can use various techniques to improve availability for
the cluster API server, including DNS round-robin, SRV records, or
a third-party load balancing solution with health checking.
-->
Kubernetes 并不会为 API 服务器端点提供跨失效区的弹性。
你可以为集群 API 服务器使用多种技术来提升其可用性，包括使用
DNS 轮转、SRV 记录或者带健康检查的第三方负载均衡解决方案等等。
{{< /note >}}
<!--
## Node behavior
Kubernetes automatically spreads the Pods for
workload resources (such as {{< glossary_tooltip text="Deployment" term_id="deployment" >}}
or {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}})
across different nodes in a cluster. This spreading helps
reduce the impact of failures.
-->
## 节点行为 {#node-behavior}
Kubernetes 自动为负载资源（如{{< glossary_tooltip text="Deployment" term_id="deployment" >}}
或 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}})）
跨集群中不同节点来部署其 Pods。
这种分布逻辑有助于降低失效带来的影响。
<!--
When nodes start up, the kubelet on each node automatically adds
{{< glossary_tooltip text="labels" term_id="label" >}} to the Node object
that represents that specific kubelet in the Kubernetes API.
These labels can include
[zone information](/docs/reference/labels-annotations-taints/#topologykubernetesiozone).
-->
节点启动时，每个节点上的 kubelet 会向 Kubernetes API 中代表该 kubelet 的 Node 对象
添加 {{< glossary_tooltip text="标签" term_id="label" >}}。
这些标签可能包含[区信息](/zh/docs/reference/labels-annotations-taints/#topologykubernetesiozone)。
<!--
If your cluster spans multiple zones or regions, you can use node labels
in conjunction with
[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
to control how Pods are spread across your cluster among fault domains:
regions, zones, and even specific nodes.
These hints enable the
{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} to place
Pods for better expected availability, reducing the risk that a correlated
failure affects your whole workload.
-->
如果你的集群跨了多个可用区或者地理区域，你可以使用节点标签，结合
[Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
来控制如何在你的集群中多个失效域之间分布 Pods。这里的失效域可以是
地理区域、可用区甚至是特定节点。
这些提示信息使得{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}
能够更好地分布 Pods，以实现更好的可用性，降低因为某种失效给整个工作负载
带来的风险。
<!--
For example, you can set a constraint to make sure that the
3 replicas of a StatefulSet are all running in different zones to each
other, whenever that is feasible. You can define this declaratively
without explicitly defining which availability zones are in use for
each workload.
-->
例如，你可以设置一种约束，确保某个 StatefulSet 中的三个副本都运行在
不同的可用区中，只要其他条件允许。你可以通过声明的方式来定义这种约束，
而不需要显式指定每个工作负载使用哪些可用区。
<!--
### Distributing nodes across zones
Kubernetes' core does not create nodes for you; you need to do that yourself,
or use a tool such as the [Cluster API](https://cluster-api.sigs.k8s.io/) to
manage nodes on your behalf.
Using tools such as the Cluster API you can define sets of machines to run as
worker nodes for your cluster across multiple failure domains, and rules to
automatically heal the cluster in case of whole-zone service disruption.
-->
### 跨多个区分布节点 {#distributing-nodes-across-zones}
Kubernetes 的核心逻辑并不会帮你创建节点，你需要自行完成此操作，或者使用
类似 [Cluster API](https://cluster-api.sigs.k8s.io/) 这类工具来替你管理节点。
<!--
Using tools such as the Cluster API you can define sets of machines to run as
worker nodes for your cluster across multiple failure domains, and rules to
automatically heal the cluster in case of whole-zone service disruption.
-->
使用类似 Cluster API 这类工具，你可以跨多个失效域来定义一组用做你的集群
工作节点的机器，以及当整个区的服务出现中断时如何自动治愈集群的策略。
<!--
## Manual zone assignment for Pods
You can apply [node selector constraints](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
to Pods that you create, as well as to Pod templates in workload resources
such as Deployment, StatefulSet, or Job.
-->
## 为 Pods 手动指定区
<!--
You can apply [node selector constraints](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
to Pods that you create, as well as to Pod templates in workload resources
such as Deployment, StatefulSet, or Job.
-->
你可以应用[节点选择算符约束](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
到你所创建的 Pods 上，或者为 Deployment、StatefulSet 或 Job 这类工作负载资源
中的 Pod 模板设置此类约束。
<!--
## Storage access for zones
When persistent volumes are created, the `PersistentVolumeLabel`
[admission controller](/docs/reference/access-authn-authz/admission-controllers/)
automatically adds zone labels to any PersistentVolumes that are linked to a specific
zone. The {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} then ensures,
through its `NoVolumeZoneConflict` predicate, that pods which claim a given PersistentVolume
are only placed into the same zone as that volume.
-->
## 跨区的存储访问
当创建持久卷时，`PersistentVolumeLabel`
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
会自动向那些链接到特定区的 PersistentVolume 添加区标签。
{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}通过其
`NoVolumeZoneConflict` 断言确保申领给定 PersistentVolume 的 Pods 只会
被调度到该卷所在的可用区。
<!--
You can specify a {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
for PersistentVolumeClaims that specifies the failure domains (zones) that the
storage in that class may use.
To learn about configuring a StorageClass that is aware of failure domains or zones,
see [Allowed topologies](/docs/concepts/storage/storage-classes/#allowed-topologies).
-->
你可以为 PersistentVolumeClaim 指定{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
以设置该类中的存储可以使用的失效域（区）。
要了解如何配置能够感知失效域或区的 StorageClass，请参阅
[可用的拓扑逻辑](/zh/docs/concepts/storage/storage-classes/#allowed-topologies)。
<!--
## Networking
By itself, Kubernetes does not include zone-aware networking. You can use a
[network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
to configure cluster networking, and that network solution might have zone-specific
elements. For example, if your cloud provider supports Services with
`type=LoadBalancer`, the load balancer might only send traffic to Pods running in the
same zone as the load balancer element processing a given connection.
Check your cloud provider's documentation for details.
-->
## 网络 {#networking}
Kubernetes 自身不提供与可用区相关的联网配置。
你可以使用[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
来配置集群的联网，该网络解决方案可能拥有一些与可用区相关的元素。
例如，如果你的云提供商支持 `type=LoadBalancer` 的 Service，则负载均衡器
可能仅会将请求流量发送到运行在负责处理给定连接的负载均衡器组件所在的区。
请查阅云提供商的文档了解详细信息。
<!--
For custom or on-premises deployments, similar considerations apply.
{{< glossary_tooltip text="Service" term_id="service" >}} and
{{< glossary_tooltip text="Ingress" term_id="ingress" >}} behavior, including handling
of different failure zones, does vary depending on exactly how your cluster is set up.
-->
对于自定义的或本地集群部署，也可以考虑这些因素
{{< glossary_tooltip text="Service" term_id="service" >}}
{{< glossary_tooltip text="Ingress" term_id="ingress" >}} 的行为，
包括处理不同失效区的方法，在很大程度上取决于你的集群是如何搭建的。
<!--
## Fault recovery
When you set up your cluster, you might also need to consider whether and how
your setup can restore service if all the failure zones in a region go
off-line at the same time. For example, do you rely on there being at least
one node able to run Pods in a zone?
Make sure that any cluster-critical repair work does not rely
on there being at least one healthy node in your cluster. For example: if all nodes
are unhealthy, you might need to run a repair Job with a special
{{< glossary_tooltip text="toleration" term_id="toleration" >}} so that the repair
can complete enough to bring at least one node into service.
Kubernetes doesn't come with an answer for this challenge; however, it's
something to consider.
-->
## 失效恢复 {#fault-recovery}
在搭建集群时，你可能需要考虑当某区域中的所有失效区都同时掉线时，是否以及如何
恢复服务。例如，你是否要求在某个区中至少有一个节点能够运行 Pod？
请确保任何对集群很关键的修复工作都不要指望集群中至少有一个健康节点。
例如：当所有节点都不健康时，你可能需要运行某个修复性的 Job，
该 Job 要设置特定的{{< glossary_tooltip text="容忍度" term_id="toleration" >}}
以便修复操作能够至少将一个节点恢复为可用状态。
Kubernetes 对这类问题没有现成的解决方案；不过这也是要考虑的因素之一。
## {{% heading "whatsnext" %}}
<!--
To learn how the scheduler places Pods in a cluster, honoring the configured constraints,
visit [Scheduling and Eviction](/docs/concepts/scheduling-eviction/).
-->
要了解调度器如何在集群中放置 Pods 并遵从所配置的约束，可参阅
[调度与驱逐](/zh/docs/concepts/scheduling-eviction/)。
content/zh-cn/docs/setup/best-practices/node-conformance.md
+193
View File
@@ -0,0 +1,193 @@
---
title: 校验节点设置
weight: 30
---
<!--
reviewers:
- Random-Liu
title: Validate node setup
weight: 30
-->
{{< toc >}}
<!--
## Node Conformance Test
-->
## 节点一致性测试 {#node-conformance-test}
<!--
*Node conformance test* is a containerized test framework that provides a system
verification and functionality test for a node. The test validates whether the
node meets the minimum requirements for Kubernetes; a node that passes the test
is qualified to join a Kubernetes cluster.
-->
**节点一致性测试** 是一个容器化的测试框架，提供了针对节点的系统验证和功能测试。
测试验证节点是否满足 Kubernetes 的最低要求；通过测试的节点有资格加入 Kubernetes 集群。
<!--
The test validates whether the node meets the minimum requirements for Kubernetes; a node that passes the testis qualified to join a Kubernetes cluster.
-->
该测试主要检测节点是否满足 Kubernetes 的最低要求，通过检测的节点有资格加入 Kubernetes 集群。
<!--
## Node Prerequisite
-->
## 节点的前提条件 {#node-prerequisite}
<!--
To run node conformance test, a node must satisfy the same prerequisites as a
standard Kubernetes node. At a minimum, the node should have the following
daemons installed:
-->
要运行节点一致性测试，节点必须满足与标准 Kubernetes 节点相同的前提条件。节点至少应安装以下守护程序：
<!--
* Container Runtime (Docker)
* Kubelet
-->
* 容器运行时 (Docker)
* Kubelet
<!--
## Running Node Conformance Test
-->
## 运行节点一致性测试 {#running-node-conformance-test}
<!--
To run the node conformance test, perform the following steps:
-->
要运行节点一致性测试，请执行以下步骤：
<!--
1. Work out the value of the `--kubeconfig` option for the kubelet; for example:
`--kubeconfig=/var/lib/kubelet/config.yaml`.
Because the test framework starts a local control plane to test the kubelet,
use `http://localhost:8080` as the URL of the API server.
There are some other kubelet command line parameters you may want to use:
* `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
remove the flag to run the test.
-->
1. 得出 kubelet 的 `--kubeconfig` 的值；例如：`--kubeconfig=/var/lib/kubelet/config.yaml`。
由于测试框架启动了本地控制平面来测试 kubelet，因此使用 `http://localhost:8080`
作为API 服务器的 URL。
一些其他的 kubelet 命令行参数可能会被用到：
* `--cloud-provider`：如果使用 `--cloud-provider=gce`，需要移除这个参数来运行测试。
<!--
2. Run the node conformance test with command:
```shell
# $CONFIG_DIR is the pod manifest path of your Kubelet.
# $LOG_DIR is the test output path.
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
k8s.gcr.io/node-test:0.2
```
-->
2. 使用以下命令运行节点一致性测试：
```shell
# $CONFIG_DIR 是你 Kubelet 的 pod manifest 路径。
# $LOG_DIR 是测试的输出路径。
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
k8s.gcr.io/node-test:0.2
```
<!--
## Running Node Conformance Test for Other Architectures
-->
## 针对其他硬件体系结构运行节点一致性测试 {#running-node-conformance-test-for-other-architectures}
<!--
Kubernetes also provides node conformance test docker images for other
architectures:
-->
Kubernetes 也为其他硬件体系结构的系统提供了节点一致性测试的 Docker 镜像：
<!--
Arch | Image |
--------|:-----------------:|
amd64 | node-test-amd64 |
arm | node-test-arm |
arm64 | node-test-arm64 |
-->
架构 | 镜像 |
--------|:-----------------:|
amd64 | node-test-amd64 |
arm | node-test-arm |
arm64 | node-test-arm64 |
<!--
## Running Selected Test
-->
## 运行特定的测试 {#running-selected-test}
<!--
To run specific tests, overwrite the environment variable `FOCUS` with the
regular expression of tests you want to run.
-->
要运行特定测试，请使用你希望运行的测试的特定表达式覆盖环境变量 `FOCUS`。
```shell
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e FOCUS=MirrorPod \ # Only run MirrorPod test
k8s.gcr.io/node-test:0.2
```
<!--
To skip specific tests, overwrite the environment variable `SKIP` with the
regular expression of tests you want to skip.
-->
要跳过特定的测试，请使用你希望跳过的测试的常规表达式覆盖环境变量 `SKIP`。
<!--
```shell
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test
k8s.gcr.io/node-test:0.2
```
-->
```shell
sudo docker run -it --rm --privileged --net=host \
-v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
-e SKIP=MirrorPod \ # 运行除 MirrorPod 测试外的所有一致性测试内容
k8s.gcr.io/node-test:0.2
```
<!--
Node conformance test is a containerized version of [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md).
-->
节点一致性测试是[节点端到端测试](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md)的容器化版本。
<!--
By default, it runs all conformance tests.
-->
默认情况下，它会运行所有一致性测试。
<!--
Theoretically, you can run any node e2e test if you configure the container and
mount required volumes properly. But **it is strongly recommended to only run conformance
test**, because it requires much more complex configuration to run non-conformance test.
-->
理论上，只要合理地配置容器和挂载所需的卷，就可以运行任何的节点端到端测试用例。但是这里**强烈建议只运行一致性测试**，因为运行非一致性测试需要很多复杂的配置。
<!--
## Caveats
-->
## 注意事项 {#caveats}
<!--
* The test leaves some docker images on the node, including the node conformance
test image and images of containers used in the functionality
test.
* The test leaves dead containers on the node. These containers are created
during the functionality test.
-->
* 测试会在节点上遗留一些 Docker 镜像，包括节点一致性测试本身的镜像和功能测试相关的镜像。
* 测试会在节点上遗留一些死的容器。这些容器是在功能测试的过程中创建的。