云原生系列「二」Kubernetes网络详解
前言
K8s是一个强大的平台,但它的网络比较复杂,涉及很多概念,例如Pod网络,Service网络,Cluster IPs,NodePort,LoadBalancer和Ingress等等,这么多概念足以让新手望而生畏。但是,只有深入理解K8s网络,才能为理解和用好K8s打下坚实基础。为了帮助大家理解,模仿TCP/IP协议栈,我把K8s的网络分解为四个抽象层,从0到3,除了第0层,每一层都是构建于前一层之上,如下图所示:
第0层Node节点网络比较好理解,也就是保证K8s节点(物理或虚拟机)之间能够正常IP寻址和互通的网络,这个一般由底层(公有云或数据中心)网络基础设施支持。第0层我们假定已经存在,所以不展开。第1到3层网络,我将分三篇文章,分别进行剖析,本文是第一篇Pod网络。
注意,本文旨在帮助大家建立K8s网络的概念模型,而不是对底层技术的精确描述。实际我们学技术以应用为主,重要的是快速建立起直观易懂的概念模型,能够指导我们正常应用即可,当然理解一定的技术细节也是有帮助的。另外,本文假定读者对基本的网络技术,ip地址空间和容器技术等有一定的了解。
Pod网络概念模型
Pod相当于是K8s云平台中的虚拟机,它是K8s的基本调度单位。所谓Pod网络,就是能够保证K8s集群中的所有Pods(包括同一节点上的,也包括不同节点上的Pods),逻辑上看起来都在同一个平面网络内,能够相互做IP寻址和通信的网络,下图是Pod网络的简化概念模型:
Pod网络构建于Node节点网络之上,它又是上层Service网络的基础。为了进一步理解Pod网络,我将对同一节点上的Pod之间的网络,以及不同节点上的Pod之间网络,分别进行剖析。
同一节点上的Pod网络
前面提到,Pod相当于是K8s云平台中的虚拟机,实际一个Pod中可以住一个或者多个(大多数场景住一个)应用容器,这些容器共享Pod的网络栈和其它资源如Volume。那么什么是共享网络栈?同一节点上的Pod之间如何寻址和互通?我以下图样例来解释:
上图节点上展示了Pod网络所依赖的3个网络设备,eth0是节点主机上的网卡,这个是支持该节点流量出入的设备,也是支持集群节点间IP寻址和互通的设备。docker0是一个虚拟网桥,可以简单理解为一个虚拟交换机,它是支持该节点上的Pod之间进行IP寻址和互通的设备。veth0则是Pod1的虚拟网卡,是支持该Pod内容器互通和对外访问的虚拟设备。docker0网桥和veth0网卡,都是linux支持和创建的虚拟网络设备。
上图Pod1内部住了3个容器,它们都共享一个虚拟网卡veth0。内部的这些容器可以通过localhost相互访问,但是它们不能在同一端口上同时开启服务,否则会有端口冲突,这就是共享网络栈的意思。Pod1中还有一个比较特殊的叫pause的容器,这个容器运行的唯一目的是为Pod建立共享的veth0网络接口。如果你SSH到K8s集群中一个有Pod运行的节点上去,然后运行docker ps,可以看到通过pause命令运行的容器。
Pod的IP是由docker0网桥分配的,例如上图docker0网桥的IP是172.17.0.1,它给第一个Pod1分配IP为172.17.0.2。如果该节点上再启一个Pod2,那么相应的分配IP为172.17.0.3,如果再启动Pod可依次类推。因为这些Pods都连在同一个网桥上,在同一个网段内,它们可以进行IP寻址和互通,如下图所示:
从上图我们可以看到,节点内Pod网络在172.17.0.0/24这个地址空间内,而节点主机在10.100.0.0/24这个地址空间内,也就是说Pod网络和节点网络不在同一个网络内,那么不同节点间的Pod该如何IP寻址和互通呢?下一节我们来分析这个问题。
不同节点间的Pod网络
实际上不同节点间的Pod网络互通,有很多技术实现方案,底层的技术细节也很复杂。为了简化描述,我把这些方案大体分为两类,一类是路由方案,另外一类是覆盖(Overlay)网络方案。
如果底层的网络是你可以控制的,比如说企业内部自建的数据中心,并且你和运维团队的关系比较好,可以采用路由方案,如下图所示:
如果底层的网络是你无法控制的,比如说公有云网络,或者企业的运维团队不支持路由方案,可以采用覆盖(Overlay)网络方案,如下图所示:
CNI简介
总结
- K8s的网络可以抽象成四层网络,第0层节点网络,第1层Pod网络,第2层Service网络,第3层外部接入网络。除了第0层,每一层都构建于上一层之上。
- 一个节点内的Pod网络依赖于虚拟网桥和虚拟网卡等linux虚拟设备,保证同一节点上的Pod之间可以正常IP寻址和互通。一个Pod内容器共享该Pod的网络栈,这个网络栈由pause容器创建。
- 不同节点间的Pod网络,可以采用路由方案实现,也可以采用覆盖网络方案。路由方案依赖于底层网络设备,但没有额外性能开销,覆盖网络方案不依赖于底层网络,但有额外封包解包开销。
- CNI是一个Pod网络集成标准,简化K8s和不同Pod网络实现技术的集成。
Service网络概念模型
我们假定第1层Pod网络已经存在,下图是K8s的第2层Service网络的简化概念模型:
- 服务发现(Service Discovery): Client Pod如何发现定位Account-App集群中Pod的IP?况且Account-App集群中Pod的IP是有可能会变的(英文叫ephemeral),这种变化包括预期的,比如Account-App重新发布,或者非预期的,例如Account-App集群中有Pod挂了,K8s对Account-App进行重新调度部署。
- 负载均衡(Load Balancing):Client Pod如何以某种负载均衡策略去访问Account-App集群中的不同Pod实例?以实现负载分摊和HA高可用。
实际上,K8s通过在Client和Account-App的Pod集群之间引入一层Account-Serivce抽象,来解决上述问题:
- 服务发现:Account-Service提供统一的ClusterIP来解决服务发现问题,Client只需通过ClusterIP就可以访问Account-App的Pod集群,不需要关心集群中的具体Pod数量和PodIP,即使是PodIP发生变化也会被ClusterIP所屏蔽。注意,这里的ClusterIP实际是个虚拟IP,也称Virtual IP(VIP)。
- 负载均衡:Account-Service抽象层具有负载均衡的能力,支持以不同策略去访问Account-App集群中的不同Pod实例,以实现负载分摊和HA高可用。K8s中默认的负载均衡策略是RoundRobin,也可以定制其它复杂策略。
K8s中为何要引入Service抽象?背后的原理是什么?后面我将以技术演进视角来解释这些问题。
服务发现技术演进
DNS域名服务是一种较老且成熟的标准技术,实际上DNS可以认为是最早的一种服务发现技术。
- 不同DNS客户端实现功能有差异,有些客户端每次调用都会去查询DNS服务,造成不必要的开销,而有些客户端则会缓存DNS信息,默认超时时间较长,当目标PodIP发生变化时(在容器云环境中是常态),存在缓存刷新不及时,会导致访问Pod失效。
- DNS客户端实现的负载均衡策略一般都比较简单,大都是RoundRobin,有些则不支持负载均衡调用。
- 首先,在服务Pod实例发布时(可以对应K8s发布中的Kind: Deployment),Kubelet会负责启动Pod实例,启动完成后,Kubelet会把服务的PodIP列表汇报注册到Master节点。
- 其次,通过服务Service的发布(对应K8s发布中的Kind: Service),K8s会为服务分配ClusterIP,相关信息也记录在Master上。
- 第三,在服务发现阶段,Kube-Proxy会监听Master并发现服务ClusterIP和PodIP列表映射关系,并且修改本地的linux iptables转发规则,指示iptables在接收到目标为某个ClusterIP请求时,进行负载均衡并转发到对应的PodIP上。
- 运行时,当有消费者Pod需要访问某个目标服务实例的时候,它通过ClusterIP发起调用,这个ClusterIP会被本地iptables机制截获,然后通过负载均衡,转发到目标服务Pod实例上。
注意,K8s的服务发现机制和目前微服务主流的服务发现机制(如Eureka + Ribbon)总体原理类似,但是也有显著区别(这些区别主要体现在客户端):
- 首先,两者都是采用客户端代理(Proxy)机制。和Ribbon一样,K8s的代理转发和负载均衡也是在客户端实现的,但Ribbon是以Lib库的形式嵌入在客户应用中的,对客户应用有侵入性,而K8s的Kube-Proxy是独立的,每个Worker节点上有一个,它对客户应用无侵入。K8s的做法类似ServiceMesh中的边车(sidecar)做法。
- 第二,Ribbon的代理转发是穿透的,而K8s中的代理转发是iptables转发,虽然K8s中有Kube-Proxy,但它只是负责服务发现和修改iptables(或ipvs)规则,实际请求是不穿透Kube-Proxy的。注意早期K8s中的Kube-Proxy代理是穿透的,考虑到有性能损耗和单点问题,后续的版本就改成不穿透了。
- 第三,Ribbon实现服务名到服务实例IP地址的映射,它只有一层映射。而K8s中有两层映射,Kube-Proxy实现ClusterIP->PodIP的映射,Kube-DNS实现ServiceName->ClusterIP的映射。
总结
- K8s的Service网络构建于Pod网络之上,它主要目的是解决服务发现(Service Discovery)和负载均衡(Load Balancing)问题。
- K8s通过一个ServiceName+ClusterIP统一屏蔽服务发现和负载均衡,底层技术是在DNS+Service Registry基础上发展演进出来。
- K8s的服务发现和负载均衡是在客户端通过Kube-Proxy + iptables转发实现,它对应用无侵入,且不穿透Proxy,没有额外性能损耗。
- K8s服务发现机制,可以认为是现代微服务发现机制和传统Linux内核机制的优雅结合。
NodePort
先提前强调一下,NodePort是K8s将内部服务对外暴露的基础,后面的LoadBalancer底层有赖于NodePort。
LoadBalancer
Ingress
有了前面的NodePort + LoadBalancer,将K8s内部服务暴露到外网甚至公网的需求就已经实现了,那么为啥还要引入Ingress这样一个概念呢?它起什么作用?
注意,上图的Ingress概念模型是一种更抽象的画法,隐去了K8s集群中的节点,实际HostPort是暴露在节点上的。
注意,Ingress是一个7层反向代理,如果你要暴露的是4层服务,还是需要走独立LB+IP方式。
Kubectl Proxy & Port Forward
上面提到的服务暴露方案,包括NodePort/LoadBalancer/Ingress,主要针对正式生产环境。如果在本地开发测试环境,需要对本地部署的K8s环境中的服务或者Pod进行快速调试或测试,还有几种简易办法,这边一并简单介绍下,如下图所示:
- 办法一,通过kubectl proxy命令,在本机上开启一个代理服务,通过这个代理服务,可以访问K8s集群内的任意服务。背后,这个Kubectl代理服务通过Master上的API Server间接访问K8s集群内服务,因为Master知道集群内所有服务信息。这种方式只限于7层HTTP转发。
- 办法二,通过kubectl port-forward命令,它可以在本机上开启一个转发端口,间接转发到K8s内部的某个Pod的端口上。这样我们通过本机端口就可以访问K8s集群内的某个Pod。这种方式是TCP转发,不限于HTTP。
- 办法三,通过kubectl exec命令直接连到Pod上去执行linux命令,功能类似docker exec。
总结
- NodePort是K8s内部服务对外暴露的基础,LoadBalancer底层有赖于NodePort。NodePort背后是Kube-Proxy,Kube-Proxy是沟通Service网络、Pod网络和节点网络的桥梁。
- 将K8s服务通过NodePort对外暴露是以集群方式暴露的,每个节点上都会暴露相应的NodePort,通过LoadBalancer可以实现负载均衡访问。公有云(如阿里云/AWS/GCP)提供的K8s,都支持自动部署LB,且提供公网可访问IP,LB背后对接NodePort。
- Ingress扮演的角色是对K8s内部服务进行集中反向代理,通过Ingress,我们可以同时对外暴露K8s内部的多个服务,但是只需要购买1个(或者少量)LB。Ingress本质也是一种K8s的特殊Service,它也通过HostPort(80/443)对外暴露。
- 通过Kubectl Proxy或者Port Forward,可以在本地环境快速调试访问K8s中的服务或Pod。
- K8s的Service发布主要有3种type,type=ClusterIP,表示仅内部可访问服务,type=NodePort,表示通过NodePort对外暴露服务,type=LoadBalancer,表示通过LoadBalancer对外暴露服务(底层对接NodePort,一般公有云才支持)。
至此,Kubernetes网络三部曲全部讲解完成,希望这三篇文章对你理解和用好K8s有帮助。下表是对三部曲的浓缩总结,是希望大家带走记住的:
云原生系列「二」Kubernetes网络详解相关推荐
- 云原生系列「三」容器网络
Docker的网络实现 标准的Docker支持以下4类网络模式. ◎ host模式:使用--net=host指定. ◎ container模式:使用--net=container:NAME_or_ID ...
- 云原生系列「五」我为啥又看上了serviceMesh?
上一篇文章,说到为什么不看好服务网格,核心是没有强大的运维监控以及性能问题,那么lstio的出现让那个我们看到了一线曙光.因为实际生产活动中,各种运营上报.https证书各种对接.各种监控指标采集.流 ...
- 云原生系列「四」我为啥不看好ServiceMesh?
前言 今年,ServiceMesh(服务网格)概念在社区里头非常火,有人提出2018年是ServiceMesh年,还有人提出ServiceMesh是下一代的微服务架构基础.作为架构师,如果你现在还不了 ...
- 云原生系列「0」容器概述
一.Docker概述 Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的Linux或Windows 机器上,也可以实现虚拟化. 1. ...
- 【云原生】Helm 架构和基础语法详解
文章目录 一.概述 二.Helm 架构 三.Helm 安装 四.Helm 组件及相关术语 五.Helm Chart 详解 1)Chart 目录结构 2)Chart.yaml 文件 3)Chart 依赖 ...
- java g1的并行_「g1」JVM G1详解 - seo实验室
g1 当我们调优java程序时,通常的目标有两个: 响应能力 或者 吞吐量 响应能力 响应能力指一个程序或者系统对请求的是否能够及时响应. 比如: 一个桌面UI能多快的响应一个事件: 一个网站能够多快 ...
- 云原生系列 【基于CCE Kubernetes编排实战二】
✅作者简介: CSDN内容合伙人,全栈领域新星创作者,阿里云专家博主,阿里云问答板块版主,华为云享专家博主,掘金后端评审团成员
- 云原生系列 【基于CCE Kubernetes编排实战】
✅作者简介: CSDN内容合伙人,全栈领域新星创作者,阿里云专家博主,华为云享专家博主,掘金后端评审团成员
- Elasticsearch系列「二」如何物理删除给定期限的历史数据?
1.题记 想到删除,基础认知是delete,细分为删除文档(document)和删除索引:要删除历史数据,基础认知是:删除了给定条件的数据,用delete_by_query. 实际操作发现: - ...
最新文章
- C++知识点杂记1——typedef、static_cast、const_cast、遍历二维数组、聚合类
- python求向量与x轴的夹角_2020届石家庄高考模拟题,参数方程解决向量问题
- Python 技术篇-获取requests里的二进制文本并保存为音频、图片文件,提取requests里的多媒体信息
- 点击出现黑色背景的解决
- 前端学习(3287):Aop2
- java 字符串第一个字符_深入Java源码剖析之字符串常量
- 【registry】registry AbstractMethodError javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws
- Paint的方法总结(一):基本常用Api
- 该来的还是要来,数据挖掘
- 从零开始学androidNotification通知.四十四.
- 计算机软件资格好考吗,计算机软件资格辅导哪个好
- 【iOS开发】实现App内替换图标
- python 姓名转拼音
- 项目笔记:EGO商城
- 中职计算机英语教学大纲,中等职业学校英语教学大纲
- 东方博宜oj平台c 语言题库答案,东方博宜OJ
- 如何在谷歌地图(google maps)中获取经纬度
- 雷军投资“style”:不熟不投 找准“台风口”
- 鹰偶尔飞的比鸡低,但鸡永远也飞不了鹰那么高!
- flutter 欢迎页
热门文章
- 2014年度辛星解读css第四节
- xib和storyboard小谈,
- andengine游戏引擎总结基础篇
- 全球变暖java_第九届 蓝桥杯 JavaB组 全球变暖
- 计算机分组教学,中职计算机教学分组协作式学习论文
- 用c语言编程矩阵乘法,c语言矩阵相乘
- python 并行计算库_Python 大规模数据存储与读取、并行计算:Dask库简述
- 脚本必须位于html的,js 前端第三剑客
- java动物乐园_基于jsp的动物园管理系统-JavaEE实现动物园管理系统 - java项目源码...
- 四十五、和我一起看看,国外的Python考试到底是怎么样(上篇)