k8s pod的各种ip和port很容易把人搞晕,其实都是与k8s service的访问有密切关系,这篇我们来梳理一下它们的差异,来更好的了解一下k8s的访问机制。

[root@k8smaster ~]# kubectl get pod -n kube-system -o wide
NAME                                READY   STATUS    RESTARTS   AGE    IP                NODE        NOMINATED NODE   READINESS GATES
coredns-7ff77c879f-7sd8g            1/1     Running   9          120d   10.244.1.118      k8snode     <none>           <none>
coredns-7ff77c879f-8gnnq            1/1     Running   13         120d   10.244.0.109      k8smaster   <none>           <none>

[root@k8smaster ~]# kubectl get svc -n kube-system -o wide
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE    SELECTOR
kube-dns   ClusterIP   10.1.0.10    <none>        53/UDP,53/TCP,9153/TCP   120d   k8s-app=kube-dns

[root@k8smaster ~]# kubectl get endpoints -n kube-system -o wide
NAME                      ENDPOINTS                                                     AGE
kube-dns                  10.244.0.109:53,10.244.1.118:53,10.244.0.109:53 + 3 more...   120d

1.不同类型的IP

  • 1.Node IP:Node节点的IP地址,也就是节点物理网卡的ip地址
  • 2.Pod IP:Pod的IP地址。Docker Engine根据docker0网桥的IP地址段进行分配的,通常是一个虚拟的二层网络。
  • 3.Cluster IP:Service的IP地址。 属于Kubernetes集群内部的地址,无法在集群外部直接使用这个地址。
1.1 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来服务客户。

1.2 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的流量转至endpoints中。

根据是否生成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使用。

2.不同类型的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
2.1 port

port是k8s集群内部访问service的端口(service暴露在Cluster IP上的端口),即通过clusterIP: port可以访问到某个service

2.2 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://nodeip:nodePort访问到该web服务。而数据库等服务可能不需要被外界访问,只需被内部服务访问即可,那么我们就不必设置service的NodePort。

2.3 TargetPort

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

2.4 containerPort

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

2.5 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上的容器内。

3.Endpoint

创建Service的同时,会自动创建跟Service同名的Endpoints。

Endpoint是k8s集群中一个资源对象,存储在etcd里面,用来记录一个service对应的所有pod的访问地址。service通过selector和pod建立关联。

Endpoint = Pod IP + Container Port

service配置selector,Endpoint controller才会自动创建对应的endpoints对象,否则是不会生成endpoints对象。

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

4.Endpoint Controller

Endpoint Controller是k8s集群控制器的其中一个组件,其功能如下:

  • 负责生成和维护所有endpoints对象的控制器;
  • 负责监听service和对应pod的变化;
  • 监听到service被删除,则删除和该service同名的endpoint对象;
  • 监听到新的service被创建,则根据新建service信息获取相关pod列表,然后创建对应endpoint对象;
  • 监听到service被更新,则根据更新后的service信息获取相关pod列表,然后更新对应endpoint对象;
  • 监听到pod事件,则更新对应的service的endpoints对象,将podIp记录到endpoints中。

5.定义Endpoint

对于Service,我们还可以定义Endpoint,Endpoint把Service和Pod动态地连接起来,Endpoint的名称必须和service的名称相匹配。

创建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

查看endpoints信息:

[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>

6.使用Endpoint引用外部服务

service不仅可以代理pod,还可以代理任意其它的后端(运行在k8s集群外部的服务,比如mysql mongodb)。如果需要从k8s里面链接外部服务(mysql),可定义同名的service和endpoint。

在实际生成环境中,像mysql mongodb这种I/O密集行应用,性能问题会显得非常突出,所以在实际应用中,一般不会把这种有状态的应用(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: name
subsets:
- addresses:
  - ip: xxx.xxx.xx.xxx
  ports:
   - port: 30017
     name: mongod

可以看到service跟endpoint成功挂载一起了,表面外面服务成功挂载到k8s里面了,在应用中配置链接的地方使用mongodb://mongodb:30017链接数据。

7.创建ExternalName类型的服务

除了手动配置服务的endpoint来代替公开外部服务方法,还可以通过完全限定域名(FQDN)访问外部服务———创建ExternalName类型的服务。

apiVersion: v1
kind: Service
metadata:
  name : external-service
spec:
  type : ExternalName   # 代码的type被设置成ExternalName
  externalName: someapi.somecompany.com    # 实际服务的完全限定域名
  ports:
  - port:80

ExternalName类型的服务创建后,pod可以通过external-service.default.svc.cluster.local域名连接到外部服务,或者通过external-service。当需要指向其他外部服务时,只需要修改spec.externalName的值即可。

posted on 2022-11-17 18:10  jiayou111  阅读(1083)  评论(0编辑  收藏  举报