这篇文章已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。
Kubernetes 中策略的当前状态
Kubernetes 在行业中的影响显著增长；随着快速增长，我们开始看到组件在定义和应用策略方面存在差异。
目前，与策略相关的组件可以在身份服务、网络服务、存储服务、多集群联邦、RBAC 和许多其他领域找到，它们的成熟度不同，解决特定问题的动机也不同。在每个组件中，一些策略是可扩展的，而另一些则不是。每个项目用于表达意图的语言因原始作者和经验而异。在整个领域中推动对策略的一致看法是一项艰巨的任务。
受监管行业对 Kubernetes 的采用也将推动确保已部署的集群符合各种法律要求的需求，例如 PCI、HIPPA 或 GDPR。这些合规标准中的每一项都对用户信息、数据和隔离实施了一定程度的隐私保护。
当前 Kubernetes 策略实现的核心问题如下
- 缺乏对整个平台的宏观认识
- 不同策略组件之间缺乏协调和通用语言
- 整个平台缺乏一致的可扩展策略创建
- 在某些领域，策略组件是可扩展的，而在某些领域，则强制执行严格的端到端解决方案。尚未就可扩展和可插拔架构的偏好达成共识。
- 对于已创建、修改或禁用的策略，以及代表应用的策略执行的操作，Kubernetes 架构缺乏一致的可审计性。
成立 Kubernetes 策略工作组
我们已经成立了一个新的工作组来直接解决这些问题。我们打算提供一个总体架构，描述当前与策略相关的实现以及 Kubernetes 中未来与策略相关的提案。通过协作方法，我们希望向开发人员和最终用户展示 Kubernetes 中策略的统一视图。
我们不寻求重新定义和替换经过深入讨论和共识达成的现有实现。而是对当前实现进行总结性审查，并解决差距，以解决初始设计提案中定义的广泛的端到端场景。
Kubernetes 策略工作组一直专注于设计提案文档，并利用每周的会议进行工作组成员之间的讨论。设计提案概述了我们成立工作组的背景和动机、从中推导出差距/需求分析的具体用例、总体架构和容器策略接口提案。
Kubernetes 中的关键策略场景
在工作组集思广益的几个用例中，最终突出了三个主要场景。
第一个是关于立法/法规合规性，要求 Kubernetes 集群必须符合。合规性场景以 GDPR 为立法示例，讨论中提出的策略架构是让数据策略控制器负责审计。
第二个场景是关于容量租赁，或者说传统 IaaS 概念中的多租户配额，它处理的是当大型企业希望将其资源控制委托给各个业务线时，如何配置 Kubernetes 集群以具有策略驱动机制来强制执行配额系统。多租户工作组中提出的正在进行的多租户控制器设计可能是配额策略控制器的理想执行点，而该控制器可能会借鉴 kube-arbitrator 的经验。
最后一个场景是关于集群策略，它指的是一般的安全和面向资源的策略控制。Luster 策略将涉及集群级别和命名空间级别的策略控制以及强制执行，并且策略工作组的成员正在开发一个名为 Kubernetes 安全配置文件的提案，以提供此用例的 PoC。
Kubernetes 策略架构
基于这三个场景，工作组现在正与 sig-arch、sig-auth 和其他相关项目一起制定三个具体的提案。除了针对集群策略用例的 Kubernetes 安全配置文件提案外，我们还有部分针对容量租赁用例的调度策略提案，以及处理基于服务要求的亲和性和路由级别强制执行的拓扑服务策略提案。
当这些具体的提案变得更加清晰时，工作组将能够提供一个高层次的 Kubernetes 策略架构，作为成立策略工作组的动机的一部分。
迈向云原生策略驱动架构
策略绝对超越了 Kubernetes，并适用于更广泛的云原生环境。我们在 Kubernetes 策略工作组中的工作将为构建 CNCF 范围内的策略架构奠定基础，将 Kubernetes 与各种其他云原生组件（如开放策略代理、Istio、Envoy、SPIFEE/SPIRE 等）集成在一起。策略工作组已经与 CNCF SAFE WG（正在组建）团队合作，并将致力于更多的对齐，以确保社区驱动的云原生策略架构设计。