怎么自己做论坛网站吗怎么做自己的网站平台

序言

    运行在k8s的应用是越来越多了，有状态的，无状态的，而在前面运行的网关一般都是ingress nginx，那么在容器的状态下是否应该开启亲和性的配置呢？

     答案是否，在虚拟机中经常开启的配置，但是在pod中就不一定合适了，一般你根据什么来判断这些结果呢？要么使用可观测的手段，要么就只能使用压测了。

pod里的nginx

    1 问题背景

    当把nginx运行在pod的时候，发现偶发的会出现rt抖动，那么也就需要想办法查一下为什么抖动，哪里抖动，是否能通过手段进行优化，从而让rt不抖动。

    优化一般是遇到了问题才进行优化，不要过早进行优化，除非万不得已，谁愿意去查一个qps几万的pod上面一天出现1个或者2个抖动呢，抖动多久才算抖动，几百毫秒。

    2 pod的一些指标

    当出现延迟抖动的时候，我们首先要检查一些pod的资源情况，例如cpu，内存，磁盘是否充足，查看一些nginx的日志，看看是后端慢了，还是nginx处理慢了，还是说网络有抖动。

    检查网络，一般最简单的处理方式，就是使用tcpdump抓包，一般就是循环抓，例如每个文件200M，抓20个，出现问题的时候，中断抓包程序，这样不会让存储占满，抓包能解决两个问题：第一个是出现重传包，重传一个数据包，那么就是200ms，从而会让业务进行告警；第二个是出现syn重传，基本上就是1秒起步。

    当网络出现重传的时候，一般就要检查pod所在的机器，目前看来要么就是网络抖动，要么就机器不稳定，进行热迁移就能恢复了。

    在另外的场景中，其实pod的资源情况很正常，nginx的日志显示request time也就20ms，那么问题来了，为什么会抖动，优化是否能解决这种问题。

    3 cpu的使用

    在查看cpu的使用率的时候，当前的使用率比较空闲，远远没有达到limit的值，也就使用了30%，那么这个时候，要看下是否存在cpu使用率的尖刺，导致cpu受限，这个直接看pod的监控指标就好，但是也不一定准确，因为监控只是秒级，达不到毫秒级。

   查看cpu的时候，可以直接在容器中查看，或者在宿主机上查看，使用top -p p1，p2 -d 0.1 ，然后就能看到cpu的瞬间使用率，如果是cpu受限，那么你就会偶尔看到cpu的使用率达到100%。

    常见的top，如果不加上时间间隔，其实很难观测到这种cpu受限的情况，因为如果你的limit设置为4，worker也是4，那么可能整体上没有受到限制，但是单个的workerprocess其实已经受限了，在这种情况下，开展了一些测试，从而尝试优化提升cpu使用率。

    4 开启worker process的亲和性

    开启亲和性，其实也就是将worker_cpu_affinity设置为auto，从而自动进行绑定cpu，然后呢，然后就是进行压测了。

   wrk压测神器，在进行默认参数压测的情况下，发现吞吐量升高，延迟降低，还开心了一下，以为这个调优是有效的，接着修改参数，将时间拉长到5分钟，发现和默认参数一样。

    然后再调整参数，将并发连接数修改为1000，发现性能不如没有亲和性的好的，开启亲和性和没有开启亲和性是一组对比数据，从而来观测性能是否真的有所提升。

    那么在容器化的环境下，为啥开启亲和性相反没有开启好呢？这个时候就要看看worker process的绑定情况了，使用的命令是ps -o pid,comm,psr，看看是否这个参数是否生效了，一看不知道一看吓一跳，的确绑定了cpu，而且所有的pod全部是前面4个核，例如有10个nginx的pod，然后在一个宿主机上，你会发现所有的都绑定的是0,1,2,3这个4个核，这还不如不绑定，不绑定的时候，你会发现不停的切换cpu，依旧很快，如果都是同一个核心，争抢资源很严重。

    在容器化的环境中，cpu的调度受到k8s的cgroup控制，所以还是别绑核了。

    5 超卖worker process

    既然不能开启亲和性，那么我们换一种思路，cpu既然可以超卖，那么worker process是否可以超卖，也就是说假设我们的limit是4c，那么我开启8个worker process，让cpu充分的运转起来。从而又开始用wrk进行压测，发现效果其实还是没有超卖的好。

    不过压测也不充分，我们压测的时候，是一个后端ng，请求的时候直接return 200，从而去掉后端的影响。但是也说明了，超卖worker process也不是一个好的办法。

   6 开启work priority

    既然超卖worker process不行，那么是否可以提升worker proces的优先级，从而让这个ng得到更多的调度时间，你猜这个结果是啥？大家可以自行压测一下，也对比一下看看结果。

    绑定cpu是为了减少cpu切换的次数，从整体的压测结果来看，切换的次数没什么太大的影响，可能切换的多，但是性能依旧很强，切换的少，性能还不行，例如绑定了cpu，所以大部分的情况，nginx都是被动进行进行切换，而很少有阻塞的主动切换。

    当使用多核的时候，为了解决惊群效应，最好是在liste的后面加上reuseport，这样的化，在内核3.10之后的版本，基本上是性能最好，延迟最低的方式，也算是最佳实践之一了，升级内核也行5.x也不错。

   在进行tcpdump抓包的时候，有的时候虽然你使用的root账户，但是依旧显示没有权限，那么你就创建对应的文件，然后将用户和组设置成tcpdump即可抓包，否则虽然是root，但是依旧无法抓包，一般是在宿主机上进行抓包，不会到容器里面进行抓包。

风言风语

    有的时候，当有人有合适的工具进行问题排查的时候，你会发现很快，非常的块，一眼就能知道大概得问题在哪里，但是如果靠你自己花时间摸索，可能是很久很久，但是依旧不能解决问题。

    当看到可能问题的突破点时，其实有的就很好解决，但是如果是软件本身的问题，可能就比较棘手了。

    猜测可能的原因，学习对应的架构原理，再来在测试环境进行复现，然后逐步解决，也是一种解决问题的思路。