从电子产品到智能设备的发展

安全同样重要

长篇大论的探讨完网络之后，来简单说一下安全问题。容器默认应该被最大限度的沙盒化，并需要显式的双重确认步骤。

我们可以直接应用Jessie Frazelle在容器安全方面出色的工作成果。打开默认的apparmor和seccomp配置文件。不允许在容器中以root身份运行。使用user命名空间进行隔离，这样哪怕有人设法在容器中升级为root，那也不是系统root。默认阻止所有设备挂载。不允许主机绑定挂载。为了达到效果，写一个你能想的的最严格的Pod安全策略，然后把他们作为默认值，并且让它们很难背离默认值。

Pod安全策略与此相当接近，因为它们强制执行双重确认：集群运维人员确认允许用户做不安全的操作，而用户必须显式申请权限执行不安全的操作。遗憾的是，Kubernetes现有的设计并没有这么考虑。这里我们先不关心向下的兼容性，把默认值做得尽可能安全。

(温馨提示：从这里开始，章节内容开始有点天马行空。这些都是我想要的设计，不过我强烈意识到，很多细节没有考虑清楚。)

gVisor?Firecracker?

说到默认情况下的最高级别的安全，我觉得不妨采取更激进的沙盒化措施。可以考虑将gVisor或Firecracker作为默认容器沙箱，并开启双重确认机制，最终达到“与主机共享内核的最安全的容器环境”这目的?

这里需要再斟酌斟酌。一方面，这些工具所承诺的极度安全非常吸引我。另一方面，这也不可避免地要运行一大堆额外的代码，也带来潜在漏洞和复杂性。而且这些沙盒对你能做的事情进行了极度的限制。甚至，任何与存储有关的事情都会演变成“不，你不能有任何存储”。这对于某些场景而言来说是不错，但把它变成默认值就限制得太过分了。

至少在存储方面，virtio-fs的成熟会解决很多这样的问题，能让这些沙盒在不破坏安全模型的前提下，执行有效地绑定和挂载操作。可能我们应该在那个时候再重新审视这个决定?

去中心化集群

我猜这个时髦的术语应该是“边缘计算”，但我真正的意思是，我想让我所有的服务器都在一个编排系统下，把它们作为一个单元来运作。这意味着我家里服务器机架上的计算机，我在DigitalOcean上的虚拟机，以及在互联网上的其他几台服务器。这些都应该是集群内基本等效的一部分，实际上也具备这样的能力。

这就导致了几个与Kubernetes不一样的地方。首先，工作节点应该设计得比当前更加独立，对控制节点的依赖更少。可以在没有控制节点的情况下长时间(极端情况下是几周)运行，只要没有机器故障，导致需要Pod重新调度。

我认为主要的转变是将更多的数据同步节点上，并存到持久化存储中。这样节点自身就有了恢复正常运行所需要的数据，和主节点失联后也能从冷启动中恢复到可响应状态。理论上，我希望集群编排系统在每个节点上填充一组systemd单元，在节点的运行过程中扮演一个被动管理的角色。它在本地拥有它需要的一切，除非这些东西需要改变，否则节点是独立于管理节点的。

这确实导致了如何处理节点失联的问题。在“中心化”的集群中，这是触发工作负载重新调度的关键信号，但在去中心化的情况下，我更有可能会说“别担心，这可能是短暂的失联，节点很快就会回来”。所以，节点生命周期以及它与Pod生命周期的关系将不得不改变。也许你必须显式声明你是否希望Pod是“高可用”(即当节点失联时主动地重新调度)或 “尽力”(只有当系统确定一个节点已经挂了并无法恢复时才重新调度)。

一种说法是，在我设计的“去中心化”集群中，Pod的表现更像是“独一无二的宠物”而不是“牧场里的羊群”。我会考虑设计类似无状态应用水平扩展的机制，但与Kubernetes不同，在这个场景下，当应用副本数缩小到一个时，我可以干预这一个应用运行在哪个节点上。这是Kubernetes不鼓励的做法，所以此处我们不得不背离Kubernetes的某些做法。

（编辑：伊春站长网）

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