Kubernetes系统架构演进过程与背后驱动的原因

为了正确地保护Kubernetes集群并使其能够安全扩展，一些基本概念需要由系统的组件进行定义和约定。最好从安全的角度把Kubernetes看作是一系列的环，每个层都赋予连续的层功能去行动。

• 用于存储核心API的一个或者多个数据存储系统(etcd)
• 核心APIs
• 高度可信赖资源的APIs(system policies)
• 委托的信任API和控制器(用户授予访问API /控制器，以代表用户执行操作)，无论是在集群范围内还是在更小的范围内
• 在不同范围，运行不受信任/作用域API和控制器和用户工作负载

当较低层依赖于更高的层时，它会使安全模型崩溃，并使系统变得更加复杂。管理员可以选择这样做以获得操作简单性，但这必须是有意识的选择。一个简单的例子是etcd：可以将数据写入etcd的任何组件现在都在整个集群上，任何参与者(可以破坏高度信任的资源)都几乎可以进行逐步升级。为每一层的进程，将上面的层划分成不同的机器集(etcd-> apiservers +控制器->核心安全扩展->委托扩展- >用户工作负载)，即使有些可能在实践中崩溃。

如果上面描述的层定义了同心圆，那么它也应该可能存在重叠或独立的圆-例如，管理员可以选择一个替代的秘密存储解决方案，集群工作负载可以访问，但是平台并不隐含地具有访问权限。这些圆圈的交点往往是运行工作负载的机器，并且节点必须没有比正常功能所需的特权更多的特权。

最后，在任何层通过扩展添加新的能力，应该遵循最佳实践来传达该行为的影响。

当一个能力通过扩展被添加到系统时，它有什么目的?

• 使系统更加安全
• 为集群中的每一个人，启用新的“生产质量”API
• 在集群的子集上自动完成一个公共任务
• 运行一个向用户提供API的托管工作负载(spark、数据库、etcd)

它们被分为三大类：

1. 集群所需的(因此必须在内核附近运行，并在存在故障时导致操作权衡)
2. 暴露于所有集群用户(必须正确地租用)
3. 暴露于集群用户的子集(像传统的“应用程序”工作负载运行)

如果管理员可以很容易地被诱骗，在扩展期间安装新的群集级安全规则，那么分层被破坏，并且系统是脆弱的。

本文译者：季向远，北京神舟航天软件技术有限公司产品经理。

【编辑推荐】

1. Kubernetes的未来是Serverless
2. Kubernetes会不会被自身的复杂性压垮？
3. 向Kubernetes容器云平台迁移，你必须知道的9件事
4. 阿里云Serverless Kubernetes全球公测，应用部署只需30秒
5. 超越Kubernetes：值得关注的5大云原生技术

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!