首先， Kafka 的弹性和容错能力是kafka自身的能力，这一点和容器化并没有直接关联，如果二者的优势可以结合，就要选择合适的集群模式。比如说，如果有一些流量大的数据链路，在容器云上可以配置比较多的 Pod 和 CPU 数量。当突发流量到来时，使用容器云弹性可以快速扩充 Mirrormaker ...

本次测试中没有实测使用对象存储的性能。原理上看，Kafka产生的以海量小IO小文件为主，且要求高速读写，从workload诉求出发，不太适合对象存储场景。

高可用方案建议根据业务系统的重要性等级的需求，分层地进行高可用设计。譬如在KAFKA服务层，可将KAFKA部署在多个K8S集群，通过负载均衡实现应用接入的高可用。 存储层根据相应的技术选型和存储产品特性，通过数据副本、数据同步等实现高可用。KAFKA服务层必须要设计为多租户支...

 Operator 本质上是K8S内建的自定义资源CRD（Custom Resource Definition） + Controller。其中：CRD 定义用户的资源；Controller 监听 CRD 对象实例的增、删、改事件，然后执行相应的业务逻辑。 Operator 仅依赖于 Kubernetes 申明式 API 和 Controller 的能力，实现了用户资源...

在容器云环境下性能的影响因素有很多，例如虚机容器相对于裸金属容器就会带来额外的10%-15%的开销，因此从性能的角度，裸金属容器是更好的选择。回到存储，首先为了保证性能，无论是存算一体还是存算分离都建议使用SSD盘来保证性能。在成本方面，服务器本地盘看似便宜，但因为其相对低...

1，常见套路就是要么应用层自己做，就是Kafka的一主多从能力，要么容器平台体系支撑，就是靠容器平台自身的漂移能力解决可靠性和恢复能力。2，两种方案各有优劣，一主多从结合本地盘，就是当前的常规套路，但是有几个问题，服务器自身的可靠性，3年寿命的周期替换，数据迁移；RAID卡的抖动问题，本...

Kafka的存储需求，在功能面是存储的数据是消息流，数据量级非常大；数据CRUD操作足够简单，主要为并发非常高和百万级TPS的追加写、无需更改、能根据消费位移offset和时间戳timestamp查询消息、能定期删除过期的消息；在非功能性面是高性能要求、高可用的稳定性要求、高扩展性要求...

部分容器云平台支持GPU的资源调度

基本都可以，这个问题需要从容器云平台的提供商来看，实现方式不太一样，我们把提供商分成2类：第一类就是头部云厂商提供容器云平台，基本都支持GPU资源池化，支持跨服务器进行灵活调度，同时支持单张卡的切分，即，多个pod可以共享一张卡，比如阿里云的cGPU，腾讯云的qGPU等；第二类是规模较小...