Get best of the week

Kubernetes中的DNS问题。公开验尸

注意 perev。：它是Preply的工程博客中公共事后验尸的翻译。它描述了Kubernetes集群中的conntrack问题，该问题导致某些生产服务的停机。

对于那些想了解更多事后了解信息或希望将来避免DNS潜在问题的人士，本文可能会很有用。

图片

这不是DNS
，可能不是DNS，
而是DNS

关于Preply中的验尸和流程的一些信息


验后描述了销售办公室的故障或事件。事后分析包括事件的时间顺序，对用户的影响的描述，根本原因，行动和经验教训。

寻求SRE

在每周一次的与披萨的会议上，在技术团队的圈子里，我们共享各种信息。此类会议中最重要的部分之一是验尸，验尸通常伴随着幻灯片的演示和对事件的更深入分析。尽管我们在验尸后不“鼓掌”，但我们还是尝试建立一种“ 无怪 ”的文化（无怪的文化）。我们相信，撰写和展示验尸报告可以（不仅）帮助我们防止将来发生类似事件，这就是我们分享这些事件的原因。

参与该事件的人员应该感到可以详细谈论该事件，而不必担心受到惩罚或报复。不用谴责！撰写验尸报告不是一种惩罚，而是整个公司学习的机会。

保持CALMS和DevOps：S用于共享

Kubernetes中的DNS问题。验尸


日期： 2020年2月28日

作者： Amet U.，Andrey S.，Igor K.，Aleksey P.

状态：已完成

简介： Kubernetes集群中某些服务的DNS部分不可用（26分钟）

影响：服务A丢失了15,000个事件， B和C

根本原因： Kube-proxy无法从conntrack表中正确删除旧条目，因此某些服务仍尝试连接到不存在的提交
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，自动配置器降低deploymenta豆荚数量从三个减为两个

决定：另一个部署应用程序启动的新节点的创建，CoreDNS-自动配置器增加了更多的甲板群集服务，这引起覆盖连接跟踪表

检测： Prometheus监视检测到服务A，B和C的大量5xx错误，并向Kibana中的值班工程师


发出了5xx错误的电话

动作


法案一种负责任的任务
对CoreDNS禁用自动缩放预防Amet U.DEVOPS-695
安装缓存DNS服务器减少最大V。DEVOPS-665
配置conntrack监视预防Amet U.发展674

得到教训


一切顺利：

  • 监控工作很清楚。反应迅速而有条理。


:

  • , conntrack
  • , ()
  • , DNS,

:

  • CoreDNS-autoscaler, conntrack

(EET)


22:13CoreDNS-autoscaler
22:18
22:21
22:39
22:405xx ,

  • 检测时间： 4分钟。
  • 完成动作的时间： 21分钟。
  • 修复时间： 1分钟

附加信息



为了最大程度地减少处理器利用率，Linux内核使用诸如conntrack之类的东西。简而言之，这是一个实用程序，其中包含存储在特殊表中的NAT条目列表。当下一个数据包与以前一样从同一容器发送到同一容器时，最终IP地址将不会重新计算，而是从conntrack表中获取。

conntrack如何工作

摘要


这是我们验尸之一的示例，其中包含一些有用的链接。在本文中，我们特别分享了可能对其他公司有用的信息。这就是为什么我们不怕犯错误，这就是为什么我们将验尸报告之一公开。以下是一些更有趣的公共验尸主题：

More articles:


All Articles