k8s的服务发现机制
1. k8s的服务发现机制每个k8s中的service都会有一个唯一的Cluster IP以及唯一的名字,名字是由开发者自己定义的,部署的时候比没有必要改变,所以完全可以固定在配置中。如何通过k8s的Service name找到Cluster IP呢?最早的时候采用了Linux环境变量的方式解决这个问题,即每个Service生成一些对应的Linux环境变量(ENV),并且在每个Pod的容器在启动时
1. k8s的服务发现机制
-
每个k8s中的service都会有一个唯一的Cluster IP以及唯一的名字,名字是由开发者自己定义的,部署的时候比没有必要改变,所以完全可以固定在配置中。
-
如何通过k8s的Service name找到Cluster IP呢?
-
最早的时候采用了Linux环境变量的方式解决这个问题,即每个Service生成一些对应的Linux环境变量(ENV),并且在每个Pod的容器在启动时自动注入这些环境变量。
-
目前通过Add-On增值包的方式引入DNS系统,把服务名作为DNS域名,这样就可以直接使用服务来建立通信了。
-
2. 外部系统访问Service的问题
-
k8s里的“三个IP”概念:
- Node IP:Node节点的IP地址。
- 是k8s集群中每个节点的物理网卡的IP地址,这是真实存在的物理网络,所有属于这个网络的服务器之间都能通过这个网络直接通信。
- k8s集群之外的节点访问k8s集群内部的节点或者TCP/IP服务的时候,必须要通过Node IP进行通信。
- Pod IP:Pod的IP地址。
- 是每个Pod的IP地址,虚拟的二层网络。是Docker Engine根据docker0网桥的IP地址段进行分配的。
- k8s里的一个Pod容器通过Pod IP访问另一个Pod里的容器,真实的CTP/IP流量通过Node IP物理网卡流出的。
- Cluster IP:Service 的IP地址。
- 虚拟的IP,仅作用于Service这个对象,由k8s管理和分配IP地址(来源于Cluster IP地址池)
- 单独的Cluster IP不具备TCP/IP通信基础。
k8s集群外部的用户访问k8s的服务是通过NodePort来实现的,例如
apiVersion: v1 kind: Service metadata: name: tomcat-service spec: type: NodePort ports: - port: 8080 nodePort: 31002 selector: tier: frontend
其中,nodePort:31002表明我们手动指定tomcat-service的NodePort为31002,否则k8s会自动分配一个可用的端口。
NodePort的实现方式是在Kubernetes集群的每个Node上需要为外部访问的Service开启一个对应的TCP监听端口。外部系统只要用任意一个Node的IP地址+具体的NodePort端口号就可以访问此服务,在任意Node上运行netstat命令,可以看到NodePort端口被监听。
[root@node2 test]# netstat -tunlp | grep 31002 tcp 0 0 0.0.0.0:31002 0.0.0.0:* LISTEN 3385/kube-proxy
外部访问Service还有一个问题——负载均衡问题,此时需要一个负载均衡器,外部的请求只需要访问此负载均衡器的IP地址,由负载均衡器负责转发流量到后面某个Node的NodePort上。
- Node IP:Node节点的IP地址。
Load balancer组件独立于k8s集群之外,通常是一个硬件的负载均衡器或者以软件的方式实现,例如HAProxy或者Nginx。
更多推荐
所有评论(0)