这篇文章发布已超过一年。较旧的文章可能包含过时的内容。请检查页面信息自发布以来是否已失效。

Kubernetes 中策略的现状

Kubernetes 在行业中的影响力显著增长;随着快速发展,我们开始看到不同组件在定义和应用策略的方式上存在差异。

目前,与策略相关的组件遍布于身份服务、网络服务、存储服务、多集群联邦、RBAC 以及许多其他领域,它们的成熟度不同,解决特定问题的动机也各异。在每个组件内部,一些策略是可扩展的,而另一些则不是。每个项目用来表达意图的语言因原始作者和经验而异。在整个领域推动策略的统一视图是一项艰巨的任务。

在受监管行业中采用 Kubernetes 也将推动确保部署的集群符合各种法律要求,例如 PCI、HIPPA 或 GDPR。这些合规标准都对用户信息、数据和隔离强制执行一定程度的隐私保护。

当前 Kubernetes 策略实现的核心问题确定如下:

  • 平台缺乏全局视野
  • 不同策略组件之间缺乏协调和通用语言
  • 跨平台可扩展策略创建缺乏一致性。
    • 有些领域的策略组件是可扩展的,而另一些领域则强制执行严格的端到端解决方案。对于可扩展和可插拔架构的偏好尚未达成共识。
  • Kubernetes 架构中创建、修改或禁用的策略以及代表应用策略执行的操作缺乏一致的可审计性。

组建 Kubernetes 策略工作组 (WG)

我们成立了一个新的工作组,直接解决这些问题。我们旨在提供一个总体架构,描述 Kubernetes 中当前与策略相关的实现以及未来与策略相关的提案。通过协作方式,我们希望为开发者和终端用户提供一个统一的 Kubernetes 策略视图。

我们不寻求重新定义和替换通过充分讨论和共识达成的现有实现。而是旨在对当前实现进行总结性回顾,并解决我们初始设计提案中定义的广泛端到端场景所存在的差距。

Kubernetes 策略工作组一直专注于设计提案文档,并利用每周会议进行工作组成员间的讨论。设计提案概述了我们成立工作组的背景和动机、从中推导出差距/需求分析的具体用例、总体架构以及容器策略接口提案。

Kubernetes 中的关键策略场景

在工作组头脑风暴的多个用例中,最终突出了三个主要场景。

第一个场景是关于立法/法规遵从性,要求 Kubernetes 集群符合相关规定。合规性场景以 GDPR 作为立法示例,讨论中建议的策略架构是设置一个负责审计的数据策略控制器。

第二个场景是关于容量租赁,或者传统 IaaS 概念中的多租户配额。它探讨了当大型企业希望将其资源控制委托给其拥有的各个业务线时,如何配置 Kubernetes 集群以拥有策略驱动的机制来强制执行配额系统。多租户工作组中提出的正在进行的多租户控制器设计可能是配额策略控制器的理想执行点,而这又可以借鉴 kube-arbitrator。

最后一个场景是关于集群策略,它指的是通用的安全和资源导向的策略控制。集群策略将涉及集群级别和 Namespace 级别的策略控制以及执行,策略工作组成员正在开发一个名为 Kubernetes 安全配置文件的提案,以为此用例提供一个概念验证 (PoC)。

Kubernetes 策略架构

在这三个场景的基础上,工作组现在正在与 sig-arch、sig-auth 和其他相关项目一起研究三个具体提案。除了针对集群策略用例的 Kubernetes 安全配置文件提案外,我们还有部分针对容量租赁用例的调度策略提案,以及处理基于服务需求的亲和性和路由级别强制执行的拓扑服务策略提案。

当这些具体提案更加清晰时,工作组将能够提供一个高级别的 Kubernetes 策略架构,作为成立策略工作组的动机的一部分。

迈向云原生策略驱动架构

策略显然超出了 Kubernetes 的范畴,适用于更广泛的云原生上下文。我们在 Kubernetes 策略工作组中的工作将为构建一个 CNCF 范围的策略架构奠定基础,并整合 Kubernetes 和各种其他云原生组件,例如 Open Policy Agent、Istio、Envoy、SPIFEE/SPIRE 等。策略工作组已经与 CNCF SAFE 工作组(正在组建中)团队进行了协作,并将努力进行更多协调,以确保社区驱动的云原生策略架构设计。