Kubernetes 应用自愈与集中日志管理
1. 应用自愈的局限性与实践
在正常的故障情况下,资源限制、容器探测和原子升级等方法有助于保持应用的运行。不过,我们需要明白,并非所有类型的故障都能由 Kubernetes 修复。
1.1 自愈应用的局限性
Kubernetes 会将 Pod 分配到某个节点上运行,除非该节点离线,否则 Pod 不会被替换。本章中介绍的修复机制主要是通过重启 Pod 来实现的,也就是替换应用容器。
例如,当部署一个具有两个副本的 Pi 应用,每个副本设置 300 毫核 CPU 限制,而命名空间的 CPU 配额为 500 毫核时,副本集只能创建一个 Pod,因为剩余的 CPU 配额不足以创建第二个 Pod。
对于大多数临时故障场景,Pod 重启是可行的,但如果出现反复失败的情况,Pod 会进入 CrashLoopBackOff 状态,这可能导致应用离线。而且,Kubernetes 没有提供关于允许重启次数或退避期的配置选项,也不支持用不同节点上的新 Pod 替换失败的 Pod。
1.2 清理集群
在完成自愈应用的学习后,我们需要清理集群,为后续实验做准备。可以按照以下步骤删除相关对象:
# 删除命名空间
kubectl delete ns -l kiamol=ch12
kubectl delete all -l kiamol=ch12
# 删除所有剩余对象
kubectl delete secret,configmap,pvc -l kiamol=ch12
超级会员免费看
订阅专栏 解锁全文
389

被折叠的 条评论
为什么被折叠?



