医院网站asp,设计网站开发方案流程,哪里有网站制作建设,可信网站是否必须做文章目录 Kubernetes Service的实现基础内容1. 命令 ip route show table all2. DNAT3. IPVS和iptables4. Service Service的实现简述 Kubernetes Service的实现
基础内容
在了解Service之前,需要先了解一些额外的知识:
命令: ip route show table allDNATIPVS和iptables基础… 文章目录 Kubernetes Service的实现基础内容1. 命令 ip route show table all2. DNAT3. IPVS和iptables4. Service Service的实现简述 Kubernetes Service的实现
基础内容
在了解Service之前,需要先了解一些额外的知识:
命令: ip route show table allDNATIPVS和iptables基础的网络知识(网关,网段或子网,转发)
1. 命令 ip route show table all
这条命令会列出主机内所有的路由.内容展示包含了对应的网段或者IP,要通过那个虚拟设备发送出去.示例:
rootdebian:~/kubernetes# ip route show table all
default via 10.0.0.2 dev ens33 onlink
10.0.0.0/24 dev ens33 proto kernel scope link src 10.0.0.50
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
local 10.0.0.50 dev ens33 table local proto kernel scope host src 10.0.0.50
broadcast 10.0.0.255 dev ens33 table local proto kernel scope link src 10.0.0.50
local 10.96.0.1 dev kube-ipvs0 table local proto kernel scope host src 10.96.0.1
......摘取一条,比如:local 10.96.0.1 dev kube-ipvs0 table local proto kernel scope host src 10.96.0.1 local这表示这是一个本地路由用于指示目标地址是本地主机。 10.96.0.1目标地址,即要匹配的 IP 地址. dev kube-ipvs0指定了数据包应该通过的网络接口即 kube-ipvs0. table local指定了路由表名称,即 local 表. proto kernel表示该路由表项是内核生成的. scope host表示该路由的作用域仅限于本地主机. src 10.96.0.1源 IP 地址,即数据包的出站地址.
2. DNAT
在网络中发送数据包,都是要写明源IP地址及目标IP地址等信息的.可以参考OSI模型. 而DNAT就是,修改数据包中的目标IP为另一个IP,源IP不变.然后重新把这个数据包发送出去.实际上就是一个转发.
3. IPVS和iptables
kube-proxy是k8s中的一个组件.主要负责网络相关的事情,或者说Service就是基于kube-proxy实现的. 而kube-proxy实际上是调用了系统的iptables和IPVS.所以Service也是基于他们两个实现的. 前者是防火墙,后者是一个性能更好的转发服务.两者在k8s集群中起到的作用都是转发数据包,也就是DNAT.
查看IPVS
rootdebian:~/kubernetes# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size4096)
Prot LocalAddress:Port Scheduler Flags- RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.96.0.1:443 rr- 10.0.0.50:6443 Masq 1 3 0
TCP 10.96.0.10:53 rr- 10.244.0.24:53 Masq 1 0 0 - 10.244.0.25:53 Masq 1 0 0
TCP 10.96.0.10:9153 rr- 10.244.0.24:9153 Masq 1 0 0 - 10.244.0.25:9153 Masq 1 0 0
TCP 10.107.158.131:80 rr- 10.244.0.30:80 Masq 1 0 0 - 10.244.0.33:80 Masq 1 0 0 - 10.244.0.34:80 Masq 1 0 0
UDP 10.96.0.10:53 rr- 10.244.0.24:53 Masq 1 0 0 - 10.244.0.25:53 Masq 1 0 0 rr表示轮询策略。 4. Service
Service 是一种抽象用于定义一组 Pod 的逻辑网络端点。它是 Kubernetes 集群内部的一种资源对象用于实现服务发现和负载均衡。 Service对应了一组endpoint。每个endpoint都是一个Pod的IP地址他是基于IPVS实现的所以你访问Service可以转发到对应的Pod上。 示例
rootdebian:~/kubernetes# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 none 443/TCP 34d
nginx ClusterIP 10.107.158.131 none 80/TCP 36m现在集群里有一个nginx的Service。
rootdebian:~/kubernetes# kubectl get endpoints -o wide
NAME ENDPOINTS AGE
kubernetes 10.0.0.50:6443 34d
nginx 10.244.0.30:80,10.244.0.33:80,10.244.0.34:80 36m查看他们对应的endpoints可以看到nginx对应了三个IP地址。
rootdebian:~/kubernetes# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-6595874d85-5hpvq 1/1 Running 0 4m9s 10.244.0.33 master none none
nginx-deployment-6595874d85-mm2m5 1/1 Running 0 4m9s 10.244.0.34 master none none
nginx-deployment-6595874d85-qtnwb 1/1 Running 0 41m 10.244.0.30 master none none最后我们看一下Pod的IP地址和endpoint的是完全对应的。而endpoints和Service ClusterIP的地址也是在上面ipvs表中可以找到对应关系的。
所以当创建或者更新了一个Pod的时候controller会去同步更新endpoint的地址。接下来endpoint通知kube-proxykube-proxy更新IPVS的规则。
Service的实现 当Pod对一个Service发起请求后
首先通过集群DNS解析到Service的IP地址。然后数据包源IP填写为当前Pod自己的IP目标IP填写为对应的Service的IP然后这个数据包通过虚拟设备来到宿主机。 对于虚拟设备和如何来到宿主机可以参考docker 网络通信原理kubernetes flannel 网络flannel的host-gw与calico。或者参考 深入剖析 Kubernetes 张磊。 数据包来到宿主机后这里就和Pod和Pod通信不同了。 通过命令可以看到service的IP地址和Pod的IP地址完全不是一个网段
rootdebian:~/kubernetes# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-6595874d85-5hpvq 1/1 Running 0 14m 10.244.0.33 master none none
nginx-deployment-6595874d85-mm2m5 1/1 Running 0 14m 10.244.0.34 master none none
nginx-deployment-6595874d85-qtnwb 1/1 Running 0 51m 10.244.0.30 master none none
rootdebian:~/kubernetes# kubectl get service -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.96.0.1 none 443/TCP 34d none
nginx ClusterIP 10.107.158.131 none 80/TCP 50m appnginxPod的地址是10.244.0.30而Service的地址是10.107.158.131。 这就意味着请求Service的数据包来到宿主机内核后不能像其他到Pod的数据包一样直接通过CNI进行转发。
所以接下来查看下路由表
rootdebian:~/kubernetes# ip route show table all|grep 10.107.158.131
local 10.107.158.131 dev kube-ipvs0 table local proto kernel scope host src 10.107.158.131在这里可以看到。路由表中过滤了一下对应的IP地址可以看到他要通过kube-ipvs0这个虚拟设备发出。 这个虚拟设备也是kube-proxy添加的了这个虚拟设备就像一根网线一端在宿主机上一段对接到了IPVS。数据包接下来通过kube-ipvs0发送给了IPVSIPVS根据自己的策略轮询选择一个endpoints
# 这里只截取了重要部分
rootdebian:~/kubernetes# ipvsadm -Ln
TCP 10.107.158.131:80 rr- 10.244.0.30:80 Masq 1 0 0 - 10.244.0.33:80 Masq 1 0 0 - 10.244.0.34:80 Masq 1 0 0 IPVS里有目标IP为10.107.158.131的这一条记录。然后从对应的这三个IP轮询获取一个重新DNAT数据包比如选择了10.244.0.30这个IP那么DNAT后数据包的目标IP就改为了10.244.0.30。
IPVS自己是发送不了数据包的。他只能把这个数据包重新发送到宿主机的网络栈里。但是这个时候经过IPVS加工处理过的数据包和Pod请求Pod的数据包没什么区别了。源IP是发送数据包的Pod的IP目标是nginx 的一个Pod的IP。 所以主机内核就会根据路由表找到目标IP所在的主机节点发送出去。这里会根据使用的CNI和模式的不同采取的策略也不同同样参考上面的文档。但是数据包已经可以正常发送到对端Pod了。
简述
数据包从pod内发出后在主机内核匹配路由表转发给了IPVS。IPVS虽然说是负载但是实际上只做了一个DNAT的操作。然后操作结束后数据包的目标IP就不再是Service的而是对端Pod的了。接下来数据包重新发送到主机网络栈主机网络栈就可以根据CNI配置的规则进行下一步的转发了。
对于IPVS如何知道Pod的IP是因为contaoller manage在创建Pod后会更新endpoints然后告知 kube-proxy。kube-proxy会去操作修改IPVS的规则表。这样IPVS就可以轮流的使用多个IP转发数据包了。
所以kube-proxy实际上是操作的IPVS去工作。他们负责给每个节点的IPVS规则表里加上整个集群的Service对应endpoints的规则。当集群Service较多的时候iptables的性能就不如IPVS了。
