k8s 开船记-触礁:四涡轮发动机撞坏3个引发502故障

(图片来自网络)

非常抱歉,这次开船触礁故障给您带来麻烦了,请您谅解。

在我们昨天发布 k8s 开船记首航博文后,有园友在评论中发来贺词——“泰坦尼克号出发了[狗头]”,借此吉言,今天船就触礁了,还好不是冰山。在触礁后,我们收到了唯一一封贺电,贺电署名——“隔壁正在打酱油的 docker swarm 集群”。

触礁时间发生在今天上午 10:18~10:30 左右,当时航行用的是四涡轮发动机(4个nodes)。

10:18 左右开始,3与4号发动机(k8s-n3与k8s-n4节点)被撞坏熄火,重新点火屡屡失败(重启 blog-web pod 失败),syslog 错误日志如下。

Dec 14 10:18:01 k8s-n3 kubelet[702]: E1214 10:18:01.739352     702 pod_workers.go:191] Error syncing pod 9b27ac6f-5518-4e12-862f-63b1254457d2 ("blog-web-r4zld_production(9b27ac6f-5518-4e12-862f-63b1254457d2)"), skipping: failed to "StartContainer" for "blog-web" with CrashLoopBackOff: "back-off 2m40s restarting failed container=blog-web pod=blog-web-r4zld_production(9b27ac6f-5518-4e12-862f-63b1254457d2)

10:20 左右,2号发动机(k8s-n2)也被撞坏熄火。

Dec 14 10:20:12 k8s-n2 kubelet[703]: E1214 10:20:12.138738     703 pod_workers.go:191] Error syncing pod 4ab7b193-cf0d-4a41-b83a-689d546acb2f ("blog-web-4dh84_production(4ab7b193-cf0d-4a41-b83a-689d546acb2f)"), skipping: failed to "StartContainer" for "blog-web" with CrashLoopBackOff: "back-off 2m40s restarting failed container=blog-web pod=blog-web-4dh84_production(4ab7b193-cf0d-4a41-b83a-689d546acb2f)"

唯一幸免的是1号发动机(k8s-n1),但是纵使它使尽浑身解数也无法驱动巨轮前进,于是只能停船发 502 求救信号。

我们收到求救信号后,通过下面的命令手动修改了 livenessProbe 的超时时间,daemonset 重新部署 pods 后恢复了正常。

kubectl edit daemonset blog-web

之后,我们启动了5号发动机(k8s-n5),k8s 尼克号又出发了。

对于故障原因,有待进一步排查。

以下的 syslog 错误日志有待排查确认。

Dec 14 10:18:53 k8s-n2 dockerd[1045]: time="2019-12-14T10:18:53.719195677+08:00" level=info msg="Container ddf3e4ed0dd63878dd1c87cb63cfd57d712f8719fb097e6c8ef15587eb3f81da failed to exit within 30 seconds of signal 15 - using the force"

Dec 14 10:18:54 k8s-n2 dockerd[1045]: time="2019-12-14T10:18:54.008174148+08:00" level=error msg="stream copy error: reading from a closed fifo"

Dec 14 10:18:54 k8s-n2 dockerd[1045]: time="2019-12-14T10:18:54.056924047+08:00" level=error msg="Error running exec 827374c9541db5b8d69383798c961078cba8fee08d1c8b93e84622b6a9caa61c in container: OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused \"process_linux.go:101: executing setns process caused \\\"exit status 1\\\"\": unknown"

Dec 14 10:18:54 k8s-n2 dockerd[1045]: time="2019-12-14T10:18:54.129287298+08:00" level=warning msg="ddf3e4ed0dd63878dd1c87cb63cfd57d712f8719fb097e6c8ef15587eb3f81da cleanup: failed to unmount IPC: umount /var/lib/docker/containers/ddf3e4ed0dd63878dd1c87cb63cfd57d712f8719fb097e6c8ef15587eb3f81da/mounts/shm, flags: 0x2: no such file or directory"

原文地址:https://www.cnblogs.com/cmt/p/12038692.html

时间: 2024-07-31 07:23:18

k8s 开船记-触礁:四涡轮发动机撞坏3个引发502故障的相关文章

k8s 开船记:升级为豪华邮轮(高可用集群)与遇到奇怪故障(dns解析异常)

之前我们搭建的 k8s 集群只用了1台 master ,可用性不高,这两天开始搭建高可用集群,但由于之前用 kubeadm 命令创建集群时没有使用 --control-plane-endpoint 参数,无法直接升级现有集群,只能重新创建高可用(High-Availability)集群. 高可用集群的原理很简单,多台 master ,每台都保存集群数据(etcd),所有 nodes 通过专门搭建的负载均衡访问 api server ,这样当部分 master 宕机时,对集群正常运行无影响. 我们

k8s 开船记-修船:改 readinessProbe ,去 DaemonSet ,上 ??Autoscaler

(图片来自网络) 改 readinessProbe 对于昨天 k8s 尼克号发生的触礁事故,我们分析下来主要是2个原因,一是当时4个节点不够用造成部分容器负载过高而宕机,二是 readinessProbe 健康检查配置不合理,造成重启后的容器无法通过健康检查. skipping: failed to "StartContainer" for "blog-web" with CrashLoopBackOff. CrashLoopBackOff 是指容器“启动 ->

k8s 开船记-首航:博客站点从 docker swarm 切换到 k8s

昨天晚上,我们将博客站点的生产环境从 docker swarm 集群切换到了 k8s 集群,开船到目前,航行非常平稳,可以说首航成功! k8s 集群是我们用10台阿里云服务器自己搭建的,1台 master 配置是2核4G,9台 nodes 配置都是4核8G,kubernetes 版本是 1.16.3 . 博客站点请求入口没有走 ingress ,直接通过 service 监听 30080 端口,阿里云负载均衡转发请求到该端口. apiVersion: v1 kind: Service metad

K8s 开船记-全站登船:Powered by .NET Core on Kubernetes

今天 18:30 左右,我们迈出了 kubernetes 航行的关键一步——全站登船,完成了全站应用部署从 docker swarm 集群向 k8s 集群的切换,以前所未有的决心与信心重新开起这艘巨轮,而这次航行能否成功就看明天访问高峰时狂风巨浪下的表现. 部署在 k8s 上的应用会在页脚显示下面的信息,如果航行失败,"Kubernetes" 会变成 "Linux" . Powered by .NET Core on Kubernetes Kubernetes 集群

单点登录CAS使用记(四):为登录页面加上验证码

CAS默认的登录页面样式如下,只有用户名与密码两项验证项目. 现在需要为首页登录加上验证码功能. 第一步:首页对默认登录页面的样式进行了调整,使其看上去还算美观. 在页面上加上了验证码项目. 第二步:导入验证码生成工具包及生成验证码配置 pom.xml中加入如下配置 <dependency> <groupId>com.google.code.kaptcha</groupId> <artifactId>kaptcha</artifactId> &l

Atitit.&#160;包厢记时系统&#160;的说明,教程,维护,故障排查手册v2&#160;pb25.doc

Atitit. 包厢记时系统 的说明,教程,维护,故障排查手册v2 pb25.doc 1. 服务器方面的维护1 1.1. 默认情况下,已经在系统的启动目录下增加了 个启动项目1 1.2. 后台服务.保持mysql数据库服务启动状态2 1.3. 服务器如无必要无需关闭,保持一直开启状态...2 1.4. 配置文件说明3 1.4.1. 指明选片服务端url3 1.4.2. 包厢计时系统提供的接口url (部分分店需要)3 1.4.3. 其他设置3 2. 故障排查4 3. 包厢记时系统5 3.1. 维

Atitit.播放系统的选片服务器,包厢记时系统&#160;的说明,教程,维护,故障排查手册p825

Atitit.播放系统的选片服务器,包厢记时系统 的说明,教程,维护,故障排查手册p825 1. 播放系统服务器方面的维护2 1.1. 默认情况下,已经在系统的启动目录下增加了俩个启动项目2 1.2. 后台服务.保持mysql数据库服务启动状态2 1.3. 影片图片与简介映射z盘需要有效可用2 1.4. 服务器如无必要无需关闭,保持一直开启状态...3 1.5. Loading时间的配置3 1.6. 其他3 1.6.1. 影片图片与简介缓存3 1.7. 包厢里面播放系统htpc的维护4 1.8.

记一次项目中yaml文档引发的惨案 (#yaml文档格式#yaml中&#39;-&#39;的作用)

项目已经在收尾阶段了,然后老大让我去把dockerCompose.yaml文件中公用配置给抽取一下,就是说以后改配置啊什么的就可以直接在抽出来的公用变量里面改就行了, 不用一个模块一个模块地去改(我们这个项目是微服务项目,十多个模块),本来是个很没技术含量的活儿,但是呢,引发了一场切(diao)尸吊的话题,来看下原始的配置 文件: 看下官网的语法: 我抽取的: 然后当然就是报错啦, 再然后就是各种检查顺序啊,检查有没有空格的尝试,然后无果,我就和老大汇报说抽不了,如果能抽我切尸吊俩厘米,然后我老

真硅谷巨骗、假女版乔布斯覆灭记:4星|《坏血》

详尽还原所谓“女版乔布斯”的硅谷创业明星.独角兽公司希拉洛斯及其创始人伊丽莎白的发展与覆灭历史. 伊丽莎白精力充沛,充满梦想,崇拜并刻意模仿乔布斯.她在2002年被斯坦福录取,2003年秋天辍学创业,想发明一种薄薄的贴片,实时监测病人身体状况并实时治疗.她顺利筹到了启动资金,在公司启动后想法略有收敛,改为迷你生化仪+一滴血实时检测. 公司多次筹得巨额资金,并说服了沃尔格林连锁药店和西夫韦连锁零售店两个巨头跟其合作,在门店部署便捷一滴血检测仪. 实际上希拉洛斯的产品一直停留在原型阶段,从来不可用.