序言

    见过的人越多，就越喜欢狗。

    感觉没有秋天，突然一下就凉凉的，偶尔还下个雨。

k8s事件和for循环

    人人都爱for循环，无论是开发还是运维，经常随便来个for循环来执行一些脚本，例如进行一个测试。

for i in `seq 1000`;do curl -I http://example.com;done

    for循环是最简单的一种调用方式，但是也有巨坑，在一些特别的场景之中。

    1 k8s事件

    在k8s的集群中，总是会有各种自己写的代码，来监听k8s的事件，然后来做一些对应的操作，例如将pod注册到注册中心，例如将pod的状态同步到注册中心，例如使用pod来进行监控。

    当收到了pod创建事件之后，然后将pod注册到注册中心；当收到了pod删除事件之后，将pod从注册中心下线；当pod进行rolling update的时候，将pod从注册中心又要下线，又要上线。

    这个时候就要for循环出现了，一个for循环进行处理对应的操作，在正常情况下，这种处理机制好像没啥问题，直到。。。

    在运维k8s集群的时候，最常出现的两种操作：第一种，k8s的node机器宕机，从而造成大量的pod进行重新调度，可能是10个pod，也可能是200个pod，这在于node上的pod数量；第二种，当进行集群升级的时候，那么风险最小的做法就是将新建节点池，然后将老的pod进行驱逐，此时也是有大量的pod立刻处于terminating状态，然后会新建pod，最终老的pod被delete掉。

    那么如果这种情况一旦发生，对于for循环来说，卧槽，处理不过来了，而且极度依赖for循环里面每个事件的处理，如果一个事件处理出现延迟，那么整体的服务都会有问题。

    2 如何发现这种问题

    for循环的阻塞问题，怎么发现有问题的呢？其实也是比较难，尤其是对于代码新手。

    没事的时候，在测试环境进行一下演练，找个机器，上面跑几百个pod，然后进行一下宕机，就会收到业务那边的反馈，怎么出现了各种各样的报错，然后去查各种事件的日志，有的处理了，有的没处理，而没处理的都是反馈了问题的。

    操作日志，你值得拥有，你会发现事件最长的延迟时间是8个小时。虽然开始说fuck了，但是也毫无办法。。。

    在生产环境中，node机器宕机，也是稀松平常的事儿，一般都不会怎么太大关注，除非有业务在那叫，才开始进行排查。。。

    在进行排查这种事件问题的时候，一定要关注每个细节的时间点，例如代码在什么时间捕获到了时间，什么时候注册到了注册中心，什么时间点从注册中心下线了，什么时间点在注册中心变成了健康状态，从发生到结束，到底耗时多久。。。

    如果出现了上面的问题，那么你就会有两种疑问：一种怀疑是是不是丢失了事件，我们的事件捕获的不全？还有一种是大量的事件积压，处理不过来了，从而有延迟，但是最终能处理好。

    如果是屎上雕花，那么就先看看代码吧，特别是在事件处理的时候，如果用的是for循环，用for循环其实也没问题，更大的问题是每个事件是不是单独的一个协程来进行处理的，从而当同时到达几百个事件的时候，事件的处理不是串行的，而是并行的，而不是相互之间阻塞的。

    狗屎一样的代码也就算了，写代码的人还不查问题，简直是个垃圾。。。信誓旦旦说没问题，简直就是狗屎。

    3 事件监听需要注意的点

    Q1：监听事件的时候，有的时候需要选择，例如有的时候，你是监听pod的事件，但是如果是监控，那么在rolling update的时候，可能会造成监控数据的丢失，这个时候，如果你的服务都有svc，那么你可以试试监听endpoint的事件，完美解决监控数据丢失的问题。

    Q2：监听事件的时候，如果你要非常快速的能摘除节点，其实endpoint也比pod好，因为在宕机的场景中，pod的状态在默认情况下，5分钟还是running，这种一般都开始fuck了，但是如果你改成endpoint，就能做到妙级进行摘除了。

    Q3：监听事件的时候，关注极端场景下的测试，例如机器宕机的时候，其实pod的状态一直会保持5分钟状态为running，然后才会变成terminating，再进行重新调度，而node的感知到not ready状态是差不多45秒，3个健康检查周期一过，node是最先感知到的。

    Q4：监听事件的时候，如果要演练，驱逐的风险比宕机的风险要小很多，因为驱逐是直接整个机器上的pod状态立刻从running变成terminating，然后立刻进行重新调度，从而也能看到大量事件，对于大部分的应用来说，基本无损。

    Q5：监听事件的时候，如果每个事件的处理速度比较慢，不能达到秒级或者毫秒级，那么可能还是会依赖老的pod进行处理流量，那么可以尽量将老的pod的terminationGracePeriodSeconds设置的长一点，例如一分钟，例如五分钟，尽可能的让事件处理完成，让流量无损过度。

风言风语

   屎上雕花其实蛮烦的，代码的组织结构混乱，代码日志、日志格式混乱，这就是让人无法接手的代码，致命的玫瑰。

    很难预见能碰到什么问题，但是一般遇到问题解决问题也就差不多了，也不用过分焦虑，风险无时不在，只是时机未到而已。

    运维有的时候也是看运气，运气好呢，不会出故障，运气不好呢，卧槽，再牛逼也是一个故障接着一个故障，不过，该来的总是会来的，只是早与晚而已。

    碰到恶心的人的话，只能祝福他碰到的人以后都和他自己一样。。。以子之矛攻子之盾

    Good Luck for you