本文探讨了Kubernetes中infra容器的作用，如何处理pod网络故障注入导致的container重启问题，以及如何利用infra容器共享网络命名空间来避免重启影响。作者提出了两种方案，最终选择在infra容器上直接注入故障以确保故障恢复的稳定性。
目录
一、infra容器的作用
我们知道，在kubernetes中，pod中容器的资源隔离主要通过namespace和cgroup来实现。那如果我们需要为pod中的容器共享某种资源应该怎么做。kubernetes 中的 pause 容器就提供了以下功能：
- 在 pod 中担任 Linux 命名空间共享的基础；
- 启用 pid 命名空间，开启 init 进程。
二、pod网络故障注入问题
背景：
在给pod注入网络故障，模拟pod网络延迟，丢包的场景下，会出现注入故障的目标container重启，进而导致故障恢复失败，最后只能重启相应pod来恢复故障。
如上图所示，注入故障后显示0/1的pod。
问题分析：
是什么原因导致目标pod会重启呢？故障注入本身是由tc实现的，并不会引起该问题。然后想到容器具有探针机制，当用户容器配置了livenessProbe探针时，由于容器被注入了各种网络延迟或者丢包，会导致探针失败，从而使kubelet重启container，导致后续一系列依赖之前容器的操作失败。
三、充分利用pod infra容器
思考：
那有没有一种办法可以既可以注入故障，又可以不受重启container的影响？这边想到两种方案。
1.重启查询新启动的container，对新的目标container进行故障恢复。
2.通过前面infra容器的前置知识，可以知道infra container是和pod所有容器共享networknamespace的，因此可以直接把故障做在infra容器上，并且infra容器的生命周期是和pod相同的。
解决：
有了上述两种方案，我们再对其进行比较。
在方案1中，有下面几种情况仍然会出现恢复失败：
1.在恢复过程中，恰巧目标container重启了。
2.恢复时间点在新旧container重启的间隙。
3.尝试重试并且成功的时间间隔和新旧container重启并启动的时间间隔相关。
因此，需要不停重试，直到恢复成功为止，并不是一个看上去很好的解决方案。
再看看方案2，和没有重启的故障注入、恢复假设一模一样。通过分析和尝试最后选择了方案2。
扫一扫
1688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
