实战演练：一文教你将交换机纳入K8s，对容器进行纳管

随着云计算的发展和云原生应用的兴起，容器技术成为一种流行的应用部署和管理方式。容器化应用程序具有轻量、可移植和可扩展的特点，能够快速部署和运行在不同的环境中。Kubernetes作为一个容器编排平台，为云原生应用的部署、管理和自动化提供了强大的支持，因此得到了广泛的关注和采用。

AsterNOS由于其系统的开放性，能够提供计算资源给用户以部署容器化服务。在客户拥有K8s管理集群的条件下，可以通过K8s纳管AsterNOS设备，将第三方应用部署在AsterNOS上，从而简化应用程序的管理和运维过程。通过使用K8s进行容器编排和自动化管理，便能实现应用的自动伸缩、自动恢复和自动升级，减少了人工干预和操作的工作量。可以提高运维效率，降低运维成本，并提供更好的应用程序可用性和稳定性。

配置K8s之前，先给读者们讲个故事：

在K8s诞生时，CNCF（云原生计算基金会——主导了K8s项目）便致力于推行一个标准的容器对接方案CRI，符合该容器标准的容器技术能够被K8s纳管，但是docker当时已经作为市场主流方案被接受，因此不符合该标准。出于市场原因K8s最开始在内部运行了名为docker-shim的垫片程序作为与docker的临时对接方案，在1.24版本后，K8s便放弃了与docker的兼容工作，将该垫片剥离出去。这方面工作就由Mirantis公司（docker母公司）接手，开发出名为cri-dockerd的垫片程序进行兼容工作。自此，如果想使用K8s管理docker，便需要使用一个名为cri-dockerd的容器运行时作为中间垫片。

---

因此，方案整体采用docker + cri-dockerd + K8s 的架构进行部署验证。

方案主体

可以通过两种方式将CX-N作为K8s集群中的工作节点：

• 将CX-N作为普通node节点纳入集群，在此方案中K8s中的kube-proxy以及kubelet作为必要组件会运行在工作节点中。该方案所占资源更多但是更加通用，能够实现K8s所有的功能。
• 将CX-N作为边缘设备纳入集群，该方案使用kubeedge组件，在主节点启用cloudcore，边缘节点启动edgecore加入主节点