2021 Kubecon 大会总结:喜忧参半

2021 Kubecon Takeaways: A Mixed Bag

让我们马上明确一些事情。

首先,KubeCon 已经不再是它曾经的样子了。2019 年它充满活力,甚至有些泡沫。本周在洛杉矶,它显得相当黯淡。预测参会人数为 3000 人,但我们怀疑实际人数可能不到 2000 人。与赞助商方面的人交谈后,我的感觉是线上情况也不理想。

尽管如此,能够再次与人进行一对一的交流还是件好事。交谈机会不多,但因此也无需匆匆结束。不过,我还是希望 CNCF 能够找到恢复正常状态的方法,因为这种体验根本不值得投入。

其次,CNCF 在多元化和包容性方面言出必行。从很多方面来看,这都非常棒,而今天提供给演讲者和领导者的机会将重塑未来几年的行业人口结构,因为他们的才华将会展现出来。做得好。

第三,从技术的角度来看,KubeCon 与 2019 年我们上次线下见面时相比,有了很大的不同。这从展会的主题中可以清楚地体现出来,也突显了 Kubernetes 变革企业技术的速度之快。这可以从演讲和主题中看出来,也可以从那些有资金亲自参加展会的公司中看出来。以下是我们今年的一些收获。有关之前的文章,请查看 2020 年2019 年 的文章。

宏观主题 – Kubernetes 的运维

从宏观角度来看,今年的一个重要主题是围绕 Kubernetes 的运维。这体现在各种形式和风格中,我们将在下面列出,但总的来说,行业正在考虑 Day 2 的运维,而不是 Day 1。与会者对容器化和编排的概念非常熟悉。这不是一个教育性的展会,而是一个高级从业者的展会。我们在 MinIO 获得的流量来自现有用户。不到 1% 的问题与“什么是对象存储”有关——每个人都知道 Kubernetes 更偏好对象存储,因此我们 70% 的流量来自熟悉 MinIO 的用户——因为他们在日常工作中使用它。

那么,运维是什么样子的呢?

  1. 可观测性 – 我们将从更广泛的角度看待这个术语,但最终,人们对关联每个可用的数据源有着极大的兴趣。这正是将简单的监控与可行的洞察区分开来的关键。当前的思路远远超出了简单地从集群中各个应用程序和服务收集日志、指标和跟踪的范畴。现代的可观测性架构能够找到有助于理解集群深处发生的复杂事件的关系。Kubernetes 在这方面尤其具有挑战性。它复杂、多层且高度动态。它包括资源和服务。这是一个值得解决的问题,并且得到了足够的关注。
  2. 治理 – 容器生态系统的治理概念在过去几年中引起了广泛关注,并涉及到与云原生做事方式相关的下一级问题。企业可能仍然每三个月部署 300 台虚拟机,但它们每 3 小时就会部署 3000 个容器。差异以数量级来衡量。这对企业而言具有现实意义。CNCF 在将治理分解为其核心维度方面做得很好。他们谈论了两件事,策略范围,即特定规则应该在何处应用、执行或验证;以及策略目标,涉及应该执行和验证什么。主题内容非常多样,值得单独发文讨论,但这里只需说,关于安全策略、访问权限、网络、应用程序和配置等方面都有相关内容。再次强调,Kubernetes 成熟的一个很好的例子是其在这些领域所受到的关注。
  3. 安全 – 如今,安全无处不在,这是理所当然的。Kubernetes 的一般基础不会改变,但实现路径更加复杂,而复杂性带来了风险。这里有很多元素,从基于角色的访问控制 (RBAC) 到使用进程白名单和隔离 Kubernetes 节点,但总的主题是,安全需要成为设计的一部分,而不是依赖信任。
  4. 管理 – 当成本管理解决方案像在 KubeCon 上一样大量涌现时,你就会知道你正在接近成熟的平台。展会上肯定有十几种解决方案专门用于管理与容器增长相关的成本——尤其是在各种公共云中。从根本上说,这是一件好事,因为云账单带来的意外开支已经成为了过去,并且只对云提供商有利——其他人都是输家。

超越运维,多云和边缘

虽然运维的总体主题体现了 Kubernetes 生态系统的成熟——但仍有一些领域需要改进和创新。其中两个位于中心位置的领域包括多云和边缘。

多云

多云是 Kubernetes 社区的下一个重大推动力。

AWS 被认为,无论正确与否,是一个需要警惕的实体。与人们交谈时,可以明显感觉到,选择性和摆脱 AWS 锁定是需求,而不是锦上添花。此外,你还会感觉到,这只是轶事,GCP 和 Azure 在赢得人心方面正在取得进展。我甚至听到一位客户提到他们正在考虑使用 Oracle。当然,这似乎更多是基于价格而不是性能,但这也是成熟的标志。无论如何,多云的魔瓶已经打开,企业寻求一致的存储、同时又寻求计算的多样性,其影响可见一斑。

众所周知,这带来了明显的挑战。GCP、Azure、Oracle 等并不完全支持 S3。鉴于 Kubernetes 所需的精确性,这非常成问题。要在 Kubernetes 上下文中拥有可移植的数据,就需要可移植的对象存储,而这正是 MinIO 所创建的。

不用说,作为唯一真正存在的多云对象存储(每个公共云、每个 K8s 发行版、私有云、边缘),这一挑战使 MinIO 获得了不成比例的益处。这正是我们如此受 Kubernetes 社区欢迎的原因。

我们已经就此主题写了大量文章,这里这里,所以我们不再赘述。回顾过去,我们在 2019 年的总结中提到了多云,但现在它已经成为标准,这要归功于 Kubernetes。

边缘

边缘对于 Kubernetes 社区来说是一个有趣的领域。Kubernetes 不是为边缘设计的,但它在那里找到了立足之地。当你思考片刻,就会发现这很有道理。在边缘发生故障的情况下(任何设计中的默认部分),Kubernetes 已经知道如何应对——这与处理失败节点的方式相同——它会重新路由流量。

有一些很酷的计划,例如 K3s 和 microK8s,它们应用相同的架构,但适用于更小的占用空间。边缘存储最终是一个容器游戏,而容器需要编排。


从存储的角度来看,Kubernetes 在边缘的存储需求很明确

  1. 软件定义,可在异构硬件上运行
  2. 轻量级,可在受限空间中运行
  3. 弹性,即使资源有限也能保持稳定
  4. 高性能,可在本地处理数据,节省宝贵的带宽费用
  5. 安全 – 这意味着能够从前沿到边缘到数据中心进行完全加密的运行

根据我们的谈话,供应商社区仍在弄清楚其他一些部分(见上文),但那些专注于边缘的供应商如今正在成功地自行构建。我们预计未来几个季度将开始出现更多“参考架构”。

总结


虽然这不是一次“很棒”的 KubeCon——但它是一次重要的会议。至少对我们来说,它标志着我们第一次参加线下展会。它标志着多元化方面向前迈出了重要一步,并且标志着该技术的一些重大成熟里程碑。如果您有任何不同意见,请告诉我们。您可以在我们的 通用 Slack 频道 上发表评论,或发送电子邮件至 hello@min.io