kubernetes_关于Kubernetes垃圾收集的艰苦教训

最新推荐文章于 2024-04-17 15:30:56 发布

cumo7370

最新推荐文章于 2024-04-17 15:30:56 发布

阅读量257

点赞数

文章标签： python java 编程语言 linux 大数据

原文链接：https://opensource.com/article/20/6/kubernetes-garbage-collection

版权

kubernetes

前段时间，我很艰难地学到了重要的Kubernetes课程。故事始于Kubernetes Operators ，它是打包，部署和管理Kubernetes应用程序的一种方法。我绊倒的是集群中的垃圾回收，清理了不再拥有所有者对象的对象（但稍后会进行更多讨论）。

任务

去年，我工作的团队被分配来开发Kubernetes Operator。对于团队中的大多数人来说，这是他们第一次使用Operator SDK （软件开发套件）和Kubernetes控制器，这是为Kubernetes供电的控制回路。我们都阅读了有关Operator SDK的一些基本介绍信息，并遵循了使用Go编程语言构建Operator的快速入门指南。我们学习了一些基本原理和一些方便的技巧，并且我们渴望应用它们。

我们的任务是开发一个操作员，该操作员将安装，配置并确保许多项目的生产就绪。我们的目标是使我们的站点可靠性工程（SRE）团队能够以最少的人工工作来自动化管理实例队列。这不是一件容易的事，但是我们喜欢挑战和可以使用的技术，因此我们在快速前进并打破了一些难题。

错误

最初，我们追求的是概念验证的实现，因此我们记录了错误，并计划在以后修复它们。

^{（ Davidjcmorris ， CC-BY-SA-4.0 ）}

我将描述的错误完全适合此艾森豪威尔矩阵的象限II（正如斯蒂芬·科维所倡导的那样），它并不紧急，但很重要。实际上非常重要-操作员创建的所有名称空间有时都会在没有用户任何请求的情况下终止。它很少发生，因此我们决定稍后对其进行修复。

最终，我从积压的订单中发现了这个错误，并开始寻找根本原因。操作员肯定无法终止名称空间，因为那时我们还没有在代码中编写任何Delete API调用，因此，这是第一个线索。我通过拨打Kubernetes API服务器上的日志并确保安全保存日志来开始侦探工作。然后，我等待问题再次发生。

一旦问题出现在我设置的环境中，我便在日志中搜索以下字符串组合： "requestURI":"/api/v1/namespaces/my-namespace" + "verb":"delete" 。

从搜索结果中，我发现正在执行名称空间删除的内容： "user":{"username":"system:serviceaccount:kube-system:generic-garbage-collector" 。

现在，我知道如何删除名称空间，但是不知道为什么 。我打开了Kubernetes 垃圾收集文档，但是由于我不是一个有耐心的人，所以我只是浏览了有关ownerReference字段的基本信息，并继续思考为什么会这样。

我们在创建的名称空间上使用了ownerReference元数据字段。所有者是由自定义资源API定义的我们自己的资源。并且当我们的自定义资源被删除时，它通过ownerReference拥有的关联名称空间也将被删除。关联对象的删除使卸载步骤变得轻而易举。

我没有发现任何问题，因此我继续阅读日志以获取更多线索。我注意到当kube-controller-manager pod重启时，名称空间将被删除。重新启动的原因对我来说很有意义： kube-controller-manager pod在主节点上运行，我们的开发集群中只有一个主节点，并且对于我们使用的实例大小，该节点上的负载非常高。

因此，我尝试自己重现该问题。我删除了一个新创建的kube-controller-manager pod，并检查了它的日志。一旦看到有关垃圾收集的一些日志，我最终将两个和两个放在一起，并返回到垃圾收集文档。在那里：