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