实战演练：一文教你将交换机纳入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加入主节点。此方案所占用性能更低，但是如果将该节点当作普通node来使用可能会出现兼容性以及功能方面的缺失问题。

01 IP规划

02 kubeedge方式部署

2.1 软件环境

2.2最终效果

在主节点上显示节点信息:

显示容器信息：

在CX-N设备上显示容器信息：

03 node方式部署

3.1 软件环境

3.2 最终效果

04 结论

两种方案对比：

总的来说，kubeedge是专属于为边缘计算场景设计：

1. 边缘计算环境：能够在边缘设备上运行容器化应用和进行边缘计算。因此，KubeEdge 特别适用于需要在边缘设备上进行实时数据处理、低延迟计算或离线工作的场景。
   
   
2. 边缘数据处理：要求边缘设备具有本地数据处理能力，可以减少数据传输到云端的延迟和带宽消耗。这使得 KubeEdge 适用于需要实时数据处理、减少云端数据传输、保护数据隐私等场景，如物联网应用、视频监控、智能交通等。
3. 离线工作支持：即使在边缘设备失去网络连接的情况下，仍然能够继续工作，适用于偏远地区或断网环境下的场景。

而普通的K8s节点更适用于如下场景：

1. 云端和数据中心环境：节点具备完整的容器编排和管理能力，适用于在云端和数据中心部署和管理大规模的容器化应用。
2. 易于扩展和管理的场景：普通 Kubernetes 节点在扩展性和管理性方面具有优势，可以轻松地扩展和管理大规模的集群，适用于需要高度可扩展性和灵活性的场景。
3. 依赖云端资源的场景：普通 Kubernetes 节点通常依赖于云端的弹性和资源来处理工作负载，适用于需要利用云端资源来处理应用程序的场景。
4. 广泛的生态系统和社区支持：普通 Kubernetes 在生态系统和社区支持方面非常强大，有着广泛的工具、插件和文档资源，适用于需要成熟的生态系统和广泛的社区支持的场景。

相关资料：K8s配置手册