it编程 > 编程语言 > Java

kafka实现负载均衡的原理，OpenKruise v0(1)

36人参与 • 2024-07-28 • Java

阿里巴巴集团内部拥有着百万级的容器数量连同上面承载的上千个业务，因此，sidecar 容器的管理与升级也就成为了亟待完善的主题。因此，我们总结了内部许多 sidecar 容器的通用化需求，并将其沉淀到 openkruise 上面，最终抽象为 sidecarset 作为管理和升级种类繁多 sidecar 容器的利器。

openkruise sidecarset

==========================================================================================

sidecarset 是 openkruise 中针对 sidecar 抽象出来的概念，负责注入和升级 kubernetes 集群中的 sidecar 容器，是 openkruise 的核心 workload 之一。它提供了非常丰富的功能，用户使用 sidecarset 可以非常方便实现 sidecar 容器的管理。主要特性如下：

1. sidecar logging architectures

应用日志可以让你了解应用内部的运行状况，日志对调试问题和监控集群活动非常有用。应用容器化后，最简单且最广泛采用的日志记录方式就是写入标准输出和标准错误。

但是，在当前分布式系统、大规模集群的时代下，上述方案还不足以达到生产环境的标准。首先，对于分布式系统而言，日志都是分散在单个容器里面，没有一个统一汇总的地方。其次，如果发生容器崩溃、pod 被驱逐等场景，会出现日志丢失的情况。因此，需要一种更加可靠，独立于容器生命周期的日志解决方案。

sidecar logging architectures 是将 logging agent 放到一个独立的 sidecar 容器中，通过共享日志目录的方式，实现容器日志的采集，然后存储到日志平台的后端存储。

1.png

阿里巴巴以及蚂蚁集团内部同样也是基于这种架构实现了容器的日志采集，下面我将介 绍openkruise sidecarset 如何助力 sidecar 日志架构在 kubernetes 集群中的大规模落地实践。

2. 自动注入

openkruise sidecarset 基于 kubernetes admissionwebhook 机制实现了 sidecar 容器的自动注入，因此只要将 sidecar 配置到 sidecarset 中，不管用户用 cloneset、deployment、statefulset 等任何方式部署，扩出来的 pod 中都会注入定义好的 sidecar 容器。

2.png

sidecar 容器的所有者只需要配置自身的 sidecarset，就可以在业务无感知的情况下完成 sidecar 容器的注入，这种方式极大的降低了 sidecar 容器使用的门槛，也方便了 sidecar 所有者的管理工作。为了满足 sidecar 注入的多种场景，sidecarset 除 containers 之外还扩展了如下字段：

sidecarset.yaml

apiversion: apps.kruise.io/v1alpha1

kind: sidecarset

metadata:

name: test-sidecarset

spec:

通过selector选择pod

selector:

matchlabels:

app: web-server

指定 namespace 生效

namespace: ns-1

container definition

containers:

image: logtail:1.0.0

共享指定卷

volumemounts:

mountpath: /var/log/web

共享所有卷

sharevolumepolicy: disabled

环境变量共享

transferenv:

tz代表时区，例如：web-server容器中存在环境变量 tz=asia/shanghai

envname: tz

volumes:

emptydir: {}

3. 原地升级

sidecarset 不仅实现 sidecar 容器的注入，而且复用了 openkruise 中原地升级的特性，实现了在不重启 pod 和主容器的前提下单独升级 sidecar 容器的能力。由于这种升级方式基本上能做到业务方无感知的程度，所以 sidecar 容器的升级已不再是上下交困的难题，从而极大解放了 sidecar 的所有者，提升了 sidecar 版本迭代的速度。

3.png

为了满足一些复杂的 sidecar 升级场景，sidecarset 除了原地升级以外，还提供了非常丰富的灰度发布策略。

4. 灰度发布

灰度发布应该算是日常发布中最常见的一种手段，它能够比较平滑的完成 sidecar 容器的发布，尤其是在大规模集群的场景下，强烈建议使用这种方式。下面是首批暂停，后续基于最大不可用滚动发布的例子，假设一个有 1000 个 pod 需要发布：

apiversion: apps.kruise.io/v1alpha1

kind: sidecarset

metadata:

name: sidecarset

spec:

…

updatestrategy:

type: rollingupdate

partition: 980

maxunavailable: 10%

上述配置首先发布（1000 - 980）= 20 个 pod 之后就会暂停发布，业务可以观察一段时间发现 sidecar 容器正常后，调整重新 update sidecarset 配置：

apiversion: apps.kruise.io/v1alpha1

kind: sidecarset

metadata:

name: sidecarset

spec:

…

updatestrategy:

type: rollingupdate

maxunavailable: 10%

这样调整后，对于余下的 980 个 pod，将会按照最大不可用的数量（10% * 1000 = 100）的顺序进行发布，直到所有的 pod 都发布完成。

partition 的语义是保留旧版本 pod 的数量或百分比，默认为 0。这里的 partition 不表示任何 order 序号。如果在发布过程中设置了 partition:

maxunavailable 是发布过程中保证的，同一时间下最大不可用的 pod 数量，默认值为 1。用户可以将其设置为绝对值或百分比（百分比会被控制器按照 selected pod 做基数来计算出一个背后的绝对值）。

注意：maxunavailable 和 partition 两个值是没有必然关联。举例：

5. 金丝雀发布

对于有金丝雀发布需求的业务，可以通过 strategy.selector 来实现。方式：对于需要率先金丝雀灰度的 pod 打上固定的 labels[canary.release] = true，再通过 strategy.selector.matchlabels 来选中该 pod。

apiversion: apps.kruise.io/v1alpha1

kind: sidecarset

metadata:

name: sidecarset

spec:

…

updatestrategy:

type: rollingupdate

selector:

matchlabels:

maxunavailable: 10%

上述配置只会发布打上金丝雀 labels 的容器，在完成金丝雀验证之后，通过将 updatestrategy.selector 配置去掉，就会继续通过最大不可用来滚动发布。

6. 打散发布

sidecarset 对于 pod 的升级顺序，默认按照如下规则：

除了上述默认发布顺序之外，scatter 打散策略允许用户自定义将符合某些标签的 pod 打散到整个发布过程中。比如，对于像 logtail 这种全局性的 sidecar container，一个集群当中很可能注入了几十个业务 pod，因此可以使用基于 应用名 的方式来打散 logtail 的方式进行发布，实现不同应用间打散灰度发布的效果，并且这种方式可以同最大不可用一起使用。

apiversion: apps.kruise.io/v1alpha1

kind: sidecarset

metadata:

name: sidecarset

spec:

…

updatestrategy:

type: rollingupdate

配置pod labels，假设所有的pod都包含labels[app_name]

scatterstrategy:

value: nginx

value: web-server

value: api-gateway

maxunavailable: 10%

7. 实践

阿里巴巴以及蚂蚁集团内部已经大规模的使用 sidecarset 来管理 sidecar 容器，下面我将通过日志采集 logtail sidecar 来作为一个示例。

  1. 基于 sidecarset.yaml 配置文件创建 sidecarset 资源。

sidecarset.yaml

apiversion: apps.kruise.io/v1alpha1

kind: sidecarset

metadata:

name: logtail-sidecarset

spec:

selector:

matchlabels:

app: nginx

updatestrategy:

type: rollingupdate

maxunavailable: 10%

containers:

image: log-service/logtail:0.16.16

when recevie sigterm, logtail will delay 10 seconds and then stop

command:

livenessprobe:

exec:

command:

resources:

limits:

memory: 512mi

requests:

cpu: 10m

memory: 30mi

share this volume

volumemounts:

mountpath: /var/log/nginx

transferenv:

envname: tz

volumes:

emptydir: {}

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、oppo等大厂，18年进入阿里一直到现在。

深知大多数java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。img

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注java获取）

img

最后总结

搞定算法，面试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大面试高频知识点及解析

最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化

image

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》
va开发知识点，真正体系化！**

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注java获取）

img

最后总结

搞定算法，面试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大面试高频知识点及解析

最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化

[外链图片转存中…(img-ykygph7s-1713458257861)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》

赞 (0)

您想发表意见！！点此发布评论

推荐阅读

kafka事务的详解

kafka事务的详解

07-28
(ROOT)KAFKA详解

(ROOT)KAFKA详解

07-28

spring boot 使用 Kafka

07-28

Kafka Rebanlace次数过高问题

07-28
SpringBoot——集成Kafka详解

SpringBoot——集成Kafka详解

07-28
如何在SpringCloud中使用Kafka Streams实现实时数据处理

如何在SpringCloud中使用Kafka Streams实现实时数据处理

07-28

猜你喜欢

版权声明：本文内容由互联网用户贡献，该文观点仅代表作者本人。本站仅提供信息存储服务，不拥有所有权，不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 2386932994@qq.com 举报，一经查实将立刻删除。

发表评论