K8S - 容器探针(Probe)

Configure Liveness and Readiness Probes
对线上业务来说,保证服务的正常稳定是重中之重,对故障服务的及时处理避免影响业务以及快速恢复一直是开发运维的难点。Kubernetes提供了健康检查服务,对于检测到故障服务会被及时自动下线,以及通过重启服务的方式使服务自动恢复

使用Liveness及Readness探针

Liveness探针:主要用于判断Container是否处于运行状态,比如当服务crash或者死锁等情况发生时,kubelet会kill掉Container,然后根据其设置的restart policy进行相应操作(可能会在本机重新启动Container,或者因为设置Kubernetes QoS,本机没有资源情况下会被分发的其他机器上重新启动)。
Readness探针:主要用于判断服务是否已经正常工作,如果服务没有加载完成或工作异常,服务所在的Pod的IP地址会从服务的Endpoints中被移除,也就是说,当服务没有ready时,会将其从服务的load balancer中移除,不会再接受或响应任何请求。

探针检查结果分为3种情况:

  • 成功(Success):通过检查。
  • 失败(Failure):检查失败。
  • 未知(Unknown):检查未知,需要人工干预。

在这里插入图片描述
服务可用性与自动恢复

  • 如果服务的健康检查(readiness)失败,故障的服务实例从service endpoint中下线,外部请求将不会再转发到该服务上,一定程度上保证正在提供的服务的正确性,如果服务自我恢复了(比如网络问题),会自动重新加入service endpoint对外提供服务。
  • 另外,如果设置了Container(liveness)的探针,对故障服务的Container(liveness)的探针同样会失败,container会被kill掉,并根据原设置的container重启策略,系统倾向于在其原所在的机器上重启该container、或其他机器重新创建一个pod。

由于上面的机制,整个服务实现了自身高可用与自动恢复。

使用建议

  • 对全部服务同时设置服务(readiness)和Container(liveness)的健康检查。
  • 通过TCP对端口检查(TCPSocketAction),仅适用于端口已关闭或进程停止情况。因为即使服务异常,只要端口是打开状态,健康检查仍然是通过的。
  • 基于第二点,一般建议用ExecAction自定义健康检查逻辑,或采用HTTP Get请求进行检查(HTTPGetAction)。
  • 无论采用哪种类型的探针,一般建议设置检查服务(readiness)的时间短于检查Container(liveness)的时间,也可以将检查服务(readiness)的探针与Container(liveness)的探针设置为一致。目的是故障服务先下线,如果过一段时间还无法自动恢复,那么根据重启策略,重启该Container、或其他机器重新创建一个Pod恢复故障服务。

Pod的重启策略:
当pod中一个container处于退出状态(Exited)时,kubelet会根据Pod Spec中设置restartPolicy进行相应操作,重启的策略分别如下:

  • Always: 默认的重启策略,只要有一个container处于Exited时,即会重启
  • OnFailure:container退出状态不为0时,即会重启。
  • Never: 从不重启。

需要重点说明的是:
一个pod设置重启策略,适用于pod中全部container。
处于退出状态的容器由 kubelet 以五分钟为上限的指数衰减延迟(10秒,20秒,40秒…)重新启动,并在container重启成功十分钟后会重置该值。

liveness.yaml
容器会创建一个文件/tmp/healthy,30秒后删除;探针5秒会检查一次,检查方式为cat /tmp/healthy文件是否存在,检查到容易有问题,探测失败3次,则重建容器

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec-wfq
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

如检测日志:

Events:
  Type     Reason                 Age                From                Message
  ----     ------                 ----               ----                -------
  Normal   Scheduled              17m                default-scheduler   Successfully assigned liveness-exec-wfq to 10.0.1.16
  Normal   SuccessfulMountVolume  17m                kubelet, 10.0.1.16  MountVolume.SetUp succeeded for volume "default-token-nqldz"
  Normal   Pulling                15m (x3 over 17m)  kubelet, 10.0.1.16  pulling image "busybox"
  Normal   Pulled                 15m (x3 over 17m)  kubelet, 10.0.1.16  Successfully pulled image "busybox"
  Normal   Created                15m (x3 over 17m)  kubelet, 10.0.1.16  Created container
  Normal   Started                15m (x3 over 17m)  kubelet, 10.0.1.16  Started container
  Warning  Unhealthy              14m (x9 over 17m)  kubelet, 10.0.1.16  Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing                7m (x7 over 16m)   kubelet, 10.0.1.16  Killing container with id docker://liveness:Container failed liveness probe.. Container will be killed and recreated.
  Warning  BackOff                2m (x27 over 10m)  kubelet, 10.0.1.16  Back-off restarting failed container

liveness_http.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http-wfq
spec:
  containers:
  - name: liveness
    image: googlecontainer/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

readness.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginxsvc
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    protocol: TCP
    name: http
  - port: 443
    protocol: TCP
    name: https
  selector:
    run: my-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: nginxhttps
        image: ymqytw/nginxhttps:1.5
        command: ["/home/auto-reload-nginx.sh"]
        ports:
        - containerPort: 443
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 3
          timeoutSeconds: 1
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          failureThreshold: 3
          timeoutSeconds: 1

initcontailner
如在initcontainer中先拉取nginx的配置,然后在nginx container 中去消费nginx的配置

init_container.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;’]

  • 1
    点赞
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
一、为什么学习kubernetes众所周知,随着容器的快速发展,容器管理工具kubernetes也应运而生,目前不仅百度、京东、阿里、google等大公司在使用kubernetes,一些中小企业也开始把业务迁移到kubernetes,那么作为运维、开发、测试或者架构师来说,必须要掌握这项技术,才能提现我们的工作价值,才能在行业具备保持较高的技术水平,kubernetes作为成熟的容器编排工具,具有容器集群的自动化部署、自动化伸缩和故障自恢复的能力,让容器的部署和管理变得更加容易,能够给企业和提供一个智能化的容器云管理平台,为企业快速上云提供一个安全可靠的解决方案,此课程主要介绍kubernetes1.14/kubernetes1.15版本高可用集群的安装部署和使用,通过我多年工作经验总结,带你深入体验企业实战案例,让您轻松快速的掌握k8s,接下来让我们一起出发吧。 二、课程亮点 三、讲师简介 先超(lucky):高级运维工程师、资深DevOps工程师,在互联网上市公司拥有多年一线运维经验,主导过亿级pv项目的架构设计和运维工作 主要研究方向: 1.云计算方向:容器 (kubernetes、docker),虚拟化(kvm、Vmware vSphere),微服务(istio),PaaS(openshift),IaaS(openstack)等2.系统/运维方向:linux系统下的常用组件(nginx,tomcat,elasticsearch,zookeeper,kafka等),DevOps(Jenkins+gitlab+sonarqube+nexus+k8s),CI/CD,监控(zabbix、prometheus、falcon)等.
k8s存活探针和就绪探针是用来检测容器的状态和可用性的。存活探针(Liveliness Probe)用于判断容器是否处于正在运行状态,如果容器出现故障或死锁,k8s会自动将其下线并重新启动。而就绪探针(Readiness Probe)用于判断服务是否已经准备好接收流量,如果服务还未完全启动或出现异常情况,k8s会将其从服务的负载均衡器中移除,不再接受或响应任何请求。 存活探针可以通过执行容器内部的shell命令、检查容器的TCP连接或发送HTTP请求来进行健康检查,如果探测失败,k8s会将故障的容器kill掉,并根据设置的重启策略进行重启。而就绪探针则通过HTTP请求来检查服务是否准备就绪,如果就绪探测失败,k8s会将服务从负载均衡器中移除,直到服务完全就绪后再将其添加回负载均衡器。 在使用存活探针和就绪探针时,建议将检查服务的时间短于检查容器的时间,以实现先下线再重启的策略。这样,在故障发生后,服务会先被下线,如果一段时间后服务无法自动恢复,k8s会根据重启策略进行重启。通过使用这两种探针,可以确保服务的可用性和自动恢复能力。 总结来说,存活探针用于判断容器是否处于运行状态,并在容器故障时重新启动,而就绪探针用于判断服务是否已经准备好接收流量,并将未就绪的服务下线,直到服务完全就绪后再上线。这两种探针是确保k8s中应用的稳定性和可用性的重要工具。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [k8s的就绪探针和存活探针](https://blog.csdn.net/qingqingxiangyang/article/details/118026170)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值