背景长期以来，弹性云线上服务一直饱受缓存不一致的困扰。 缓存不一致的发生一般伴随着kube-apiserver的升级或重启。且当缓存不一致问题发生时，用户侧能够较为明显的感知，问题严重时会引发线上故障。而常见的故障有： 平台数据不一致：Pod状态一会正常，一会不正常，并且来回跳动 服务管理事件丢失：服务变更时，服务管理未正常工作，如服务树未挂载、流量未接入等等 在问题未定位之前，弹性云制定了诸多问题感知与及时止损策略： 问题感知： 人工：kube-apiserver升级或重启时，人工通知关联方也重启平台服务 智能：配置监控与报警策略，当一段时间内未收到k8s对象的变更事件时，发送告警信息 ...

背景近期，线上报障了多起Pod删除失败的Case，用户的多次删除请求均已失败告终。Pod删除失败的影响主要有二： 面向用户：用户体验下降，且无法对该Pod执行后续的发布流程 面向弹性云：失败率提升，SLA无法达标 并且，随着弹性云Docker版本升级 (1.13 → 18.06) 进度的推进，线上出现Pod删除失败的Case隐隐有增多的趋势。 线上问题无小事！不论是从哪个角度出发，我们都应该给线上环境把把脉，看看是哪个系统出了问题。 问题定位由于线上出Case的频率并不低，基本每周都会出现，这反而给我们定位问题带来了便利^_^。 排查线上问题的思路一般分如下两个步骤： 定位出现问题的组件 ...

锄禾日当午，值班好辛苦； 汗滴禾下土，一查一下午。 问题描述今天，在值班排查线上问题的过程中，发现系统日志一直在刷docker异常日志： 123May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T09:08:40.642410594+08:00" level=error msg="stream copy error: reading from a closed fifo"May 12 09:08:40 HOSTNAME dockerd[4085]: time="2021-05-12T ...

背景承接上文，近期我们排查弹性云线上几起故障时，故障由多个因素共同引起，列举如下： 弹性云在逐步灰度升级docker版本至 18.06.3-ce 由于历史原因，弹性云启用了docker服务的systemd配置选项 MountFlags=slave 为了避免dockerd重启引起业务容器重建，弹性云启用了 live-restore=true 配置，docker服务发生重启，dockerd与shim进程mnt ns不一致 在以上三个因素合力作用下，线上容器在重建与漂移场景下，出现删除失败的事件。 同样，文章最后也给出了两种解决方案： 长痛：修改代码，忽略错误 短痛：修改配置，一劳永逸 作为 ...

背景近期，弹性云线上集群发生了几起特殊的容器漂移失败事件，其特殊之处在于容器处于Pod Terminating状态，而宿主则处于Ready状态。 宿主状态为Ready说明其能够正常处理Pod事件，但是Pod却卡在了退出阶段，说明此问题并非由kubelet引起，那么docker就是1号犯罪嫌疑人了。 下文将详细介绍问题的排查与分析全过程。 抽丝剥茧排除kubelet嫌疑Pod状态如下： 12[stupig@master ~]$ kubectl get pod -owidepod-976a0-5 0/1 Terminating 0 ...

背景背景详见：docker-hang-死排查之旅。总结成一句话：runc非预期写pipe造成一系列组件的阻塞，当我们读pipe以消除阻塞时，发生了一个非预期的现象——宿主上所有的容器都被重建了。 再详细分析问题原因之前，我们先简单回顾下linux pipe的基础知识。 linux pipelinux pipe（也即管道），相信大家对它都不陌生，是一种典型的进程间通信机制。管道主要分为两类：命名管道与匿名管道。其区别在于： 命名管道：管道以文件形式存储在文件系统之上，系统中的任意两个进程都可以借助命名管道通信 匿名管道：管道不以文件形式存储在文件系统之上，仅存储在进程的文件描述符表中，只有具有 ...

背景最近升级了一版kubelet，修复因kubelet删除Sidecar类型Pod慢导致平台删除集群超时的问题。在灰度redis隔离集群的时候，发现升级kubelet并重启服务后，少量宿主状态变成了NotReady，并且回滚kubelet至之前版本，宿主状态仍然是NotReady。查看宿主状态时提示 ‘container runtime is down’ ，显示容器运行时出了问题。 我们使用的容器运行时是docker。我们就去检查docker的状态，检测结果如下： docker ps 查看所有容器列表，执行正常 docker inspect 查看容器详细状态，某一容器执行阻塞 典型的doc ...

背景最近，我们在升级kubelet时，发现部分宿主机上docker出现hang死的现象，发现过程详见：docker-hang-死阻塞-kubelet-初始化流程。 现在，我们聚焦在docker上，分析docker hang死问题发生时的现象、形成的原因、问题定位的方法，以及对应的解决办法。本文详细记录了整个过程。 docker hang死我们对docker hang死并不陌生，因为已经发生了好多起。其发生时的现象也多种多样。以往针对docker 1.13.1版本的排查都发现了一些线索，但是并没有定位到根因，最终绝大多数也是通过重启docker解决。而这一次发生在docker 18.06.3版本 ...

揭开面纱周一，接到RD反馈线上容器网络访问存在异常，具体线上描述如下： 上游服务driver-api所有容器访问下游服务duse-api某一容器TCP【telnet测试】连接不通，访问其余下游容器均正常 上游服务容器测试下游容器IP连通性【ping测试】正常 从以上两点现象可以得出一个结论： 容器的网络设备存在，IP地址连通，但是容器服务进程未启动，端口未启动 但是，当我们和业务RD确认之后，发现业务容器状态正常，业务进程也正运行着。嗯，问题不简单。 此外，同事这边排查还有一个结论： arp反向解析duse-api特殊容器IP时，不返回MAC地址信息 当telnet失败后，立即执行a ...

众所周知，Go实现了自动垃圾回收，这就意味着：当我们在申请内存时，不必关心如何以及何时释放内存，这些都是由Go语言内部实现的。注：我们关心的是堆内存，因为栈内存会随着函数调用的返回自动释放。 自动垃圾回收极大地降低了我们写程序时的心智负担，但是，这是否就意味着我们能够随心所欲的申请大量内存呢？理论上当然可以，但实际写代码时强烈不推荐这种做法，因为大量的临时堆内存会给GC线程的造成负担。 此时，小明同学就问：有没有办法能缓解海量临时对象的分配问题呢？ 当然是有的，内存复用就是一个典型方案，而内存池就是该方案的一个实例，Go语言官方提供一种内存池的实现方案——sync.Pool。 首先我们来看sy ...