k8s-故障转移 livenessProbe readinessProbe 学习总结
k8s-故障转移学习总结
大纲
- 概念
- K8S中Pod健康检查
- livenessProbe & readinessProbe
- livenessProbe 存活探测实例
- readinessProbe 就绪探测实例
概念
故障转移有哪些情况
- 物理机故障
- 程序故障
在计算机术语中，故障转移（英语：failover），即当活动的服务或应用意外终止时，快速启用冗余或备用的服务器、系统、硬件或者网络接替它们工作。
K8S中Pod健康检查
默认情况下，kubelet根据容器运行状态作为健康依据，不能监控容器中应用程序状态！
例如程序假死。这就会导致无法提供服务，丢失流量。因此引入健康检查机制确保容器健康存活。
Pod通过两类探针来检查容器的健康状态
- LivenessProbe（存活探测）
- ReadinessProbe（就绪探测）
启动（Startup）探针是另外的一个探测
官方资料： https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
livenessProbe(存活探测)
kubelet 使用livenessProbe(存活探测)来确定什么时候要重启容器。 例如，存活探针可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。
存活探测将通过http、shell命令或者tcp等方式去检测容器中的应用是否健康，然后将检查结果返回给kubelet，
如果检查容器中应用为不健康状态提交给kubelet后，kubelet将根据Pod配置清单中定义的重启策略restartPolicy来对Pod进行重启。
readinessProbe(就绪探测)
kubelet 使用就绪探针可以知道容器何时准备好接受请求流量，当一个 Pod 内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。
如果容器或则Pod状态为(NoReady)状态，Kubernetes则会把该Pod从Service的后端endpoints Pod中去剔除。
livenessProbe(存活探测)，readinessProbe(就绪探测)，这两种探测都支持以下方式对容器进行健康检查
- Exec(执行脚本)：在容器中执行命令，命令执行后返回的状态为0则成功，表示我们探测结果正常
- HTTP：根据容器IP、端口以及路径发送HTTP请求，返回码如果是200-400之间表示成功
- TCPSocketAction：根据容器IP地址及特定的端口进行TCP检查，端口开放表示成功
以上每种检查动作都可能有以下三种返回状态
- Success，表示通过了健康检查
- Failure，表示没有通过健康检查
- Unknown，表示检查动作失败
livenessProbe(存活探测)
livenessProbe(存活探测) 控制Pod的重启
livenessProbe: # 会访问localhost:5555/health 这个http请求httpGet: path: /healthport: 5555initialDelaySeconds: 10 #延迟探测时间timeoutSeconds: 1periodSeconds: 10 #访问频率单位秒failureThreshold: 3
配置说明
periodSeconds 字段指定了 kubelet 应该每几秒执行一次存活探测
initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒
failureThreshold 针对 HTTP 或 TCP 检测，可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对启动时间过慢的情况
例如
failureThreshold: 3
periodSeconds：10
应用程序将会有最多 半分钟（3 * 10 = 30s）的时间来完成其启动过程
注意：使用livenessProbe(存活探测)时要注意程序的启动时间如果启动时间过长会导致健康检查失败 一直重启
可以使用startupProbe（启动探针）保护慢启动容器
startupProbe:httpGet:path: /healthport: 5555failureThreshold: 30periodSeconds: 10
readinessProbe(就绪探测)
readinessProbe(就绪探测) 控制Service是否可以使用Pod
readinessProbe:# 会访问localhost:5555/health 这个http请求httpGet: path: /startokport: 5555# 可以自定义请求头httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 5 #延迟探测时间timeoutSeconds: 1periodSeconds: 5 #访问频率failureThreshold: 3
livenessProbe 存活探测实例
step1 镜像与配合的代码
调整docker容器JVM堆内存大小,让java.lang.OutOfMemoryError来得快点
对应的controller代码
//定义一个列表保存数据
private List<Object> list = new ArrayList<>();@RequestMapping("/oop")
public boolean oop(){System.out.println(list.size());new Thread(()->{while(true){//循环创建一个1M的数组 没有释放 让其触发OutOfMemoryErrorlist.add(new String[1024][1024]);list.add(new String[1024][1024]);list.add(new String[1024][1024]);list.add(new String[1024][1024]);System.out.println("加数据");}}).start();return true;
}//健康检查接口 无法继续创建对象
@RequestMapping("/health")
public String health() {Health h = createHealth();return h.getStatus();
}private Health createHealth(){Health h = new Health();h.setArry(new String[1024][1024]);h.setStatus("ok");return h;
}
step2 启动pod
http-health-check.yaml 关键配置如下：
livenessProbe: # 会访问localhost:5555/health 这个http请求httpGet: path: /healthport: 5555initialDelaySeconds: 10 #延迟探测时间timeoutSeconds: 1periodSeconds: 10 #访问频率failureThreshold: 3
详情见《/yaml/http-health-check.yaml》
kubectl apply -f http-health-check.yaml 创建Pod
可以看到 RESTARTS是0 表示还没重启过
step3 测试故障转移
触发OOM异常
此时 springboot已经无法正常使用了
step4 k8s故障转移
k8s会自动的重启 Pod 让服务重新可用
可以看到Pod RESTARTS是1 表示已经重启过一次
注意： livenessProbe 存活探测只无法处理节点宕机的情况
readinessProbe就绪探测实例
就绪探测可以测试pod是否可以开始对外提供服务了，Service可以开始使用pod了
step1 代码改造
step2 启动pod
http-health-check.yaml 关键配置如下：
readinessProbe:# 会访问localhost:5555/health 这个http请求httpGet: path: /startokport: 5555# 可以自定义请求头httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 5 #延迟探测时间timeoutSeconds: 1periodSeconds: 5 #访问频率failureThreshold: 3
详情见《/yaml/http-health-check.yaml》
kubectl apply -f http-health-check.yaml 创建Pod
step3 测试就绪探测
Pod成功创建 ，使用Pod ip可以访问程序，但使用service ip 则无法访问
等待90s后
成功访问
k8s-故障转移 livenessProbe readinessProbe 学习总结相关推荐
- 十、k8s健康检查之 livenessProbe/readinessProbe
健康检查 一个pod启动了之后,它有可能还在做初始化,这就意味着在初始化的应用进程还不能接受网络流量,所以要去控制一下pod的状态,也就是我还没有就绪,我还不能够接受流量. 有些应用跑着跑着没有响应, ...
- sqlserver 2012实施与管理学习笔记（一）：选型和部署之单机部署、故障转移群集与日志传送
sqlserver 2012实施与管理学习笔记(一):选型和部署之单机部署.故障转移群集与日志传送 数据库的选型和部署 sqlserver的安装和升级 选择高可用性和灾难恢复技术 故障转移群集 日志传 ...
- 学习：双机热备、集群、负载均衡、SQL故障转移群集简单理解（转）
双机热备.集群.负载均衡.SQL故障转移群集简单理解平常,大家常提到几个技术名词:双机热备.集群.负载均衡.SQL故障转移群集.这里,就我的理解,和大家简单探讨下,有不足或错误之处还请各位指出! 这些 ...
- was连接oracle rac集群,Oracle 学习之RAC(九) 集群负载均衡及故障转移
查看监听,使用grid用户 11grac1:11grac1-> lsnrctl status LSNRCTL for Linux: Version 11.2.0.3.0 - Production ...
- Redis应用学习——Redis Cluster故障转移
2019独角兽企业重金招聘Python工程师标准>>> 1. 发现故障 1. Redis Cluster节点故障发现依赖于集群中所有节点之间互相的ping/pong消息 2. 主观下 ...
- [转] 微软SQL Server 2008故障转移集群概述（Windows Server Failover Clustering (WSFC)）
前言: 最近在研究微软的大数据解决方案,在收听MS TechNet "SQL Server 2012 AlwaysOn HA+DR设计模型.架构及最佳实践" 时,需要一些预备知识, ...
- 高并发应用场景下的负载均衡与故障转移实践，AgileEAS.NET SOA 负载均衡介绍与实践...
一.前言 AgileEAS.NET SOA 中间件平台是一款基于基于敏捷并行开发思想和Microsoft .Net构件(组件)开发技术而构建的一个快速开发应用平台.用于帮助中小型软件企业建立一条适合市 ...
- SQL Server 2008 高可用性视频（四）-- 故障转移群集
做数据库的朋友都知道, 其实数据库的工作大致可以分为三类: 数据库设计与开发, 数据库管理, 数据库商业智能. 其中数据库管理的工作大部分是由DBA在做, DBA们除了要保证正常的数据库运行, 还要采 ...
- 【Hadoop 分布式部署 十 一: NameNode HA 自动故障转移】
问题描述: 上一篇就是NameNode 的HA 部署完成,但是存在问题,问题是如果 主NameNode的节点宕机了,还是需要人工去使用命令来切换NameNode的Acitve 这样很不方便,所以 ...
最新文章
- Java容器类研究4：ArrayList
- 【Swing编写图形用户界面】操作系统之磁盘调度算法图形界面和性能比较
- Step by Step WebMatrix网站开发之二：使用WebMatrix（2）
- [No000011B]为什么有些程序员悄无声息渡过35岁中年危机？
- 打包后放在服务器上二级目录找不到解决办法
- python导入同目录下的模块_如何从同一目录下的模块导入？
- JAVA的字节码技术
- JDK源码解析之 Java.lang.AbstractStringBuilder
- 解决maven加载不了oracle jdbc驱动包的问题
- 京东金融回应用户遭盗刷：系用户点击假冒链接 输短信验证码致密码泄露
- 大数据对人们的好处_大数据有什么作用和优势
- C++轻量级微服务_『高级篇』docker容器来说什么是微服务（三）
- 拓端tecdat|R语言深度学习：用keras神经网络回归模型预测时间序列数据
- 论开学第二个月干了点啥
- Navicat Premium 12破解方法
- tcp流式传输_收听互联网广播以及下载和流式传输免费音乐的最佳网站
- 手机word如何转换html,如何把Word转换为网页html格式
- 机器学习十大算法！入门看这个就够了~
- 电脑保护眼睛的颜色设置
- echart各种显示数据的格式化