k8s中sidecar死循环
序言怎么发现我的同事们很上进呢，估计做了下贱的事儿吧。
伤不到我，不代表不疼！
sidecar产生的题目
1 背景
在k8s的情况中，pod的使用越来越多了，也就产生了sidecar容器，在现在的情况中，一个pod可以带差不多快10个sidecar容器了，各种各样的场景，例如监控的sidecar容器，例如日志的sidecar容器。
sidecar容器最好用的地方在于只要在pod中加了一个annotations就可以无缝启动一个容器了，而且当pod删除之后，如果sidecar容器的配置发生了变革，那么就会自动见效了。
日志sidecar容器，主要用来将pod的日志举行网络，发送到kafka中，从而生存日志，在pod中写了一个annotions举行生存，而sidecar的配置的相关的容器，用一个helm举行安装，一个k8s中一个集群就好了。
2 sidecar容器引发的题目
在某一个月黑风高夜，要举行kafka的topic变更，从而就理所当然的修改了sidecar容器的配置，将topic修改，然后举行升级，升级完成之后，重启了一个测试pod，发现配置未发生变革。
查看sidecar的cm配置，发现没有变革，手动举行修改cm，然后再重启容器，发现见效了，但是再次更新helm，依旧变成了老的值。
没有想出特殊好的办法，从而将sidecar 配置的2的pod同时举行了删除，然后发现pod居然不能重新启动了，emmm，有点慌。
赶紧将业务的测试pod删除一个，看是否能启动，发现pod能正常删除，但是启动不了，生产情况有点压力，这个时候只要有pod挂掉或者是宿主机挂机，那么全部的业务pod将不能启动，必然会造成故障。
掐指一算，没办法了，先喊人一起帮助查，pod都没启动，看不到任何错误信息，只能直接查看namespace的变乱了。
kubectl get events -n fuck 发现有变乱，变乱显示pod无法启动，是因为sidecar的svc端点无法找到，这不是很正常吗，因为服务的pod都被删除了，那么svc肯定用不了，从而形成了一个死循环。
pod启动需要颠末验证，也就是要调用svc，而svc的两个pod被删除了，那么就卡死在这里，都不能启动。
webhooks.failurePolicyfailurePolicy 定义了如何处理来自准入端点的无法识别的错误 - 允许的值是 Ignore 或 Fail。默认为 Fail 默默地修改了webhook的失败策略，从默认值修改为Ignore，然后发现控制的pod启动了，发现业务的pod也启动了，危机办理，默默地送了一口吻，说了一句fuck，居然还会有循环依赖的情况发生。
我知道你很急，但是请先别急，找找思路，实在不可，就只能摇人了。
故障都是天注定的，所以急也没用，没用也急。
validatingwebhookconfiguration 全局资源，用来进行验证使用。 3 日志sidecar存在的题目
在使用日志sidecar的时候，碰到几个题目，留意避雷。
使用sidecar的时候，如果修改配置，必须要重启原来的pod，如果重启pod影响很大，大概要使用其他的方案，因为在使用sidecar的时候，如果单独启动sidecar容器，配置是不能见效的；如果对于发布摆设类的，这种比较好用，如果是中心件那种万年不启动的，有点难度，所以选择sidecar的时候，最好的是pod能自动对修改的配置见效。
在使用sidecar的时候，留意分配好对应的request和limit，如果一个宿主机上的呆板过多，不要把request和limit设置成一样，设置的很大，因为sidecar占用的资源也很大，最好是request很少，limit稍微大一点，而且这个配置都是固定的，不能说有的pod是一个值，其他的pod又是一个值。
在使用日志配置的时候，有一个是多行的配置，默认值是开启的，这个轻易产生一个bug，在有的云上面，如果日志为空，那么会直接将这个宿主机的磁盘直接吃满，不外没仔细查，其时也就草草的把这个配置设置为false就办理了。
sidecar的配置是全局的时候，你会发送最新的配置更新了，但是在其他的namespace里面的配置没更新，直到你重启了一个pod，才会发现配置更新，这点也需要留意，经常会在重启pod之前去查抄配置，然后发现没更新，在那折腾半天。
在使用helm的时候，如果发现upgrade的时候，set的值未见效，查抄一下template，没准就会发现有些傻叉把对应的配置要么就是不能配置，要么就是配置的位置不对，从而导致不能见效。
风言风语
sidecar用起来的确很爽，因为使用起来很简单，只要加一个annotation，但是要留意使用的时候，大概会壅闭pod的启动，如果你使用了istio，也大概存在这种题目。
两个pod同时删除，就导致了webhook不能使用，这个也是个风险点，如果2个pod同时在一个呆板上，而这台呆板宕机了；如果这两个pod所在的两个呆板同时宕机了，也不能使用了，而且这个时候，如果业务容器重启了，那还启不起来，如果告警做的欠好，那估计等整个集群挂了，你才能发现这个题目，告警做的是否富足，也是个考验。
上进和下贱有区别吗？当然没分别了，凡是有上进心的人一定会做出下贱的事儿，这下贱的人也一定会有上进心的。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]