Skip to content

Commit 5c2eb69

Browse files
authored
Merge pull request #34249 from tengqm/zh-34221-concepts-4
[zh] Resync some concepts pages (concepts-4)
2 parents c6acdf1 + 91f4680 commit 5c2eb69

File tree

10 files changed

+262
-285
lines changed

10 files changed

+262
-285
lines changed

content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md

Lines changed: 66 additions & 55 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,11 @@ Kubernetes {{< skew currentVersion >}} 支持[容器网络接口](https://github
2020
你必须使用和你的集群相兼容并且满足你的需求的 CNI 插件。
2121
在更广泛的 Kubernetes 生态系统中你可以使用不同的插件(开源和闭源)。
2222

23+
<!--
24+
A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model).
25+
-->
26+
要实现 [Kubernetes 网络模型](/zh-cn/docs/concepts/services-networking/#the-kubernetes-network-model),你需要一个 CNI 插件。
27+
2328
<!--
2429
You must use a CNI plugin that is compatible with the
2530
[v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) or later
@@ -37,80 +42,96 @@ CNI 规范的插件(插件可以兼容多个规范版本)。
3742
<!--
3843
## Installation
3944
40-
A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). The CRI manages its own CNI plugins. There are two Kubelet command line parameters to keep in mind when using plugins:
45+
A Container Runtime, in the networking context, is a daemon on a node configured to provide CRI Services for kubelet. In particular, the Container Runtime must be configured to load the CNI plugins required to implement the Kubernetes network model.
46+
-->
47+
## 安装 {#installation}
48+
49+
在网络语境中,容器运行时(Container Runtime)是在节点上的守护进程,
50+
被配置用来为 kubelet 提供 CRI 服务。具体而言,容器运行时必须配置为加载所需的
51+
CNI 插件,从而实现 Kubernetes 网络模型。
52+
53+
{{< note >}}
54+
<!--
55+
Prior to Kubernetes 1.24, the CNI plugins could also be managed by the kubelet using the `cni-bin-dir` and `network-plugin` command-line parameters.
56+
These command-line parameters were removed in Kubernetes 1.24, with management of the CNI no longer in scope for kubelet.
57+
-->
58+
在 Kubernetes 1.24 之前,CNI 插件也可以由 kubelet 使用命令行参数 `cni-bin-dir`
59+
`network-plugin` 管理。Kubernetes 1.24 移除了这些命令行参数,
60+
CNI 的管理不再是 kubelet 的工作。
4161

42-
* `cni-bin-dir`: Kubelet probes this directory for plugins on startup
43-
* `network-plugin`: The network plugin to use from `cni-bin-dir`. It must match the name reported by a plugin probed from the plugin directory. For CNI plugins, this is "cni".
62+
<!--
63+
See [Troubleshooting CNI plugin-related errors](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)
64+
if you are facing issues following the removal of dockershim.
4465
-->
45-
## 安装
66+
如果你在移除 dockershim 之后遇到问题,请参阅[排查 CNI 插件相关的错误](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)
67+
{{< /note >}}
4668

47-
CNI 插件需要实现 [Kubernetes 网络模型](/zh/docs/concepts/services-networking/#the-kubernetes-network-model)
48-
CRI 管理它自己的 CNI 插件。
49-
在使用插件时,需要记住两个 kubelet 命令行参数:
69+
<!--
70+
For specific information about how a Container Runtime manages the CNI plugins, see the documentation for that Container Runtime, for example:
71+
-->
72+
要了解容器运行时如何管理 CNI 插件的具体信息,可参见对应容器运行时的文档,例如:
5073

51-
* `cni-bin-dir`: kubelet 在启动时探测这个目录中的插件
52-
* `network-plugin`: 要使用的网络插件来自 `cni-bin-dir`
53-
它必须与从插件目录探测到的插件报告的名称匹配。
54-
对于 CNI 插件,其值为 "cni"。
74+
- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
75+
- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
5576

5677
<!--
57-
## Network Plugin Requirements
78+
For specific information about how to install and manage a CNI plugin, see the documentation for that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model).
79+
-->
80+
要了解如何安装和管理 CNI 插件的具体信息,可参阅对应的插件或
81+
[网络驱动(Networking Provider)](/zh-cn/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model)
82+
的文档。
5883

59-
Besides providing the [`NetworkPlugin` interface](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) to configure and clean up pod networking, the plugin may also need specific support for kube-proxy. The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables. For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly. If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy.
84+
<!--
85+
## Network Plugin Requirements
6086
61-
By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy.
87+
For plugin developers and users who regularly build or deploy Kubernetes, the plugin may also need specific configuration to support kube-proxy.
88+
The iptables proxy depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables.
89+
For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly.
90+
If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy.
6291
-->
63-
## 网络插件要求
92+
## 网络插件要求 {#network-plugin-requirements}
6493

65-
除了提供
66-
[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)
67-
来配置和清理 Pod 网络之外,该插件还可能需要对 kube-proxy 的特定支持。
68-
iptables 代理显然依赖于 iptables,插件可能需要确保 iptables 能够监控容器的网络通信。
94+
对于插件开发人员以及时常会构建并部署 Kubernetes 的用户而言,
95+
插件可能也需要特定的配置来支持 kube-proxy。
96+
iptables 代理依赖于 iptables,插件可能需要确保 iptables 能够监控容器的网络通信。
6997
例如,如果插件将容器连接到 Linux 网桥,插件必须将 `net/bridge/bridge-nf-call-iptables`
70-
系统参数设置为`1`,以确保 iptables 代理正常工作。
98+
sysctl 参数设置为 `1`,以确保 iptables 代理正常工作。
7199
如果插件不使用 Linux 网桥(而是类似于 Open vSwitch 或者其它一些机制),
72100
它应该确保为代理对容器通信执行正确的路由。
73101

102+
<!--
103+
By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy.
104+
-->
105+
74106
默认情况下,如果未指定 kubelet 网络插件,则使用 `noop` 插件,
75107
该插件设置 `net/bridge/bridge-nf-call-iptables=1`,以确保简单的配置
76108
(如带网桥的 Docker )与 iptables 代理正常工作。
77109

78110
<!--
79-
### CNI
80-
81-
The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option. Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network. The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`).
111+
### Loopback CNI
82112
83-
If there are multiple CNI configuration files in the directory, the kubelet uses the configuration file that comes first by name in lexicographic order.
84-
85-
In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0
113+
In addition to the CNI plugin installed on the nodes for implementing the Kubernetes network model, Kubernetes also requires the container runtimes to provide a loopback interface `lo`, which is used for each sandbox (pod sandboxes, vm sandboxes, ...).
114+
Implementing the loopback interface can be accomplished by re-using the [CNI loopback plugin.](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) or by developing your own code to achieve this (see [this example from CRI-O](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)).
86115
-->
87-
### CNI
88-
89-
通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项可以选择 CNI 插件。
90-
Kubelet 从 `--cni-conf-dir` (默认是 `/etc/cni/net.d`) 读取文件并使用
91-
该文件中的 CNI 配置来设置各个 Pod 的网络。
92-
CNI 配置文件必须与
93-
[CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)
94-
匹配,并且配置所引用的所有所需的 CNI 插件都应存在于
95-
`--cni-bin-dir`(默认是 `/opt/cni/bin`)下。
116+
### 本地回路 CNI {#loopback-cni}
96117

97-
如果这个目录中有多个 CNI 配置文件,kubelet 将会使用按文件名的字典顺序排列
98-
的第一个作为配置文件
99-
100-
除了配置文件指定的 CNI 插件外,Kubernetes 还需要标准的 CNI
101-
[`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)
102-
插件,最低版本是0.2.0
118+
除了安装到节点上用于实现 Kubernetes 网络模型的 CNI 插件外,Kubernetes
119+
还需要容器运行时提供一个本地回路接口 `lo`,用于各个沙箱(Pod 沙箱、虚机沙箱……)
120+
实现本地回路接口的工作可以通过复用
121+
[CNI 本地回路插件](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)来实现,
122+
也可以通过开发自己的代码来实现
123+
(参阅 [CRI-O 中的示例](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)
103124

104125
<!--
105-
#### Support hostPort
126+
### Support hostPort
106127
107128
The CNI networking plugin supports `hostPort`. You can use the official [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
108129
plugin offered by the CNI plugin team or use your own plugin with portMapping functionality.
109130
110131
If you want to enable `hostPort` support, you must specify `portMappings capability` in your `cni-conf-dir`.
111132
For example:
112133
-->
113-
#### 支持 hostPort
134+
### 支持 hostPort {#support-hostport}
114135

115136
CNI 网络插件支持 `hostPort`。 你可以使用官方
116137
[portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
@@ -149,7 +170,7 @@ CNI 网络插件支持 `hostPort`。 你可以使用官方
149170
```
150171

151172
<!--
152-
#### Support traffic shaping
173+
### Support traffic shaping
153174
154175
**Experimental Feature**
155176
@@ -159,7 +180,7 @@ plugin offered by the CNI plugin team or use your own plugin with bandwidth cont
159180
If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI configuration file
160181
(default `/etc/cni/net.d`) and ensure that the binary is included in your CNI bin dir (default `/opt/cni/bin`).
161182
-->
162-
#### 支持流量整形
183+
### 支持流量整形 {#support-traffic-shaping}
163184

164185
**实验功能**
165186

@@ -216,16 +237,6 @@ metadata:
216237
kubernetes.io/egress-bandwidth: 1M
217238
...
218239
```
219-
<!--
220-
## Usage Summary
221-
222-
* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`).
223-
-->
224-
## 用法总结
225-
226-
* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件,实际的 CNI 插件
227-
可执行文件位于 `--cni-bin-dir`(默认是 `/opt/cni/bin`)下, CNI 插件配置位于
228-
`--cni-conf-dir`(默认是 `/etc/cni/net.d`)下。
229240

230241
## {{% heading "whatsnext" %}}
231242

content/zh-cn/docs/concepts/services-networking/_index.md

Lines changed: 34 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -7,43 +7,46 @@ description: Kubernetes 网络背后的概念和资源。
77
<!--
88
## The Kubernetes network model
99
10-
Every [`Pod`](/docs/concepts/workloads/pods/) gets its own IP address.
10+
Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address.
1111
This means you do not need to explicitly create links between `Pods` and you
1212
almost never need to deal with mapping container ports to host ports.
1313
This creates a clean, backwards-compatible model where `Pods` can be treated
1414
much like VMs or physical hosts from the perspectives of port allocation,
15-
naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), application configuration,
16-
and migration.
17-
18-
Kubernetes imposes the following fundamental requirements on any networking
19-
implementation (barring any intentional network segmentation policies):
20-
21-
* pods on a [node](/docs/concepts/architecture/nodes/) can communicate with all pods on all nodes without NAT
22-
* agents on a node (e.g. system daemons, kubelet) can communicate with all
23-
pods on that node
24-
25-
Note: For those platforms that support `Pods` running in the host network (e.g.
26-
Linux):
27-
28-
* pods in the host network of a node can communicate with all pods on all
29-
nodes without NAT
15+
naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing),
16+
application configuration, and migration.
3017
-->
3118
## Kubernetes 网络模型 {#the-kubernetes-network-model}
3219

33-
每一个 [`Pod`](/zh/docs/concepts/workloads/pods/) 都有它自己的IP地址,
34-
这就意味着你不需要显式地在 `Pod` 之间创建链接, 你几乎不需要处理容器端口到主机端口之间的映射。
20+
集群中每一个 [`Pod`](/zh-cn/docs/concepts/workloads/pods/) 都会获得自己的、
21+
独一无二的 IP 地址,
22+
这就意味着你不需要显式地在 `Pod` 之间创建链接,你几乎不需要处理容器端口到主机端口之间的映射。
3523
这将形成一个干净的、向后兼容的模型;在这个模型里,从端口分配、命名、服务发现、
36-
[负载均衡](/zh/docs/concepts/services-networking/ingress/#load-balancing)应用配置和迁移的角度来看,
37-
`Pod` 可以被视作虚拟机或者物理主机。
24+
[负载均衡](/zh/docs/concepts/services-networking/ingress/#load-balancing)
25+
应用配置和迁移的角度来看,`Pod` 可以被视作虚拟机或者物理主机。
3826

27+
<!--
28+
Kubernetes imposes the following fundamental requirements on any networking
29+
implementation (barring any intentional network segmentation policies):
30+
-->
3931
Kubernetes 强制要求所有网络设施都满足以下基本要求(从而排除了有意隔离网络的策略):
4032

41-
* [节点](/zh/docs/concepts/architecture/nodes/)上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信
33+
<!--
34+
* pods can communicate with all other pods on any other [node](/docs/concepts/architecture/nodes/)
35+
without NAT
36+
* agents on a node (e.g. system daemons, kubelet) can communicate with all
37+
pods on that node
38+
-->
39+
* Pod 能够与所有其他[节点](/zh-cn/docs/concepts/architecture/nodes/)上的 Pod 通信,
40+
且不需要网络地址转译(NAT)
4241
* 节点上的代理(比如:系统守护进程、kubelet)可以和节点上的所有 Pod 通信
4342

44-
备注:对于支持在主机网络中运行 `Pod` 的平台(比如:Linux):
45-
46-
* 运行在节点主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信
43+
<!--
44+
Note: For those platforms that support `Pods` running in the host network (e.g.
45+
Linux), when pods are attached to the host network of a node they can still communicate
46+
with all pods on all nodes without NAT.
47+
-->
48+
说明:对于支持在主机网络中运行 `Pod` 的平台(比如:Linux),
49+
当 Pod 挂接到节点的宿主网络上时,它们仍可以不通过 NAT 和所有节点上的 Pod 通信。
4750

4851
<!--
4952
This model is not only less complex overall, but it is principally compatible
@@ -62,7 +65,8 @@ usage, but this is no different from processes in a VM. This is called the
6265
如果你的任务开始是在虚拟机中运行的,你的虚拟机有一个 IP,
6366
可以和项目中其他虚拟机通信。这里的模型是基本相同的。
6467

65-
Kubernetes 的 IP 地址存在于 `Pod` 范围内 - 容器共享它们的网络命名空间 - 包括它们的 IP 地址和 MAC 地址。
68+
Kubernetes 的 IP 地址存在于 `Pod` 范围内 —— 容器共享它们的网络命名空间 ——
69+
包括它们的 IP 地址和 MAC 地址。
6670
这就意味着 `Pod` 内的容器都可以通过 `localhost` 到达对方端口。
6771
这也意味着 `Pod` 内的容器需要相互协调端口的使用,但是这和虚拟机中的进程似乎没有什么不同,
6872
这也被称为“一个 Pod 一个 IP”模型。
@@ -90,9 +94,10 @@ Kubernetes networking addresses four concerns:
9094
-->
9195

9296
Kubernetes 网络解决四方面的问题:
93-
- 一个 Pod 中的容器之间[通过本地回路(loopback)通信](/zh/docs/concepts/services-networking/dns-pod-service/)
97+
98+
- 一个 Pod 中的容器之间[通过本地回路(loopback)通信](/zh-cn/docs/concepts/services-networking/dns-pod-service/)
9499
- 集群网络在不同 pod 之间提供通信。
95-
- [Service 资源](/zh/docs/concepts/services-networking/service/)允许你
96-
[对外暴露 Pods 中运行的应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)
100+
- [Service 资源](/zh-cn/docs/concepts/services-networking/service/)允许你
101+
[向外暴露 Pods 中运行的应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)
97102
以支持来自于集群外部的访问。
98-
- 可以使用 Services 来[发布仅供集群内部使用的服务](/zh/docs/concepts/services-networking/service-traffic-policy/)
103+
- 可以使用 Services 来[发布仅供集群内部使用的服务](/zh-cn/docs/concepts/services-networking/service-traffic-policy/)

0 commit comments

Comments
 (0)