AKS 支持 Kata Container容器沙盒 -预览阶段

您准备好提升您的云和 DevOps 技能了吗？
🐥《云原生devops》专门为您打造，我们精心打造的数十篇文章库，这些文章涵盖了 Azure、AWS 和 DevOps 方法论的众多重要主题。无论您是希望精进专业知识的资深专业人士，还是渴望学习相关知识的新手，这套资源库都能满足您的需求。

各位老铁，如果文章能够给大家带来一定的帮助！欢迎一键三连！

使用 Kata Containers 实现 Pod 沙盒

Kubernetes 中一项名为“Pod 沙盒”的安全功能，可以限制 Pod 对底层主机以及在同一节点上运行的其他 Pod 的访问。

通过将 Pod 的文件系统、网络和其他资源与其他 Pod 和主机的文件系统、网络和其他资源隔离，Pod 沙盒增加了一层额外的保护。这降低了错误或恶意代码影响其他 Pod 或基础主机的可能性。

Kubernetes 通过使用遵循容器网络接口 (CNI) 规范的容器运行时来实现 Pod 沙盒。CNI 提供网络隔离，使 Kubernetes 能够为每个 Pod 建立一个网络命名空间。此外，Kubernetes 还使用 Linux 命名空间功能隔离 Pod 的文件系统、进程树和其他资源。

总而言之，Kubernetes 的 Pod 沙盒是一项至关重要的安全功能，有助于防范潜在的安全威胁并维护集群的稳定性。

Azure Kubernetes 服务 (AKS) 如何实现 Pod 沙盒？

Azure 宣布了 AKS 集群上 Pod 沙盒的预览版。此功能使您可以在沙盒环境中运行 Pod，而无需与主机或其他 Pod 交互。在传统的 Pod 设置中，它们共享运行集群的操作系统的同一内核。例如，如果该集群在 Linux Pod 上运行，则可以使用 Linux 内核系统调用来访问网络和 CPU 等资源。

使用 Pod 沙盒，每个容器都可以运行其内核。因此，每个 Pod 彼此隔离。

在安全环境中，这将增强 Pod 的安全性。如果未启用沙盒，恶意代码可以访问主机系统并提升权限。

AKS 使用 Kata 容器来实现 Pod 沙盒。Kata 容器是一个由社区积极贡献的开源项目。

利用 Mariner Linux AKS 容器主机，AKS 上的 Kata 容器构建在安全强化的 Azure 主机之上。利用轻量级的 Kata 嵌套虚拟机（该虚拟机从父虚拟机节点划分资源），实现了每个 Pod 的隔离。此架构中的每个 Kata Pod 为每个嵌套的 Kata 来宾虚拟机接收一个单独的内核。这允许用户在单个来宾虚拟机中容纳多个 Kata 容器，同时仍在父虚拟机中运行容器，从而在共享 AKS 集群中提供了强大的隔离边界。

工作原理

为了在 AKS 上实现此功能，运行在适用于 AKS 堆栈的 Azure Linux 容器主机上的 Kata 容器提供了硬件强制隔离。Pod 沙盒扩展了硬件隔离的优势，例如为每个 Kata Pod 分配单独的内核。硬件隔离会为每个 Pod 分配资源，并且不会与同一主机上运行的其他 Kata 容器或命名空间容器共享这些资源。

该解决方案架构基于以下组件：

• 适用于 AKS 的 Azure Linux 容器主机
• Microsoft Hyper-V 虚拟机管理程序
• Azure 调优的 Dom0 Linux 内核
• 开源云虚拟机管理程序虚拟机监视器 (VMM)
• 与 Kata 容器框架集成

使用 Kata 容器部署 Pod 沙盒与使用标准的 containerd 工作流部署容器类似。部署过程包含 kata-runtime 选项，您可以在 Pod 模板中定义这些选项。

要在 Pod 中使用此功能，唯一的区别是将运行时类名 kata-mshv-vm-isolation 添加到 Pod 规范中。

当 Pod 使用 kata-mshv-vm-isolation 运行时类时，它会创建一个虚拟机作为 Pod 沙盒来托管容器。如果容器资源清单 (containers[].resources.limits) 未指定 CPU 和内存的限制，则虚拟机的默认内存为 2 GB，默认 CPU 为 1 个核心。当您在容器资源清单中指定 CPU 或内存的限制时，虚拟机会使用 containers[].resources.limits.cpu 和 1 参数指定使用 1 + xCPU，并使用 containers[].resources.limits.memory 和 2 参数指定 2 GB + yMemory。容器只能使用不超过容器限制的 CPU 和内存。在我们努力降低 CPU 和内存开销期间，此预览版中将忽略 containers[].resources.requests 参数。

在 AKS 中启用 Pod 沙盒

在启用 Pod 沙盒之前，必须配置以下先决条件。

1. 注册 KataVMIsolationPreview 功能标志。
2. 如果您正在使用具有 Pod 沙盒的新集群，请执行以下步骤。
3. 为现有集群部署 Pod 沙盒。
4. 使用以下命令添加现有集群

#此命令添加了附加标签

az aks nodepool add --cluster-name aks-storage-solutions --resource-group rg-k8s-storage-solutions --name nodepool3 --os-sku mariner --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3 --labels kata=enabled

我们可以按如下方式验证 Kata 虚拟机是否用于集群节点。

对于 Pod 沙盒，AKS 使用单独的虚拟机管理程序和针对 Kata 容器优化的 Linux 操作系统。

使用以下命令，我们可以验证可用的运行时

kubectl get RuntimeClasses.node.k8s.io

接下来，我们将部署一个启用了 Pod 沙盒的容器。使用以下 YAML 清单。在此清单中，我们指定了 RuntimeClassName，用于选择 Pod 需要运行的特定运行时。此外，还有一个 nodeSelector，用于在 Kata 容器启用的节点池中调度 Pod。

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: nginx-kata
spec:containers:- name: nginximage: nginxruntimeClassName: kata-mshv-vm-isolation #runtime class nametolerations:- key: kataoperator: Equalvalue: "enabled"effect: NoSchedulenodeSelector:kata: enabled
EOF

验证：

我们可以验证 Pod 是否正在运行

kubectl get pods nginx-kata

进入pod 中的容器，检查内核的版本：

kubectl exec -it nginx-kata -- bash

截至撰写本文时，该功能仍处于预览阶段，不建议用于生产环境。从这里，您可以了解使用 Pod 沙盒的局限性。

结论

主机内核及其保护具有最高优先级。如果您在集群上运行大量工作负载、多租户应用程序、可能受到攻击的应用程序，或者希望为工作负载提供最高级别的安全性，此功能将非常有用。请理解沙盒确实存在一些缺点，但请权衡这些缺点与其提供的额外保护。

如果您只打算将 AKS 用于只有您信任的员工才能访问的内部应用，则可能不需要此功能。但是，如果您担心主机和容器的安全性，则应该考虑此功能。