皮皮网

1.Kata Container、码分Docker 和 Kubernetes的码分关系
2.多年锤炼，迈向Kata 3.0 ！码分走进开箱即用的码分安全容器体验之旅
3.威联通Container Station全功能详解——玩威联通docker，看这一篇就够了
4.Nydus 镜像加速插件迁入 Containerd 旗下
5.K8s-katacontainer 实践
6.openstack和k8s的区别

Kata Container、码分Docker 和 Kubernetes的码分视频强制分享源码关系

       Kata Container 是一个专注于提供强大隔离性且保持高效性能的容器运行时，其核心创新在于为每个容器独立运行一个虚拟机，码分从而避免共享内核带来的码分潜在风险。这种深层次的码分隔离机制旨在确保一个容器的漏洞不会影响同一主机上的其他容器，同时保持与传统容器运行时类似的码分操作灵活性。

       Kata 与 Docker 的码分主要区别在于其角色定位：Kata 是一个专注于底层运行的组件，而 Docker 则是码分一个完整的容器生态系统，包含创建、码分编排和管理容器应用程序的码分工具。Kubernetes 是码分一个容器编排器，它并不局限于特定的运行时，而是兼容多种，包括Kata。Kata 项目遵循 Kubernetes 支持的开放容器计划（OCI）标准，这意味着开发者可以无缝地在 Kubernetes 中编排使用Kata 运行的容器，甚至Kata 提供了预配置的部署配置以简化在 Kubernetes 环境中的集成。

多年锤炼，迈向Kata 3.0 ！走进开箱即用的安全容器体验之旅

       Kata Containers的安全容器在云原生多租户场景下解决了许多普通容器无法解决的问题，包括多租户安全保障、单机赛马源码下载不同SLO混部容器混合部署以及可信与不可信容器的混合部署。安全容器追求极致的轻薄，以接近runC容器方案的资源消耗和弹性能力，实现Secure as VM、Fast as Container的技术目标。随着Kata Containers的发展，从1.x升级到了2.x，Rust重构的Kata-agent极大减少了内存开销和整体攻击面，为Kata带来了更稳定的技术迭代。同时，阿里云内部的“袋鼠”团队基于Kata Containers打造了一套云原生底层系统，通过使用Rust重写Kata Container 2.0的go runtime以及为Kata Container专门开发的针对容器场景深度优化的轻量级虚拟机管理器Dragonball，袋鼠安全容器在性能和资源利用上表现出色，能够实现高密和弹性，支撑阿里云的函数计算FC和弹性容器实例ECI业务。袋鼠安全容器的优化和使用，不仅提高了业务的核心竞争力，还节省了大量资源成本。随着Kata 3.0版本的推出，内置VMM Dragonball沙箱将解决多进程交互、运维复杂、VMM版本适配以及安全容器虚拟化缺失的问题，实现Kata容器生态下的虚拟化最优解。Rust版本的一创量化源码kata-runtime提供可扩展框架，资源管理抽象公共接口，并采用Rust Async Runtime以兼顾并发、异步优势与安全性和低开销。通过提供内置于Kata Runtime的Dragonball VMM，安全容器的整体生态实现闭环，支持可扩展Rust Runtime以适应不同安全容器形态，使用户能够轻松使用和维护Kata，开箱即用体验将为小白和工程师团队带来多方面提升。Kata 3.0处于第一阶段开发，预计在年7月发布第一个alpha版本。随着Kata 3.0的推出，龙蜥云原生生态将整合云原生优势能力，输出开箱即用的发行版，并提供大数据、混部等场景解决方案。欢迎关注龙蜥社区公众号及龙蜥云原生SIG，参与共建云原生生态。

威联通Container Station全功能详解——玩威联通docker，看这一篇就够了

       大家好，欢迎来到Cherry的分享，专注于NAS和docker的探索。威联通TS-C2的新5.2系统让人眼前一亮，尤其是其Container Station 3.0，为docker使用带来了全新的游戏试玩盒子源码体验。作为沉浸NAS市场年的老品牌，威联通一直紧跟科技步伐，不断优化系统以满足用户需求。

       Container Station 3.0集成了LXD、Docker和Kata三种虚拟化技术，用户可以根据需求选择，提升效率。接下来，Cherry将从docker博主的角度，详细介绍Container Station 3.0的个关键功能点，帮助大家更好地理解和利用这个工具。对于docker基础不熟悉的朋友，可先阅读之前的docker系列文章，了解LXD和docker的区别。

功能点1：存储库——默认提供hub.docker和images.linux，支持登录Docker Hub获取认证镜像，还可添加自定义国内镜像站，方便网络环境不佳的用户。

功能点2：镜像管理——包括镜像列表、导出、删除、推送到存储库，以及高级模式支持直接导入镜像。

功能点3：卷管理——区分bind和卷模式，2023士兵扫雷源码支持查看、挂载、管理容器内的文件。

       ...（以下逐点列出，共8个功能点，省略）

       总的来说，威联通的Container Station 3.0是一个强大的一站式容器管理工具，极大地方便了用户操作。但若能进一步丰富应用程序模板，将有助于提升用户社区的活跃度和应用便利性。

Nydus 镜像加速插件迁入 Containerd 旗下

       Nydus，蚂蚁集团的容器镜像加速项目，已经成为Containerd社区的子项目。此举加强了Nyds与Containerd的协同，减少迭代过程中不兼容问题，让用户更容易使用Nyds服务。Nyds已将代码迁移到Containerd新仓库。

       Nydus是CNCF Dragonfly项目的一部分，专注于容器镜像加速。其核心是Rafs文件系统，加速容器启动，提高大规模集群中的成功率。Nyds支持多种创建方法，包括Nydusify、Acceld和Buildkit。Acceld是Nyds和eStargz的子项目，提供加速镜像转换服务。Nyds-snapshotter是Containerd的插件，负责镜像准备阶段的数据下载和处理。

       Nydus的特性包括层间块级数据去重、数据完整性校验、支持P2P分发、数据和元数据分离存储、审计容器访问行为。Nyds可以集成到vm-based容器运行时、KataContainers以及作为内核文件系统EROFS的用户态服务。

       Nydus团队与Containerd社区紧密合作，致力于提供更优秀的容器镜像加速方案，提升存储和分发效率，提供安全可靠的容器镜像服务。团队正在招收届实习生，关注业务、前沿技术和基础设施技术，重视成员成长。

K8s-katacontainer 实践

       调研 Kata Container 以解决容器内部的安全问题，通过结合 Intel Clear Containers 和 Hyper runV，Kata Container 实现了高性能与安全性兼备的容器运行时。传统的 Docker 容器存在安全性问题，如多容器间攻击风险，以及在使用 KVM 等虚拟化技术时的性能损耗。Kata Container 利用硬件虚拟化技术作为安全防御层，提供了更强的容器工作负载隔离。

       通过集成 Intel Clear Containers 的最佳部分与 Hyper.sh RunV，Kata Container 支持多种架构，包括 x_、AMD、ARM、IBM p 系列和 IBM z 系列。它还支持 QEMU、NEMU 和 Firecracker 等虚拟机管理程序，与其他容器化项目实现了良好的集成。Kata Container 的架构原理基于创建轻量级虚拟机实现资源隔离，进而提供网络、I/O 和内存的隔离，利用虚拟化 VT 提供硬件强制隔离，确保安全性的同时保持高性能。

       Kata Container 包含两个主要组件：container runtime 负责创建 QEMU*/KVM 虚拟机，支持 OCI 运行时规范，并与 Docker、Kubernetes 等平台集成；agent 在宿主机中用于管理容器及其进程。Kata-shim 是 Kata Container 集成到 Docker 中的关键组件，它在 shimv2 接口中实现了与 Kubernetes 的更高效交互，简化了 Pod 和容器沙箱的管理。

       在 Kubernetes 中集成 Kata Container 需要一系列准备步骤，包括在 VMware 虚拟机中开启嵌套虚拟化、安装 Kata Container、修改 containerd 和 kubelet 配置文件、以及配置 Kubernetes 使用 Kata Container。Kubernetes 使用 Kata Container 的方法有使用 untrusted_workload_runtime 或 RuntimeClass，具体版本要求根据所用 Kata Container 版本调整。

       通过集成 Kata Container，开发人员能够构建更安全、性能更高的容器环境，增强工作负载的隔离性，为多容器应用提供更强大的防护机制。

openstack和k8s的区别

       OpenStack和K8s是2种不同的开源类软件类型，简单的说就是OpenStack面向资源层，改变的是资源供给模式；而K8s面向应用层，变革的是业务架构。

       æ‰€ä»¥ï¼Œä½¿ç”¨å®¹å™¨ä¸”集群规模不大，直接用K8s就可以；集群规模大，不管应用是否只是跑在容器中，都是OpenStack＋K8s更好。

       OpenStack＋K8s是各取所长，并不只是因为惯性，而是对于多租户需求来说，Container（容器）的隔离性还需要加强，需要加一层VM（虚拟机）来弥补，而OpenStack是很好的方案。

       ä¸è¿‡ï¼ŒVM＋Container的模式，必然有性能的损耗，所以OpenStack基金会也推出一个项目叫KataContainers，希望减少虚拟化的开销，兼顾容器的性能和隔离性。

OpenStack实现方案

       1、OpenStack的网络分为flat、vlan、vxlan。

       2、br-tun是vxlan的隧道，隧道id对应了对应vlan id的vlan二层。

       3、br-int是添加vlan头、解vlan头的部分。

       4、route是ovs虚拟出来的路由器，不同vlan对应不同网关，通过snat出外网。

       5、浮动ip是ovs在虚拟路由器上dnat反向到vm的过程。

深入理解container--容器运行时

       容器技术的崛起并非一蹴而就，随着云计算的推动，它在近年来才逐渐成为大众关注的焦点。本文将深入探讨容器运行时的概念、组件原理，以及oci、runc、containerd等核心术语之间的关系。

       容器运行时的核心职责在于管理容器从镜像拉取到启动、运行直至终止的全过程，这与Java中的Java hotspot运行时相类似。以Docker为例，其系统功能包括：镜像拉取、启动、管理等，但这些功能可以由独立组件实现且无相互依赖。

       随着Docker与CoreOS、Google的合作，诞生了Open Container Initiative (OCI)，提供了两种主要规范：文件系统束（filesystem bundle），定义了编码容器为文件系统束的格式，包含了必要的元数据和配置信息；以及runc等工具，作为OCI的实践参考。此后，如rkt、containerd、cri-o等多样化的运行时工具出现，有的专注于运行容器，如runc，有的则扩展到镜像管理，如containerd。

       容器运行时大致分为low-level和high-level两类：low-level专注运行层面，通过namespace和cgroup实现资源隔离与限制；high-level则包含更多高级功能，如镜像存储管理和grpc接口。low-level运行时如busybox示例，涉及namespace和cgroup的配置，通过unshare命令实现隔离，实践部分参考了相关文章。

       high-level运行时如containerd，其架构包括grpc接口、metrics监控、存储管理等模块。containerd流程涉及创建metadata、调用runtimes、启动container等步骤，通过shim组件，containerd与容器进程解耦，保证容器运行稳定性。

       对于想要替换runc的场景，例如使用kata container或gViser，需要配合相应的shim版本。至于K8s如何利用containerd和shim，会在后续文章中详述。感兴趣的读者可以关注我的公众号或博客 packyzbq.coding.me 获取更多学习资源。