广告

为什么大家都忽视了Kubernetes的Day2问题?

  • 浏览(271)
  • 评论(0)
  • 译者:k8s

这种情况一次又一次地发生

一个组织着手采用云原生技术并实现Kubernetes。然后事情开始变得有趣。

集群成倍增加。变化激增。访问需求不断增加。云成本飙升。

Kubernetes运营平台Rafay的首席执行官兼联合创始人Budhani表示:“无论是与高科技公司、金融服务公司、医疗保健公司还是运行边缘应用程序的零售商交流,问题都是一样的。”

“如何管理对集群的访问?将在所有环境中使用的策略模型是什么?生产集群的标准蓝图中必须始终包含哪些附加组件?部署属于多个业务部门的应用程序的策略是什么?必须很快升级所有集群,因为已经全面落后了三个版本,可是怎么做?”

这些问题都可以归在“Day2”类下。Day2对站点可靠性工程师(SRE)和IT运维工程师来说可能是一个永远头疼的问题。“我们必须诚实地面对这里的痛苦。”

为什么Day2如此痛苦?

Budhani说,这种痛苦有很多根源。首先,是技能差距的问题——Kubernetes已经八岁了,但仍然没有足够的工程师对K8s生态系统有充分的了解。

Canonical去年6月发布的一项调查显示,公司在采用容器和Kubernetes时面临的最大挑战是缺乏内部技能。

然后,组织使用云原生生态系统中的各种工具来操作Kubernetes,每种工具都需要定期升级和关注。

Budhani说:“所有这些工具都有自己的生命周期。每隔一段时间,这些工具中的每一个都需要在所有集群中更新。因此,随着新的内部团队部署更多的应用程序、每个应用程序的灾难恢复策略、计费策略等,你必须管理Kubernetes集群的生命周期、每个工具的生命周期、应用程序的生命周期、集中化的策略和访问管理。”

“这是Day2。Day2是关于在基础技术需要以完全自动化的方式为其治理、运维安全性和可见性定制策略的同时,需要采取什么措施来保持了解。”

他看到的一个首要问题是,没有足够的企业使用他所说的“治理自动化”——云原生架构所承诺的开发速度和不必要的辛苦,以及组织需要控制对关键数据、应用程序和基础设施的访问并控制云成本。

“如果你一次又一次地构建它,你就没有遵循DevOps的第一条规则:自动化一切。”

Kubernetes Ops的Day2是什么样子?

持续管理Kubernetes运维需要跟踪许多事情。对于需要部署到多云或混合环境中的组织来说,这种复杂性以及跟踪所有移动部件的挑战更加复杂。事实上,对处理这种复杂性的恐惧可能会阻止组织首先转向多云解决方案,并可能导致供应商锁定,从而阻止组织实现其业务目标。

但是,无论你在哪里部署应用程序,需要注意的关键领域都保持不变。根据Budhani和其他专家的说法,这里是Kubernetes Ops的五大支柱:

集群标准化和生命周期管理

Budhani说:“当你构建集群时,你就知道它今天的样子。但是你怎么知道一个月后的情况呢?”他指出,即使你不再接触集群,“一个已安装的具有足够高权限的附加组件最终可能会在你不知情的情况下更改基础配置。”

你需要密切关注集群的整个生命周期,包括它如何受到与之交互的其他工具和用户的影响。设置在整个组织中创建和更新集群的标准,同时确保一组经批准的附加组件始终在集群群中运行,这有助于简化Day2的任务,即在异常发生时识别异常。

安全访问和隔离

在Kubernetes的帮助下,一个完全或部分在云上运行的分布式网络需要一种全新的方法来实现运维人员/开发人员的访问和安全。无处不在的网络容易受到来自任何地方的攻击。

零信任安全方法在已经或正在迁移到云的组织中越来越流行。零信任摒弃了旧的“城堡和护城河”安全模式,使用细粒度、自动化的身份验证和授权权限来保护重要的基础设施和数据,无论它们位于何处。

但许多组织(如果不是大多数的话)在访问控制方面仍在努力掌握基本知识。strongDM在1月份发布的一项调查中,80%的参与者表示,他们的组织今年将致力于访问管理;只有30%的人表示他们的计划中有零信任项目。(同一研究中,三分之一的受访者称Kubernetes是他们使用的最具挑战性的技术。)

保护对Kubernetes API服务器的访问有助于防止未经授权的探测。当特定Kubernetes集群出现问题时(例如恶意软件的注入),需要隔离该集群或微服务,以避免问题蔓延。

可观察性和可见性

Kubernetes集群的管理员需要对所有环境有足够的可见性,以及必要的警报和监控级别,以便在出现问题时进行分类。Rafay的Kubernetes Operations Platform等解决方案提供了这些现成的功能。访问长期指标和警报数据可以真正帮助SRE和IT运维部门了解整个集群群的趋势,从而帮助规划和预测。

治理和合规性

当然,Kubernetes是开源的——完全开放。使用它的公司往往难以添加关键的治理和合规性功能,如日志记录、漂移检测和可审核性。

集中式可执行集群配置模型有助于实现企业范围的集群标准化。有办法确保部署所有已授权的安全和操作附加组件有助于确保遵守企业策略。此外,有一种方法可以检测集群何时偏离企业策略,并在出现问题时进行补救,这也是一项关键要求。

Rafay的Kubernetes Operations Platform提供了诸如集群蓝图、附加版本控制、策略实施和违规报告等功能,以及可以阻止对集群范围资源(如入口控制器、运行时安全工具等)的更改的漂移检测逻辑,以及对集群活动的端到端审计跟踪。

第三方集成和维护

要使所有服务和工具(这些服务和工具为你的现代(基于Kubernetes的)基础设施提供动力)无缝运行并协同工作可能很棘手。主要的云提供商通常都有一套工具来帮助管理Kubernetes,但如果超越了该云提供商的范围(可能部署到多个云、内部部署环境中,或者在某些情况下部署到边缘),这些工具并不总是能很好地转换。

这就像一个由需要不断组合在一起的组件组成的拼图,即使每个拼图都有自己的生命周期需要管理。开源工具和组件可能会带来自己的问题:例如,2021晚些时候发现的Log4j漏洞。或者仅仅是每季度更新Kubernetes版本的辛苦工作。

过时的工具可能会导致计划外停机,这会直接影响最终客户,并最终影响业务。

构建K8s平台的持续成本

Kubernetes的Day2负担不仅仅是云开支。运维和维护Kubernetes还可以让团队成员远离直接为公司带来收入的产品和应用程序。

Day2令人头疼的一些事情是由于缺乏标准化。当具有独特配置的集群出现故障时,它们可能包括复杂的分类和支持成本,或者由于控制器和集群之间的自定义访问和联网而导致的安全风险。缺乏kubectl访问控制也会使业务面临合规性和治理风险。

Budhani说:“经理们有时不愿意在Kubernetes旅程的早期提出Day2问题,因为“他们不想让开发人员担心。”

他补充道,这种沉默是被误导的:开发人员已经知道,由于Kubernetes Day2的问题,他们的工作量已经失衡。

Budhani说:“当我与开发人员交谈时,他们会说,‘我不知道为什么我要写Helm chart而不是我的应用程序。’‘是的,我想用Kubernetes做试验。我有点喜欢这项新技术。我喜欢在刚接触它的时候学习它。但是,天哪,我还有一份工作要做。”

他说,C级管理人员、DevOps经理和开发人员都想要同样的东西:一种高效的方式来发布更多更好的代码,并为业务创造更多的收入。但是,“他们各自立场不同。在这个过程中,这些大型企业在交付成果方面远远落后于计划。”

解决Kubernetes Day2问题

Budhani说:“为了让团队和组织做好监督构建在Kubernetes之上的云架构的长期准备,准确了解组织正在进入什么领域非常重要。”

他敦促说,在你开始一个包括操作Kubernetes在内的云原生项目之前,想想你的组织正在努力实现什么。

Budhani说,首席信息官和其他高级管理人员“过去常常要求他们的团队做更多的工作,做更多的试验。”现在,问题应该是,“你为什么要试验Kubernetes附加组件?向我证明,你需要在试验之前,在现成的东西之外构建一些东西。”

K8s标准化的真正成本包括定价模型、实施和维护。要问的问题包括:

——如何确定哪些工具最适合你的用例?

——如何跟上开源的变化?

——是否会继续投资于工具集成?

——当出现互操作性问题和运维问题时,谁来解决它们?

——你能足够快地雇佣足够多的具有云计算本领的人,或者培训已经拥有的团队成员吗?

最重要的是,考虑与其他也跨越了鸿沟并实施了Kubernetes的组织进行交流。

Budhani说:“首先,了解别人是如何做事的,因为这会让你感觉到这个问题是多么的困难或简单。从失败中学习是伟大的,但它是以时间为代价的。当你可以向同行学习时,为什么要走这条路呢?Kubernetes社区的美妙之处在于,人们乐于分享经验和观点。”

他总结道:“2022年,你并不是唯一一家致力于Kubernetes的公司。很多其他公司都经历过这一过程,或者正在这一过程中。有足够的资源来找到他们,与之交流学习。”

原文链接:

https://thenewstack.io/why-is-everyone-ignoring-the-day-2-kubernetes-problem/


  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头