k8s-服务发现service和ingress

回到目录

service用于集群内部应用的网络调用，处理东西流量

ingress用于集群外部用户访问内部服务，处理南北流量

一 kube-proxy三种代理模式

• kubernetes集群中有三层网络，一类是真实存在的，例如Node Network、Pod Network,提供真实IP地址;一类是虚拟的，例如Cluster Network或Service Network，提供虚拟IP地址，不会出现在接口上，仅会出现在Service当中

• kube-proxy始终watch（监控）kube-apiserver上关于Service相关的资源变动状态，一旦获取相关信息kube-proxy都要把相关信息转化为当前节点之上的，能够实现Service资源调度到特定Pod之上的规则，进而实现访问Service就能够获取Pod所提供的服务

• kube-proxy三种代理模式：UserSpace模式、iptables模式、ipvs模式

1 UserSpace模式

userspace 模式是 kube-proxy 使用的第一代模式，该模式在 kubernetes v1.0 版本开始支持使用。

kube-proxy 会为每个 Service 随机监听一个端口(proxy port)，并增加一条 iptables 规则。所以通过 ClusterIP:Port 访问 Service 的报文都 redirect 到 proxy port，kube-proxy 从它监听的 proxy port 收到报文以后，走 round robin(默认) 或是 session affinity(会话亲和力，即同一 client IP 都走同一链路给同一 pod 服务)，分发给对应的 pod。

由于 userspace 模式会造成所有报文都走一遍用户态（也就是 Service 请求会先从用户空间进入内核 iptables，然后再回到用户空间，由 kube-proxy 完成后端 Endpoints 的选择和代理工作），需要在内核空间和用户空间转换，流量从用户空间进出内核会带来性能损耗，所以这种模式效率低、性能不高，不推荐使用。

2 iptables模式

iptables 模式是 kube-proxy 使用的第二代模式，该模式在 kubernetes v1.1 版本开始支持，从 v1.2 版本开始成为 kube-proxy 的默认模式。

iptables 模式的负载均衡模式是通过底层 netfilter/iptables 规则来实现的，通过 Informer 机制 Watch 接口实时跟踪 Service 和 Endpoint 的变更事件，并触发对 iptables 规则的同步更新。

在 iptables 模式下，kube-proxy 只是作为 controller，而不是 server，真正服务的是内核的 netfilter，体现在用户态的是 iptables。所以整体的效率会比 userspace 模式高

3 ipvs模式

ipvs 模式被 kube-proxy 采纳为第三代模式，模式在 kubernetes v1.8 版本开始引入，在 v1.9 版本中处于 beta 阶段，在 v1.11 版本中正式开始使用。

ipvs(IP Virtual Server) 实现了传输层负载均衡，也就是 4 层交换，作为 Linux 内核的一部分。ipvs运行在主机上，在真实服务器前充当负载均衡器。ipvs 可以将基于 TCP 和 UDP 的服务请求转发到真实服务器上，并使真实服务器上的服务在单个 IP 地址上显示为虚拟服务。

ipvs 和 iptables 都是基于 netfilter 的，那么 ipvs 模式有哪些更好的性能呢？

• ipvs 为大型集群提供了更好的可拓展性和性能

• ipvs 支持比 iptables 更复杂的负载均衡算法（包括：最小负载、最少连接、加权等）

• ipvs 支持服务器健康检查和连接重试等功能

• 可以动态修改 ipset 的集合，即使 iptables 的规则正在使用这个集合

ipvs 依赖于 iptables。ipvs 会使用 iptables 进行包过滤、airpin-masquerade tricks(地址伪装)、SNAT 等功能，但是使用的是 iptables 的扩展 ipset，并不是直接调用 iptables 来生成规则链。通过 ipset 来存储需要 DROP 或 masquerade 的流量的源或目标地址，用于确保 iptables 规则的数量是恒定的，这样我们就不需要关心有多少 Service 或是 Pod 了。

使用 ipset 相较于 iptables 有什么优点呢？iptables 是线性的数据结构，而 ipset 引入了带索引的数据结构，当规则很多的时候，ipset 依然可以很高效的查找和匹配。我们可以将 ipset 简单理解为一个 IP(段) 的集合，这个集合的内容可以是 IP 地址、IP 网段、端口等，iptables 可以直接添加规则对这个“可变的集合进行操作”，这样就可以大大减少 iptables 规则的数量，从而减少性能损耗。

举一个例子，如果我们要禁止成千上万个 IP 访问我们的服务器，如果使用 iptables 就需要一条一条的添加规则，这样会在 iptables 中生成大量的规则；如果用 ipset 就只需要将相关的 IP 地址(网段)加入到 ipset 集合中，然后只需要设置少量的 iptables 规则就可以实现这个目标。

下面的表格是 ipvs 模式下维护的 ipset 表集合：

设置名称	成员	用法
KUBE-CLUSTER-IP	所有服务 IP + 端口	在 masquerade-all=true 或 clusterCIDR 指定的情况下对 Service Cluster IP 地址进行伪装，解决数据包欺骗问题
KUBE-LOOP-BACK	所有服务 IP + 端口 + IP	解决数据包欺骗问题
KUBE-EXTERNAL-IP	服务外部 IP + 端口	将数据包伪装成 Service 的外部 IP 地址
KUBE-LOAD-BALANCER	负载均衡器入口 IP + 端口	将数据包伪装成 Load Balancer 类型的 Service
KUBE-LOAD-BALANCER-LOCAL	负载均衡器入口 IP + 端口 以及externalTrafficPolicy=local	接受数据包到 Load Balancer externalTrafficPolicy=local
KUBE-LOAD-BALANCER-FW	负载均衡器入口 IP + 端口 以及loadBalancerSourceRanges	使用指定的 loadBalancerSourceRanges 丢弃 Load Balancer 类型 Service 的数据包
KUBE-LOAD-BALANCER-SOURCE-CIDR	负载均衡器入口 IP + 端口 + 源 CIDR	接受 Load Balancer 类型 Service 的数据包，并指定 loadBalancerSourceRanges
KUBE-NODE-PORT-TCP	NodePort 类型服务 TCP 端口	将数据包伪装成 NodePort（TCP）
KUBE-NODE-PORT-LOCAL-TCP	NodePort 类型服务 TCP 端口，带有externalTrafficPolicy=local	接受数据包到 NodePort 服务，使用 externalTrafficPolicy=local
KUBE-NODE-PORT-UDP	NodePort 类型服务 UDP 端口	将数据包伪装成 NodePort(UDP)
KUBE-NODE-PORT-LOCAL-UDP	NodePort 类型服务 UDP 端口，使用externalTrafficPolicy=local	接受数据包到 NodePort 服务，使用 externalTrafficPolicy=local

二 service 

使用原因

使用kubernetes集群运行工作负载时，由于Pod经常处于用后即焚状态，Pod经常被重新生成，因此Pod对应的IP地址也会经常变化，导致无法直接访问Pod提供的服务

Kubernetes中使用了Service来解决这一问题

即在Pod前面使用Service对Pod进行代理，无论Pod怎样变化 ，只要有Label，就可以让Service能够联系上Pod

把PodIP地址添加到Service对应的端点列表（Endpoints）实现对Pod IP跟踪，进而实现通过Service访问Pod目的。

作用

• 通过service为pod客户端提供访问pod方法，即可客户端访问pod入口

• 通过标签动态感知pod IP地址变化等

• 防止pod失联

• 定义访问pod访问策略

• 通过label-selector相关联

• 通过Service实现Pod的负载均衡（TCP/UDP 4层）

• 底层实现由kube-proxy通过userspace、iptables、ipvs三种代理模式

1 service类型

Service类型决定了访问Service的方法

• ClusterIP

  • 默认，分配一个集群内部可以访问的虚拟IP

• NodePort

  • 在每个Node上分配一个端口作为外部访问入口

  • nodePort端口范围为:30000-32767

• LoadBalancer

  • 工作在特定的Cloud Provider上，例如Google Cloud，AWS，OpenStack

• ExternalName

  • 表示把集群外部的服务引入到集群内部中来，即实现了集群内部pod和集群外部的服务进行通信

2 ClusterIp类型

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

Service两类：

• 普通Service:

为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP(Cluster IP), 实现集群内的访问。

• Headless Service:

该服务不会分配Cluster IP, 也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为pod IP列表。

2.1 普通ClusterIP

为service分配一个集群内可以访问的固定虚拟ip(Cluster IP)，实现集群内访问

yaml文件

#创建一个service，关联pod标签为app=nginx的端口80，service访问端口80；
apiVersion: v1  #版本直接是v1
kind: Service  #类型为service
metadata:
  name: nginx-svc #service的名称
spec:
  type: ClusterIP #类型为ClusterIP
  ports:
  - protocol: TCP #协议类型
    port: 80			#访问service端口
    targetPort: 80 #pod中的容器端口
  selector:				#标签选择
    app: nginx
---								# yaml分段
#创建一个deployment，pod为nginx，标签为app=nginx
apiVersion: apps/v1
kind: Deployment  #类型为Deployment
metadata:
  name: nginx-server1
spec:
  replicas: 2     #副本数
  selector:				#标签选择
    matchLabels:
      app: nginx
  template:				#pod模版
     metadata:
       labels:
         app: nginx
     spec:
       containers:
       - name: nginx-smart
         image: nginx:1.15-alpine
         imagePullPolicy: IfNotPresent
         ports:
         - containerPort: 80

创建

[root@k8s-master1 service]# kubectl apply -f nginx-service.ymal 
service/nginx-svc created
deployment.apps/nginx-server1 created

查看

[root@k8s-master1 service]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx-svc    ClusterIP   10.100.242.217           80/TCP    2m14s

CLUSTER-IP是集群分配给service的ip

PORT(S)是访问service的端口和协议

在集群内通过该ip和端口即可访问该service下的应用

[root@k8s-master1 service]# curl 10.100.242.217







Welcome to nginx!
省略...

查看endpoints

[root@k8s-master1 service]# kubectl get endpoints
NAME         ENDPOINTS                            AGE
nginx-svc    10.244.107.195:80,10.244.122.65:80   3m38s

ENDPOINTS为service代理下的deployment管理的pod实际ip的端口

查看pod,可以发现endpoints的ip对应pod所在ip

[root@k8s-master1 service]# kubectl get po -o wide
NAME                           READY   STATUS    RESTARTS   AGE    IP             NODE        
nginx-server1-5fbd6f4c84-8p4v7 1/1     Running   0          6m8s   10.244.107.195 k8s-node3  
nginx-server1-5fbd6f4c84-qfvg7 1/1     Running   0          6m8s   10.244.122.65  k8s-node4 

2.2 Headless-service

• 普通的ClusterIP service是service name解析为cluster ip,然后cluster ip对应到后面的pod ip

• Headless service是指service name 直接解析为后面的pod ip

yaml文件

apiVersion: v1
kind: Service
metadata:
  name: headless-service
  namespace: default
spec:
  type: ClusterIP     # ClusterIP类型,也是默认类型
  clusterIP: None     # None就代表是无头service,普通service没有该行
  ports:                                # 指定service 端口及容器端口
  - port: 80                            # service ip中的端口
    protocol: TCP
    targetPort: 80                      # pod中的端口
  selector:                             # 指定后端pod标签
     app: nginx                    # 可通过kubectl get pod -l app=nginx查看哪些pod在使用此标签

查看创建好的service

#查看创建后的service
[root@master ~]# kubectl get svc
输出
NAME               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
headless-service   ClusterIP   None                     80/TCP           2m18s

发现，cluster-ip为None

此时还需要通过DNS来解决访问

DNS记录格式为: ..svc.cluster.local.

所以，该serivce的访问域名为headless-service.default.svc.cluster.local.

如何访问一个service

对于一个service，在同一个命名空间中的其他容器中可以通过service名称直接访问，比如一个service名称为haedless-service，在集群中的另一个容器通过haedless-service可直接访问改服务说代理的pod，如果haedless-service所代理的是一个nginx，那么在另一个容器中curl haedless-service则返回nginx的欢迎页面

不在同一个命名空间则，需要添加service所在命名空间名，如上面的service所在命名空间为namespace1，则在namespace2中的容器访问service则为 curl haedless-service.namespace1

3 NodePort类型

• 在每个Node上分配一个端口作为外部访问入口

• nodePort端口范围为:30000-32767

yaml文件

apiVersion: v1
kind: Service
metadata:
  name: nginx-app
spec:
  type: NodePort     #service类型为nodeport
  selector:
    app: nginx-app
  ports:
  - protocol: TCP
    nodePort: 30001		# 指定使用node上的端口号（每个node都会绑定该端口，如果端口被占用则失败），不指定则在范围内随机未使用的端口
    port: 8060				#pod的端口
    targetPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
  labels:
    app: nginx-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: c1
        image: nginx:1.15-alpine
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

查看

[root@master01 ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
nginx-app    NodePort    10.104.157.20            8060:30001/TCP   36s

通过ip:port即可在k8s集群同一网络中访问该service

在集群外或集群内都可通过curl http://node-ip:port进行访问nodePort类型的service

curl http://192.158.10.200:30001,其中ip为k8s的主机ip，port为上面serivce指定使用的节点端口

4 ExternalName

• 把集群外部的服务引入到集群内部中来，实现了集群内部pod和集群外部的服务进行通信

• ExternalName 类型的服务适用于外部服务使用域名的方式，缺点是不能指定端口

• 还有一点要注意: 集群内的Pod会继承Node上的DNS解析规则。所以只要Node可以访问的服务，Pod中也可以访问到, 这就实现了集群内服务访问集群外服务

yaml

apiVersion: v1
kind: Service
metadata:
  name: my-externalname
  namespace: default
spec:
  type: ExternalName
  externalName: www.baidu.com                  # 对应的外部域名为www.baidu.com

通过访问域名my-externalname.default.svc.cluster.local和访问www.baidu,com效果一样

5 k8s集群如何通过service访问外部应用

代理外部应用，让内部应用访问外部应用，外部应用没有域名

流程：

• 创建一个不带标签选择器的service，这样不会自动创建endpoint

• 手动创建一个endpoint，代理外部应用ip

• 内部服务访问service，service通过endpoint访问外部应用

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc-external 	    # service名称
  namespace: default			# 命名空间
  labels:						# service标签
  	app: nginx
spec:
	ports:						# service端口
	- port: 80					# pod端口
		targetPort: 80			# service使用端口
		name: web				# 代理端口名称
  type: ClusterIP				# service类型
---
apiVersion: v1
kind: Endpoints					# endpoint
metadata:
  labels:
    app: nginx 					# 与 service 一致
  name: nginx-svc-external 	    # 与 service 一致
  namespace: default 			# 与 service 一致
subsets:						# 子网
- addresses:
  - ip:  			# 目标 ip 地址，外部应用ip
  ports: 						# 与 service 一致
  - name: web					# 与service一致
    port: 80					# 外部应用ip端口
    protocol: TCP				# 使用协议

此时，在内部应用中，通过访问service即可对外部网络进行访问http://nginx-svc-external

三 ingress

Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。

ingress控制器

客户端通过ingress控制器【负载均衡器】分配到对应ingress，通过路由转发到对应service

用于管理和使用ingress

有许多具体实现，如ingress-nginx、HAProxy Ingress 等等

下面使用ingress-nginx

创建ingress

apiVersion: networking.k8s.io/v1
kind: Ingress                # 资源类型为 Ingress
metadata:
  name: test-nginx-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:                     # ingress 规则配置，可以配置多个
  - host: k8s.fooleryang.cn  # 域名配置，可以使用通配符 *
    http:
      paths:                 # 相当于 nginx 的 location 配置，可以配置多个
      - pathType: Prefix     # 路径类型，按照路径类型进行匹配 
        backend:
          service: 
            name: nginx-svc  # 代理到哪个 service
            port: 
              number: 80     # service 的端口
        path: /api           # 等价于 nginx 中的 location 的路径前缀匹配

说明：

该ingress名称为test-nginx-ingress

规则为 访问域名为k8s.fooleryang.cn时进行路径匹配，如果是/api路径这转发到nginx-svc这个service的80端口/api路径上去

查看

#查看ingress
[root@k8s-master1 ingress]# kubectl get ingress
NAME                     CLASS    HOSTS               ADDRESS        PORTS   AGE
test-nginx-ingress      k8s.fooleryang.cn   10.98.123.30   80      83s

验证

在集群外电脑，host中提前配置k8s.fooleryang.cn 和集群主机ip对应

浏览器中访问k8s.fooleryang.cn/api 进入代理的nginx-svc的nginx欢迎界面

在nginx-svc所代理的pod中查看日志，发现有访问记录

[root@k8s-master1 ingress]# kubectl get po
NAME                             READY   STATUS    RESTARTS   AGE
nginx-server1-5fbd6f4c84-2b5vp   1/1     Running   0          38m
nginx-server1-5fbd6f4c84-w97f7   1/1     Running   0          38m
[root@k8s-master1 ingress]# kubectl logs -f nginx-server1-5fbd6f4c84-2b5vp
172.19.55.209 - - [12/Jun/2023:09:31:47 +0000] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36"

四 总结

service主要用于集群内部pod之间的访问，nodeport类型可以实现集群外访问serivce，一般用于部署管理工具的管理容器访问，测试容器时使用

ingress主要用于集群外访问集群内部服务

即

service处理东西流量【内部见pod访问】

ingress处理南北流量【集群外访问集群内serivce】