您现在的位置是：首页 > 故事语录 > 励志语录励志语录
kubernetes 负载均衡方案(kubernetes运维)
admin2022-12-02 02:42:19励志语录146人已围观
简介kubernetes负载均衡方案(kubernetes运维),本文通过数据整理汇集了kubernetes负载均衡方案(kubernetes运维)相关信息，下面一起看看。作者：西电网淘@Gmail0.38860.38868686861Kubernetes的资源调度使用静态调度。将P
kubernetes 负载均衡方案(kubernetes运维),本文通过数据整理汇集了kubernetes 负载均衡方案(kubernetes运维)相关信息，下面一起看看。
作者：西电网淘@ Gmail 0 . 38860 . 38868686861
Kubernetes的资源调度使用静态调度。将Pod请求资源与节点可分配资源进行比较，确定节点是否有足够的资源来容纳Pod。静态调度带来的问题是，集群的资源被服务容器快速分配，但集群整体负载很低，各节点负载不均衡。本文将介绍几种优化Kubernetes集群负载的技术解决方案。
为什么Kubernetes使用静态调度？静态调度是指根据容器请求的资源进行打包调度，而不考虑节点的实际负载。静态调度最大的优点是调度简单高效，集群资源管理方便。最大的缺点很明显，就是不考虑节点的实际负载，容易造成集群负载低。
为什么Kubernetes使用静态调度？因为做好通用动态调度几乎是不可能的，是的，通用动态调度很难满足不同企业不同业务的诉求，结果可能适得其反。我们是不是有必要尝试一下动态排班的技术？不一定！平台可以根据托管的业务属性，通过scheduler extender对Kubernetes Scheduler进行适当的扩展，做出一定权重的动态调度决策。
集群资源构成以cpu资源为例，大规模Kubernetes集群的资源构成结构大致如下：
它由以下部分组成：
每个节点的保留资源对应于kubelet的system-reserved、Kube-reserved和Eviction-hard配置的资源的总和。Kubernetes在计算节点的可分配资源时会减去这部分预留资源。目前，我们集群的平均资源碎片约为5%~10%，根据不同的CVM模型略有不同。这些资源碎片分散在集群中的各个节点，主要是1C1g、2C2G和3XG。这些碎片很难与平台上用户提供的容器规格相匹配。经常会出现这样的情况，在调度一个Pod的时候，发现某个节点上的cpu够用，但是mem不够用，或者相反。剩下的就是服务Pod真正能分配和使用的资源。容器规范的服务选择具有主观性和盲目性，导致服务容器的负载较低。如此大比例的服务容易导致集群的低负载，但是根据Kubernetes的静态调度策略，集群无法容纳更多的服务容器。如上图所示，集群分配cpu水印较高，但实际cpu利用率并不高。除了借助强大的容器监控数据做出具有一定权重的动态调度决策，还有没有其他方案可以用来解决静态调度导致的集群负载低的问题？下面，我将给出一套完整的技术解决方案，尝试从多个技术维度提升Kubernetes集群负载。
Pod资源压缩如前所述，R&D同学在部署业务选择容器的资源规范时存在一定的盲目性，Kubernetes native不支持容器规范的实时无感知修改(虽然这可以通过静态VPA方案解决)，导致业务容器负载较低。为了解决这个问题，我们可以按一定比例压缩Pod请求资源(Pod限制资源不压缩)。请注意，只有在创建或重建Pod时，才会压缩Pod请求资源，例如当业务发生变化和发布时。在正常操作中不能对Pod执行此操作，否则可能会导致相应的工作负载控制器重新构建Pod(取决于工作负载的更新策略)，从而影响业务。
请注意：
每个工作负载的负载变化不同，所以Pod分配资源的压缩率也不同。需要支持每个工作负载的自定义配置，用户是察觉不到的。这个压缩比是在工作负载的注释中设置的，比如cpu资源压缩对应的注释stke.platform/cpu-requests-ratio；
压缩比，谁来定？自主开发的组件(pod-resource-compress-ratio-reconciler)根据工作负载的历史监控数据动态/定期调整压缩比。例如，如果一个工作负载的负载持续7天/1m，可以设置更大的压缩比，这样集群剩余的可分配资源就可以更大，可以容纳更多的业务容器。其实压缩比的调整策略并没有那么简单，还需要更多的监测数据来辅助。
Pod的分发压缩功能必须能够关闭和恢复。工作负载注释stke.platform/enable-resource-compress:' n '用于禁用工作负载级别，并且通过将压缩比设置为1来执行压缩恢复。
什么时候通过压缩比调整Pod规范中的请求资源？Kubernetes发展到现在这个阶段，直接改Kubernetes代码是最蠢的办法。我们应该充分利用Kubernetes的扩展模式。这里，我们通过改变kube-apiserver的准入Webhook来拦截Pod的创建事件。自行开发的web hook(POD-资源-压缩-web hook)检查压缩功能是否在POD注释中启用，压缩率是否配置。如果是，根据压缩比重新计算Pod对APIServer的请求资源和补丁。
节点超售Pod资源压缩方案是针对每个工作负载级别的动态资源调整方案。它的优点是可以细化到每一个工作负载，可以有的放矢。它的缺点是，业务不改不发布，就没有效果，见效慢。
节点的资源超售方案是一种节点级的资源动态调整方案。根据各节点的真实历史负载数据，超售不同比例的资源。
每个节点的资源超售率设置在节点的注释中，比如cpu超售对应的注释stke.platform/cpu-oversale-ratio。
每个节点的超跌比例谁来定？自主开发的组件(节点-资源-超售比-协调器)根据节点的历史监控数据动态/周期性地调整超售比。例如，如果一个节点连续7d/1M保持低负载，并且该节点分配资源的水位很高，则可以适当提高超售率，使该节点可以容纳更多的业务pod。
必须关闭并恢复节点的超卖功能。如果通过节点注释‘false’的stke.platform/mutate:关闭节点的超售，节点的资源回收将在下一次心跳中完成。
节点状态下的可分配容量资源何时按压缩比调整？同样，我们通过改变kube-apiserver的准入Webhook来拦截节点的创建和状态更新事件。自行开发的web hook(Node-Resource-over sale-web hook)检查节点注释中是否启用了超卖和配置了超卖比例，如果是，则根据超卖比例重新计算节点的可分配容量资源，并修补到APIServer。
节点资源超卖。表面上看起来很简单，但实际上，还有很多细节需要考虑：
Kubelet向ApiServer注册节点的详细原理是什么，直接通过webhook打节点状态补丁是否可行？
当节点资源超卖时，Kubernetes对应的Cgroup动态调整机制能否继续正常工作？
节点状态更新过于频繁，每次状态更新都会触发webhook。大规模集群很可能会给apiserver带来性能问题。如何解决它们？
节点超售对Kubelet驱逐的配置是否也有超分配的影响，还是驱逐仍然根据实际的节点配置和负载进行？如果影响了驱逐，该怎么办？
当超订率由大变小时，出现sum (pods的请求资源)节点在现有节点上可分配的情况。这里面有没有风险，怎么处理？
监控系统对节点的监控与节点分配的容量资源有关。超跌后，意味着监控系统对Node的监控不再正确，需要进行一定程度的修正。监控系统如何动态感知超卖比以修正数据和观点？
节点可分配性和容量分别应该如何超卖？超售对节点预留资源有什么影响？
这里涉及到很多Kubernetes的技术细节，我会在下一篇文章中详细介绍。
优化自动缩放的能力带来了Kubernetes的弹性缩放。我们熟悉HPA和HNA，其中一种横向扩展工作负载单元，另一种横向扩展群集中的节点。社区里还有一个VPA项目，用来调整Pod的资源，但是需要重建Pod才能生效。VPA的意义在于迅速扩大产能。如果像HPA一样，它需要重新构建Pod来启动应用程序以扩展容量，那么它实际上已经失去了价值。
Kube控制器管理器的内置HPA控制器存在以下问题：
性能问题：一个goroutine循环遍历集群中的所有HPA对象，为每个HPA对象获取相应的Pod监控数据，并计算新的副本，对于大型业务来说非常耗时。
核心配置不支持工作负载定制：每个企业的HPA扩展响应时间可能不同。一些企业期望5s响应，而另一些企业认为60s足够了。而内置HPA控制器只能在响应时间控制中配置全局启动参数horizontal-pod-auto scale-sync-period。此外，对于每种服务，负载抖动的容忍度是不同的。在内置HPA控制器中，只能通过水平-pod-autoscale r-tolerance进行全局配置，无法提供服务级别定制。
Kubernetes目前支持自定义指标，只能注册一个后端监控服务。如果集群中的一些业务使用prometheus来暴露自定义指标的应用，一些业务使用Monitor来监控自定义指标的应用，那么此时All in是做不到的。这是云上自研场景中的某个场景。
我们开发了HPAPlus控制器组件：
每个HPA对象都会启动一个goroutine协程，负责HPA对象的管理和计算。每个协程将被并行执行，这极大地优化了性能。HPA-Controller独立部署，其资源需求可以根据集群规模和HPA数量进行合理调整，比原来内置的HPA-Controller更加灵活。
HPAPlus-Controller支持自定义每个HPA对象的伸缩响应时间，自动感知服务是否发生变化并发布和决定是否禁用HPA(部分服务有这样的要求：升级时禁止触发灵活伸缩)，根据pod资源限制计算Pod资源利用率，从而推导出扩展和收缩后的期望副本，这对于节点超售、Pod资源压缩的集群非常重要。
支持个性化配置服务级别对负载的抖动容忍度。
支持基于更多维度的监控数据进行规模决策，比如Pod历史7d/1M的cpu负载。
支持CronHPA以满足常规扩展和收缩的业务需求。
公司的监控器通过扩展APIServer的方式连接，基于Prometheus的应用监控通过Prometheus-Adaptor的方式支持，使得基于各种应用监控系统的自定义指标可以用于HPA。
注意：HPAPlus-Controller和Kubernetes Buit-in HPA-Controller之间存在功能冲突，在上线之前需要禁用kube-controller-manager的HPA-Controller。
除了优化和增强HPA之外，我们还在开发动态VPA技术，这将在后面的单独文章中介绍。
其他技术方案：另外，开发动态调度器、基于服务级别的配额动态管理组件、基于服务优先级和配额管理的线上线下服务混合能力、主动检测节点资源碎片信息并上报给控制器进行Pod重漂移管理资源碎片等。也是我们正在进行的实践的方向，相应的解决方案和实现比较复杂，后面会另文介绍。
总结了Kubernetes静态调度导致的集群资源分配高水位而集群实际负载低的问题，并对技术方案进行了探讨。详细介绍了Pod资源动态压缩、节点资源动态超售、自动缩放能力优化的技术方案。后面还会介绍动态排班、动态业务额度管理、线上线下业务混合方案。为了具有动态性，所有这些集群负载提升方案都强烈依赖于强大的集装箱监控系统。我们正在与腾讯云监控产品团队紧密合作，更好地服务于腾讯自研业务。
更多kubernetes 负载均衡方案(kubernetes运维)相关信息请关注本站，本文仅仅做为展示！
很赞哦！ ()
相关文章
随机图文
| 留言与评论 （共有 条评论） |