视频
适用于 Kubernetes 的 Redis Enterprise 现在支持闪存
了解更多
Redis 8 发布了——并且是开源的
了解更多
分享
促使开发者越来越依赖 Kubernetes 的因素包括其混合云功能、对团队友好的可移植性以及云部署的成本意识。
Kubernetes 自 2014 年 Google 首次将其作为 Borg（Google 的内部容器编排解决方案）的开源替代方案推出以来，已经走过了漫长的道路。
自那时以来，这个部署系统和容器化应用程序工具已经进行了许多技术升级。在 2015 年发布 Kubernetes v1.0 之后，它开始在 2016 年 12 月支持 OpenAPI，这使得 API 提供商能够定义他们的操作，并为开发者自动化他们的工具开辟了道路。到 2018 年，Kubernetes 已经变得如此主流，以至于 Google 专门为其开设了一个 播客。
快进到今天。Kubernetes 的受欢迎程度与 云原生服务 的采用同步猛增。根据最近的 Splunk Kubernetes 状态报告，过去五年中容器生产使用量增加了“300%”，大型组织是 Kubernetes 主流采用的主要驱动力。
根据 云原生计算基金会 (CNCF) 2020 年度调查，使用或评估 Kubernetes 的组织从 2019 年的 78% 飙升至 2022 年的 96%，使其成为构建平台的首选平台。
这并不是说 Kubernetes 立即被开发社区所接受。有一段时间，容器编排需要在 Kubernetes、Docker 和 Mesosphere 之间做出技术选择。最终，Docker 和 Kubernetes 彼此成为了朋友，开发人员可以轻松地同时使用两者。然而，Mesosphere 失去了他们的注意力。
Kubernetes 始终保持开源，其流行程度的一个标志是为其代码库做出的贡献数量。公司已经为 Kubernetes 贡献了超过 280 万个 代码。
我们今天所知的 Kubernetes 已经内置了许多自动化功能，这使得开发团队更容易上手。很容易用手指列出它的优势：一切都通过代码进行管理，并且如果在云上运行，则易于移植。Kubernetes 的灵活性使 扩展应用程序 变得简单。容器在设计上是精简的；它们只存储应用程序运行所需的必备资源。这使得应用程序更快、更轻，并且 Kubernetes 对开发人员更具吸引力。
根据 VMware Tanzu 的 2022 Kubernetes 状态 报告，随着时间的推移，云计算持续获得关注，而本地 Kubernetes 部署的采用率同比下降了 3%。大多数 Kubernetes 部署都在多云或混合云中。报告指出：“当我们询问人们未来一年的增长计划时，几乎一半 (48%) 的人预计他们运营的 Kubernetes 集群数量将增长 50% 以上；另外 28% 的人预计 集群数量将显著增加（20% 到 50%）。
Kubernetes 的增长部分归功于其对 软件 开发和基础设施效率的持续投资。开发团队已经开始依赖从本地、单云、混合云或 多云进行编排所提供的灵活性。这些基于容器的混合云和多云环境允许团队以最少的重构或重新平台化来处理海量的工作负载。
在构建 基于微服务的应用程序时，这种开发人员效率尤其明显。由于它们由不同的单元组成，团队可以更轻松地将他们的资源投入到正确的任务中，同时在一个平台上工作。当使用单体架构时，这是一个相当困难的要求。这是一种有用的方式，可以防止过多的谚语厨师进入谚语厨房。
Kubernetes 的拿手好戏是它的自动化。通过获取高度可重复的命令并将它们设置为自动化，团队可以消除不必要的人头，并避免任何耗时的 IT 调整。在调查中，VMware 报告中的 45% 的注册者表示他们依赖 Kubernetes 是因为它的产品功能和路线图。
根据 Synergy Research 的数据，云基础设施市场在 2022 年第三季度同比增长 24%。随着越来越多的大型企业将容器化的云部署纳入其堆栈，并希望自由地将他们的数据从一个云移动到另一个云，而没有任何锁定，在混合云环境中工作的能力对于大多数大型组织来说正变得至关重要；正如 VMware 的报告所述，这一持续趋势反映在 41% 的受访者选择 Kubernetes 的原因就在于此。
2022 年 Evans Data 云开发调查指出，大多数主要的云服务平台都有针对其各自服务量身定制的 Kubernetes 发行版。最重要的是，37% 的开发人员使用专用的基于 Kubernetes 的云服务，例如 AWS 的 Amazon EKS 或 Microsoft 的 Azure Kubernetes Service。报告解释说：“这些 Kubernetes 的实现，具有不同级别的服务，使用这些公司内部的云后端进行容器编排。” 在 Evans Data 报告中，32% 的开发人员使用商业 Kubernetes 发行版，28% 的开发人员拥有托管的“vanilla” Kubernetes。
疫情推动了数字服务和体验进入超速状态，这鼓励了已经进行的向在线业务迁移的过渡。一个结果是云部署升级——以及应用程序负载。早在 2018 年 6 月，Kubernetes 1.11 发布，它引入了基于 IPVS 的集群内负载平衡，这一进步大大提高了应用程序的生产可扩展性。
负载平衡是关键，因为它是一种维护基础设施效率的免提方式，反过来，它可以防止云成本飙升。根据 Cast.ai 的数据，公司在 2022 年浪费了高达 162 亿美元的云浪费。这种过度配置正在耗尽开发团队的可用资源。节省金钱、时间和人力的自动化是目标，尽管这需要团队实施他们自己的工具，通过 operator 的商业支持来实现 自动故障转移。
如前所述，Kubernetes 的核心具有许多内置的自动化功能，但由于 Kubernetes operator 模式，因此可以自动化 Kubernetes 软件中没有的任务。
Kubernetes 非常擅长通过负载平衡集群节点以达到其理想状态来保持低成本。operator 通过添加一个额外的编排层更进一步，该层在发生自动故障转移时自动介入，通过协调循环监视资源，甚至自动扩展集群。
如果您使用 Redis – 或者正在考虑使用 – 我们可以让它变得更加容易。适用于 Kubernetes 的 Redis Enterprise Operator 简化并自动化了 Kubernetes 层的管理。 它是我们从数百万次集群部署中学习和总结的成果。
对于任何在 Kubernetes 上运行 Redis 并且有兴趣比较 Redis operator 和 Helm charts 的人，请阅读 Helm 工具和 Helm Charts 简介。
