Py学习  »  docker

network bridge'docker0'在k8s中扮演什么角色?

jacking • 4 年前 • 583 次点击  

K8S版本:v1.10.4
法兰绒版本:v0.10.0
Docker版本v1.12.6

当我使用命令时 brctl show 在节点上,显示如下:

[root@node03 tmp]# brctl show
bridge name bridge id       STP enabled interfaces
cni0        8000.0a580af40501   no      veth39711246
                                        veth591ea0bf
                                        veth5b889fed
                                        veth61dfc48a
                                        veth6ef58804
                                        veth75f5ef36
                                        vethc162dc8a
docker0     8000.0242dfd605c0   no
它显示vethxxx绑定在名为cni0的网桥上,但是当我使用命令'ip addr'时,它显示:
[root@node03 tmp]# ip addr |grep veth
6: veth61dfc48a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
7: veth591ea0bf@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
9: veth6ef58804@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
46: vethc162dc8a@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
55: veth5b889fed@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
61: veth75f5ef36@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP 
78: veth39711246@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP
这些veth都绑定在if3上,但if3不是cni0,而是docker0`
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 

好像是网桥 docker0 没用,但是 ip addr 显示所有的兽医设备都绑在上面。网桥扮演什么角色 道克尔0 在K8S里玩法兰绒?谢谢

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/43967
 
583 次点击  
文章 [ 1 ]  |  最新文章 4 年前
Crou
Reply   •   1 楼
Crou    5 年前

Docker和Kubernetes有两种网络模型。

Docker模型

默认情况下,Docker使用主机专用网络。它创建了一个虚拟桥,称为 docker0 默认情况下,从中定义的一个专用地址块分配子网。 RFC1918 为了那座桥。对于Docker创建的每个容器,它分配一个虚拟以太网设备(称为 veth )它附在桥上。兽医被映射为 eth0 在容器中,使用Linux命名空间。集装箱内 种族歧视 接口被赋予来自网桥地址范围的IP地址。

结果是,只有在同一台机器上,DOCKER容器才能与其他容器对话。 (因此也是同样的虚拟桥)。 不同机器上的容器不能互相接触。 -事实上,它们最终可能拥有完全相同的网络范围和IP地址。

kubernetes模型

Kubernetes对任何网络实现提出了以下基本要求(除非有任何有意的网络分段策略):

  • 所有容器都可以与所有其他容器进行通信,而不需要NAT。
  • 所有节点都可以与所有容器通信(反之亦然),不需要NAT。
  • 一个容器将自己视为的IP与其他人将其视为的IP相同

Kubernetes在 Pod 作用域-中的容器 豆荚 共享他们的网络名称空间-包括他们的IP地址。这意味着 豆荚 都能到达对方的端口 localhost . 这确实意味着 豆荚 必须协调端口使用,但这与虚拟机中的进程没有区别。这称为“每个pod的ip”模型。这是使用Docker作为一个“pod容器”实现的,它保持网络名称空间打开,而“app容器”(用户指定的东西)将该名称空间与Docker的连接起来。 --net=container:<id> 功能。

与Docker一样,可以请求主机端口,但这会减少到一个非常小的操作。在这种情况下,将在主机上分配端口 Node 交通会被转移到 豆荚 . 这个 豆荚 它本身对主机端口的存在或不存在是盲目的。

为了将平台与底层网络基础设施集成,kubernetes提供了一个名为 Container Networking Interface (CNI) . 如果满足了KubNetes的基本要求,供应商可以使用他们喜欢的网络堆栈,通常使用覆盖网络来支持。 多子网 多AZ 集群。

下面展示了如何通过 Flannel 它很受欢迎 CNI .

flannel

您可以阅读更多关于其他CNI的 here . kubernetes方法在 Cluster Networking 博士学位。我也推荐阅读 Kubernetes Is Hard: Why EKS Makes It Easier for Network and Security Architects 这就解释了 法兰绒 工作,也是另一个 article from Medium

希望这能回答你的问题。