kubernetes
前段时间,我很艰难地学到了重要的Kubernetes课程。 故事始于Kubernetes Operators ,它是打包,部署和管理Kubernetes应用程序的一种方法。 我绊倒的是集群中的垃圾回收 ,清理了不再拥有所有者对象的对象(但稍后会进行更多讨论)。
任务
去年,我工作的团队被分配来开发Kubernetes Operator。 对于团队中的大多数人来说,这是他们第一次使用Operator SDK (软件开发套件)和Kubernetes控制器 ,这是为Kubernetes供电的控制回路。 我们都阅读了有关Operator SDK的一些基本介绍信息,并遵循了使用Go编程语言构建Operator的快速入门指南 。 我们学习了一些基本原理和一些方便的技巧,并且我们渴望应用它们。
我们的任务是开发一个操作员,该操作员将安装,配置并确保许多项目的生产就绪。 我们的目标是使我们的站点可靠性工程(SRE)团队能够以最少的人工工作来自动化管理实例队列 。 这不是一件容易的事,但是我们喜欢挑战和可以使用的技术,因此我们在快速前进并打破了一些难题。
错误
最初,我们追求的是概念验证的实现,因此我们记录了错误,并计划在以后修复它们。
![决策矩阵 Decision-making matrix](https://i-blog.csdnimg.cn/blog_migrate/bb8f8d8bdfaa8d72936e40c23da2b656.png)
( 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,并检查了它的日志。 一旦看到有关垃圾收集的一些日志,我最终将两个和两个放在一起,并返回到垃圾收集文档。 在那里:
” 注意:跨命名空间所有者引用在设计上是不允许的。这意味着:1)命名空间范围的从属只能指定同一命名空间中的所有者,而集群范围的所有者。2)集群范围的从属只能指定集群-范围内的所有者,但不是命名空间范围内的所有者。”
我们的自定义资源是命名空间范围的,但是命名空间是群集范围的。 即使设计使我们不允许使用所有者引用,Kubernetes API服务器也会创建名称空间。 因此,使用所有者引用创建名称空间,然后必须删除它们,因为垃圾回收遵循记录的规则。
经验教训
kube-controller-manager pod
启动。
但是我学到的更重要的教训是不要低估文档 。 如果我在第一次阅读文档时比较耐心,那肯定可以节省一些时间。
您可能还认为,如果在将无效所有者引用添加到代码库中时遵循我的建议,我们可以避免这种情况。 但是事实证明它尚未被记录。 在Kubernetes是一种成熟的技术很久之后,于2019年2月的拉取请求添加了此重要说明。
我认为这突出了这样一个事实,即文档总是存在改进的空间。 让我们一起做,从阅读有关Kubernetes文档贡献的指南开始。
翻译自: https://opensource.com/article/20/6/kubernetes-garbage-collection
kubernetes