2024 年云原生领域（特别是 K8s）的趋势是什么？

kubeflow

趋势和你列举的一部分重合，另一部分不是云原生领域。
像有状态应用上 k8s 有一些是需要改造的，这部分属于中间件研发而非云原生。
比如 confluent 对应 kafka 就可以轻松上 k8s, 而 kafka 就没有。
kubeflow 这些属于 MLOps, 是需要懂 AI 专业领域来能搞的
今年最火的是平台工程以及 EBPF 整合 k8s,其次是 wasm 。

楼主说的有状态应用部署，国内已经有个公司做了，看起来不错： https://apecloud.cn/

插一嘴，现在 kafka 已经无需依赖 zk 来托管 broker 信息了喔

@mightybruce 是的，但是我们这的中间件团队没有这种开发能力，估计还得我们去找一些现成的 operator
@workingpad2 这个在训练集群用起来了

@dululu 谢谢，但是我们估计不会采购，毕竟要降本增效
@CivAx 嗯嗯，但是我们用的还是 1.1.1 的，有一些老

你说的是 bitnami 吗？

@ryanking8215 #6 如果你问我的话，是，但与 Bitnami 无关。Kafka 有脱离 ZK 运行的 Raft 模式，而且最小只需要单个节点。

新手，弱弱问下。有状态应用部署在 k8s 中，为什么挑战会比较大？ 指的是大规模、高可用 redis/kakfak/zk 集群吗？

@justdoit123 #8 “无状态” 与 “有状态” 的通俗区别是，该应用的数据是否会因为应用退出而被删除。因为有状态应用的数据、配置、程序自身三者高度绑定（但目前 Cloud Native 的势头已经对这个情况大幅优化了）。

比如常见的 K8S 场景：Kafka 需要外挂数据卷，而 K8S Admin 选择分配 HostPath 的方式，那么 Kafka 的数据目录中的 properties 文件会包含 BrokerID 。如果有状态应用被 reschedule 了，很可能会导致 Broker-0 被分配到先前 Broker-3 的所在节点上，导致 BrokerID 读取不吻合，导致错误退出。

Stateful 在水平扩展时需要保证数据目录被妥当创建，同时程序或配置里要存在 “初始化新节点” 的逻辑，并且当服务节点宕机、迁移时要有完善的节点退出或数据重用逻辑（比如上面提到的 BrokerID 读取问题，以及 Galera Cluster 的数据落盘保证机制），这些数据与程序的硬绑定逻辑会让有状态应用比无状态应用更难随意调度。

阿里云 24 年拳头产品是 ACS ，可以了解一下，看文档比 ASK 灵活不少

kubevirt 这条路不好走，VM 的场景未来会越来越少，想想什么情况下会用 VM 。
1. 上古服务难以容器化
2. 强状态服务，比如游戏服务之类的
3. 需求强隔离的服务，大部分都是安全原因
kubevirt 的设计很差，强行在 k8s 里面上 VM ，还不如用 openstack ，至少该有的功能都有，kubevirt 大部分功能都是残废，只能说“我有这个功能，你用不用的起来那是你的事情”，比如说，热迁移。

eBPF
平台工程
AI 算力
以上这些吧

公司还有岗位嘛？这两个我们混部和大数据 on K8s 我们都做过。

主流是下云, 单体化.

@CivAx 说得不错，不过用 HostPath 这些是不常见的，除非是小集群。
像很多传统采用 MPP 架构的数据上 k8s 是不太契合的，主要是存储资源、计算资源紧密耦合的架构，不太容易满足云时代不同场景下的不同 workload 需求。

当我们需要扩容集群扩充 CPU 资源时，往往会引发数据的 reshuffle ，这会消耗比较大的网络带宽和 CPU 资源。
而通过分离存储资源、计算资源，可以独立规划存储、计算的资源规格和容量。这样计算资源的扩容、缩容、释放，均可以比较快完成，并且不会带来额外的数据搬迁的代价。

最好的方式就是这些中间件计算和存储分开， 现在存储和网络这方面比如 RDMA 也是不断发展去减少分布式数据库的消耗

天下大势,合久必分,分久必合。过几年估计去 k8s 成为主流。

FinOps

kubevirt 是比较差的做法。FabricPath 已经谈到了。
较好的做法是用 kata container

@FabricPath
@mightybruce 主要是想把 Redis Kafka zk 这种占虚机很多的，物理机直接复用管理起来有一些乱的给纳管到 K8s 里面，这样省成本还好运维，审计

Cilium!