0%

《Kubernetes》Service的实现原理

K8s中有哪些网络

k8s中包含3中网络

  1. node ip的网络。是真实网络
  2. pod ip的网络。虚拟网络
  3. service ip网络。虚拟网络

Pod IP地址实际存在于某个网卡(可以是虚拟设备)上,而Service的地址却是一个虚拟IP地址,没有任何网络接口配置此地址

它由kube-proxy借助iptables规则或ipvs规则重新定向到本地端口,再将其调度至后端Pod对象。Service的IP地址是集群提供服务的接口,也称为Cluster IP。

Kubernetes为每个Pod都附属了gcr.io/google_containers/pause:latest,这个容器只接管Pod的网络信息,提供pod的虚拟网卡。此容器随着pod创建而创建,随着Pod删除而删除。

k8s的网络插件Flannel保证各个node中的pod都处于一个网络平面下,可以通过pod ip直接访问

Service

比如

1
2
3
4
5
6
7
8
9
10
11
12
kind: Service
apiVersion: v1
metadata:
name: bridge
spec:
type: NodePort
selector:
app: bridge
ports:
- protocol: TCP
port: 80
targetPort: 8000

表示service从80端口转发到pod的8000端口

带有selector的Service在创建时会同步创建对应的Endpoint,如果不带selector,则需要自己创建Endpoint对象,名称与Service的名称一样即可

Service负载均衡原理

首先kubeDNS(也是一个应用,部署在kube-system命名空间中,存在于老版本k8s中,现已被CoreDNS取代,但功能类似)监控到Service对象和Endpoint对象创建后会加一条 bridge -> 10.4.38.11(分配的,保证不重复,就是Service的cluster ip)到DNS配置中

k8s安装时kubeDNS就通过kubelet修改了每个节点的文件/etc/resolv.conf,其中配了DNS服务器指向kubeDNS的Service的ClusterIP,那么每个容器中的应用访问任何域名都会去找kubeDNS解析ip,那么bridge域名会解析到10.4.38.11

同时kube-proxy会在每个节点的iptables中加上一条规则(iptables 代理模式下)

10.4.38.11:80 -> 32451(随机决定的端口,但会保证不冲突,每个节点都会监听这个端口,访问这个端口的流量会被kube-proxy负载均衡到各个节点的pod上)

这样的话访问bridge:80的流量都流向10.4.38.11:80然后通过iptables流向10.4.38.11:32451,然后被kube-proxy负载均衡到各个节点的pod上




微信关注我,及时接收最新技术文章