云南建设注册考试中心网站app,有关做生态环境的官方网站,天津展示型网站建设外包,模板的种类在Kubernetes集群中维护容器状态更像是一种艺术#xff0c;而不是科学。原文: The Art and Science of Probing a Kubernetes Container[1] 在Kubernetes集群中维护容器状态更像是一种艺术#xff0c;而不是科学。 本文将带你深入理解容器探测[2]#xff0c;并特别关注相对较… 在Kubernetes集群中维护容器状态更像是一种艺术而不是科学。原文: The Art and Science of Probing a Kubernetes Container[1] 在Kubernetes集群中维护容器状态更像是一种艺术而不是科学。 本文将带你深入理解容器探测[2]并特别关注相对较新的启动探测。在此过程中通过文中的推荐链接可以进一步了解相关领域以实现文中的各种建议。 启动……不对……是在Kubernetes集群中请求启动新容器相对简单: 只需要为集群提供一个pod规范[3]尤其是封装了各种工作负载[4]资源(比如Deployment[5]或Job[6])的pod模板[7]。在接收到pod规范后kube-scheduler[8]将为pod分配一个节点然后该节点的kubelet[9]负责启动pod中的容器。 pod遵循明确的生命周期[10]其中就允许kubelet探测pod容器以确保始终都有响应。探测器遵循如下契约: pod容器通告端点kubelet从端点轮询其内部不同状态。 简单来说有三种类型的探针来表示容器的内部状态: 准备就绪探针(Readiness probes): 该探针告诉kubelet容器何时准备好处理请求是最普遍的容器探测。 活跃探针(Liveness probes): 该探针在紧急情况下会触发容器中断。kubelet将终止在指定时间间隔内没有成功响应的容器理想情况下容器应该在意识到无法继续工作后退出但在有bug的情况下很少能够优雅退出。 启动探针(Startup probes): 意思是我刚到这里别管我。它告诉kubelet何时开始对readiness和liveness进行探测。 图1: 容器探测和pod生命周期之间的关系 Readiness probes 如果容器未能响应其readiness探测kubelet将从服务负载均衡器中删除容器将流量从容器中转移。在这种情况下开发人员希望其他地方的副本可以处理流量。 readiness探测的设计比较简单只需要考虑依赖状态和容器中的资源使用情况: 依赖关系(Dependencies)。 假设容器依赖数据库服务器或另一个远程服务在这种情况下这些依赖项往往会提供一个端点或命令行接口来评估它们的就绪情况。如果依赖关系处于关键路径中则在计算探测的readiness状态时需要考虑依赖关系状态。 允许的最大连接数。 许多框架都有接受多少新连接的阈值因此考虑这些限制并在超过阈值时报告readiness失败。 系统资源。 这一点并不明显但是在接近内存上限和文件系统空间不足的情况下运行会导致进程不稳定。我们希望集群在耗尽系统资源之前停止向pod发送流量因此可以考虑在这些限制达到最大值的某个阈值时探测调用失败。我最不喜欢的资源耗尽形式之一是耗尽文件句柄这比简单的磁盘空间不足更难发现甚至可能阻碍最基本的故障排除任务。 要做: 实现探针。 始终为运行时容器定义readiness探测。可能你觉得容器客户机可以处理容器无响应问题。尽管如此让集群将请求路由到还没有准备好处理请求的容器从来都不是个好选择。 准备好状态。 考虑用单独的readiness线程向外部汇报远程依赖和资源利用状态。readiness探测超时时最好立即返回清晰的故障代码而不是冒着暂停响应的风险从所有依赖项收集输入。 不要做: 不要超过liveness探针的探测时间。 如果容器也有liveness探测不要使最大超时时间( failureThreshold * periodSeconds)超过liveness探测的最大时间。这会让集群将请求路由到可能没有希望的即将崩溃的容器。 不要把反应缓慢和readiness混在一起。 缓慢的反应也是一种反应。由于依赖关系处理请求的时间比通常要长得多可能你会觉得容器需要让调用者知道它还没有准备好。不过监视服务性能是应用级的关注点最好通过可观察性解决。 Liveness probes 如果容器不能连续响应此探测kubelet将终止容器。具体是终止还是重启取决于pod的重启策略[11]。 众所周知对这些探针进行正确编码非常困难因为探针开发人员的目标是预测意外情况比如进程中的bug可能会使整个容器处于不可恢复状态这样的情况。 如果探测过于宽松容器可能会处于无响应状态而不会被终止从而减少了可以提供服务的pod副本数量。 如果探测过于严格容器可能会一直被不必要的终止这种情况在间歇性发生时很难察觉当你排查问题时pod可能看起来很健康。 要做: 定义liveness探针。 没有liveness探测意味着容器可能会因为某个错误而永远无法响应所以即使无法完全确定万无一失的liveness标准还是要尝试定义。 监控资源。 覆盖文件系统空间、文件句柄和内存等资源。这些资源在耗尽时会发生容器锁定这样臭名昭著的现象。当内存利用率超过90%时返回错误比在达到100%后完全失去响应更明智。探测有超时值但最好返回清晰的失败代码而不是让kubelet从超时来推断崩溃。 使用命令。 调用命令而不是tcp或http请求。这个建议可能有争议但是调用shell命令将使用较低级别的接口反过来又有更多机会评估容器内部状态。我遇到过一些网络服务器即使由于内存不足而半死不活仍然能够响应简单的ping请求。 微控制面(Micro control-planes)。 如果可能的话使用与用于服务客户流量的连接池不同的连接池或者专门为探测设置连接将其设想为集群中与 常规工作负载 [12]不同(但规模要小得多)的控制平面。除非liveness探针具有响应探测的专用连接否则容器可能正在忙于服务客户流量(并通过readiness探针报告了未准备就绪状态)。在这种情况下终止容器对业务有害因为集群最后(临时)只有更少的容器来处理业务流量。 准备好状态。 类似于liveness探针一节中的建议考虑用单独的liveness探针服务线程向外部汇报活跃状态。liveness探测超时时最好立即返回清晰的故障代码而不是冒着暂停响应的风险从所有依赖项收集输入。 不要做: readiness不是liveness: 不要检查依赖关系的可用性如果失败这是readiness探针的责任终止pod不太可能有帮助。 不要重用readiness条件: 经常看到容器探测使用相同的端点但在 failureThreshold和 periodSeconds中使用不同的阈值。liveness探测的关注点不同于readiness探测的关注点。容器可能由于外部因素而无法处理流量而liveness探测使用与readiness探测相同的端点可能会告诉kubelet终止容器从而加剧问题。 超时时间超过readiness探测: 无论是查看 failureThreshold、 periodSeconds还是考虑容器中系统资源的可用性都要确保liveness探测的超时范围超过readiness探测的超时范围。例如最大超时时间( initialDelaySeconds failureThreshold * periodSeconds)比readiness探测的最大超时时间更短会造成容器在仍然为远程请求服务的情况下被过早终止。 不要过于保守: 在有疑问时宁可宽大处理也要为 failureThreshold、 periodSeconds和 initialDelaySeconds设置更高的值给容器足够的自由度来报告生存状态。一个不错的经验法则是使用比readiness探针的最大超时时间长两倍或更长的总超时时间。意外挂起进程是一种边缘情况比响应缓慢的进程更罕见liveness探测应该支持最常见的情况。 图2: liveness探测应该比readiness探测的时间更长。 Startup probes startup探针是容器探针中相对较新的成员2020年底在Kubernetes 1.20[13]中达到了GA。注意这要归功于我的同事博学的Nathan Brophy[14]他指出这个功能在Kubernetes 1.18尽管还处于测试阶段但已经默认可用[15]了。 startup探测在容器生命周期中为需要大量时间才能准备就绪的容器创建了一个缓冲区。 在过去在没有startup探测的情况下开发人员使用初始化容器[16]并为readiness探测和liveness探测设置较长的initialDelaySeconds值每一种都有自己的权衡: 可以等待但不应该等待。 初始化容器允许开发人员将特定工具和安全特权与运行时容器隔离开来但这是一种等待外部条件的笨拙方式。初始化容器是独立容器因此将持续运行直到完成将它们的工作结果转移到pod中的其他容器中可能会很麻烦。 启动缓慢。 在readiness探测上通过 initialDelaySeconds字段设置长时间等待会在容器启动期间浪费时间因为kubelet总是需要在将流量发送到pod之前等待这么长时间。 考虑现有liveness探测和readiness探测是否需要相对较长的时间来启动并将较大的initialDelaySeconds值替换为等效的startup探测。 例如下面的容器规范: spec: containers: - name: myslowstarter image: ... ... readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 600 periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 600 periodSeconds: 20 可以通过将延迟挪到startup探测中来显著改善如下例所示: spec: containers: - name: myslowstarter image: ... ... readinessProbe: tcpSocket: port: 8080 # i̵n̵i̵t̵i̵a̵l̵D̵e̵l̵a̵y̵S̵e̵c̵o̵n̵d̵s̵:̵ ̵6̵0̵0̵ periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 # i̵n̵i̵t̵i̵a̵l̵D̵e̵l̵a̵y̵S̵e̵c̵o̵n̵d̵s̵:̵ ̵6̵0̵0̵ periodSeconds: 20 startupProbe: tcpSocket: port: 8080 failureThreshold: 60 periodSeconds: 10 在第一个示例中kubelet在评估readiness和liveness之前等待600秒。相比之下在第二个示例中kubelet以10秒的间隔检查最多60次从而使容器能够在满足启动条件时立即启动。 在startup探测中频繁检查的隐藏好处是允许开发人员为failureThreshold和periodSeconds设置较高的值而不用担心减慢容器启动速度。相反死板的设置initialDelaySeconds给开发人员施加了压力忽略了边缘情况只能通过设置较低的值才能让整个应用更快启动。根据我的经验边缘情况是我们在开发过程中没有看到的东西的同义词这意味着在某些生产环境中会出现不稳定的容器。 根据经验如果readiness探测和liveness探测中的initialDelaySeconds字段超过failureThreshold * periodSeconds字段指定的总时间则使用startup探测。另一条经验法则是readiness探测或liveness探测中initialDelaySeconds的时间如果超过60秒就说明应用将受益于使用startup探测。 速度就是一切 在看到本文的建议后你可能不可避免的会问下面的问题: 那么我应该用什么来设置探针呢? 我们通常希望readiness探针比较敏感并且在容器开始难以响应请求时就报告失败。另一方面希望liveness探针稍微宽松一点只在代码失去对有效内部状态的控制时才报告失败。 对于timeoutSeconds我建议保持默认值(1秒)。这个建议建立在另一个建议之上即通过用于评估响应kubelet请求的线程之外的探针的响应。使用较高的值将扩大窗口集群会将流量路由到无法处理请求的容器。 对于periodSeconds和failureThreshold的组合在相同间隔内进行更多检查往往比较少检查更准确。假设我们遵循了将容器状态与响应请求的线程分开评估的建议那么更频繁的检查不会给容器增加显著的开销。 注意CPU限制 不同的集群不同的速度。 探测(尤其是liveness探测)的一个常见问题是假设集群总是按照要求为容器提供足够的CPU另一个常见错误是假设集群总是能够精确观察到部分请求。 从hypervisor和承载工作节点的VM开始一直到pod规范中的CPU限制[17]容器有无数原因可以以不同速度运行同一段代码。 以下是最容易让开发者措手不及的因素: hypervisor中的cpu复用: IaaS供应商的共享虚拟机即使硬件和网络速度相同也会偶尔受到邻居的影响从而导致CPU使用量激增。现代hypervisors非常擅长补偿这样的突发状况甚至会采取节流措施。尽管如此IaaS还是可能会超卖CPU并假设不会同时出现流量突发状况。 无穷小的CPU请求: 将CPU分配给容器的CPU限制设置为20ms似乎是一个负责任的、有意识的决定因为容器很少进行任何处理。然而在现实世界中工作节点的vCPU并不只有完整vCPU大小的2%。工作节点试图通过在短时间内为容器提供整个vCPU来模拟这个微小的vCPU从而导致对容器CPU分配产生碎片。因此容器可能在短时间内运行比所请求的更多的CPU时间然后暂停比预期更长的时间。 了解一些关于IaaS提供商的硬件特性和超卖设置的知识可以帮助我们决定将安全乘数添加到timeoutSeconds、failureThreshold和periodSeconds等设置中。在为探针特别是liveness探针设置时请记住这两个因素。根据所了解的内容还可以重新考虑CPU requests和limits的设置以便探针有足够的处理能力及时响应请求。 图3: 由于严格的CPU限制而终止正常运行的容器 结论 本文提供了一系列建议来提高容器探测的精度和性能使容器能够更快启动并运行更长时间。 下一步是仔细分析容器中运行的内容并研究在不同集群和条件下的实际运行时行为模拟依赖关系失败或者降低系统资源可用性。使用kubectl及其格式化和过滤内容的功能是查找重新启动多次以及探测不充分的容器的好方法在The art and science of probing a Kubernetes container, part 2: kubectl queries[18]这篇文章中有更多相关技术内容。将PromQL与Kubernetes指标结合使用可以用各种时间序列图表进一步扩展该技术这也是那篇文章的主题。 总之在编写探针时牢记目标并确保快速可靠的运行在对kubelet的响应中以尽可能(如果有的话)精确的方式提供清晰的信息。然后信任集群会以最佳方式处理数据确保容器对其客户端提供最大的可用性。 你好我是俞凡在Motorola做过研发现在在Mavenir做技术工作对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣平时喜欢阅读、思考相信持续学习、终身成长欢迎一起交流学习。 微信公众号DeepNoMind 参考资料 [1] The Art and Science of Probing a Kubernetes Container: https://dnastacio.medium.com/the-art-and-science-of-probing-a-kubernetes-container-db1f16539080 [2] Pod Probe: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#Probe [3] Pod Specification: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1 [4] Workload Resource: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources [5] Deployment: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/deployment-v1 [6] Job: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1 [7] Pod Template: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-template-v1/#PodTemplateSpec [8] kube-scheduler: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler [9] kubelet: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet [10] Pod Lifecycle: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle [11] Pod Restart Policy: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy [12] Kubernetes Components: https://kubernetes.io/docs/concepts/overview/components [13] Kubernetes 1.20: https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement [14] Nathan Brophy: https://www.linkedin.com/in/nathan-brophy-905a16171 [15] Feature Gates: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates [16] Init Container: https://kubernetes.io/docs/concepts/workloads/pods/init-containers [17] Resource Management for Pods and Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers [18] The art and science of probing a Kubernetes container, part 2: kubectl queries: https://sourcepatch.blogspot.com/2021/12/6-kubectl-queries-for-validating.html - END - 本文由 mdnice 多平台发布
