前言
Pod 已经成功运行起来了&＃xff0c;但是有两个问题。
一是这些 Pod 无法从集群外部直接访问到&＃xff0c;二是 Pod 出现故障自愈后&＃xff0c;IP 会发生变化。
如何解决这两个问题&＃xff0c;这里有一个非常重要的概念&＃xff1a;Service
更新历史
- 20200625 - 初稿 - 左程立
- 原文地址 - https://blog.zuolinux.com/2020/06/25/about-service.html
Service 的意义和特点
- 对一组 Pod 提供负载均衡&＃xff08;工作在 TCP/UDP 4 层&＃xff09;
- 防止 Pod 更换 IP 失联&＃xff0c;即服务发现
- 通过 label selector 关联 Pod
Service 工作原理
Service 是由 kube-proxy 组件加上 iptables/LVS 共同实现。 说白了就是通过 kube-proxy 生成了一堆 iptables 规则&＃xff0c;通过 iptables 规则来转发数据。
iptables 转发&＃xff1a;
- K8S 默认的转发设置。
- 选择后端 Pod 为随机选择。
- 当 Pod 没有响应&＃xff0c;连接会失败&＃xff0c;并没有健康检查机制。
- 需要配合 Pod 就绪探测器来确保访问到健康的 Pod。
- 当集群规模达到上万个服务时&＃xff0c;iptables 转发效率会显著降低。
LVS转发&＃xff1a;
- 基于内核哈希表&＃xff0c;性能强大&＃xff0c;具有更高网络吞吐量。
- 适用于 Pod 量级大&＃xff0c;转发规则更多的大规模集群。
- LVS 支持更多的 Pod 负载均衡调度算法。
- LVS 只负责负载均衡和代理功能&＃xff0c;剩余的包过滤和SNAT等操作还是需要 iptables 处理&＃xff0c;但这些操作规则数量不会因 Pod 数量的增加而增加。
- 也叫 IPVS 。
Service 的默认工作方式
创建 Pod 和 默认Service&＃xff0c;进行默认工作状态的测试。
先创建3个 Pod
cat nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment
spec:selector:matchLabels:app: nginxreplicas: 3template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginxports:- containerPort: 80
创建一个默认类型的 Service&＃xff0c;名称为 nginx-service
cat nginx-service.yaml
apiVersion: v1
kind: Service
metadata:name: nginx-service
spec:selector:app: nginxports:- port: 80targetPort: 80protocol: TCP
port: 80 是 service 在集群内部的VIP端口
targetPort: 80 是 Pod 的端口
执行创建
kubectl apply -f nginx.yaml
kubectl apply -f nginx-service.yaml
查看运行情况
[root&＃64;master01 ~]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-d46f5678b-cldf4 1/1 Running 0 21m 192.10.137.153 work03
nginx-deployment-d46f5678b-lnxh9 1/1 Running 0 21m 192.10.205.252 work01
nginx-deployment-d46f5678b-th8xq 1/1 Running 0 21m 192.10.75.89 work02 [root&＃64;master01 ~]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service ClusterIP 192.20.150.26 80/TCP 13m
查看名称为 nginx-service 的 service 成功挂载的后端 Pod
[root&＃64;master01 ~]# kubectl get endpoints nginx-service
NAME ENDPOINTS AGE
nginx-service 192.10.137.153:80,192.10.205.252:80,192.10.75.89:80 14m
可以看到我们创建的名为 nginx-service 的 Service 后端挂载了3个 Pod
给3个 Pod 写入内容&＃xff0c;访问 Pod 时返回自身的主机名
kubectl exec nginx-deployment-d46f5678b-cldf4 -- sh -c &＃39;echo $(hostname) > /usr/share/nginx/html/index.html&＃39;;
kubectl exec nginx-deployment-d46f5678b-lnxh9 -- sh -c &＃39;echo $(hostname) > /usr/share/nginx/html/index.html&＃39;;
kubectl exec nginx-deployment-d46f5678b-th8xq -- sh -c &＃39;echo $(hostname) > /usr/share/nginx/html/index.html&＃39;;
我们访问 Service IP 看看
[root&＃64;master01 ~]# curl 192.20.150.26
nginx-deployment-d46f5678b-th8xq
[root&＃64;master01 ~]# curl 192.20.150.26
nginx-deployment-d46f5678b-cldf4
[root&＃64;master01 ~]# curl 192.20.150.26
nginx-deployment-d46f5678b-lnxh9
可以看到 Service 成功将请求代理到了后端的一组 Pod&＃xff0c;并且进行了流量的分配。
这是 Service 的默认工作类型&＃xff0c;只能在集群所属的节点上访问到&＃xff0c;离开集群后无法被访问到。
这种工作类型叫做 ClusterIP。
Service 对外提供服务的三种方式
上一节可以看到&＃xff0c;Service 默认不对集群外部提供服务&＃xff0c;那么如何才能在集群外部访问到呢&＃xff0c;有三种方案。
externalIPs 方式
Service 中配置可以 externalIPs&＃xff0c;IP 为本集群中 work 节点宿主机 IP。
apiVersion: v1
kind: Service
。。。
。。。
spec:。。。。。。externalIPs:- 192.168.10.16- 192.168.10.17
在 192.168.10.16/17 上执行 ss -lntp 可以看到 Service 定义的暴露端口。 在集群外部访问 192.168.10.16/17 上 Service 暴露的端口即可。
NodePort 方式
改造 nginx-service.yaml&＃xff0c;增加一行 type: NodePort
cat nginx-service.yaml
apiVersion: v1
kind: Service
metadata:name: nginx-service
spec:type: NodePortselector:app: nginxports:- port: 80targetPort: 80protocol: TCP
创建 service
kubectl apply -f nginx-service.yaml
查看运行情况
[root&＃64;master01 ~]# kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service NodePort 192.20.167.221 80:30913/TCP 13m
参数 PORT(S) 80:30913/TCP&＃xff0c;其中 30913 就是用来集群外部访问的端口。
可以访问任何一台物理宿主机的 ip:30913 来访问到 Pod。
30913 是 K8S 从固定范围 30000-32767 中选择的&＃xff0c;也可以通过参数 nodePort 指定固定端口。
可选择范围可以通过 kube-apiserver 的 –service-node-port-range 参数来修改。
[root&＃64;master01 ~]# ss -nltp | grep 30913
LISTEN 0 128 *:30913 *:*
可以看到宿主机上监听了 30913 端口。
测试
在没有运行 K8S 集群的机器上访问 K8S 宿主机[root&＃64;192-168-10-18 ~]# curl 192.168.10.12:30913
nginx-deployment-d46f5678b-2pmts
[root&＃64;192-168-10-18 ~]# curl 192.168.10.12:30913
nginx-deployment-d46f5678b-zv8m4
[root&＃64;192-168-10-18 ~]# curl 192.168.10.12:30913
nginx-deployment-d46f5678b-2pmts
可以看到从集群外部可以成功访问到 Pod 中内容&＃xff0c;并且为随机分配。
原理
kube-proxy 在宿主机上创建了 iptables 规则&＃xff0c;对宿主机 IP:30913 的访问将被转发到 Service IP&＃xff0c;然后 Service 再通过自己的 iptables 规则分发到 Pod
LoadBalancer 方式
NodePort 方式中&＃xff0c;如果要正式对外提供服务&＃xff0c;我们需要在集群外部再创建一个高可用的负载均衡器&＃xff0c;以方便把流量转发到宿主机开放的端口上&＃xff0c;如果宿主机开放端口发生了变更&＃xff0c;我们需要手工修改前端负载均衡器。
公有云的 LoadBalancer 自动化了这一过程。
LoadBalancer 这种方式应用于公有云&＃xff0c;提交一个 type: LoadBalancer 的 Service 创建申请后&＃xff0c;公有云会帮我们创建一个负载均衡器&＃xff0c;该负载均衡器会把请求直接分发给 Pod&＃xff0c;同时 Pod IP 发生变化后&＃xff0c;会自动更新到负载均衡器上。
其他&＃xff1a;Headless Service
通过指定 spec.clusterIP 的值为 "None" 可以创建 Headless Service。
Headless Service 不会分配 Cluster IP&＃xff0c;kube-proxy 不会处理它们&＃xff0c; 而且平台也不会为它们进行负载均衡和路由。
定义了 selector 的无头服务&＃xff0c;Endpoint 控制器会在 API 中创建 Endpoints 记录&＃xff0c; 并且修改 DNS 配置返回 A 记录&＃xff0c;通过这个地址&＃xff0c;请求可以直接到达 Service 的后端 Pod 上。
结束语
Service 对 IP 信息易变的 Pod 提供了服务发现、负载均衡等管理功能&＃xff0c;同时提供了外部访问的能力&＃xff0c;从而使外部用户能够稳定的访问到运行在集群内部的 Pod 提供的服务。
上面说的三种工作方式有如下问题&＃xff1a;
- ClusterIP 方式默认工作在集群内部&＃xff0c;使用参数 externalIPs 可指定哪个及诶按暴露端口&＃xff0c;但无法进行7层的URL跳转等控制
- NodePort 方式下&＃xff0c;全部节点都会暴露该端口&＃xff0c;但一个端口只能对应一个业务&＃xff0c;适合业务比较少的环境或者测试环境&＃xff0c;业务多了以后无法有效管理
- LoadBalance 方式只适合于现有的公有云平台&＃xff0c;无法用于自建集群&＃xff0c;同时还需要额外费用
这些问题导致无法直接应用于生产环境中。
如果想提供给自建集群的生产环境使用&＃xff0c;需要在 Service 前面再加一层 Ingress Controller。
联系我
微信公众号&＃xff1a;zuolinux_com
http://weixin.qq.com/r/nUzg_DbEaGsXrXKb9xmP (二维码自动识别)
京公网安备 11010802041100号