本文主要是详细介绍K8S中的健康检查的2类方式, 即: 存活(liveness)探针和就绪(readiness)探针, 前者关乎pod是否要重启, 后者关乎service 端点列表是否要拿掉该pod. 介绍完之后并附上最佳实践案例, 涵盖: web server, tomcat等中间件, redis等缓存服务器, mysql等开源数据库, spring微服务...
本系列文章探讨了企业客户在使用Kubernetes时遇到的一些常见问题。Container Service客户经常提出的一个问题是,“我如何处理服务之间的依赖关系?”
健康检查(Health Check)可用于服务运行的状态监控,比如腾讯旗下的DNSPOD的D监控,要求配置一个访问路径以判断网站是否可以正常访问实际上就是一个健康检查,当发现健康检查失败时会发送一个邮件通知或者短信来告知网站管理员进行维修。
我们经常会遇到Pod在启动后一会儿就挂掉然后又重启一直循环. kubernetes是如何探测Pod是否存活的呢,
Kubernetes调度Pod到Kubernetes节点上,节点上的Kubelet运行Pod的容器。如果容器内进程终止运行(容器的主进程崩溃),Kubelet会自动重启容器,这体现了Kubernetes赋予应用的自愈能力。在某些情况下,即使容器内进程没有崩溃,应用程序仍可能处于非正常工作状态。Kubernetes默认只是检查Pod的容器是否正常运行,但容器正常运行并不一定代表应用健康。我们可以通过Kubernetes提供的探针来探测容器应用是否健康,然后决定是否重启恢复应用到正常工作状态,以及决定容器是否能接收请求。
当你使用kubernetes的时候,有没有遇到过Pod在启动后一会就挂掉然后又重新启动这样的恶性循环?你有没有想过kubernetes是如何检测pod是否还存活?虽然容器已经启动,但是kubernetes如何知道容器的进程是否准备好对外提供服务了呢?让我们通过kubernetes官网的这篇文章Configure Liveness and Readiness Probes,来一探究竟。
https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
分布式系统通常被描述为一把双刃剑。网上有许多优秀的文章阐述分布式系统糟糕和伟大的方面。这篇文章并非如此。我通常倾向于相信分布式系统在适当的地方,但这篇博客文章(以及后续的两篇文章)的目标是与您分享一些我在分布式系统中出错导致广泛影响的故事。
随着环境中运行的微服务数量的增加,主动监控微服务的所有实例的运行状况变得更加重要。使用像OpenShift这样的容器管理技术,可以利用运行状况检查,来自动决定是否使用新容器来丢弃和替换不健康的容器。通过快速更换不健康的容器,OpenShift极大地提高了服务的整体正常运行时间。
Kubernetes 的 livenessProbe 是有一定危险性的。建议在用例清晰,并且理解足够深刻的情况下才使用这个功能。本文会涉及到存活检测以及就绪检测,并做出一些应该或者不该的建议。
Kubernetes如今已成为包括谷歌、Shopify、Slack在内世界上一些规模最大的运营商所采用的关键技术。Kubernetes使企业能够以以前无法实现的方式利用云计算技术,并且也能够对大数据执行相同的操作。
kubelet 使用存活探测器来知道什么时候要重启容器。例如,存活探测器可以捕捉到死锁(应用程序在运行,但是无法继续执行后面的步骤)。这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
在我们多年使用kubernetes的经验中,我们有幸看到了很多集群(在GCP,AWS和Azure上都是托管的和非托管的),并且我们看到一些错误在不断重复。
探针配置失误,线上容器应用异常死锁后,kubernetes集群未及时响应自愈重启容器?
云原生应用程序通常设计为使用微服务架构,其中每个组件都位于容器中。为了确保Kubernetes托管的应用程序高可用,在设计集群时需要遵循一些特定的模式,其中有“健康探测模式”。应用高可观察性原则(HOP)可确保您的应用程序收到的每个请求都能及时找到响应。
有些容器基础镜像。线上没法排错。使用临时容器进入这个Pod。临时容器共享了Pod的所有。临时容器有Debug的一些命令,排错完成以后,只要exit退出容器,临时容器自动删除
编写Pod配置文件: 首先,需要创建一个描述Pod的配置文件,通常使用YAML或JSON格式。在配置文件中定义Pod的名称、容器镜像、资源要求、环境变量、挂载卷等信息。
Pod 遵循一个预定义的生命周期,起始于 Pending 阶段,如果至少 其中有一个主要容器正常启动,则进入 Running,之后取决于 Pod
调试Kubernetes应用程序通常是一个痛苦的过程,充满未知和不可预知的副作用。当你的Kubernetes集群没有自我愈合时会发生什么?错误配置的资源限制如何影响应用程序在生产环境中运行?如果不遵循一些基本原则,处理这些问题通常会使调试Kubernetes成为一个非常困难的过程。
在上篇我们讲到了较为傻瓜初级的弹性伸缩和滚动更新,那么接下来我们来看看较为高级的智能的滚动更新。本节的知识点呢是K8S的liveness和readiness探测,也就是说利用健康检查来做更为智能化的弹性扩容和滚动更新。
只要将pod调度到某个节点,Kubelet就会运行pod的容器,如果该pod的容器有一个或者所有的都终止运行(容器的主进程崩溃),Kubelet将重启容器,所以即使应用程序本身没有做任何特殊的事,在Kubemetes中运行也能自动获得自我修复的能力。
本文翻译自 Kubernetes Probes (and Why They Matter for Autoscaling)。
创建 Pod 时,可以为其下的容器设置环境变量。通过配置文件的 env 或者 envFrom 字段来设置环境变量。
今天在群里又看有人问如何设置 Kubernetes 的探针,感觉要补充的话太多了,结合我们在一些 DevOps 项目中痛苦的体验,今天一劳永逸的全部说完,此外,也为大家展现一下为什么 DevOps 这么难?
Pod 的 status 定义在 PodStatus 对象中,其中有一个 phase 字段。它简单描述了 Pod 在其生命周期的阶段。熟悉Pod的各种状态对我们理解如何设置Pod的调度策略、重启策略是很有必要的。
Pod 的 status 属性是一个 PodStatus 对象,拥有一个 phase 字段。它简单描述了 Pod 在其生命周期的阶段。
配置 readiness、liveness 和 startup 探针可以处理不健康的 Pod,本文介绍了三种类型的探针、最佳实践和有关工具,以检测可能存在的配置问题。
k8s通过liveness来探测微服务的存活性,判断什么时候该重启容器实现自愈。比如访问 Web 服务器时显示 500 内部错误,可能是系统超载,也可能是资源死锁,此时 httpd 进程并没有异常退出,在这种情况下重启容器可能是最直接最有效的解决方案。
您是否害怕将集群升级到更新的 Kubernetes 版本?有几个原因可能会促使您升级。也许您想要执行以下操作之一:
Pod是kubernetes中最小的资源管理组件,Pod也是最小化运行容器化应用的资源对象。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的,例如,用于管理Pod运行的StatefulSet和Deployment等控制器对象,用于暴露Pod应用的Service和Ingress对象,为Pod提供存储的PersistentVolume存储资源对象等。
Pod中通过共享Network Namespace的方式进行网络的共享,但是如果是以下方式进行Network Namespace共享会有问题:
每个Pod里运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此他们之间通信和数据交换更为高效。在设计时可以充分利用这一特性,将一组密切相关的服务进程放入同一个Pod中;同一个Pod里的容器之间仅需通过localhost就能互相通信。
Pod 的 status 定义在 PodStatus 对象中,其中有一个 phase 字段。
用户通过Liveness探测可以告诉Kubernetes什么时候通过重启容器实现自愈;Readiness探测则是告诉Kubernetes什么时候可以将容器加入到Service负载均衡池中,对外提供服务。
本文介绍了容器健康检查的概念、检查类别、检查方式、公共参数以及相关示例,以帮助用户更好地了解和掌握容器健康检查的相关知识。
在Istio项目中,istio/operator/pkg/translate/translate.go文件的作用是处理Istio Operator的配置信息和Kubernetes的资源对象之间的翻译和转换。
Kubernetes v1.26 包括网络流量工程方面的重大进步,其中两个功能(服务内部流量策略支持和 EndpointSlice 终止条件)升级为 GA,第三个功能(代理终止端点 Proxy terminating endpoints)升级为测试版。这些增强功能的组合旨在解决当今人们在 traffic 工程中面临的缺点,并为未来解锁新功能。
YAML是一个可读性高,用来表达数据序列的格式。YAML的意思其实是:仍是一种标记语言,但为了强调这种语言以数据做为中心,而不是以标记语言为重点。
对线上业务来说,保证服务的正常稳定是重中之重,对故障服务的及时处理避免影响业务以及快速恢复一直是开发运维的难点。Kubernetes提供了健康检查服务,对于检测到故障服务会被及时自动下线,以及通过重启服务的方式使服务自动恢复。
最近一两个月生产K8s集群频繁出现短时503 Service Temporarily Unavailable,还不能主动复现,相当郁闷,压力山大。
实际生产环境中,为了稳定和高可用(晚上睡觉踏实),我们并不会把mysql装在k8s集群中,一般是用阿里云的RDS或者自己在高性能机器上搭建mysql。
K8S作为云原生架构下最流行的服务编排平台,核心功能之一就是对该平台上的容器进行动态编排。
实际生产环境中,为了稳定和高可用,运维团队一般不会把 MySQL 数据库部署在 Kubernetes 集群中,一般是用云厂商的数据库或者自己在高性能机器(如裸金属服务器)上搭建。
在更新或者创建工作负载时,经查会遇到,健康检查失败的错误,导致容器一直无法正常启动。类似如下:
翻译自 Setting Kubernetes Standards with Platform Engineering 。
健康检查(Health Check)是让系统知道您的应用实例是否正常工作的简单方法。 如果您的应用实例不再工作,则其他服务不应访问该应用或向其发送请求。 相反,应该将请求发送到已准备好的应用程序实例,或稍后重试。 系统还应该能够使您的应用程序恢复健康状态。
Kubernetes 已成为领先的容器编排平台,使组织能够大规模构建、部署和管理容器化应用程序。借助 Kubernetes您可以简化部署流程、优化资源利用率并确保应用程序的高可用性。然而,为了充分利用 Kubernetes,从头开始有效地设计应用程序至关重要。
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。一个 Pod 有一个或多个容器组成,Pod 中容器共享存储和网络,在同一个 Node 节点上运行。
在 Kubernetes 系统中,Kubernetes 对象是持久化的实体,Kubernetes 使用这些实体去表示整个集群的状态。特别地,它们描述了如下信息:
领取专属 10元无门槛券
手把手带您无忧上云