Kubernetes治理，你应该知道的

Kubernetes的治理可能听起来很沉闷。但是，如果你是一个企业，这是你必须解决的一个关键部分，以达到规模化生产。在为你的开发团队标准化随需应变服务时（DevOps的最佳实践），你必须确保部署Kubernetes集群的团队遵循特定的规则，这个过程通常通过策略管理实现自动化。

然而，即使你只有几个集群，所有这些集群都由同一个人管理，你也必须使它们保持同步。如果没有自动化，这可以转化为相当多的工作。集中的策略管理和实施将简化这一过程。

不幸的是，治理仍然是一个相当不完善的领域。不同的治理规则通过不同的框架实现。而且由于它是如此分散，不同的管理和治理扩展，可能与你已经拥有的其他安全框架重叠。

由于没有一种全面的工具可以满足你的所有治理需求，因此你需要进行混合和匹配，直到涵盖所有关键领域。你的目标是在最大化覆盖率的同时，最小化所需的治理框架的数量，以便你的ops团队更容易地管理。

治理101

治理是指运维团队跨部门、组或整个组织验证和实施某些规则的能力。在Kubernetes上下文中，这意味着跨Kubernetes集群以及在这些集群中运行的应用程序执行规则。

有两个治理维度。首先，策略范围，即应用、执行或验证特定规则的地方。第二，政策目标，与应该执行和核查的内容有关。

范围可以根据组织单元（部门、团队、组、用户）、技术单元（云提供商、数据中心、区域、集群组、命名空间、标签选择器等）或两者来指定。范围定义功能也可以从静态列表到动态规则。

让我们更详细地探讨第二个维度。

执行治理目标

在安全策略方面，Ops可能需要控制多个领域。从确保只有应该访问集群或应用程序的用户才能访问的安全设置，到提供对某些部门的访问，再到指定应用程序可以使用的操作系统功能。例如，对于数据科学部门创建的每个集群，用户将被授予对特定缺省命名空间的访问权限。

镜像管理是另一个治理领域。组织可以指定在哪些集群中使用哪些容器镜像，或者必须满足哪些条件之后，这些镜像以供生产使用。例如，所有镜像必须被扫描，并且没有高于“警告”的漏洞级别。

网络策略管理允许组织定义哪些pod或容器可以相互通信，即通过治理定义的pod安全约束。在某些情况下，安全框架将解决这些治理需求。你可能有一个公共的治理框架，涵盖安全性和其他领域，包括集群拓扑和一般集群配置约束。

配置约束和策略是另一个治理类别。它允许你定义资源可配置性权限，以及资源访问和限制。例如，业务单元A可能被允许在这些特定帐户的Azure和AWS中创建集群，并在一定限度内使用资源，但是它们没有更改配置规范的能力。这里我们处理的是Kubernetes和Kubernetes管理工具的配置结构。

还有一些与部署在这些集群中的应用程序相关的治理规则。上面讨论的一些安全规则适用于应用程序，包括网络策略，并定义哪些pod可以相互通信（称为应用程序级约束）。你还可以约束所有应用程序的资源使用、请求和限制。

显然，可以自动化许多不同的策略，以最小化管理不善和可利用漏洞的风险。要使治理框架自动化，你需要为所有资产提供某种形式的注册表。在Kubernetes集群管理的情况下，你需要一个所有集群都注册的地方。这再次强调了集中管理对所有Kubernetes集群的重要性。

实现治理框架

在实施你的治理框架时，你有三个选择：

将多个专门的治理框架组合成一个全面的解决方案。NeuVector等工具可以用于安全策略。然后，可以使用专门的云成本管理工具进行云资源管理和成本控制，如Cloudability等。

这种方法并不是没有挑战的，因为你可能有一组工具，它们彼此之间不一定进行通信和集成。不同的策略在不同的地方定义，具有不同的接口。有些框架可能不知道你的容器管理平台或容器。例如，在使用云集中的成本管理框架时，你可以在特定的云/云帐户中设置限制，但是你不知道是哪个集群或应用程序导致了意外开销。

另一种方法是在集中的Kubernetes平台上实现它。如果它有一个API，你可以通过它访问不同的集群、参数和特征，这就特别有趣了。这基本上是一种自己构建的方法，使你能够将其他云原生平台集成到现有的治理框架中。

第三种方法是选择一个包含全面治理框架的Kubernetes平台，或者至少在其路线图中包含它。