为了账号安全,请及时绑定邮箱和手机立即绑定

Kubernetes的需求层次

2019.07.18 10:01 538浏览

在我的职业生涯中,我很幸运能够与硅谷的一些最聪明的人和最前沿的公司一起工作。在过去的几年里,Kubernetes一直主导着我的客户。我认识的大多数工程师都在努力开展Kubernetes项目,成为这次技术潮流运动的一部分,以提高其市场价值。但是,即使采用Kubernetes这种疯狂的冲动,我也目睹了许多这些项目远未实现其最初目标。

事实是Kubernetes很复杂。生态系统正在迅速发展。这导致许多团队将重点转移到技术堆栈上。团队最终讨论每个单独的组件和/或CNCF项目,而不是将产品交付给他们的客户并根据反馈进行迭代。

在所有这些失败中,模式已经开始从成功的Kubernetes部署中出现 - 更具体地说,这些公司用于从白板到生产的想法。我已将这些知识整合到我称之为“Kubernetes需求层次”的内容中。

Kubernetes需求层次并不专注于单个技术组件,它是一个程序系统,使团队专注于客户可交付成果并协调一致以实现业务成功。其目的是在不断变化的基础技术领域上保持一层,在这一层大家专注于确定需要解决的问题,以便部署Kubernetes并编写代码,释放到生产环境。

Kubernetes需求层次由三个连续阶段组成:构建,部署,运维。这个序列对于驱动力的增强绝对至关重要。在每个阶段,您的客户必须验证最小可行产品(或可证明的功能),然后再进入下一阶段。这完成了三件事:

  • 作为强制功能,专注于可交付成果与个别技术。
  • 通过实现定义明确的里程碑,为企业和客户提供支持。
  • 在您的团队和关键利益相关者之间创建明确的期望,从而产生必要的反馈循环,以推动进度和效率。

图片描述

让我们更详细地看一下层次结构的每个阶段。

构建基础架构:您必须部署Kubernetes。这不仅是展示进步的第一个里程碑,而且还为您提供了如何操作和与系统交互的第一个真实体验。您和您的团队将学习命名法,建立您在部署阶段需要与之相关的可信度,并教授将加入的开发人员。此时,您是选择部署原生Kubernetes还是像GKE这样的托管服务并不重要。这一切都是为了进入一个可以加入服务的状态。

很多时候,我看到开发人员在建立他们的Kubernetes环境之前尝试回答后期问题。“我应该与Istio合作吗?我们如何跨数据中心的集群提供服务发现?“处理这些问题会带来不必要的复杂性。

请记住,这个阶段就是提供一个可用的集群,并展示您的团队对其组件的掌握程度。您这样做的速度越快,团队的可信度就越高,您的客户就越想与您合作。

部署应用程序:这是您开始考虑客户如何在平台上配置应用程序的地方。在构建任何内容之前,请与您的客户一起定义基本要求。然后建立规范。

例如,如果它是一个12因素的无状态应用程序,则无需立即提供存储持久性解决方案。而不是关注如何解决租赁问题,首先要说明用户如何与API进行交互并推送代码。一旦您了解了应用程序的生命周期和客户的能力,CI/CD管道就会变得相关。

令人惊讶的是,在许多情况下,应用程序团队在转换到Kubernetes时首次体验微服务。这对您和您的团队来说是一个巨大的机会,可以作为指导。保持技术简单,使这个过程更容易调试和优化。不要强制执行可能会创建其他学习曲线的流程或工具使用。

如果您的客户不愿意与您合作,他们将放弃该平台,影响您的团队品牌以及您招募其他内部客户的能力。

运维:恭喜!您的用户现在可以自由地推送代码,并且对他们可以实验和实施更改的速度感到发狂。而且您一直很聪明地了解您加入平台的人员,确保您的团队了解客户需求,只考虑适合现有平台功能和规模的应用程序。

不幸的是,你的工作尚未完成。您现在正在经历第一手微服务的缺点。如果您的团队组织得像我与之合作过的大多数人一样,那么核心架构师和SRE会随时待命,因为每一个警报都会出现在PagerDuty上。您发现大多数这些基于指标的警报已不再相关。它们由他们依赖的其他服务触发。更不用说,对于SLO来说,这是狂野的西部,你将与应用团队携手合作来定义它们。在事件发生期间,您会发现很多挫折感只是找到每个服务的自定义仪表板来验证SLI。最终的结果将是你曾经参与过的一些最大的战争室。

不要让这件事发生在你身上。在这里,您需要确定事件响应的优先级并建立SLO。与您的客户合作,清楚地了解客户如何监控他们的应用,哪些工作流程最重要,以及他们是否有相关(且准确)的SLO。您的团队将不再能够成为每项服务的细微差别和失败模式的专家。

有成熟的技术和CNCF项目用于记录和获取指标,两者在这些环境中仍然发挥着重要作用。由于能够提供端到端可见性,依赖性图表和性能分析,因此跟踪在微服务监控方面也获得了很大的动力。我与之合作过的最好的客户设计了可观察性数据管道和最佳实践,使服务所有者能够构建性能更高,更具弹性的应用程序。您实际上可能确定您只负责监控基础架构。这也没关系,但要确保期望从大门出发。

这让我回到最初带给我们的地方。有一个商业原因首先资助了这个项目。在一天结束时,它是关于更快地提供客户体验。

从业务方面考虑一下。当贵公司决定发布新产品时,它们会根据客户要求而定。这些要求推动了它们提供的功能的优先级。对于将在何时提供的内容有一个共同的理解,并且客户反馈和采用会告知接下来会发生什么。早期的产品采用推动了持续的投资和产品的发展。以同样的方式对待您的平台。使用Kubernetes Hierarchy of Needs来保持以客户为中心,并提供一个能够提供真正客户价值的平台。

译者注《Kubernetes实战:高可用集群搭建,配置,运维与应用》这门实战课可以帮助你和你的客户顺利度过这三个阶段,进而可以深入的走入Kubernetes的世界!


点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

2人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消