Kubernetes容器探针

简介: Kubernetes容器探针

probe(探针)是由 kubelet 对容器执行的定期诊断。要执行诊断,kubelet 既可以在容器内执行代码,也可以发出一个网络请求。容器探针就是用来定期对容器进行健康检查的。

探测类型

针对运行中的容器,kubelet 可以选择是否执行以下三种探针,以及如何针对探测结果作出反应:

livenessProbe

指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器,并且容器将根据其重启策略决定未来。如果容器不提供存活探针, 则默认状态为 Success。

readinessProbe

指示容器是否准备好为请求提供服。如果就绪态探测失败,端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。如果容器不提供就绪态探针,则默认状态为 Success。

startupProbe(1.7+版本)

指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被禁用,直到此探针成功为止。如果启动探测失败,kubelet 将杀死容器,而容器依其重启策略进行重启。如果容器没有提供启动探测,则默认状态为 Success。

探针机制

使用探针来检查容器有四种不同的方法。每个探针都必须准确定义为这四种机制中的一种:

exec

在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

grpc

使用 gRPC 执行一个远程过程调用。目标应该实现 gRPC 健康检查。如果响应的状态是 “SERVING”,则认为诊断成功。gRPC 探针是一个 Alpha 特性,只有在你启用了 “GRPCContainerProbe” 特性门控时才能使用。

httpGet

对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400,则诊断被认为是成功的。

tcpSocket

对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开,则诊断被认为是成功的。如果远程系统(容器)在打开连接后立即将其关闭,这算作是健康的。

探针结果

每次探测都将获得以下三种结果之一:

  • Success(成功)容器通过了诊断。
  • Failure(失败)容器未通过诊断。
  • Unknown(未知)诊断失败,因此不会采取任何行动。

探针参数

initialDelaySeconds: 5     # 初始化时间5s
periodSeconds: 4         # 检测间隔时间4s
timeoutSeconds: 1        # 默认检测超时时间为1s
failureThreshold: 3      # 默认失败次数为3次,达到3次后重启pod
successThreshold: 1          # 默认成功次数为1次,1次监测成功代表成功

使用探针

exec

apiVersion: v1
kind: Pod
metadata:
  name: liveness-test
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;"      # 睡眠7s后启动
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:                     # 这里使用 exec 执行 shell 命令检测容器状态
        command:  
        - ls
        - /var/run/nginx.pid            # 查看是否有pid文件
      initialDelaySeconds: 5            # 初始化时间5s
      periodSeconds: 4                # 检测间隔时间4s
      timeoutSeconds: 1               # 默认检测超时时间为1s
      failureThreshold: 3             # 默认失败次数为3次,达到3次后重启pod
      successThreshold: 1             # 默认成功次数为1次,1 次代表成功

此 Pod 文件中,定义容器启动后,先睡眠 7s,然后启动 Nginx(启动 Nginx 后会生成文件 /var/run/nginx.pid),定义的探针当容器启动 5s 后执行一次检测,由于此时还在睡眠,所以检测失败,但定义的 failureThreshold 参数表示连续失败三次才会重启容器,所以再过 4s 进行下一次检测,此时由于已经睡够 7s,Nginx 已完成启动,故而探针检测成功。所以 Pod 并不会重启。

tcpSocket

apiVersion: v1
kind: Pod
metadata:
  name: liveness-test
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;"      # 睡眠7s后启动
    imagePullPolicy: IfNotPresent
    livenessProbe:
      tcpSocket:
        port: 80                # 检测80端口
      initialDelaySeconds: 5            # 初始化时间5s
      periodSeconds: 4                # 检测间隔时间4s
      timeoutSeconds: 1               # 默认检测超时时间为1s
      failureThreshold: 3             # 默认失败次数为3次,达到3次后重启pod
      successThreshold: 1             # 默认成功次数为1次,1 次代表成功

这个 Pod 和上面的效果是一样的,只不过检测的方式是通过检测 80 端口。

httpGet

apiVersion: v1
kind: Pod
metadata:
  name: liveness-test
spec:
  containers:
  - name: nginx
    image: nginx:1.19
    ports:
    - containerPort: 80
    args:
    - /bin/sh
    - -c
    - sleep 7;nginx -g "daemon off;"      # 睡眠7s后启动
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:                    # httpget方式
        port: 80                  # 访问的端口
        path: /index.html             # 访问的路径
      initialDelaySeconds: 5            # 初始化时间5s
      periodSeconds: 4                # 检测间隔时间4s
      timeoutSeconds: 1               # 默认检测超时时间为1s
      failureThreshold: 3             # 默认失败次数为3次,达到3次后重启pod
      successThreshold: 1             # 默认成功次数为1次,1 次代表成功

这个 Pod 和上面的效果是一样的,只不过检测的方式是给 80 端口的 index.html 发送 Get 请求。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1月前
|
人工智能 弹性计算 运维
ACK Edge与IDC:高效容器网络通信新突破
本文介绍如何基于ACK Edge以及高效的容器网络插件管理IDC进行容器化。
|
1月前
|
监控 NoSQL 时序数据库
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
237 77
|
22天前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
110 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
5天前
|
Kubernetes Linux 虚拟化
入门级容器技术解析:Docker和K8s的区别与关系
本文介绍了容器技术的发展历程及其重要组成部分Docker和Kubernetes。从传统物理机到虚拟机,再到容器化,每一步都旨在更高效地利用服务器资源并简化应用部署。容器技术通过隔离环境、减少依赖冲突和提高可移植性,解决了传统部署方式中的诸多问题。Docker作为容器化平台,专注于创建和管理容器;而Kubernetes则是一个强大的容器编排系统,用于自动化部署、扩展和管理容器化应用。两者相辅相成,共同推动了现代云原生应用的快速发展。
46 10
|
1月前
|
人工智能 运维 监控
阿里云ACK容器服务生产级可观测体系建设实践
本文整理自2024云栖大会冯诗淳(花名:行疾)的演讲,介绍了阿里云容器服务团队在生产级可观测体系建设方面的实践。冯诗淳详细阐述了容器化架构带来的挑战及解决方案,强调了可观测性对于构建稳健运维体系的重要性。文中提到,阿里云作为亚洲唯一蝉联全球领导者的容器管理平台,其可观测能力在多项关键评测中表现优异,支持AI、容器网络、存储等多个场景的高级容器可观测能力。此外,还介绍了阿里云容器服务在多云管理、成本优化等方面的最新进展,以及即将推出的ACK AI助手2.0,旨在通过智能引擎和专家诊断经验,简化异常数据查找,缩短故障响应时间。
阿里云ACK容器服务生产级可观测体系建设实践
|
19天前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
12天前
|
人工智能 运维 监控
容器服务Kubernetes场景下可观测体系生产级最佳实践
阿里云容器服务团队在2024年继续蝉联Gartner亚洲唯一全球领导者象限,其可观测体系是运维的核心能力之一。该体系涵盖重保运维、大规模集群稳定性、业务异常诊断等场景,特别是在AI和GPU场景下提供了全面的观测解决方案。通过Tracing、Metric和Log等技术,阿里云增强了对容器网络、存储及多集群架构的监控能力,帮助客户实现高效运维和成本优化。未来,结合AI助手,将进一步提升问题定位和解决效率,缩短MTTR,助力构建智能运维体系。
|
1月前
|
运维 Kubernetes 调度
阿里云容器服务 ACK One 分布式云容器企业落地实践
阿里云容器服务ACK提供强大的产品能力,支持弹性、调度、可观测、成本治理和安全合规。针对拥有IDC或三方资源的企业,ACK One分布式云容器平台能够有效解决资源管理、多云多集群管理及边缘计算等挑战,实现云上云下统一管理,提升业务效率与稳定性。
|
2月前
|
运维 Kubernetes Docker
深入理解容器化技术:Docker与Kubernetes的协同工作
深入理解容器化技术:Docker与Kubernetes的协同工作
78 14
|
2月前
|
Kubernetes Cloud Native 持续交付
容器化、Kubernetes与微服务架构的融合
容器化、Kubernetes与微服务架构的融合
52 1