【读书活动感悟】bug队《从Docker到Kubernetes入门与实战》团队分享第二篇​

          站在需求与交付的角度读《从Docker到Kubernetes入门与实战》时，印象最深的是它讲到“一次构建，全环境复用”，如何让系统更健壮、多环境的一致性？如在CLP客户开发积分和商城项目时，一个应用跑在本地、UAT、生产上出现不同的问题？同样的功能需要反复的测试、客户也一度提出环境问题的质疑。依赖于Docker的镜像快照冻结依赖，以及镜像与配置分离的设计，这样能极大的缓解循环测试的压力避免团队白分子30的测试时间都在处理假阳性问题。

       初读时觉得K8s的设计总结来说”专业+协作“，做自己擅长做的事类似我们常用的windows操作系统进程管理和内核调度一般ex：例如我们现在需要创建一个nginxpod

1. apiserver得到请求，存储镜像到etd
2. apiserver发请求到scheduler，scheduler查询节点选择满足request的节点来创建pod，把消息回给apiserver
   
3. apiserver发消息到kubelet，kubelet启动nginx容器创建pod
   
4. Control manager 发消息给apiserver，定期检查pod的状态
   
5. apiserver从etd中查询pod的目标状态
   
6. apiserver从kubelet查询pod的实际状态
7. 目标=实际，回复controlmanager，等待下一次检查
8. Kubelet发送pod崩溃的消息到apiserver
9. Control manager再次检查发现目标≠实际则，则发消息到apiserver重建pod
10. apiserver发消息到kubelet，kubelet启动nginx容器创建pod
    

       每个组件有明确的定位以及分工。所有的组件交互都需要通过apiServer通信不能绕开，调度则只需要遵守规则无需额外关心实际，etd只存储配置不存储应用，Control定期检查对比目标和实际状态。即用又学，在日常的工作也要培养系统性的思维方式。

       进行团队实践过程中，从“能看懂名词”到“能动手排个问题”一点点摸索出来的，遇到的主要问题大多集中在资源配置、调度和网络。K8s 实践时的问题虽然多，但只要分步骤排查，思路清晰，大部分都能找到原因并解决。

1. 资源请求（request）与资源限制（limit）的不合理配置，是导致 Pod 调度失败、资源争用或资源浪费。在未来仍需要继续学习如何搭配grafana采集运行时指标（如cpu使用、内存暂用等），对请求和资源限制进行动态调优。
2. 节点健康状态异常比如资源耗尽、调度约束规则过于严格、网络不通等，经验是先kubectl describe node检查节点状态和kubectl describe pod kubectl describe pod 校验 Pod 调度约束规则，逐步缩小问题边界完成最终定位。
3. 网络层的问题最棘手，发起请求到Ingress再到具体的pod，整个链路是非常长的甚至还有DNS解析问题，甚至OSI的7层都可能会有问题，推荐日志朔源和链路分层的思路排查。

       总结 通过实践docker+k8s，对比传统基于物理机的集群有哪些优点呢？

1. 能解决环境一致性，实现交互一致，docker将应用的业务代码、以及依赖的库、运行时打包成不可变镜像一次构建到处运行。而K8s容器编排则能保证所有的环境都使用同一镜像部署，在工作中受环境困扰的问题可以得到解决
2. 资源的利用率，轻量和调度。看案例中的比如电商的双11秒杀，出现比平常多十倍百倍的负载。如在秒杀前打包与调度类似把订单节点和库存节点调度到同一节点减少碎片和开销代价。秒杀时甚至能做到调度扩容从原来的pod副本10扩容到100，，启动一个新 Pod 只需 “创建容器→挂载配置→启动应用”，全程仅需 2-3 秒（传统 VM 启动需 5-10 分钟）即可完成资源调度，秒杀结束以后还能释放资源。
3. 手动运维与自动化自愈，基于状态检查带来的故障自愈优势，如发现我们项目的某一个如库存pod的出现了崩溃宕机，节点短时间内自动重启无需人工值守。而且在版本更新时还可以完成滚动更新，服务不会终端，先启动新的pod确认节点健康以后才会删除旧的pod，可保障系统的可用性。
4. 网络混乱？还是服务化治理，如内部通信K8s 的 Service 为一组 Pod 提供固定访问地址（如nginx-service:80），无论 Pod 扩缩容、重建，Service 地址不变，依赖方无需修改配置。外部访问通过Ingress 统一管理域名、SSL 证书、路径转发。甚至还可以使用 NetworkPolicy 定义 Pod 间的通信规则，可以只允许某个服务访问另外一个服务，如订单服务访问支付服务，实现网络有序且安全。

         最后留一个值得深思的问题，任何事物都有双面性，任何应用都要都要基于云原生吗？