以下内容作为这段时间研究Kubernetes网络的总结,一口气写完,代表了当前对Kubernetes网络的认知,可能有误,权当摆龙门阵。
我们理一理Kubernetes相关概念和网络的关系
可以看到,Kubernetes的网络主要有以下几个方面
还有一个方面没有提到,但也很重要
总计五个方面。
总结一下用到的底层技术
Kube-proxy
Kubelet
API Server
ETCD
Scheduler
RC
CoreDNS
与网络相关的有
Kube-proxy:其主要职责就是负责Service的实现,它定期拉取集群的网络配置,更新自己的规则。有三种工作模式
CoreDNS:负责域名解析系统
CNI插件:CNI接口基本来说就两个
所以他就是集群的IP管理系统,同时网络分配后,它还需要确保网络的可达性,毕竟网络分配方式是你规定的,自然也只有你知道如何才能访问到对应的网络。你看,都保证可达性了,网络策略就是在限制各种可达性,这不又得支持一下,所以总结起来就是
Kube-proxy和CNI的关系?
Kube-poxy应该说是建立在CNI之上的,它不管Service背后的网络是否能够被访问到,只管将数据包转发过去就行了。保证这个数据包能够正确到达目的地是CNI插件的事情。
通常所说的K8s网络解决方案,指的就是各种CNI插件。这是CNI插件的主页:https://github.com/containernetworking/cni。可以看到不只是Kubernetes采用了CNI,Open Shift、Mesos等都采用了CNI。
一般Flannel和Callico会被放在一起比较
我们可以看到,K8s的网络包括CNI插件解决的是最最基本的问题:可达性。但是在实际开发中,还有大量的应用层面的共性任务需要处理
Service Mesh就是为了解决这些问题出现的,云计算的发展趋势就是这样,逐步将底层共性的技术抽象出来,通过底座的形式提供,这种发展的终极形式看起来就是Serverless。当然,Serverless有冷启动、可靠性等固有缺点,因此只能用来提供弱业务的功能。强业务方面,短时间看就是K8s了。Service Mesh就是这一脉络的发展方向。
至于说Service Mesh和网络有什么关系呢?
我们知道,传统K8s的网络架构如下
Service Mesh在每个Pod中注入一个sidecar,相当于把Service融入到了每个Pod,这样管理起来更加灵活。与此同时,K8s的Service就可以不要了
网络的特殊性,使得能够拦截网络流量的组件能够做很多事,比如CNI看起来只是分配了网络,但还负责网络的可达性和访问策略,甚至有的CNI插件也会实现Service功能;Istio在每个pod注入的side car将Kubernetes Service替换掉了。看起来一个网络库能够实现所有K8s网络相关服务,但其实不是的,总体还是CNI插件提供基础网络能力;上层库如Envoy提供应用层能力。
说到将Service融入每个Pod,Cilium也做了类似的事,不过更进一步,它是在内核层面做这件事,Istio是通过用户态程序Envoy实现,相比之下效率慢了不少。那Envoy和Cilium的关系是什么呢?
还是一个应用层、一个网络基础层,它们之间的关系大概如下
有了Istio,还需要CNI插件吗?
当然还是需要的,尽管Istio自己也有提供CNI插件,但那也是CNI插件呀。