随着云计算的发展和云原生应用的兴起，容器技术成为一种流行的应用部署和管理方式。容器化应用程序具有轻量、可移植和可扩展的特点，能够快速部署和运行在不同的环境中。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是专属于为边缘计算场景设计：
- 边缘计算环境：能够在边缘设备上运行容器化应用和进行边缘计算。因此，KubeEdge 特别适用于需要在边缘设备上进行实时数据处理、低延迟计算或离线工作的场景。
- 边缘数据处理：要求边缘设备具有本地数据处理能力，可以减少数据传输到云端的延迟和带宽消耗。这使得 KubeEdge 适用于需要实时数据处理、减少云端数据传输、保护数据隐私等场景，如物联网应用、视频监控、智能交通等。
- 离线工作支持：即使在边缘设备失去网络连接的情况下，仍然能够继续工作，适用于偏远地区或断网环境下的场景。
而普通的K8s节点更适用于如下场景：
- 云端和数据中心环境：节点具备完整的容器编排和管理能力，适用于在云端和数据中心部署和管理大规模的容器化应用。
- 易于扩展和管理的场景：普通 Kubernetes 节点在扩展性和管理性方面具有优势，可以轻松地扩展和管理大规模的集群，适用于需要高度可扩展性和灵活性的场景。
- 依赖云端资源的场景：普通 Kubernetes 节点通常依赖于云端的弹性和资源来处理工作负载，适用于需要利用云端资源来处理应用程序的场景。
- 广泛的生态系统和社区支持：普通 Kubernetes 在生态系统和社区支持方面非常强大，有着广泛的工具、插件和文档资源，适用于需要成熟的生态系统和广泛的社区支持的场景。
通过以上两种方式，星融元AsterNOS设备上能够运行K8s容器，想要自行配置体验？
方案获取：解决方案-基于Kubernetes的AsterNOS资源管理方案
