聊聊Kubernetes里的健康检查和Ingress方式服务暴露的流量走向

Posted 2021-04-03 GoDevops

Kuberneetes对pod的健康检查主要有2种探针方式实现 Livenessprobe探针 和  Readnessprobe探针 ，以及后面新增的Startup 探针 ，kubelet会定期执行这两种探针来诊断容器的健康程度

· livenessprobe探针:  主要是用来判断容器是否存活（Running状态），如果LivenessProbe探针探测到容器不健康，则由kubelet将杀掉该容器，根据重启策略做响应的处理，如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe探针返回值永远是Success.

· ReadnessProbe探针  用于判断容器服务是否处于可用Ready状态，达到Ready状态的Pod才可以接收请求，对于Service管理的Pod，Service和Pod  Eendpoint的关联关系也将Pod是否Ready进行设置，如果运行过程中状态从Ready状态变为False，则系统会自动从Service的后端endpoint列表中将其隔离出去，后续再将恢复到Ready状态的Pod加入到后端Eendpoint列表中，以此来保证客户端在访问Service时不会被转发到服务不可用的pod实例上

· Startup Probe 探针  启动检测探针设置上也与前两者相似。其目的是为了保护启动时 间过于漫长的容器。通过为这个探针设置较长的检查间隔和检查次数可以保护容器在存活检测达到最 大失败尝试次数时不重启容器，而是在经历了启动检测探针尝试次数*启动检测探针检查间隔的时间之 后才会重启应用。通过这一点，我们不用将存活检测探针设置过大的值去等待应用启动，而是为启动 检测探针设置一个值来保护容器的启动过程

LivenessProbe和ReadinessProbe 均可支持三种方式

1. ExecAction 在容器内部执行一个命令，如果该命令返回为0，则表明容器健康

2. TCPSocketAction 通过容器的IP和端口号执行TCP检查，如果能建立连接则表明容器健康

3. HTTPGetAction 通过容器的IP、端口号以及路径调用的HTTP get方法 如果返回的状态码大于等于200且小于400 则认为容器健康

无论livenessProbe还是ReadInessProbe都要设置健康监测的频率和次数这个和我们常用的公有云负载均衡、nginx、以及其他的监控检查的监控类似，即可initialDelaySeconds和timeoutSeconds initialDelaySeconds  启动容器后进行首次健康检查的等待时间 单位为s timeoutSeconds  健康检查发送请求后等待响应的超时时间单位为秒，当超时发生时，kubelet会认为容器无法提供服务，将会重启该容器

Kubernetes集群中部署了ingress controller，当创建一条ingress规则，将域名 aa.test.com 指向到 serviceA 的8080端口，流量的走向是怎样的？Service 在其中是什么角色？

流量走向见上图：

I ngress 在这里主要承担了七层负载均衡的能力，后端挂载ClusterIP ，由Service管理Pod生命周期管理中pod ip 变更，aa .te st .com 是以nginx 虚拟主机多实例方式实现多个应用的暴露，例如a.te st .com , b .te st .com 等 ，再有ingress的pod 反向代理到Service , 实现应用集群的负载均衡，最后通过多层的负载均衡实现服务暴露。

Kubernetes 自带的Service 支持 NodePort 、ClusterIP、LoadB a lancer这三种服务暴露方式，每一种都有一些优点和缺点（见下文分析），从而由衍生出 ingress 这种七层负载均衡的服务暴露方式。

Node Port : 此方式是基于Node节点的port端口暴露服务，会在每个Node节点上监听一个端口，随意访问其中的一台Node节点就可以访问内部的服务，缺点，监听的端口不规则，量大的时候不方便管理，优点：网络实现简单一些，外部应用（内网）只要能访问Node 即可调用其内部应用，但是还需要考虑其Node的高可用，

C lusterIP:  是K8S内部虚拟的一个概念，此类型的service默认能和集群里面的N o de以及pod能够通信，可以解决集群内部的高可用问题，以及Pod实例在生命周期中IP频繁更换的问题。集群内部的调用直接通过Cluster IP 即可保证高可用，此外在Calico或者kube -router 此类BGP网络CNI场景下，可以将ClusterIP和其他区域网络打通，集群外部的应用可以直接和ClusterIP 通信。

L oadBalancer: 可以理解为使用外部负载均衡的接口，例如F5这种硬件负载均衡、以及阿里云SLB、Ucloud UlB 等，目前部分云厂商还是以LoadBalancer结合Node Port 的方式，即在云上的四层或者七层负载均衡实例后挂载Node Port ，以此解决 Pod 频繁变更IP的问题，也有极个别的云厂商在研究固定IP的CNI 后期直接在负载均衡上挂载Pod 实例。