我开始编制一份与Kubernetes有关的公共故障/恐怖故事清单。它应该能使负责运维的人员更容易找到相应的中断问题。
自2016年我们在Zalando开始使用Kubernetes以来，我们收集了许多内部故障问题。Docker的bug（守护进程没有响应，进程陷入管道等待，......）在一开始就是一个主要的痛点，但Docker本身已经变得更加成熟并且最近没有让我们烦恼。最大的问题可归因于分布式系统的性质和“级联故障”，例如Kubernetes API服务器中断不应影响正在运行的工作负载，但事实上确实如此，或者看到我们最近的CoreDNS事件。
我们在演讲中分享了一些事件和Kubernetes失败：
- 在生产中运行Kubernetes：百万种方式崩溃你的集群 - DevOpsCon慕尼黑2018
- 在生产中运行Kubernetes：百万种方式崩溃你的集群 - 2018年英国集装箱营地
- Zalando在AWS上的Kubernetes：失败与学习 - DevOps NRW 2018年见面会
我对失败进行此类讨论的主要动机是我希望自己能够听到更多这些内容！Nordstrom 在KubeCon 2017上的演讲“101种方式崩溃你的群集”是我的灵感（因为你甚至可以从谈话标题的相似性中看出来;-)）。我希望看到更多的人分享他们的事后记录并给出失败的谈话。Monzo的透明度和公共尸检是对社区的一项伟大服务，应该是我们所有人都努力的方向。
编制Kubernetes失败故事列表
在我寻找更多公共Kubernetes失败故事的过程中，我发现它要么很难找到它们（或者我的网络搜索技能缺乏），要么只发布很少。搜索条件我在DuckDuckGo和Google 上试过：
我还尝试了各种组合和“k8s”，“kube-dns”和“kube-proxy”而不是“kubernetes”。这并没有产生很多结果，我发现的大多数页面都是某种更“成功”的故事，并强调如何防止中断发生。那很无聊！
到目前为止我发现的Kubernetes Failure Stories的编译列表可以在GitHub上找到。我希望从社区中看到许多对该列表的贡献，但我想很难鼓励人们发布他们的中断报告。 请通过打开问题，创建公关或在Twitter上与我联系，为列表做出贡献！