从零开始入门K8S| 从Spring Cloud到Kubernetes的微服务迁移实践( 二 ) _K8S

5. 增加 Prometheus 监控。特别是对 JVM 一些参数和一些定义指标的监控，并基于监控指标实现了 HPA 弹性伸缩。

文章插图

Kubernetes 化后业务架构将控制平面和数据平面分开。Kubernetes Master天然作为控制平面，实现整套业务的控制，不部署任何实际业务。数据平面中包含了基于 JAVA、php、Swoole、.NET Core 等不同语言或架构的项目。由于不同语言对机器性能有着不同要求，我们通过 Kubernetes 中节点 Label ，将各个项目部署在不同配置的 Node 节点上，做到应用间互不干扰。
基于Prometheus 的JVM监控在 Spring Cloud 迁移到 Kubernetes 后，我们仍需要获取 JVM 的一系列底层参数，对服务的运行状态进行实时监控。Prometheus 是目前较为成熟的监控插件，而 Prometheus 也提供了 Spring Cloud 插件，可以获取到 JVM 的底层参数，进行实时监控。
我们设置了响应时间、请求数、JVM Memory、JVM Misc、Garbage Collection 等一系列详尽的参数，为问题解决、业务优化提供可靠的依据。

文章插图

文章插图

基于HPA的峰值弹性伸缩要出发作为一家周边游服务订购平台，在业务过程中经常会涉及到景区、酒店门票抢购等需要峰值弹性的场景。Kubernetes 的 HPA 功能为弹性伸缩场景提供了很好的实现方式。
在 Kubernetes中， HPA 通常通过 Pod 的 CPU、内存利用率等实现，但在 Java 中，内存控制通过 JVM 实现，当内存占用过高时， JVM 会进行内存回收，但 JVM 并不会返回给主机或容器，单纯基于 Pod / CPU 指标进行集群的扩缩容并不合理。我们通过 Prometheus 获取 Java 中 http_server_requests_seconds_count（请求数）参数，通过适配器将其转化成 Kubernetes API Server 能识别的参数，并基于这一指标实时动态调整 Pod 的数量。

文章插图

UK8S 产品也提供了自身的集群伸缩插件，通过设置伸缩组，并匹配相应的伸缩条件，能够及时创建相应的云主机作为 Node 节点，方便我们在业务高峰时期更快速高效地拉起资源。
基于Elastic的APM链路跟踪微服务框架下，一次请求往往需要涉及到多个服务，因此服务性能监控和排查就变得复杂；不同服务可能由不同的团队开发，甚至使用不同的编程语言来实现；服务有可能部署在几千台服务器，横跨多个不同的数据中心。
因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。
目前市面有很多开源的APM组件， Zipkin、Pinpoint、Skywalking等等。我们最终选择了基于Elastic开源的apm-server 。正是由于市面上有太多的监控开源项目，但是各项目之间无法很好的互通。而Elastic通过filebeat收集业务日志，通过metricbeat监控应用服务性能，通过apm-server实现服务间的tracing ，并把数据统一存放在es ，很好的将logging、metrics、tracing整合到一起，打破了各项目之间的壁垒，能够更快速的协助运维及开发定位故障，保障系统的稳定性。

文章插图

Istio服务治理基于应用程序安全性、可观察性、持续部署、弹性伸缩和性能、对开源工具的集成、开源控制平面的支持、方案成熟度等考虑，我们最终选择了 Istio 作为服务治理的方案，主要涉及以下几个部分：
1. Istio-gateway 网关：Ingress Gateway 在逻辑上相当于网格边缘的一个负载均衡器，用于接收和处理网格边缘出站和入站的网络连接，其中包含开放端口和TLS的配置等内容，实现集群内部南北流量的治理。
2. Mesh 网关：Istio内部的虚拟Gateway ，代表网格内部的所有Sidecar ，实现所有网格内部服务之间的互相通信，即东西流量的治理。