【Kubernetes学习笔记】-服务访问之 IP & Port & Endpoint 辨析

目录

• 不一样类型的IP
  • Pod IP
  • Cluster IP
• 不一样类型的Port
  • port
  • nodePort
  • TargetPort
  • containerPort
  • hostPort
• Endpoint
  • Endpoint Controller
  • 定义 Endpoint
  • 使用Endpoint引用外部服务
  • 建立ExternalName类型的服务

当新手刚学习k8s时候，会被各类的IP 和port 搞晕，其实它们都与k8s service的访问有密切关系，梳理它们之间的差别能够更好了解k8s的服务访问机制。

不一样类型的IP

• Node IP：Node节点的IP地址。 节点物理网卡ip
• Pod IP：Pod的IP地址。 Docker Engine根据docker0网桥的IP地址段进行分配的，一般是一个虚拟的二层网络
• Cluster IP：Service的IP地址。 属于Kubernetes集群内部的地址，没法在集群外部直接使用这个地址

Pod IP

Pod IP 地址是实际存在于某个网卡(能够是虚拟设备)上的，但Service Cluster IP就不同了，没有网络设备为这个地址负责。它是由kube-proxy使用Iptables规则从新定向到其本地端口，再均衡到后端Pod的。

例如，当Service被建立时，Kubernetes给它分配一个地址10.0.0.1。这个地址从咱们启动API的service-cluster-ip-range参数(旧版本为portal_net参数)指定的地址池中分配，好比--service-cluster-ip-range=10.0.0.0/16。假设这个Service的端口是1234。集群内的全部kube-proxy都会注意到这个Service。当proxy发现一个新的service后，它会在本地节点打开一个任意端口，建相应的iptables规则，重定向服务的IP和port到这个新建的端口，开始接受到达这个服务的链接。

当一个客户端访问这个service时，这些iptable规则就开始起做用，客户端的流量被重定向到kube-proxy为这个service打开的端口上，kube-proxy随机选择一个后端pod来服务客户。

Cluster IP

Service的IP地址，此为虚拟IP地址。外部网络没法ping通，只有kubernetes集群内部访问使用。经过命令 kubectl -n 命名空间 get Service 便可查询ClusterIP

Cluster IP是一个虚拟的IP，但更像是一个伪造的IP网络，缘由有如下几点

• Cluster IP仅仅做用于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址

• Cluster IP没法被ping，他没有一个“实体网络对象”来响应

• Cluster IP只能结合Service Port组成一个具体的通讯端口Endpoint，单独的Cluster IP不具有通讯的基础，而且他们属于Kubernetes集群这样一个封闭的空间。

• 在不一样Service下的pod节点在集群间相互访问能够经过Cluster IP

为了实现图上的功能主要须要如下几个组件的协同工做：

• apiserver：在建立service时，apiserver接收到请求之后将数据存储到etcd中。
• kube-proxy：k8s的每一个节点中都有该进程，负责实现service功能，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables中。
• iptables：使用NAT等技术将virtualIP的流量转至endpoint中

根据是否生成ClusterIP又可分为普通Service和Headless Service两类：

1. 普通Service：经过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP（Cluster IP），实现集群内的访问。为最多见的方式。

2. Headless Service：该服务不会分配Cluster IP，也不经过kube-proxy作反向代理和负载均衡。而是经过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为Pod IP列表。主要供StatefulSet使用。

不一样类型的Port

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
spec:
 type: NodePort         // 有配置NodePort，外部流量可访问k8s中的服务
 ports:
 - port: 30080          // 服务访问端口，集群内部访问的端口
   targetPort: 80       // pod控制器中定义的端口（应用访问的端口）
   nodePort: 30001      // NodePort，外部客户端访问的端口
 selector:
  name: nginx-pod

port

• port是k8s集群内部访问service的端口(service暴露在Cluster IP上的端口)，即经过clusterIP: port能够访问到某个service

nodePort

• nodePort是外部访问k8s集群中service的端口，经过nodeIP: nodePort能够从外部访问到某个service。

该端口号的范围是 kube-apiserver 的启动参数 –service-node-port-range指定的，在当前测试环境中其值是 30000-50000。表示只容许分配30000-50000之间的端口。

好比外部用户要访问k8s集群中的一个Web应用，那么咱们能够配置对应service的type=NodePort，nodePort=30001。其余用户就能够经过浏览器http://node:30001访问到该web服务。而数据库等服务可能不须要被外界访问，只需被内部服务访问便可，那么咱们就没必要设置service的NodePort

TargetPort

• targetPort 是pod的端口，从port和nodePort来的流量通过kube-proxy流入到后端pod的targetPort上，最后进入容器。

containerPort

• containerPort是pod内部容器的端口，targetPort映射到containerPort。

hostPort

这是一种直接定义Pod网络的方式。hostPort是直接将容器的端口与所调度的节点上的端口路由，这样用户就能够经过宿主机的IP加上来访问Pod了，如

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  containers:
    - name: influxdb
      image: influxdb
      ports:
        - containerPort: 8086 # 此处定义暴露的端口
          hostPort: 8086

这样作有个缺点，由于Pod从新调度的时候该Pod被调度到的宿主机可能会变更，这样就变化了，用户必须本身维护一个Pod与所在宿主机的对应关系。
使用了 hostPort 的容器只能调度到端口不冲突的 Node 上，除非有必要（好比运行一些系统级的 daemon 服务），不建议使用端口映射功能。若是须要对外暴露服务，建议使用 NodePort Service。

总的来讲，port和nodePort都是service的端口，前者暴露给集群内客户访问服务，后者暴露给集群外客户访问服务。从这两个端口到来的数据都须要通过反向代理kube-proxy流入后端 pod的targetPod，从而到达pod上的容器内。

Endpoint

建立Service的同时，会自动建立跟Service同名的Endpoints。

Endpoint 是k8s集群中一个资源对象，存储在etcd里面，用来记录一个service对应的全部pod的访问地址。service经过selector和pod创建关联。

Endpoint = Pod IP + Container Port

service配置selector endpoint controller 才会自动建立对应的endpoint 对象，不然是不会生产endpoint 对象

一个service由一组后端的pod组成，这些后端的pod经过service endpoint暴露出来，若是有一个新的pod建立建立出来，且pod的标签名称(label:pod)跟service里面的标签（label selector 的label）一致会自动加入到service的endpoints 里面，若是pod对象终止后，pod 会自动从edponts 中移除。在集群中任意节点 可使用curl请求service <CLUSTER-IP>:<PORT>

Endpoint Controller

Endpoint Controller是k8s集群控制器的其中一个组件，其功能以下：

• 负责生成和维护全部endpoint对象的控制器
• 负责监听service和对应pod的变化
• 监听到service被删除，则删除和该service同名的endpoint对象
• 监听到新的service被建立，则根据新建service信息获取相关pod列表，而后建立对应endpoint对象
• 监听到service被更新，则根据更新后的service信息获取相关pod列表，而后更新对应endpoint对象
• 监听到pod事件，则更新对应的service的endpoint对象，将podIp记录到endpoint中

定义 Endpoint

对于Service，咱们还能够定义Endpoint，Endpoint 把Service和Pod动态地链接起来，Endpoint 的名称必须和服务的名称相匹配。

建立mysql-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: mysql-production
spec:
  ports:
    - port: 3306

建立mysql-endpoints.yaml

kind: Endpoints
apiVersion: v1
metadata:
  name: mysql-production
  namespace: default
subsets:
  - addresses:
      - ip: 192.168.1.25
    ports:
      - port: 3306

[root@k8s-master endpoint]# kubectl describe svc mysql-production
Name:           mysql-production
Namespace:      default
Labels:         <none>
Annotations:        <none>
Selector:       <none>
Type:           ClusterIP
IP:         10.254.218.165
Port:           <unset> 3306/TCP
Endpoints:      192.168.1.25:3306
Session Affinity:   None
Events:         <none>

使用Endpoint引用外部服务

service 不只能够代理pod, 还能够代理任意其它的后端(运行在k8s集群外部的服务，好比mysql mongodb）。若是须要从k8s里面连接外部服务（mysql），可定义同名的service和endpoint

在实际生成环境中，像mysql mongodb这种IO密集行应用，性能问题会显得很是突出，因此在实际应用中，通常不会把这种有状态的应用（mysql 等）放入k8s里面，而是使用单独的服务来部署，而像web这种无状态的应用更适合放在k8s里面 里面k8s的自动伸缩，和负载均衡，故障自动恢复 等强大功能

建立service (mongodb-service-exten)

kind: Service
apiVersion: v1
metadata:
  name: mongodb
  namespace: name
spec:
  ports:
  - port: 30017
    name: mongodb
    targetPort: 30017

建立 endpoint(mongodb-endpoint)

kind: Endpoints
apiVersion: v1
metadata:
  name: mongodb
  namespace: tms-test
subsets:
- addresses:
  - ip: xxx.xxx.xx.xxx
  ports:
   - port: 30017
     name: mongod

能够看到service跟endpoint成功挂载一块儿了，表面外面服务成功挂载到k8s里面了，在应用中配置连接的地方使用mongodb://mongodb:30017 连接数据

建立ExternalName类型的服务

除了手动配置服务的endpoint来代替公开外部服务方法，还能够经过彻底限定域名（FQDN）访问外部服务——建立ExternalName类型的服务。

ExternalName类型的服务建立后，pod能够经过external-service.default.svc.cluster.local域名链接到外部服务，或者经过externale-service。当须要指向其余外部服务时，只须要修改spec.externalName的值便可。