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所在的两个机器同时宕机了，也不能使用了，而且这个时候，如果业务容器重启了，那还启不起来，如果告警做的不好，那估计等整个集群挂了，你才能发现这个问题，告警做的是否充足，也是个考验。

     上进和下贱有区别吗？当然没分别了，凡是有上进心的人一定会做出下贱的事儿，这下贱的人也一定会有上进心的。