深入剖析Kubernetes
张磊
Kubernetes社区资深成员与项目维护者
立即订阅
21378 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (5讲)
开篇词 | 打通“容器技术”的任督二脉
免费
01 | 预习篇 · 小鲸鱼大事记(一):初出茅庐
02 | 预习篇 · 小鲸鱼大事记(二):崭露头角
03 | 预习篇 · 小鲸鱼大事记(三):群雄并起
04 | 预习篇 · 小鲸鱼大事记(四):尘埃落定
容器技术概念入门篇 (5讲)
05 | 白话容器基础(一):从进程说开去
06 | 白话容器基础(二):隔离与限制
07 | 白话容器基础(三):深入理解容器镜像
08 | 白话容器基础(四):重新认识Docker容器
09 | 从容器到容器云:谈谈Kubernetes的本质
Kubernetes集群搭建与实践 (3讲)
10 | Kubernetes一键部署利器:kubeadm
11 | 从0到1:搭建一个完整的Kubernetes集群
12 | 牛刀小试:我的第一个容器化应用
容器编排与Kubernetes作业管理 (15讲)
13 | 为什么我们需要Pod?
14 | 深入解析Pod对象(一):基本概念
15 | 深入解析Pod对象(二):使用进阶
16 | 编排其实很简单:谈谈“控制器”模型
17 | 经典PaaS的记忆:作业副本与水平扩展
18 | 深入理解StatefulSet(一):拓扑状态
19 | 深入理解StatefulSet(二):存储状态
20 | 深入理解StatefulSet(三):有状态应用实践
21 | 容器化守护进程的意义:DaemonSet
22 | 撬动离线业务:Job与CronJob
23 | 声明式API与Kubernetes编程范式
24 | 深入解析声明式API(一):API对象的奥秘
25 | 深入解析声明式API(二):编写自定义控制器
26 | 基于角色的权限控制:RBAC
27 | 聪明的微创新:Operator工作原理解读
Kubernetes容器持久化存储 (4讲)
28 | PV、PVC、StorageClass,这些到底在说啥?
29 | PV、PVC体系是不是多此一举?从本地持久化卷谈起
30 | 编写自己的存储插件:FlexVolume与CSI
31 | 容器存储实践:CSI插件编写指南
Kubernetes容器网络 (8讲)
32 | 浅谈容器网络
33 | 深入解析容器跨主机网络
34 | Kubernetes网络模型与CNI网络插件
35 | 解读Kubernetes三层网络方案
36 | 为什么说Kubernetes只有soft multi-tenancy?
37 | 找到容器不容易:Service、DNS与服务发现
38 | 从外界连通Service与Service调试“三板斧”
39 | 谈谈Service与Ingress
Kubernetes作业调度与资源管理 (5讲)
40 | Kubernetes的资源模型与资源管理
41 | 十字路口上的Kubernetes默认调度器
42 | Kubernetes默认调度器调度策略解析
43 | Kubernetes默认调度器的优先级与抢占机制
44 | Kubernetes GPU管理与Device Plugin机制
Kubernetes容器运行时 (3讲)
45 | 幕后英雄:SIG-Node与CRI
46 | 解读 CRI 与 容器运行时
47 | 绝不仅仅是安全:Kata Containers 与 gVisor
Kubernetes容器监控与日志 (3讲)
48 | Prometheus、Metrics Server与Kubernetes监控体系
49 | Custom Metrics: 让Auto Scaling不再“食之无味”
50 | 让日志无处可逃:容器日志收集与管理
再谈开源与社区 (1讲)
51 | 谈谈Kubernetes开源社区和未来走向
答疑文章 (1讲)
52 | 答疑:在问题中解决问题,在思考中产生思考
特别放送 (1讲)
特别放送 | 2019 年,容器技术生态会发生些什么?
结束语 (1讲)
结束语 | Kubernetes:赢开发者赢天下
特别放送 | 云原生应用管理系列 (1讲)
基于 Kubernetes 的云原生应用管理,到底应该怎么做?
深入剖析Kubernetes
登录|注册

33 | 深入解析容器跨主机网络

张磊 2018-11-07

你好,我是张磊。今天我和你分享的主题是:深入解析容器跨主机网络。

在上一篇文章中,我为你详细讲解了在单机环境下,Linux 容器网络的实现原理(网桥模式)。并且提到了,在 Docker 的默认配置下,不同宿主机上的容器通过 IP 地址进行互相访问是根本做不到的。

而正是为了解决这个容器“跨主通信”的问题,社区里才出现了那么多的容器网络方案。而且,相信你一直以来都有这样的疑问:这些网络方案的工作原理到底是什么?

要理解容器“跨主通信”的原理,就一定要先从 Flannel 这个项目说起。

Flannel 项目是 CoreOS 公司主推的容器网络方案。事实上,Flannel 项目本身只是一个框架,真正为我们提供容器网络功能的,是 Flannel 的后端实现。目前,Flannel 支持三种后端实现,分别是:

  1. VXLAN;

  2. host-gw;

  3. UDP。

这三种不同的后端实现,正代表了三种容器跨主网络的主流实现方法。其中,host-gw 模式,我会在下一篇文章中再做详细介绍。

而 UDP 模式,是 Flannel 项目最早支持的一种方式,却也是性能最差的一种方式。所以,这个模式目前已经被弃用。不过,Flannel 之所以最先选择 UDP 模式,就是因为这种模式是最直接、也是最容易理解的容器跨主网络实现。

© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《深入剖析Kubernetes》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(45)

  • 宝爷
    这里使用UDP,不需要可靠,因为可靠性不是这一层需要考虑的事情,这一层需要考虑的事情就是把这个包发送到目标地址。如果出现了UDP丢包的情况,也完全没有关系,这里UDP包裹的是我们真正的数据包,如果我们上层使用的是TCP协议,而Flannel使用UDP包裹了我们的数据包,当出现丢包了,TCP的确认机制会发现这个丢包而重传,从而保证可靠。
    2019-02-16
    30
  • 虎虎❤️
    我又思考了一下,二层网络可能无法连通。因为flannel网络中,node上的fdb是靠配置而非学习得到。当node1上的容器1想要通过mac地址直连node2上的容器2时,由于node1中的fdb中没有配置容器2的mac地址相关记录,所以flannel.1无法找到VTEP出口的ip。故而二层网络没有连通性。

    如果想要有连通性,需要配置VTEP为学习模式,并且把所有的VTEP加入一个分组中。这样在fdb表中查询不到mac地址时,vxlan在VTEP组中发起广播(或者组播?这个概念我有点混淆)。VTEP也可作为一个网桥设备,继续向docker0,进而目的node上的所有容器广播。正确的目的地址会响应请求,而且刚才途经的设备fdb都学习到了源容器的mac 地址映射,所以响应数据可以顺利返回源容器。这样就完成了二层网络的连通。
    2018-11-08
    1
    5
  • 广宇
    抓包分析了下,确实如老师所描述,外部数据帧的源和目的MAC地址分别为宿主机网卡的MAC地址,外部IP头的源和目的地址分别为宿主机的IP地址,内部数据帧中的源和目的MAC地址分别为VTEP设备的MAC地址,内部IP头的源和目的地址分别为容器的IP地址。但是有个问题,做了个测试,在容器里面arping另一个宿主机上的容器地址,却得不到回应,这是为什么?广播地址不会被封装出去吗?
    2019-02-23
    4
    4
  • 阿鹏
    我看很多文章都推荐calico,老师觉得呢
    2018-11-07
    4
  • Maiza
    分分钟变成了计算机网络课程 😄
    2018-11-07
    4
  • kissingers
    看了好久终于明白一点,vxlan模式下,flanneld 干了好多话,添加了去往目的容器的下一条地址即peer VTEP,还添加了对应的mac来封装innter frame, 再添加了去往peer VTEP的host ip。感觉是个大管家呀,怎么做到的? 需要事前配置还是建立时注册到一个什么地方?
    另外gateway 不太会是10.1.16.0吧,应该10.1.16.1 。
    2018-11-16
    3
  • flannel进程负责子网->VTEP mac,VTEP mac->节点ip(fdb)的维护,为什么不直接维护子网->节点ip表更直接,中间的二层网络感觉多此一举的
    2019-01-18
    2
  • jssfy
    请问bridge fdb看到的其它节点vtep的对应关系vtep是各节点主动注册的?

    作者回复: 主机上的agent要负责维护这些信息

    2018-11-26
    2
  • 继富
    为什么要使用UDP呢,UDP不是不可靠的吗

    作者回复: 好问题。你可以想想,这里是不是需要“可靠”呢?

    2018-11-12
    1
    2
  • Eurica
    文中所述“container-1里的进程发起的IP包,根据默认路由规则,通过容器的网关进入docker0网桥,从而出现在宿主机上。”请问老师“容器的网关”是谁?
    2018-11-07
    1
    2
  • xianhai
    etcdctl ls 这个命令不存在啊。
    我是用这个命令安装etcdctl的:go get github.com/coreos/etcd/cmd/etcdctl

    极客时间版权所有: https://time.geekbang.org/column/article/65287
    2018-11-07
    2
  • 俊釆
    读了至少6遍了,每次都有新的收获,感谢磊哥给力的分享。
    2019-09-23
    1
  • iGeneral
    想起来原来做毕业设计的时候,跨主机直接容器的通信好像直接用的etcd服务发现,直接吧docker的网络暴露出去,然后依赖etcd来做的跨主机通信。 其实还可以
    2019-07-16
    1
  • 好深的功底
    2019-06-20
    1
  • 请问,某个节点上flannel进程启动后,会发送相关状态到其他节点---那么,这个共享的配置信息是不是经过Etcd处理的?FDB这个转发数据库是不是也是在这个时机形成的? 这样 在打上外层标签时就这直接从内核态进行操作,从而效率比较高。
    2019-03-07
    1
  • 周娄子
    container veth设备都是attach在bridge上的, 应该无法保证二层网络(MAC 地址)的连通性
    2018-11-28
    1
  • maomaostyle
    请问为什么vxlan一定要使用udp建立连接呢?
    2018-11-21
    1
  • 勤劳的小胖子-libo
    Flannel中的UDP需要Etcd来维护相关的子网与宿主机的对应关系,在VxLan中也需要Etcd吗?老师,什么时候可以讲下Etcd在k8s中的原理与应用?

    作者回复: 现在它们都不依赖etcd,直接连apiserver

    2018-11-12
    1
  • blackpiglet
    思考题:Flannel 能负责保证二层网络(MAC 地址)的连通性吗?

    回答:我觉得不能,Flannel 的工作模式都是根据 IP 来判断下一条跳转到哪个网络设备上,是基于三层做路由。如果要基于 MAC 做寻址的话,Flannel 无法知道其他主机上的容器的 MAC 地址,所以无法转发。
    2018-11-10
    1
  • 艾斯Z艾穆
    您好,我遇到一个问题
    我在一个被service选中的app里访问不了这个service的port可以ping通,用pod的ip可以访问到端口
    别的pod可以访问到service的port
    这个pod也可以访问别的service的port
    kube-proxy用的模式是ipvs

    作者回复: 看service部分讲解

    2018-11-08
    1
收起评论
45
返回
顶部