使用liveness探针httpget方式检测pod健康,httpGet方式使用的最多

[root@k8s-master1 tanzhen]# cat nginx_pod_httpGet.yaml
apiVersion: v1
kind: Pod
metadata:
name: httpget
labels:
app: my-dep
spec:
containers:
- name: nginx
image: centos-nginx:1.23.0
imagePullPolicy: Never
ports:
- containerPort: 80 livenessProbe:
httpGet:
path: /index.html
port: 80
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 2

创建pod

[root@k8s-master1 tanzhen]# kubectl create -f nginx_pod_httpGet.yaml
pod/httpget created

查询pod描述

由于检测的是Nginx80端口index.html页面,这个连接正常存在,所以状态一直是Normal

[root@k8s-master1 ~]# kubectl describe pod httpget
Name: httpget
Namespace: default
Priority: 0
Node: k8s-node1/192.168.198.146
Start Time: Tue, 23 Aug 2022 10:56:44 +0800
Labels: app=my-dep
Annotations: <none>
Status: Running
IP: 10.244.1.53
IPs:
IP: 10.244.1.53
Containers:
nginx:
Container ID: docker://00e017fcb9763c113b39433f1e33516d25ed9426f85bca78e89f17c13a0c0282
Image: centos-nginx:1.23.0
Image ID: docker://sha256:704f81f69b5bf4f7b52006b1ebea4c4c25c92dd95994dacad66780ae82395607
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Tue, 23 Aug 2022 10:56:45 +0800
Ready: True
Restart Count: 0
Liveness: http-get http://:80/index.html delay=5s timeout=3s period=5s #success=1 #failure=2
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-clqrl (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-clqrl:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-clqrl
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 6m34s default-scheduler Successfully assigned default/httpget to k8s-node1
Normal Pulled 6m32s kubelet Container image "centos-nginx:1.23.0" already present on machine
Normal Created 6m32s kubelet Created container nginx
Normal Started 6m32s kubelet Started container nginx

重新发布一个pod:httpget2,检测端口改成8080,测试检测结果

apiVersion: v1
kind: Pod
metadata:
name: httpget2
labels:
app: my-dep
spec:
containers:
- name: nginx
image: centos-nginx:1.23.0
imagePullPolicy: Never
ports:
- containerPort: 80 livenessProbe:
httpGet:
path: /index.html
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 2
[root@k8s-master1 tanzhen]# kubectl apply -f nginx_pod_httpGet.yaml
pod/httpget2 created

探针检测 Get "http://10.244.1.54:8080/index.html"失败,容器kill掉重启

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 46s default-scheduler Successfully assigned default/httpget2 to k8s-node1
Normal Pulled 13s (x4 over 45s) kubelet Container image "centos-nginx:1.23.0" already present on machine
Normal Created 13s (x4 over 45s) kubelet Created container nginx
Normal Started 13s (x4 over 45s) kubelet Started container nginx
Warning Unhealthy 3s (x8 over 38s) kubelet Liveness probe failed: Get "http://10.244.1.54:8080/index.html": dial tcp 10.244.1.54:8080: connect: connection refused
Normal Killing 3s (x4 over 33s) kubelet Container nginx failed liveness probe, will be restarted
Warning BackOff 3s kubelet Back-off restarting failed container

httpget2  可以看到已经重启了6次

[root@k8s-master1 tangzheng]# kubectl get pod
NAME READY STATUS RESTARTS AGE
httpget 1/1 Running 0 28m
httpget2 1/1 Running 6 3m8s

pod资源的健康检查-liveness探针的httpGet使用的更多相关文章

  1. pod资源的健康检查-liveness探针的exec使用

    使用探针的方式对pod资源健康检查 探针的种类 livenessProbe:健康状态检查,周期性检查服务是否存活,检查结果失败,将重启容器 readinessProbe:可用性检查,周期性检查服务是否 ...

  2. pod资源的健康检查-readiness探针的httpGet使用

    livenessProbe:健康状态检查,周期性检查服务是否存活,检查结果失败,将重启容器 readinessProbe:可用性检查,周期性检查服务是否可用,不可用将从service的endpoint ...

  3. 2.k8s.Pod生命周期,健康检查

    #Pod生命周期,健康检查 pod创建过程 Init容器 就绪探测 存活探测 生命周期钩子 #Pod创建过程 master节点:kubectl -> kube-api -> kubenle ...

  4. pod健康检查(liveness probe存活探针&&readiness probe 可读性探针)

    在Kubernetes集群当中,我们可以通过配置liveness probe(存活探针)和readiness probe(可读性探针)来影响容器的生存周期.参考文档:https://kubernete ...

  5. Openshift中Pod的SpringBoot2健康检查

    Openshift中Pod的SpringBoot2应用程序健康检查 1. 准备测试的SpringBoot工程, 需要Java 8 JDK or greater and Maven 3.3.x or g ...

  6. Kubernetes中Pod的健康检查

    本文介绍 Pod 中容器健康检查相关的内容.配置方法以及实验测试,实验环境为 Kubernetes 1.11,搭建方法参考kubeadm安装kubernetes V1.11.1 集群 0. 什么是 C ...

  7. idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

    Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness: liveness探针用来侦测什么时候需要重启容器.比如说当liveness ...

  8. 十一、Pod的健康检查-探针

    Pod 的健康检查-探针 一.Pod 的健康检查-探针 1.1.探针基本概念 ​探针是由 kubelet 对容器执行的定期诊断.要执行诊断,kubelet 调用由容器实现的 Handler 有三种类型 ...

  9. kubernetes之pod健康检查

    目录 kubernetes之pod健康检查 1.概述和分类 2.LivenessProbe探针(存活性探测) 3.ReadinessProbe探针(就绪型探测) 4.探针的实现方式 4.1.ExecA ...

随机推荐

  1. php 访问控制可见性 public protected private

    对属性或方法的访问控制,是通过在前面添加关键字public(公有),protected(受保护的),private(私有)来实现. 被定义为公有的类成员可以在任何地方被访问. 被定义为受保护的类成员则 ...

  2. React关于constructor与super(props)之间的相爱相杀

    我们先把菜鸟教程的一段代码拿过来分析一下.下面这段代码是用了将生命周期方法添加到类中实现时钟效果. // 将生命周期方法添加到类中 class Clock extends React.Componen ...

  3. Win 系统下使用gnvm操作node版本

    下载 gnvm官方网址 有好几种安装方式,我这里使用的是百度网盘下载. 安装 下载完成将gnvm.exe文件放到node的安装根目录下,如果你不知道安装目录在哪?可以使用命令: where node ...

  4. sql server 开启一个事务

    开启事务,回滚 /*============================================================== */ /* Date : 2020年11月18日 11 ...

  5. Nacos 的安装与服务的注册

    Nacos 的安装与服务的注册 我们都知道naocs是一个注册中心,那么注册中心是什么呢? 什么是注册中心? 它类似与一个中介角色(不收费的良心中介), 在微服务中起纽带的作用,它提供了服务和服务地址 ...

  6. XML方式配置切面

    1. 概述  一个切面中需要包含什么,才能够作用到连接点?切面中是包含通知的,通知作用到连接点需要有切入点表达式. 除了使用AspectJ注解声明切面,Spring也支持在bean配置文件中声明切面. ...

  7. 关于 Flink 状态与容错机制

    Flink 作为新一代基于事件流的.真正意义上的流批一体的大数据处理引擎,正在逐渐得到广大开发者们的青睐.就从我自身的视角看,最近也是在数据团队把一些原本由 Flume.SparkStreaming. ...

  8. 5-17 ELK 日志采集查询保存

    ELK简介 什么是ELK ELK: E:Elasticsearch 全文搜索引擎 L:logstash 日志采集工具 K:Kibana ES的可视化工具 ELK是当今业界非常流行的日志采集保存和查询的 ...

  9. vivo官网APP全机型UI适配方案

    vivo 互联网客户端团队- Xu Jie 日益新增的机型,给开发人员带来了很多的适配工作.代码能不能统一.apk能不能统一.物料如何选取.样式怎么展示等等都是困扰开发人员的问题,本方案就是介绍不同机 ...

  10. vivado没用上的寄存器变量

    vivado中定义了但没用上的寄存器变量,在综合时会被移除,即没有综合出来.(如下cnt,虽然在y的过程块中用了cnt作为判断条件,但实际上cnt用了跟没用效果一样,所以综合时cnt_reg就被放弃了 ...