IT世界每天都在越来越多地采用基于容器的基础架构。但是，其优势、劣势甚至局限性，大家就不清楚了。考虑到即使是大公司也越来越接近基于容器的基础设施，可能的攻击区域和数据泄露的潜在影响被忽视了。Docker(containerd)和LXC等技术并不是真正孤立的系统，因为它们与托管操作系统共享相同的Linux内核。对于潜在的攻击者来说，在大公司内启动他们的容器是千载难逢的机会。但是容器技术本身能不能让我们轻松自卫呢？现在的容器技术已经重复了很多次，容器是一种打包、共享和部署应用程序的新方式，而不是将所有功能打包在一个软件或操作系统中的单一应用程序。目前，容器没有利用任何新东西，但它们是在Linux名称空间和cgroups之上创建的演变。命名空间创建一个虚拟的和隔离的用户空间，并为应用程序提供隔离的系统资源，例如文件系统、网络和进程。这种抽象允许应用程序独立启动，而不会干扰同一主机上运行的其他应用程序。因此，由于命名空间和cgroup的结合，我们绝对可以在隔离环境中启动在同一主机上运行的许多应用程序。容器与虚拟机显然，与虚拟机环境相比，容器技术解决了隔离、可移植性和精益架构等问题。但我们不要忘记，虚拟机允许我们隔离我们的应用程序，尤其是在内核级别，因此黑客逃出容器并破坏系统的风险远高于逃出虚拟机。大多数Linux内核漏洞可能适用于容器，这可能允许它们升级和破坏受影响的命名空间以及同一操作系统中的其他命名空间。这些安全问题促使研究人员尝试创建与主机真正独立的名称空间。具体称为“沙盒”，现在有几种提供这些功能的解决方案：gVisor或，例如，KataContainers。Kubernetes中的容器运行时我们可以在容器编排器Kubernetes中更深入地研究此类技术。Kubernetes使用组件kubelet来管理容器。我们可以将其定义为一艘船的船长，负责按照给定的规范并准时准确地执行其操作。Kubelet将pod规范作为容器运行在分配给它们的主机上，并且可以与任何容器运行时交互，只要它符合OCI标准（其实现是RunC）容器运行时的工作原理RunC最初是嵌入式的在Docker架构中，于2015年作为独立工具发布。它已成为一个通用的、标准的、跨功能的容器运行时，DevOps团队可以将其用作容器引擎的一部分。RunC提供了与现有低级Linux特性交互的所有功能。它使用命名空间和控制组来创建和运行容器进程。在接下来的段落中，我们将介绍运行时类和核心元素。还有一个默认值为RunC的RuntimeClass处理程序（对于使用containerd作为容器运行时的Kubernetes安装）。RuntimeClass顾名思义，运行时类允许我们操作各种容器运行时。2014年，Docker是Kubernetes上唯一可用的容器运行时。从Kubernetes1.3版本开始，增加了与Rocket(RKT)的兼容性，最后在Kubernetes1.5中，引入了ContainerRuntimeIterface(CRI)，它有一个标准的接口和所有容器运行时的可能性，你可以直接与这个接口标准通信免去了开发者适配各种容器运行时和担心版本维护的麻烦。事实上，CRI允许我们将容器运行时部分与Kubernetes解耦，最重要的是，允许KataContainers和gVisor等技术以containerd的形式连接到容器运行时。在Kubernetes1.14中，RuntimeClass作为内置的集群资源再次引入，其核心是处理程序属性。handler是一个接收容器创建请求的程序，对应一个containerruntime。kind:RuntimeClassapiVersion:node.k8s.io/v1metadata:name:#RuntimeClassNamehandler:#containerruntime例如：runco??verhead:podFixed:memory:""#64Micpu:""#250mscheduling:nodeSelector:
