本文探讨了在Kubernetes中，由于kubelet的GC机制导致init containers不断重建的问题。作者分析了问题原因，指出当dead容器超过配置限制时，kubelet会进行GC，而init container作为特殊的容器类型，其频繁重建引发问题。建议采用--eviction-hard或--eviction-soft参数替代以避免此问题。此外，还介绍了云原生消息中间件平台构建的相关信息。
本文由作者授权发布，未经许可，请勿转载。
作者：李岚清，网易杭州研究院云计算技术中心资深工程师
什么是init container
init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行，只有所有的Init Container执行完后，app container才会被启动。因此，init container 提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。
主要有以下应用场景：
-
等待其它模块Ready：比如我们有一个应用里面有两个容器化的服务，一个是Web Server，另一个是数据库。其中Web Server需要访问数据库。但是当我们启动这个应用的时候，并不能保证数据库服务先启动起来，所以可能出现在一段时间内Web Server有数据库连接错误。为了解决这个问题，我们可以在运行Web Server服务的Pod里使用一个InitContainer，去检查数据库是否准备好，直到数据库可以连接，Init Container才结束退出，然后Web Server容器被启动，发起正式的数据库连接请求。
-
初始化配置，下载依赖：比如某个应用的某个依赖是经常变动的，通常不会打到镜像里面。这个时候就可以在应用init container中动态下载依赖或者配置，然后再启动应用容器。
遇到了什么问题
pod状态，在Init和Running之间不断变换，发现init容器被不断删除、重建、重复运行。
分析原因
kubelet有两个命令行参数：
- --maximum-dead-containers: 每个节点上最多有几个处于exit状态的容器
- --maximum-dead-containers-per-container：每个container最多有几个处于exit状
最低0.47元/天 解锁文章
扫一扫
1643
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
