k8s的服务发现机制

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上。

Load balancer组件独立于k8s集群之外，通常是一个硬件的负载均衡器或者以软件的方式实现，例如HAProxy或者Nginx。