笔记翻译： 这是公司工程博客的公开事后分析的翻译 。 描述了 Kubernetes 集群中 conntrack 的一个问题，导致部分生产服务部分宕机。
对于那些想要更多地了解事后分析或防止将来出现一些潜在 DNS 问题的人来说，本文可能会很有用。
这不是 DNS
不可能是 DNS
原来是DNS
关于 Preply 中的事后分析和流程的一些信息
事后分析描述了生产中的故障或某些事件。 事后分析包括事件时间表、用户影响、根本原因、采取的行动和吸取的教训。
在每周与披萨举行的技术团队会议上，我们分享各种信息。 此类会议最重要的部分之一是事后分析，通常伴随着幻灯片演示和对事件的更深入分析。 尽管事后我们不会鼓掌，但我们会努力培养一种“不责备”的文化（）。 我们相信，撰写和展示事后分析可以帮助我们（和其他人）防止未来发生类似事件，这就是我们分享它们的原因。
参与事件的个人应该感到他们可以说出细节而不必担心受到惩罚或报复。 没有责怪！ 写事后分析不是一种惩罚，而是整个公司的学习机会。
Kubernetes 中的 DNS 问题。 事后剖析
日期： 28.02.2020
作者： 阿梅特 U.、安德烈 S.、伊戈尔 K.、阿列克谢 P.
标题： 完成的
简述： Kubernetes 集群中某些服务的部分 DNS 不可用（26 分钟）
影响： 服务 A、B 和 C 丢失了 15000 个事件
根本原因： Kube-proxy 无法正确从 conntrack 表中删除旧条目，因此某些服务仍在尝试连接到不存在的 pod
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...扳机： 由于 Kubernetes 集群内部负载较低，CoreDNS-autoscaler 将部署中的 pod 数量从 XNUMX 个减少到 XNUMX 个
解决方案： 应用程序的下一次部署启动了新节点的创建，CoreDNS-autoscaler 添加了更多 pod 来为集群提供服务，这引发了 conntrack 表的重写
检测： Prometheus监控检测到A、B、C服务出现大量5xx错误，并向值班工程师发起呼叫
Kibana 中的 5xx 错误
活动
行动
类型
主管
任务
禁用 CoreDNS 的自动缩放器
阻止
阿梅特 U.
DEVOPS-695
设置缓存 DNS 服务器
减少
马克斯·V。
DEVOPS-665
设置conntrack监控
阻止
阿梅特 U.
DEVOPS-674
得到教训
进展顺利的地方：
- 监控效果良好。 响应迅速且有条理
- 我们没有达到节点的任何限制
什么问题：
- 仍然未知真正的根本原因，类似于 在conntrack中
- 所有操作仅纠正后果，而不纠正根本原因（错误）
- 我们知道 DNS 迟早会出现问题，但我们没有确定任务的优先顺序
我们幸运的地方：
- 下一次部署是由 CoreDNS-autoscaler 触发的，它覆盖了 conntrack 表
- 此错误仅影响部分服务
时间表（东部时间）
时间
行动
22:13
CoreDNS-autoscaler 将 Pod 数量从三个减少到两个
22:18
值班工程师开始接到监控系统的电话
22:21
值班工程师开始查找错误原因。
22:39
值班工程师开始将一项最新服务回滚到之前的版本
22:40
5xx错误不再出现，情况已经稳定下来
- 检测时间： 4分钟
- 行动前时间： 21分钟
- 修复时间： 1分钟
更多信息
- 核心 DNS 日志：
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - 链接到 Kibana（已删减）、Grafana（已删减）
为了最大限度地减少 CPU 使用率，Linux 内核使用了名为 conntrack 的东西。 简而言之，这是一个实用程序，其中包含存储在特殊表中的 NAT 记录列表。 当下一个数据包从同一个 pod 到达与之前相同的 pod 时，最终的 IP 地址将不会重新计算，而是从 conntrack 表中获取。
Conntrack 的工作原理
结果
这是我们事后分析的一个示例，其中包含一些有用的链接。 具体来说，在本文中，我们分享可能对其他公司有用的信息。 这就是为什么我们不害怕犯错误，也是我们公开一份事后分析的原因。 以下是一些更有趣的公开事后分析：
- GitLab：
- Dropbox的：
- Spotify的：
- 还有许多其他人来自 和存储库
- 还 使用 SRE Book 进行公开事后分析
来源： habr.com