随着云计算的发展和云原生应用的兴起，容器技术成为一种流行的应用部署和管理方式。容器化应用程序具有轻量、可移植和可扩展的特点，能够快速部署和运行在不同的环境中。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来使用可能会出现兼容性以及功能方面的缺失问题。

1、IP规划

名称	IP
K8s-master	10.230.1.26/24
CX532P-N	10.230.1.10/24
CX308P-N	10.230.1.21/24
Pod-cidr	10.244.0.0/16
Service-cidr	10.96.0.0/12

2、kubeedge方式部署

（1）软件环境

机器	名称	版本
K8s-master	Linux	Ubuntu 20.04.6 LTS
	docker	docker ce：26.0.0
		containerd：1.6.28
	cri-docker	v0.3.11
	keadm	v1.16.1
	kubeedge	v1.16.1
	kubeadm、kubelet、kubecli	v.1.27.6
	flannel	v0.24.4
CX532P-N	docker	docker ce：26.0.0
		containerd：1.6.28
	cri-docker	v0.3.11
	keadm	v1.16.1
	kubeedge	v1.16.1
	cni-plugin	v1.4.1

（2）最终效果

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

节点信息

显示容器信息：

master节点容器信息

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

node节点容器信息

3、node方式部署

（1）软件环境

机器	名称	版本
K8s-master	Linux	Ubuntu 20.04.6 LTS
	docker	docker ce：26.0.0
		containerd：1.6.28
	cri-docker	v0.3.11
	kubeadm、kubelet、kubecli	v.1.27.6
	flannel	v0.24.4
CX532P-N	docker	docker ce：26.0.0
		containerd：1.6.28
	cri-docker	v0.3.11
	kubeadm、kubelet、kubecli	v.1.27.6
	flannel	v0.24.4

（2）最终效果

master节点容器信息

node节点容器信息

4、结论

两种方案对比：

	kubeedge节点	普通K8s node节点
功能	边缘计算能力，能在边缘设备上运行容器化应用和进行边缘计算	完整的容器编排和管理能力，适用于云端和数据中心环境
生态支持	生态对比普通Kubernetes有所不足	成熟的生态系统和广泛的社区支持
设备	边缘设备和边缘计算基础设施的支持	普通计算节点
网络要求	离线工作支持，能在无网络连接的情况下继续工作	需要高速稳定的网络连接和可靠的云端基础设施
性能占用	边缘设备的资源限制可能影响应用程序的性能和可扩展性	性能占用略高，不适合特定于边缘计算场景的要求
部署管理	部署和管理边缘节点更复杂	部署管理较为简单
资源控制	node资源控制能力不足	完善的pod，namespace以及node资源控制管理能力

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

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

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

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

通过以上两种方式，星融元AsterNOS设备上能够运行K8s容器，想要自行配置体验？

方案获取：解决方案-基于Kubernetes的AsterNOS资源管理方案