专栏首页深入理解k8s网络原理深入理解kubernetes(k8s)网络原理之三-跨主机pod连接
原创

深入理解kubernetes(k8s)网络原理之三-跨主机pod连接

深入理解kubernetes(k8s)网络原理之三-跨主机pod连接

在之前的两篇文章中分别介绍了pod与主机连接并且上外网的原理及service的clusterIP和nodeport的实现原理,对于组织pod的网络这件事来说,还有最后一环需要打通,就是分布在不同集群节点的pod之间如何相互通信,本章我们来解决这最后一环的问题

在这里我们继续用linux network namespace(ns)代表pod

我们将用下面三种方式实现跨主机的pod通信:

  1. 主机路由
  2. ip tunnel
  3. vxlan

我准备了两台节点:

  • host1(ip:10.57.4.20)
  • host2(ip:10.57.4.21)

先在两台节点中分别创建一个pod,并与节点能相互通信,创建pod并与节点通信的相关原理在第一章已经介绍过,这里不再一一解释,直接上命令:

  • host1中创建pod-a(ip:192.168.10.10)
ip netns add pod-a
ip link add eth0 type veth peer name veth-pod-a
ip link set eth0 netns pod-a
ip netns exec pod-a ip addr add 192.168.10.10/24 dev eth0
ip netns exec pod-a ip link set eth0 up
ip netns exec pod-a ip route add default via 169.254.10.24 dev eth0 onlink
ip link set veth-pod-a up
echo 1 > /proc/sys/net/ipv4/conf/veth-pod-a/proxy_arp
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
ip route add 192.168.10.10 dev veth-pod-a scope link
  • host2上创建pod-b(ip:192.168.11.10)
ip netns add pod-b
ip link add eth0 type veth peer name veth-pod-b
ip link set eth0 netns pod-b
ip netns exec pod-b ip addr add 192.168.11.10/24 dev eth0
ip netns exec pod-b ip link set eth0 up
ip netns exec pod-b ip route add default via 169.254.10.24 dev eth0 onlink
ip link set veth-pod-b up
echo 1 > /proc/sys/net/ipv4/conf/veth-pod-b/proxy_arp
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT
ip route add 192.168.11.10 dev veth-pod-b scope link

如无意外,host1应该能ping通pod-a,host2也能ping通pod-b了,环境准备完成,下面我们介绍主机路由模式,这是flannel的host-gw模式的原理。

主机路由

其实每一台linux主机本身就是一台路由器,可以用ip route命令配置主机上的路由表,要让pod-a和pod-b相互通信,只需要在两台主机上加一条路由即可:

  • host1:
ip route add 192.168.11.0/24 via 10.57.4.21 dev eth0 onlink 
##这个eth0是host1连接host2的网卡,要根据你的测试节点的情况调整
  • host2:
ip route add 192.168.10.0/24 via 10.57.4.20 dev eth0 onlink 
##这个eth0是host2连接host1的网卡,要根据你的测试节点的情况调整

注意上面我们加的路由是针对24位网络地址相同的子网段的,一般来说k8s集群的每个节点会独占一个24位的网络地址的子网段,所以每增加一个集群节点,其它节点加一条路由就可以了,但如果不是这样设计,像之前提过的pod要固定IP,又想要能在整个集群的任意节点运行,这个主机路由条目就会比较多,因为每条路由都是针对单个pod的

此时在pod-a中去ping pod-b应该是通了的,假设在pod-b的8080端口运行着一个http服务,在pod-a中请求这个服务,在主机路由的模式下,host1发往host2的数据包是长这样的:

图一:主机路由

注意图中的源IP和目标IP是容器的,但MAC地址却是主机的,我们在第一章中提到的linux网络知识的发送包的第5点说起过,数据包发送过程中,除非经过NAT,否则IP不会变化,始终标明通信双方,但MAC地址是每一段都会变化,数据包从pod-a到pod-b一共会经历三段:

  1. 从pod-a发往host1时,源mac是pod-a的eth0网卡的mac,而目标mac是pod-a的默认网关(169.254.10.24)的mac,因为主机的veth-pod-a开启了arp代答,所以目标mac其实是主机上veth-pod-a的mac地址。
  2. 从host1去往host2的过程中,所以源MAC是host1的eth0网卡的mac,目标MAC是host2的eth0网卡的mac。
  3. 从host2发往pod-b,源mac是host2上veth-pod-b网卡的mac,目标mac是pod-b的eth0网卡mac

这是跨节点容器通信方式中最简单高效的方式,没有封包拆包带来的额外消耗,但这种方式的使用场景有一些限制:

  • 集群节点必须在相同网段,因为主机路由的下一跳必须是二层可达的地址,如果在不同网段也想要使用非overlay的方式,那就需要把上面的路由信息同步到节点所在机房的路由器了,这就是calico BGP的方式
  • 云平台的虚拟机一般有源/目地址检查,流量从虚拟机出来时,如果源IP或源MAC与虚拟机不符,则丢包;我们使用主机路由时,源MAC是虚拟机的,但源IP是pod的,所以就被丢包了;实在是想要在云平台使用主机路由的话:
    • 关闭“源/目地址检查”(华为云),VPC路由表要加路由(阿里云、腾讯云)
    • ECS所属的安全组策略中要放开pod的网段

云平台的虚拟机为什么要做源/目地址检查呢?因为要防止IP spoofing

因为以上限制,host-gw通常在idc机房且节点数不多都在同一子网的情况下使用,或者与别的模式混合使用,比如flannel的DirectRouting开启时,相同网段的用host-gw,跨网段用vxlan;

有没有节点跨网段也能使用的模式呢?接下来介绍的ip tunnel(就是常说的ipip模式)就是了。

ip tunnel(ipip)

ipip模式并不是像主机路由那样,修改数据包的mac地址,而是在原ip包的前面再加一层ip包,然后链路层是以外层ip包的目标地址封装以太网帧头,而原来的那层ip包更像是被当成了外层包的数据,完成这个封包过程的是linux 虚拟网络设备tunnel网卡,它的工作原理是用节点路由表中匹配原ip包的路由信息中的下一跳地址为外层IP包的目标地址,以本节点的IP地址为源地址,再加一层IP包头,所以使用ip tunnel的模式下,我们需要做两件事情:

  • 在各个主机上建立一个one-to-many的ip tunnel,(所谓的one-to-many,就是创建ip tunnel设备时,不指定remote address,这样一个节点只需要一张tunnel网卡)
  • 维护节点的路由信息,目标地址为集群的每一个的node-cidr,下一跳为node-cidr所在节点的IP,跟上面的主机路由很像,只不过出口网卡就不再是eth0了,而是新建的ip tunnel设备;

我们接着上面的环境继续操作:

  • 首先删除上面使用主机路由时在两台主机上增加的路由条目

host1:

ip route del 192.168.11.0/24 via 10.57.4.21 dev eth0 onlink

host2:

ip route del 192.168.10.0/24 via 10.57.4.20 dev eth0 onlink
  • 然后在两台主机上分别创建ip tunnel设备

host1:

ip tunnel add mustang.tun0 mode ipip local 10.57.4.20 ttl 64
ip link set mustang.tun0 mtu 1480 ##因为多一层IP头,占了20个字节,所以MTU也要相应地调整
ip link set mustang.tun0 up
ip route add 192.168.11.0/24 via 10.57.4.21 dev mustang.tun0 onlink
ip addr add 192.168.10.1/32 dev mustang.tun0 ## 这个地址是给主机请求跨节点的pod时使用的

host2:

ip tunnel add mustang.tun0 mode ipip local 10.57.4.21 ttl 64
ip link set mustang.tun0 mtu 1480
ip link set mustang.tun0 up
ip route add 192.168.10.0/24 via 10.57.4.20 dev mustang.tun0 onlink
ip addr add 192.168.11.1/32 dev mustang.tun0

这时候两个pod应该已经可以相互ping通了,还是假设pod-a请求pod-b的http服务,此时host1发往host2的数据包是长这样的:

图二:ipip

因为主机协议栈工作时是由下往上识别每一层包,所以ipip包对于主机协议栈而言,与正常主机间通信的包并没有什么不同,帧头中的源/目标mac是主机的,ip包头中源/目标ip也是节点的,这让节点所处的物理网络也感觉这是正常的节点流量,所以 这个模式相对于主机路由来说对环境的适应性更广,起码跨网段的节点也是可以通的,但是在云平台上使用这种模式还是要注意下,留意图二中外层IP包中的传输层协议号是不一样的(是IPPROTO_IPIP),正常的IP包头,这应该是TCP/UDP/ICMP,这样有可能也会被云平台的安全组策略拦截掉,在linux内核源码中可以看到:

//include/uapi/linux/in.h

enum {
...
  IPPROTO_ICMP = 1,		/* Internet Control Message Protocol	*/
#define IPPROTO_ICMP		IPPROTO_ICMP

  IPPROTO_IPIP = 4,		/* IPIP tunnels (older KA9Q tunnels use 94) */
#define IPPROTO_IPIP		IPPROTO_IPIP

  IPPROTO_TCP = 6,		/* Transmission Control Protocol	*/
#define IPPROTO_TCP		IPPROTO_TCP

  IPPROTO_UDP = 17,		/* User Datagram Protocol		*/
#define IPPROTO_UDP		IPPROTO_UDP
...

一般而言我们在云平台安全组设置规则时,传输层协议都只有三个可选项,就是:TCP、UDP、ICMP(没有IPIP),所以最好是在云平台上把安全组内的主机间的所有协议都放开,会不会真的被拦截掉要看具体云平台,华为云是会限制的;

笔者曾经试过在华为云上使用ipip模式,总会出现pod-a ping不通ping-b,卡着的时候,在pod-b上ping pod-a,然后两边就同时通了,这是典型的有状态防火墙的现象; 之后我们把集群节点都加入一个安全组,在安全组的规则配置中,把组内所有节点的所有端口所有协议都放开后,问题消失,说明默认对IPIP协议是没有放开的

在host1中执行:

ip netns exec pod-a ping -c 5 192.168.11.10 

在host2的eth0用tcpdump打印一下流量,就能看到有两层ip头:

tcpdump -n -i eth0|grep 192.168.11.10

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:03:35.048106 IP 10.57.4.20 > 10.57.4.21: IP 192.168.10.10 > 192.168.11.10: ICMP echo request, id 3205, seq 1, length 64 (ipip-proto-4)
18:03:35.049483 IP 10.57.4.21 > 10.57.4.20: IP 192.168.11.10 > 192.168.10.10: ICMP echo reply, id 3205, seq 1, length 64 (ipip-proto-4)
18:03:36.049147 IP 10.57.4.20 > 10.57.4.21: IP 192.168.10.10 > 192.168.11.10: ICMP echo request, id 3205, seq 2, length 64 (ipip-proto-4)
18:03:36.049245 IP 10.57.4.21 > 10.57.4.20: IP 192.168.11.10 > 192.168.10.10: ICMP echo reply, id 3205, seq 2, length 64 (ipip-proto-4)

calico的ipip模式就是这种,ip tunnel解决了主机路由不能在跨网段中使用的问题,在idc机房部署k8s集群的场景下,会拿host-gw和ipip两种模式混合使用,节点在相同网段则用host-gw,不同网段则用ipip,思路和flannel的directrouting差不多,只不过ipip比vxlan性能要好一些;

ip tunnel仍然有一些小小的限制,像上面说的云平台安全组对协议限制的问题,下面再介绍一种终极解决方案,只要节点网络是通的,容器就能通,完全没有限制,这就是vxlan模式;

vxlan

主机路由是按普通路由器的工作原理,每一跳修改MAC地址;ipip模式是给需要转发的数据包前面加一层IP包;而vxlan模式则是把pod的数据帧(注意这里是帧,就是包含二层帧头)封装在主机的UDP包的payload中,数据包封装的工作由linux虚拟网络设备vxlan完成,vxlan设备可以用下面的命令创建:

ip link add vxlan0 type vxlan id 100 dstport 4789 local 10.57.4.20 dev eth0
##设备名为vxlan0
##vxlan id 为 100
##dstport指示使用哪个udp端口
##eth0指示封装好vxlan包后通过哪个主机网卡发送

vxlan设备在封包时是根据目标MAC地址来决定外层包的目标IP,所以需要主机提供目标MAC地址与所属节点IP的映射关系,这些映射关系存在主机的fdb表(forwarding database)中,fdb记录可以用下面的命令查看:

bridge fdb show|grep vxlan0

8a:e7:df:c0:84:07 dev vxlan0 dst 10.57.4.21 self permanent

上面的记录的意思是说去往MAC地址为8a:e7:df:c0:84:07的pod在节点IP为10.57.4.21的节点上,fdb的信息可以手工维护,也可以让vxlan设备自动学习;

  • 手工添加一条fdb记录的命令如下:
bridge fdb append 8a:e7:df:c0:84:07 dev vxlan0 dst 10.57.4.21 self permanent
  • 如果需要让vxlan设备去学习fdb记录,可以创建vxlan设备时设置多播地址,并开启learning选项:
ip link add vxlan0 type vxlan id 100 dstport 4789 group 239.1.1.1 dev eth0 learning

所有集群的节点都加入这个多播组,这样就能自动学习fdb记录了,当然这需要底层网络支持多播;

  • 也可以通过增加全0的fdb记录来告诉vxlan设备遇到不知道下一跳的MAC应该向哪些节点广播:
bridge fdb append  00:00:00:00:00:00 dev vxlan0 dst 10.57.4.21 self permanent

我们接着上面的环境继续往下做,先把mustang.tun0删除,在两个节点上执行:

ip link del mustang.tun0

然后

host1:

ip link add vxlan0 type vxlan id 100 dstport 4789 local 10.57.4.20 dev eth0 learning  ## 这个eth0要根据你自己测试节点的网卡调整
ip addr add 192.168.10.1/32 dev vxlan0
ip link set vxlan0 up
ip route add 192.168.11.0/24 via 192.168.11.1 dev vxlan0 onlink
bridge fdb append  00:00:00:00:00:00 dev vxlan0 dst 10.57.4.21 self permanent

host2:

ip link add vxlan0 type vxlan id 100 dstport 4789 local 10.57.4.21 dev eth0 learning  ## 这个eth0要根据你自己测试节点的网卡调整
ip addr add 192.168.11.1/32 dev vxlan0
ip link set vxlan0 up
ip route add 192.168.10.0/24 via 192.168.10.1 dev vxlan0 onlink
bridge fdb append  00:00:00:00:00:00 dev vxlan0 dst 10.57.4.20 self permanent

这时候两台主机的pod应该可以相互ping通了

ip netns exec pod-b ping -c 5 192.168.10.10
PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.
64 bytes from 192.168.10.10: icmp_seq=1 ttl=62 time=0.375 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=62 time=0.497 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=62 time=0.502 ms
64 bytes from 192.168.10.10: icmp_seq=4 ttl=62 time=0.386 ms
64 bytes from 192.168.10.10: icmp_seq=5 ttl=62 time=0.390 ms
--- 192.168.10.10 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.375/0.430/0.502/0.056 ms

此时pod-a请求pod-b的http服务,数据包从host-1发往host-2时是长这样的:

图三:vxlan

可以看到,vxlan包是把整个pod-a发往pod-b最原始的帧都装进了一个udp数据包的payload中,整个流程简述如下:

  • 1、 pod-a数据包到达host-1,源ip为pod-a,目标ip为pod-b,源mac为pod-a,目标mac为host-1中的veth-pod-a
  • 2、 主机因为开启了转发,所以查找路由表中去往pod-b的下一跳,查到匹配的路由信息如下:
192.168.11.0/24 via 192.168.11.1 dev vxlan0 onlink  ## 这是我们在上面的host1执行的命令中的第四条命令添加的
  • 3、 于是主机把数据包给了vxlan0,并且下一跳为192.168.11.1,此时vxlan0需要得到192.168.11.1的mac地址,但主机的邻居表中不存在,于是vxlan0发起arp广播去询问,vxlan0的广播范围是由我们配置的,这个范围就是我们给他加的全0 fdb记录标识的dstIP,就是上面命令中的:
bridge fdb append  00:00:00:00:00:00 dev vxlan0 dst 10.57.4.21 self permanent

所以,这里找到的目标只有一个,就是10.57.4.21,然后vxlan就借助host1的eth0发起了这个广播,只不过eth0发起的不是广播,而是有明确目标IP的udp数据包,如果上面我们是配置了多个全0的fdb记录,这里eth0就会发起多播。

  • 4、 192.168.11.1这个地址是我们配置在host2上的vxlan0的网卡地址,于是host2会响应arp请求,host1的vxlan设备得到192.168.11.1的mac地址后,vxlan会从主机的fdb表中查找该mac的下一跳的主机号,发现找不到,于是又发起学习,问谁拥有这个mac,host-2再次应答,于是vxlan0就拥有了封包需要的全部信息,于是把包封装成图三的样子,扔给了host1的eth0网卡;
  • 5、 host2收到这个包后,因为是一个普通的udp包,于是一直上送到传输层,传输层对于这个端口会有个特殊处理,这个特殊处理会把udp包里payload的信息抠出来扔给协议栈,重新走一遍收包流程。(vxlan的原理后面有机会专门写一篇文章)

像这种vxlan学习fdb的方式难免会在主机网络间产生广播风暴,所以flannel的vxlan模式下,是关闭了vxlan设备的learning机制,然后用控制器维护fdb记录和邻居表记录的

可以看到这个过程中两次都需要用到全0的fdb记录,我们也可以在host1上查看vxlan0学习到的fdb记录和邻居表信息:

bridge fdb|grep vxlan0

00:00:00:00:00:00 dev vxlan0 dst 10.57.4.21 self permanent ## 这是我们手工添加的
6e:39:38:33:7c:24 dev vxlan0 dst 10.57.4.21 self   ## 这是vxlan0自动学习的,6e:39:38:33:7c:24 正是host2中vxlan0的地址

邻居表记录:

ip n

192.168.11.1 dev vxlan0 lladdr 6e:39:38:33:7c:24 STALE

在pod-b中ping pod-a的时候,在host1打开网卡监听,拦截的数据如下:

tcpdump -n -i eth0 src 10.57.4.21

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:21:01.050849 IP 10.57.4.21.55255 > 10.57.4.20.otv: OTV, flags [I] (0x08), overlay 0, instance 1
IP 192.168.11.10 > 192.168.10.10: ICMP echo request, id 26972, seq 15, length 64
10:21:02.051894 IP 10.57.4.21.55255 > 10.57.4.20.otv: OTV, flags [I] (0x08), overlay 0, instance 1
IP 192.168.11.10 > 192.168.10.10: ICMP echo request, id 26972, seq 16, length 64
......

可以看到也是两层包头,外层包头显示这是otv(overlay transport virtualization)包,对于otv,用一句话解释:

OTV is a "MAC in IP" technique to extend Layer 2 domains over any transport

从上面的过程可以看出来,vxlan模式依赖udp协议和默认的4789端口,所以在云平台的ECS上使用vxlan模式,还是需要在安全组上把udp 4789端口放开

什么终极解决方案,弄了半天也是要设置安全组的哈哈哈!!

一些误解

  1. 是不是用了ipip/vxlan模式,网络策略就不起效了?

不是的,不管是ipip还是vxlan模式下,主机协议栈把外层包头摘掉后,会把原始数据包重新扔回协议栈,重走一遍netfilter的几个点,所以针对podIP的防火墙策略依旧会生效的;

对比几种常用的cni

  • flannel
    • vxlan模式兼容性强,但速度差一点
    • host-gw模式:只有二层直联的环境才能用,节点不能在多个子网,速度最快
    • 不支持network policy
  • calico
    • bgp在idc机房较合适,云平台不支持
    • ipip模式,兼容性强,速度比vxlan好,最推荐
    • 支持network policy
  • cilium
    • 性能好,也支持network policy,但对linux内核有要求(推荐是4.18以上)
    • 对于运维来说比较有难度,因为一切都是新的,没有iptables/ipvs,以前的排错经验用不上

解答上一篇问题

  • 使用ipvs模式时,k8s集群的每个节点会有一张叫kube-ipvs0的网卡,网卡下挂着所有的clusterIP,有什么作用?

看回上一篇文章的图一,ipvs工作在netfilter扩展点中的LOCAL_IN点(也就是INPUT点),之前的内容中提过,流量在经过IPIsLocal时,会判断目标IP是否为本机地址,如果是则会走INPUT点,否则走FORWATD;为了让ipvs能操作流量,必须先让流量先到达INPUT点,于是就把所有clusterIP都挂在kube-ipvs0上,所有访问clusterIP的流量到达IPIsLocal点时,主机协议栈都会认为这是去往本机的流量,转到INPUT点去;

  • 下面这条iptables规则到底有什么作用?
-A KUBE-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

首先要了解,现在的防火墙技术都是基于连接状态的基础之上的,就是常说的有状态的防火墙;

拿上面的pod-a和pod-b来举例,假设我们不允许pod-a访问pod-b,于是在host1上创建一条这样的iptables规则:

iptables -A FORWARD -t filter -s 192.168.10.10 -d 192.168.11.10 -j DROP

好了,这时候pod-a中去ping pod-b已经不通了,但是,pod-b中去ping pod-a也不通了,因为pod-a回pod-b的包也命中了上面那条策略;

当我们说:不允许pod-a访问pod-b,只是说不允许pod-a主动访问pod-b,但是允许pod-a被动访问pod-b

这个听着有点绕,类似你跟你的二逼朋友说:平时没事别主动给老子打电话,但老子打你电话你要接!

好了,问题来了,怎么标识这是主动和流量还是被动的流量呢?这个问题linux内核协议栈已经帮我们解决好了,linux内核协议栈会悄悄维护连接的状态:

  • 当pod-a向pod-b主动发送数据包时,到达pod-b时,连接状态为NEW;
  • 当pod-b主动向pod-a发送数据包,pod-a回给pod-b的数据包到达pod-b时,连接状态为ESTABLISHED;

于是我们只要优先放过所有的连接状态为ESTABLISHED的包就可以了,问题中的命令的作用正是这个:

-A KUBE-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-m conntrack是说使用连接追踪模块标识的数据包状态,--ctstate是connection track state(连接追踪状态)的简称,状态值有:NEW/ESTABLISHED/INVALID/RELATED等,各种状态的解释自行google;

上面这条规则的优先级一般都是最高的,如果放在其它限制规则的后面就没有意义了,不单是容器平台的防火墙策略,大多数云平台网络中ACL、安全组的策略也是这种玩法;

下一章我们来介绍pod的流量控制。

(上面的三张图,其中一张图中的有个细节是错误的,你看出来了吗?)

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 深入理解kubernetes(k8s)网络原理之一-pod连接主机

    对于刚接触k8s的人来说,最令人懵逼的应该就是k8s的网络了,如何访问部署在k8s的应用,service的几种类型有什么区别,各有什么使用场景,服务的负载均衡是...

    一生无聊
  • docker bridge 到 k8s pod 跨节点网络通信机制演进

    2020 还没来得及品味就即将过去一个季度,愿剩下的时光不被辜负。进入正题,docker container是单进程模式,能够解决一些单一的问题,在现实中,我们...

    用户5166556
  • 深入理解kubernetes(k8s)网络原理之六-同主机pod连接的几种方式及性能对比

    本来说这一篇是要撸个cni出来的,但感觉这个没什么好说的,cni的源码github一大堆了,大概的套路也就是把前面说的命令用go语言实现一下,于是本着想到啥写啥...

    一生无聊
  • 2.2 Kubernetes--网络通讯

      k8s的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中, 这在GCE(Google Compute Engine)里面是线程的网络模型, ...

    用户7798898
  • Kubernetes容器云平台实践

    Kubernetes是Google开源的一个容器编排引擎,它支持自动化部署、大规模可伸缩、应用容器化管理。伴随着云原生技术的迅速崛起,如今Kubernetes ...

    孙杰
  • k8s基本原理

    前面hello world程序中,对于如何访问到服务,有必要了解一下k8s的网络模型,在这之前先介绍docker的网络模型

    kinnylee
  • Jenkins连接k8s的多种姿势

    a、在实际生产环境中,由于某些历史原因我们或许不能完美的实现所谓的一切皆“云原生”,例如有传统的jenkins和执行专有任务的slave节点

    仙人技术
  • 在Kubernetes中简化多集群

    客座文章作者:Gianluca Arbezzano,Equinix Metal 软件工程师,CNCF 大使;Alex Palesandro,都灵理工学院研究助理

    CNCF
  • 深入理解kubernetes(k8s)网络原理之四-pod流量控制

    在前面的几篇文章中,我们解决了pod连接主机、pod连接外网、pod与相同节点或不同节点的pod连接、用clusterIP和nodeport的方式访问pod等几...

    一生无聊
  • 跨VPC或者跨云供应商搭建K8S集群正确姿势-番外篇

    上周发了几篇关于Kubernetes集群搭建相关的文章,里面有一个部分谈到了Kubernetes集群CNI插件(也就是容器网络接口)的部署,很多读者看到了这个部...

    云爬虫技术研究笔记
  • Kubernetes架构学习笔记

    Kubernetes是Google开源的容器集群管理系统,其提供应用部署、维护、 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用,是...

    kubernetes中文社区
  • 史上最全Kubernetes资料集萃!菜鸟变高手这一篇就够了

    Kubernetes是一个全新的基于容器技术的分布式架构领先方案, 它是Google在2014年6月开源的一个容器集群管理系统,使用Go语言开发,Kuberne...

    小小科
  • 艾编程arry老师课堂笔记:kubernetes K8S基于Docker安装部署

    在Docker容器技术被炒得热火朝天之时,大家发现,如果想要将Docker应用于具体的业务实现,是存在困难的——编排、管理和调度等各个方面,都不容易。于是,人们...

    艾编程
  • 跨VPC或者跨云供应商搭建K8S集群正确姿势-番外篇

    上周发了几篇关于Kubernetes集群搭建相关的文章,里面有一个部分谈到了Kubernetes集群CNI插件(也就是容器网络接口)的部署,很多读者看到了这个部...

    我的小碗汤
  • kubernetes集群网络

    问题:Pod是K8S最小调度单元,一个Pod由一个容器或多个容器组成,当多个容器时,怎么都用这一个Pod IP?

    yuezhimi
  • 为容器时代设计的高级 eBPF 内核特性(FOSDEM, 2021)

    本文翻译自 2021 年 Daniel Borkmann 在 FOSDEM 的一篇分享:Advanced eBPF kernel features for th...

    米开朗基杨
  • 腾讯云私有化容器平台之网络

    刚开始接触容器集群的人会发现,与在单节点上使用容器相比,容器集群一个很复杂的领域就是网络。Kubernetes 作为容器编排领域的事实标准,对容器集群的网络进行...

    腾讯云原生
  • 了解 Kubernetes

    Docker 虽好用,但面对强大的集群,成千上万的容器,突然感觉不香了。这时候就需要我们的主角 Kubernetes 上场了,先来了解一下 Kubernetes...

    耕耘实录
  • 杨雨:Tungsten Fabric如何增强Kubernetes的网络性能

    在混合多云的世界里,Kubernetes是如此流行,已经成为应用统一部署和管理的事实标准,而Tungsten Fabric与Kubernetes的集成,更增强了...

    Tungsten Fabric

扫码关注云+社区

领取腾讯云代金券