kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #44399 from my-git9/kubeadm-init-429 

[zh-cn]sync kubeadm-init api-concepts
This commit is contained in:
Kubernetes Prow Robot 2023-12-21 08:29:50 +01:00 committed by GitHub
parent 50629368f8 531503195c
commit 6c441f0e80
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 55 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
content/zh-cn/docs/reference/setup-tools/kubeadm/kubeadm-init.md
View File

@ -56,14 +56,14 @@ following steps:
APIServer 证书将为任何 `--apiserver-cert-extra-sans` 参数值提供附加的 SAN 条目，必要时将其小写。
<!--
1. Writes kubeconfig files in `/etc/kubernetes/` for
the kubelet, the controller-manager and the scheduler to use to connect to the
API server, each with its own identity, as well as an additional
kubeconfig file for administration named `admin.conf`.
1. Writes kubeconfig files in `/etc/kubernetes/` for the kubelet, the controller-manager and the
scheduler to use to connect to the API server, each with its own identity. Also
additional kubeconfig files are written, for kubeadm as administrative entity (`admin.conf`)
and for a super admin user that can bypass RBAC (`super-admin.conf`).
-->
3. 将 kubeconfig 文件写入 `/etc/kubernetes/` 目录以便 kubelet、控制器管理器和调度器用来连接到
API 服务器，它们每一个都有自己的身份标识，同时生成一个名为 `admin.conf` 的独立的 kubeconfig
文件，用于管理操作。
API 服务器，它们每一个都有自己的身份标识。再编写额外的 kubeconfig 文件，将 kubeadm
作为管理实体（`admin.conf`）和可以绕过 RBAC 的超级管理员用户（`super-admin.conf`）。
<!--
1. Generates static Pod manifests for the API server,
@ -303,17 +303,17 @@ List of feature gates:
{{< table caption="kubeadm feature gates" >}}
Feature | Default | Alpha | Beta | GA
:-------|:--------|:------|:-----|:----
`EtcdLearnerMode` | `true` | 1.27 | 1.29 | -
`PublicKeysECDSA` | `false` | 1.19 | - | -
`RootlessControlPlane` | `false` | 1.22 | - | -
`EtcdLearnerMode` | `false` | 1.27 | - | -
{{< /table >}}
-->
{{< table caption="kubeadm 特性门控" >}}
特性 | 默认值 | Alpha | Beta | GA
:-------|:--------|:------|:-----|:----
`EtcdLearnerMode` | `true` | 1.27 | 1.29 | -
`PublicKeysECDSA` | `false` | 1.19 | - | -
`RootlessControlPlane` | `false` | 1.22 | - | -
`EtcdLearnerMode` | `false` | 1.27 | - | -
{{< /table >}}
{{< note >}}
@ -328,6 +328,15 @@ Feature gate descriptions:
-->
特性门控的描述：
<!--
`EtcdLearnerMode`
: With this feature gate enabled, when joining a new control plane node, a new etcd member will be created
as a learner and promoted to a voting member only after the etcd data are fully aligned.
-->
`EtcdLearnerMode`
: 启用此特性门控后，当加入新的控制平面节点时，将创建一个新的 etcd
成员作为学习者（learner），并仅在 etcd 数据完全对齐后进级为投票成员（voting member）。
<!--
`PublicKeysECDSA`
: Can be used to create a cluster that uses ECDSA certificates instead of the default RSA algorithm.
@ -352,15 +361,6 @@ you upgrade to a newer version of Kubernetes.
以非 root 用户身份运行。如果未设置该标志，则这些组件以 root 身份运行。
你可以在升级到更新版本的 Kubernetes 之前更改此特性门控的值。
<!--
`EtcdLearnerMode`
: With this feature gate enabled, when joining a new control plane node, a new etcd member will be created
as a learner and promoted to a voting member only after the etcd data are fully aligned.
-->
`EtcdLearnerMode`
: 启用此特性门控后，当加入新的控制平面节点时，将创建一个新的 etcd
成员作为学习者（learner），并仅在 etcd 数据完全对齐后进级为投票成员（voting member）。
<!--
List of deprecated feature gates:
-->
@ -368,13 +368,13 @@ List of deprecated feature gates:
<!--
{{< table caption="kubeadm deprecated feature gates" >}}
Feature | Default
Feature | Default
:-------|:--------
`UpgradeAddonsBeforeControlPlane` | `false`
{{< /table >}}
-->
{{< table caption="kubeadm 弃用的特性门控" >}}
特性 | 默认值
特性 | 默认值
:-------|:--------
`UpgradeAddonsBeforeControlPlane` | `false`
{{< /table >}}
@ -429,17 +429,31 @@ List of removed feature gates:
{{< table caption="kubeadm removed feature gates" >}}
Feature | Alpha | Beta | GA | Removed
:-------|:------|:-----|:---|:-------
`UnversionedKubeletConfigMap` | 1.22 | 1.23 | 1.25 | 1.26
`IPv6DualStack` | 1.16 | 1.21 | 1.23 | 1.24
`UnversionedKubeletConfigMap` | 1.22 | 1.23 | 1.25 | 1.26
{{< /table >}}
-->
{{< table caption="kubeadm 已移除的特性门控" >}}
特性 | Alpha | Beta | GA | 移除
:-------|:------|:-----|:---|:-------
`UnversionedKubeletConfigMap` | 1.22 | 1.23 | 1.25 | 1.26
`IPv6DualStack` | 1.16 | 1.21 | 1.23 | 1.24
`UnversionedKubeletConfigMap` | 1.22 | 1.23 | 1.25 | 1.26
{{< /table >}}
<!--
Feature gate descriptions:
-->
特性门控的描述：
<!--
`IPv6DualStack`
: This flag helps to configure components dual stack when the feature is in progress. For more details on Kubernetes
dual-stack support see [Dual-stack support with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/).
-->
`IPv6DualStack`
: 在 IP 双栈特性处于开发过程中时，此标志有助于配置组件的双栈支持。有关 Kubernetes
双栈支持的更多详细信息，请参阅 [kubeadm 的双栈支持](/zh-cn/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)。
<!--
`UnversionedKubeletConfigMap`
: This flag controls the name of the {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} where kubeadm stores
@ -463,15 +477,6 @@ if that does not succeed, kubeadm falls back to using the legacy (versioned) nam
kubeadm 尝试首先使用无版本（后缀）的 ConfigMap 名称；
如果不成功，kubeadm 将回退到使用该 ConfigMap 的旧（带版本号的）名称。
<!--
`IPv6DualStack`
: This flag helps to configure components dual stack when the feature is in progress. For more details on Kubernetes
dual-stack support see [Dual-stack support with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/).
-->
`IPv6DualStack`
: 当前此特性正在推进时，此标志有助于配置组件的 IP 双栈。有关 Kubernetes
双栈支持的更多详细信息，请参阅 [kubeadm 的双栈支持](/zh-cn/docs/setup/production-environment/tools/kubeadm/dual-stack-support/)。
<!--
### Adding kube-proxy parameters {#kube-proxy}
@ -771,12 +776,16 @@ DNS name or an address of a load balancer.
```
<!--
Once the cluster is up, you can grab the admin credentials from the control-plane node
at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
Once the cluster is up, you can use the `/etc/kubernetes/admin.conf` file from
a control-plane node to talk to the cluster with administrator credentials or
[Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users).
-->
一旦集群启动起来，你就可以从控制平面节点的 `/etc/kubernetes/admin.conf` 文件获取管理凭证，
并使用这个凭证同集群通信。
一旦集群启动起来，你就可以从控制平面节点中的 `/etc/kubernetes/admin.conf`
文件获取管理凭证或通过[为其他用户生成的 kubeconfig 文件](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users)与集群通信。
<!--
Note that this style of bootstrap has some relaxed security guarantees because
it does not allow the root CA hash to be validated with

29
content/zh-cn/docs/reference/using-api/api-concepts.md
View File

@ -289,7 +289,7 @@ For example:
_test_ namespace. Each change notification is a JSON document. The HTTP response body
(served as `application/json`) consists a series of JSON documents.
-->
2. 从资源版本 10245 开始，接收影响 _test_ 名字空间中 Pod 的所有 API 操作
2. 从资源版本 10245 开始，接收影响 **test** 名字空间中 Pod 的所有 API 操作
（例如 **create**、**delete**、**patch** 或 **update**）的通知。
每个更改通知都是一个 JSON 文档。
HTTP 响应正文（用作 `application/json`）由一系列 JSON 文档组成。
@ -443,7 +443,7 @@ _consistent read_ by setting empty resource version using `resourceVersion=`) co
in the following sequence of events:
-->
举个例子：你想监视一组 Pod。对于该集合，当前资源版本为 10245，并且有两个 Pod：`foo` 和 `bar`。
接下来你发送了以下请求（通过使用 `resourceVersion=` 设置空的资源版本来明确请求 **一致性读**），
接下来你发送了以下请求（通过使用 `resourceVersion=` 设置空的资源版本来明确请求**一致性读**），
这样做的结果是可能收到如下事件序列：
```
@ -524,7 +524,7 @@ The `content-encoding` header indicates that the response is compressed with `gz
-->
## 分块检视大体量结果 {#retrieving-large-results-sets-in-chunks}
{{< feature-state for_k8s_version="v1.9" state="beta" >}}
{{< feature-state for_k8s_version="v1.29" state="stable" >}}
<!--
On large clusters, retrieving the collection of some resource types may result in
@ -538,15 +538,14 @@ response (10-20MB) and consume a large amount of server resources.
跨所有名字空间检索所有 Pod 可能会导致非常大的响应 (10-20MB) 并消耗大量服务器资源。
<!--
Provided that you don't explicitly disable the `APIListChunking`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), the
Kubernetes API server supports the ability to break a single large collection request
The Kubernetes API server supports the ability to break a single large collection request
into many smaller chunks while preserving the consistency of the total request. Each
chunk can be returned sequentially which reduces both the total size of the request and
allows user-oriented clients to display results incrementally to improve responsiveness.
-->
如果你没有明确禁用 `APIListChunking` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
Kubernetes API 服务器支持将单个大型集合请求分解为许多较小块的能力，同时保持总请求的一致性。
Kubernetes API 服务器支持将单个大型集合请求分解为许多较小块的能力，
同时保持总体请求的一致性。每个块都可以按顺序返回，这既减少了请求的总大小，
又允许面向用户的客户端增量显示结果以提高响应能力。
<!--
You can request that the API server handles a **list** by serving single collection
@ -572,7 +571,7 @@ continuing until the server returns an empty `continue` value, you can retrieve
entire collection.
-->
作为 API 客户端，你可以在下一次请求时将 `continue` 值传递给 API 服务器，
以指示服务器返回下一页（_块_）结果。继续下去直到服务器返回一个空的 `continue` 值，
以指示服务器返回下一页（**块**）结果。继续下去直到服务器返回一个空的 `continue` 值，
你可以检索整个集合。
<!--
@ -1128,14 +1127,14 @@ When you **delete** a resource this takes place in two phases.
"kind": "ConfigMap",
"apiVersion": "v1",
"metadata": {
"finalizers": {"url.io/neat-finalization", "other-url.io/my-finalizer"},
"finalizers": ["url.io/neat-finalization", "other-url.io/my-finalizer"],
"deletionTimestamp": nil,
}
}
```
<!--
When a client first sends a **delete** to request removal of a resource, the `.metadata.deletionTimestamp` is set to the current time.
When a client first sends a **delete** to request the removal of a resource, the `.metadata.deletionTimestamp` is set to the current time.
Once the `.metadata.deletionTimestamp` is set, external controllers that act on finalizers
may start performing their cleanup work at any time, in any order.
@ -1157,7 +1156,7 @@ Once the last finalizer is removed, the resource is actually removed from etcd.
一旦设置了 `.metadata.deletionTimestamp`，
作用于终结器的外部控制器可以在任何时间以任何顺序开始执行它们的清理工作。
终结器之间 **不存在** 强制的执行顺序，因为这会带来卡住 `.metadata.finalizers` 的重大风险。
终结器之间**不存在**强制的执行顺序，因为这会带来卡住 `.metadata.finalizers` 的重大风险。
`.metadata.finalizers` 字段是共享的：任何有权限的参与者都可以重新排序。
如果终结器列表是按顺序处理的，那么这可能会导致这样一种情况：
@ -1220,7 +1219,7 @@ By default, the API server drops fields that it does not recognize
from an input that it receives (for example, the JSON body of a `PUT` request).
-->
默认情况下，如果接收到的输入信息中含有 API 服务器无法识别的字段，API 服务器会丢弃该字段
（例如： `PUT` 请求中的 JSON 主体）。
（例如：`PUT` 请求中的 JSON 主体）。
<!--
There are two situations where the API server drops fields that you supplied in
@ -1658,7 +1657,7 @@ but has drawbacks:
#### HTTP PUT 替换现有资源 {#update-mechanism-update}
**update** (HTTP `PUT`) 操作实现简单且灵活，但也存在一些缺点：
**update**（HTTP `PUT`）操作实现简单且灵活，但也存在一些缺点：
<!--
* You need to handle conflicts where the `resourceVersion` of the object changes
@ -1999,7 +1998,7 @@ Continue Token, Exact
从 token 开始、精确匹配
: 返回初始分页 **list** 调用的资源版本的数据。
返回的 _Continue 令牌_ 负责跟踪最初提供的资源版本，最初提供的资源版本用于在初始分页 **list** 之后的所有分页 **list** 中。
返回的 **Continue 令牌**负责跟踪最初提供的资源版本，最初提供的资源版本用于在初始分页 **list** 之后的所有分页 **list** 中。
{{< note >}}