V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
zhoudaiyu
V2EX  ›  Kubernetes

2024 年云原生领域(特别是 K8s)的趋势是什么?

  •  
  •   zhoudaiyu · 2024-02-07 19:14:24 +08:00 · 4645 次点击
    这是一个创建于 376 天前的主题,其中的信息可能已经有所发展或是发生改变。
    迫于不想单纯运维 K8s ,想整一些云原生领域的新东西落地。总的基调是:( 1 )降低成本;( 2 )提升可纳管的计算种类;目前想到了( 1 ) BigData on K8s ,将 flink 、spark 、kylin 等类型大数据应用部署到 K8s 里面,初步实现在、离混部与潮汐计算;( 2 )有状态应用部署,将 Redis 、kafka 、ZK 等,还有个别的有状态的应用部署到 K8s 中来(这个挑战可能较大)。大家还有啥好的思路吗?
    第 1 条附言  ·  2024-02-08 08:37:53 +08:00

    又想到了一点就是用kubevirt管理虚拟机,省去购买很多虚机,改为买物理机后自己虚拟化,这样也能节省成本。

    28 条回复    2024-06-18 14:49:16 +08:00
    workingpad2
        1
    workingpad2  
       2024-02-07 21:59:18 +08:00
    kubeflow
    mightybruce
        2
    mightybruce  
       2024-02-07 22:17:07 +08:00
    趋势和你列举的一部分重合,另一部分不是云原生领域。
    像有状态应用上 k8s 有一些是需要改造的,这部分属于中间件研发而非云原生。
    比如 confluent 对应 kafka 就可以轻松上 k8s, 而 kafka 就没有。
    kubeflow 这些属于 MLOps, 是需要懂 AI 专业领域来能搞的
    今年最火的是平台工程以及 EBPF 整合 k8s,其次是 wasm 。
    dululu
        3
    dululu  
       2024-02-08 00:00:49 +08:00
    楼主说的有状态应用部署,国内已经有个公司做了,看起来不错: https://apecloud.cn/
    CivAx
        4
    CivAx  
       2024-02-08 01:07:09 +08:00 via iPhone
    插一嘴,现在 kafka 已经无需依赖 zk 来托管 broker 信息了喔
    zhoudaiyu
        5
    zhoudaiyu  
    OP
       2024-02-08 08:44:33 +08:00 via iPhone
    @mightybruce 是的,但是我们这的中间件团队没有这种开发能力,估计还得我们去找一些现成的 operator
    @workingpad2 这个在训练集群用起来了

    @dululu 谢谢,但是我们估计不会采购,毕竟要降本增效
    @CivAx 嗯嗯,但是我们用的还是 1.1.1 的,有一些老
    ryanking8215
        6
    ryanking8215  
       2024-02-08 09:35:11 +08:00
    你说的是 bitnami 吗?
    CivAx
        7
    CivAx  
       2024-02-08 10:04:21 +08:00
    @ryanking8215 #6 如果你问我的话,是,但与 Bitnami 无关。Kafka 有脱离 ZK 运行的 Raft 模式,而且最小只需要单个节点。
    justdoit123
        8
    justdoit123  
       2024-02-08 10:16:43 +08:00
    新手,弱弱问下。有状态应用部署在 k8s 中,为什么挑战会比较大? 指的是大规模、高可用 redis/kakfak/zk 集群吗?
    CivAx
        9
    CivAx  
       2024-02-08 11:05:59 +08:00   ❤️ 4
    @justdoit123 #8 “无状态” 与 “有状态” 的通俗区别是,该应用的数据是否会因为应用退出而被删除。因为有状态应用的数据、配置、程序自身三者高度绑定(但目前 Cloud Native 的势头已经对这个情况大幅优化了)。

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

    Stateful 在水平扩展时需要保证数据目录被妥当创建,同时程序或配置里要存在 “初始化新节点” 的逻辑,并且当服务节点宕机、迁移时要有完善的节点退出或数据重用逻辑(比如上面提到的 BrokerID 读取问题,以及 Galera Cluster 的数据落盘保证机制),这些数据与程序的硬绑定逻辑会让有状态应用比无状态应用更难随意调度。
    yyttrr
        10
    yyttrr  
       2024-02-08 11:10:45 +08:00
    阿里云 24 年拳头产品是 ACS ,可以了解一下,看文档比 ASK 灵活不少
    FabricPath
        11
    FabricPath  
       2024-02-08 11:27:44 +08:00   ❤️ 2
    kubevirt 这条路不好走,VM 的场景未来会越来越少,想想什么情况下会用 VM 。
    1. 上古服务难以容器化
    2. 强状态服务,比如游戏服务之类的
    3. 需求强隔离的服务,大部分都是安全原因
    kubevirt 的设计很差,强行在 k8s 里面上 VM ,还不如用 openstack ,至少该有的功能都有,kubevirt 大部分功能都是残废,只能说“我有这个功能,你用不用的起来那是你的事情”,比如说,热迁移。
    Cola98
        12
    Cola98  
       2024-02-08 11:30:24 +08:00
    eBPF
    平台工程
    AI 算力
    以上这些吧
    leixx
        13
    leixx  
       2024-02-08 13:46:37 +08:00
    公司还有岗位嘛?这两个我们混部和大数据 on K8s 我们都做过。
    lujiaxing
        14
    lujiaxing  
       2024-02-08 14:01:03 +08:00
    主流是下云, 单体化.
    mightybruce
        15
    mightybruce  
       2024-02-08 14:41:46 +08:00   ❤️ 1
    @CivAx 说得不错,不过用 HostPath 这些是不常见的,除非是小集群。
    像很多传统采用 MPP 架构的数据上 k8s 是不太契合的,主要是存储资源、计算资源紧密耦合的架构,不太容易满足云时代不同场景下的不同 workload 需求。

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

    最好的方式就是这些中间件计算和存储分开, 现在存储和网络这方面比如 RDMA 也是不断发展去减少分布式数据库的消耗
    defunct9
        16
    defunct9  
       2024-02-08 15:11:33 +08:00
    天下大势,合久必分,分久必合。过几年估计去 k8s 成为主流。
    Sparkli
        17
    Sparkli  
       2024-02-08 17:57:27 +08:00
    FinOps
    mightybruce
        18
    mightybruce  
       2024-02-08 20:08:47 +08:00
    kubevirt 是比较差的做法。FabricPath 已经谈到了。
    较好的做法是用 kata container
    zhoudaiyu
        19
    zhoudaiyu  
    OP
       2024-02-08 21:44:14 +08:00 via iPhone
    @FabricPath
    @mightybruce 主要是想把 Redis Kafka zk 这种占虚机很多的,物理机直接复用管理起来有一些乱的给纳管到 K8s 里面,这样省成本还好运维,审计
    stevenyue
        20
    stevenyue  
       2024-02-09 02:20:40 +08:00
    Cilium!
    winson030
        21
    winson030  
       2024-02-09 20:22:10 +08:00 via iPhone
    今年想把虚拟机平台从 pve 转到 harvester ,用 kubectl 和 terraform 管理。
    但我发现手上的硬件配置不符合 rancher 的硬件建议(两台 x86 minipc )不知道能不能装起来。
    Pve 老牌,稳定,harvesters 比较新,更新频繁。不知道这个决定怎样?
    请问有哪位 v 友在物理机或者虚拟平台上成功装过 harvester ?想了解一下硬件配置。我目前在 windows10 上用 virtualbox 和 vmware 搭建的 harvester 虚拟机都失败了,找不到网卡,安装程序走不下去。
    winson030
        22
    winson030  
       2024-02-09 20:24:30 +08:00 via iPhone
    @zhoudaiyu 这样做也不是不行,把数据持久化的问题解决好就行了
    dayeye2006199
        23
    dayeye2006199  
       2024-02-10 13:57:01 +08:00
    计算密集型任务 on k8s
    这类任务的 scheduling ,容错性,状态维护都有很多挑战
    paulw54jrn
        24
    paulw54jrn  
       2024-02-10 19:43:28 +08:00   ❤️ 1
    > Kafka on k8s

    可以考虑一下
    https://strimzi.io/

    > Spark on k8s

    可以看看
    https://github.com/GoogleCloudPlatform/spark-on-k8s-operator

    这个项目有点糙, 可以自己 fork 一下
    https://github.com/apple/batch-processing-gateway
    zhoudaiyu
        25
    zhoudaiyu  
    OP
       2024-02-10 20:58:34 +08:00 via iPhone
    @stevenyue 这个是不错,但是没法切合到降本增效
    hezhiming1993
        26
    hezhiming1993  
       2024-02-17 19:06:05 +08:00
    @FabricPath

    确实, kubevirt 这东西一言难尽, 老外的 PR 做的好.
    hancai
        27
    hancai  
       362 天前
    看到第一条降低成本有点难崩, 降低成本第一步: 开掉运维
    windcode
        28
    windcode  
       244 天前
    k8s 社区发展很快,最近 CNCF 基金会中最火的是 平台工程 和 AI ,今年的 KubeCon 中 k8s 和这两个领域结合的 session 有很多。

    推荐两个项目:
    - k8s + 平台工程: https://github.com/KusionStack/kusion
    - k8s + AI: https://github.com/KusionStack/karpor
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   6135 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 02:19 · PVG 10:19 · LAX 18:19 · JFK 21:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.