为什么在kubernetes中我需要3种不同的探针: startupProbe readinessProbe livenessProbe 有一些关于这个主题的问题(k8s - livenessProbe vs readinessProbe, Setting up a readiness, liveness or startup probe)和文章。但这一点还不太清楚: 为什么我需要三种不同的探测器? 用例是什么? 最好的做法是什么?
我配置了一个弹簧启动吊舱,并配置了liveness和readiness探针。启动pod时,describe命令将显示以下输出。
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 92s default-scheduler Successfully assigned pradeep-ns
是否有一种方法来配置活性探测,以便在Pod成功完成时停止运行?
我正在使用一个活性探测来确保批处理作业(预计在几分钟到几周内完成)能够响应并正常运行。但是,当Pod成功完成时,在Pod停止为活性探测服务(在本例中为触摸文件)和在成功完成Pod之后删除Pod之间似乎存在延迟。在此延迟期间,活性探针失败次数足以触发Kubernetes重新启动Pod。
除了提高活性探测器的失效阈值或期间,或者减少Pod的终止宽限期之外,我还没有遇到任何可能的缓解措施,也没有针对这个问题的任何强有力的解决方案。事实上,我没有在Kubernetes的文档中发现在批作业中使用活性探针的任何提及。
来自kubectl de
我用Jenkins和Kubernetes来执行这个动作。
因为我的loadBalancer需要一个健康的吊舱,所以我不得不将livenessProbe添加到我的吊舱中。
我的吊舱配置:
apiVersion: v1
kind: Pod
metadata:
labels:
component: ci
spec:
# Use service account that can deploy to all namespaces
serviceAccountName: default
# Use the persisnte volume
containers:
- name: g
在Azure上部署了Spring数据流,使用Helm:helm安装-命名我-发布稳定/弹簧云数据流
Data Flow Server Implementation
Name: spring-cloud-dataflow-server
Version: 2.0.1.RELEASE
但是获得活性探针和准备性探针失败了401:
Events:
Type Reason Age From Message
---- ------ ----
我在Python中使用Kafka,并在Kubernetes集群中运行代码。“主要”消费者功能如下所示:
def consume(self):
logger.info("Consumer starting listening.")
try:
while True:
msg = self.consumer.poll(timeout=0.1)
if msg is None:
continue
if msg.error():
我在OpenShift中运行了一个pod。pod运行一个Kafka消费者,不断地轮询主题,并在给定的时间内将记录存储在本地。偶尔,该主题将获得大量新记录。由于存储记录所需的内存空间,这将导致OOM异常。但是,这很好,因为pod只需重新启动并再次消费即可。
然而,问题是pod不会在OOM异常时重新启动。pod崩溃后,健康端点(服务器)仍处于活动状态。因此,pod不会重新启动,因为OpenShift仍然认为pod是健康的。从日志消息看,shutdownHook似乎从未运行过。
我的健康端点服务实现为
class HealthService : ILogging by Logging<Heal
我不能制造管道。我甚至不能在AI平台管道仪表板上加载示例/教程,因为它似乎无法代理它需要的任何东西。
An error occurred
Error occured while trying to proxy to: ...
我查看了集群的详细信息,发现了三个有错误的组件:
Deployment metadata-grpc-deployment Does not have minimum availability
Deployment ml-pipeline Does not have minimum availability
Deployment ml-pipeline
在微服务部署期间,我使用openshift、docker、springboot和flyway。如果flyway在部署运行状况检查期间使用脚本数据库花费了大量时间,则会抛出此错误: Killing container with id docker//app:Conainter failed liveness probe. Container will be killed and recreated. 如何避免这个错误?
当我尝试在Kubernetes集群(AKS)中部署我的web应用程序时,我发现我的后端pods没有出现,它们继续进入下面的重启细节:
C:\Work\k8> kubectl获取pods
NAME READY STATUS RESTARTS AGE
backend-mypod-backend-766b54f6dd-85v6v 0/1 CrashLoopBackOff 549