随着全面云化时代的到来，很多公司都走上了容器化的道路，容器化确实带来了很多便捷，也降低了公司成本，但企业在落地容器技术的过程中也踩过不少坑。

比如，对应用和架构进行大的改造没有经验，没有合适的技术人才，技术还不成熟，没有合适的应用场景等。那么，在使用容器技术时，如何更好地与现有系统进行集成和共存？

InfoQ 与华为云原生技术团队共同建立了【容器魔方】技术社群，每天在群内分享技术资料，有任何疑问都可以与群内开发者讨论。在这里我们既谈技术，也交个朋友。

扫描小助手二维码加入容器魔方技术交流群

【容器魔方】技术社群得到了来自微博大V阮一峰、廖雪峰等老师的倾情推荐，几位老师后续也将在社群里与大家进行互动交流。

除了技术分享，从上周开始，线上公开课正式开始。第一节课获得了社群粉丝们的热烈响应，讨论也非常激烈。在线上直播结束后，讲师也回答了网友的提问。部分问题摘取如下：

关键词 1：云边数据协同

问：KubeEdge 云和边的数据协同有什么优势？
讲师回答：K8s 的原生架构中， Node (Kubelet) 是通过 List-watch 机制主动与 Master 通信。List-watch 机制有几个特点：

事件传输没有 ACK 类的校验机制，要依赖数据中心稳定的网络保证不丢事件。
每次网络断开，Node 侧都会从新执行 List 操作 (取回所有数据)，要依赖数据中心稳定的网络保证长连接不频繁断开，否则对 Master 及网络都是很大的损耗。
在边缘场景下，众所周知网络都是很不稳定的，包括丢失数据、连接断开等。针对不稳定的网络，在 KubeEdge 云边协同的设计中主要采用的措施有：
把 List-watch 中的事件取出来，加了 ACK 校验机制，只有边缘收到数据且回复 ACK 信息，云端才认为发送成功，反之则进行重试；
在网络断开 (确认节点离线) 后，云端会将待同步数据持久化，等到边缘节点上线，再将缓存的待发送数据逐一下发；
针对未发送的消息实时检查合并去重，避免网络震荡。
KubeEdge 的云边协同机制不仅保证了云和边之间数据的可靠传输，也避免了网络不稳定时重新 List 造成的网络压力。

关键词 2：KubeEdge 边缘节点自治

问：KubeEdge 目前是如何解决边缘节点自治能力的？
讲师回答：KubeEdge 会在边缘将收到的应用、设备元数据都进行本地持久化。相比 Kubelet 在内存中缓存对象的方式，KubeEdge 可以有效保证节点离线、故障恢复时的业务自治和快速自愈。

关键词 3：边缘应用和云端数据保持一致

问：边缘节点离线后，依赖数据多次变更，边缘应用和云端数据的最终一致是怎么保证的？
讲师回答：目前，KubeEdge 应用管理等操作都需要通过 K8s master 进行，针对边缘节点离线场景主要提供自治的能力，即本地持久化的数据仅用于管理节点上的应用和设备，云边通信恢复时，节点将同步更新本地元数据。
这里稍有不同的是边缘设备管理，对设备期望状态的设置需要通过 Device CRD 中的 Desired State 来操作（从云到边），而设备实际状态的上报会体现在 Reported State 中（从边到云），两个方向的数据同步不会冲突。

关键词 4：KubeEdge 与 K3s

问：KubeEdge 与 K3s 的区别是什么？
讲师回答：首先是架构选型问题，K3s 选择的是在边缘运行整个 K8s 集群的方案，不具备云边协同的能力；其次， K3s 虽然对 K8s 做了轻量化，但整体资源要求仍然较高，无法运行在 IoT Hub、工业网关等小型设备中。
KubeEdge 针对边缘场景的优化包括：

针对边缘网络不稳定的情况，增加了云边数据协同的可靠性传输、边缘元数据持久化，减少了网络不稳定造成的压力震荡，实现了边缘离线自治的能力，在云边断联、节点故障恢复时保证业务不受影响；
针对边缘资源不足的情况，对 Kubelet 进行轻量化裁剪，支持在 256MB 的设备上运行；
针对复杂多样的边缘设备管理，KubeEdge 定义了一套通用的设备管理 API（K8s CRD）以及设备协议解耦层，用户可以方便地使用 KubeEdge 管理各种边缘设备。

关键词 5：中心 K8s 对边缘节点的管理

问：中心 K8s 对边缘节点的管理，有哪些主要操作？
讲师回答：KubeEdge 运行在 K8s 完整的应用调度、管理能力之上，意味着 KubeEdge 的云端不负责应用的调度、管理，只是将调度到边缘节点的应用、设备元数据下发到边缘。KubeEdge 在云端的核心组件是 CloudCore，包含 EdgeController、DeviceController、CloudHub 三个模块，EdgeController、DeviceController 负责将应用、设备元数据下发到边缘，同时将来自边缘的节点状态、应用状态、设备状态刷新到 K8s 集群中；CloudHub 负责直接与边缘通信。

关键词 6：边缘节点 Nodeport 支持

问：新版本边缘节点的 Service 还是仅支持 HostPort 吗，Nodeport 是否支持？
讲师回答：从 KubeEdge 1.1 版本开始集成了 CRI，意味着用户可以使用 CNI 插件来配置网络，不再限制于 Hostport。NodePort 是 K8s 中服务访问的概念，需要通过 Kube-proxy 来配置，目前在边缘端还不支持。另外 KubeEdge 提供了 EdgeMesh 实现边缘应用间的互访。

关键词 7：容器镜像拉取

问：边缘节点的 Docker 容器镜像是从整个云 - 边 K8s 系统统一的镜像仓库拉取的吗？
讲师回答：只要边缘端能够访问到的镜像仓库，都能够用来拉取镜像。

关键词 8：KubeEdge 将容器化应用程序编排功能扩展到 Edge 的主机

问：PPT 里提到"KubeEdge 用于将容器化应用程序编排功能扩展到 Edge 的主机。" 那么，是把云上的应用下沉到 Edge、还把终端设备上的应用提升到 Edge 呢？
讲师回答：KubeEdge 作为应用管理平台时，可以在云端统一管控，既可以把应用部署到云端节点，也可以部署到边缘节点。用户可以根据自身需求，将云端的部分业务下沉到边缘。如果需要将终端设备上的应用部署到边缘节点，也可以通过 KubeEdge 来部署。

关键词 9：边缘侧应用通信

问：边缘侧的各个应用是怎么通信的？比如一个做 SQL 过滤的应用和另一个做数据分析的应用是通过 Hub 统一转发的，还是应用间就同步了，亦是通过 MQTT 等协议？同步异步消息分别怎么实现的？
讲师回答：目前 KubeEdge 中使用 EdgeMesh 机制来做边缘端应用的互访，不需要通过 Hub 与 MQTT 转发，在 EdgeMesh 实现应用互通的前提下，同步异步消息依赖用户应用自身的机制。

关键词 10：KubeEdge 节点 VS 普通节点

问：KubeEdge 节点和普通节点都在 Kubectl Get Node 中获取到，这两者有什么区别？
讲师回答：没有本质区别，KubeEdge 的边缘组件会将 Node 通过云边协同通道注册到 K8s Master，唯一的不同是普通节点由 Kubelet 直接访问 Master 完成节点注册，KubeEdge 是通过云边协同通道注册，API 都是一致的。

你有想跟讲师和开发者交流讨论的问题吗？欢迎加入容器魔方技术社群。

群规说明：

1、在容器魔方技术社群里，我们会每天分享一份技术干货，不限于 PPT/PDF/ 文档等形式，讲解各大厂进行容器化改造的案例以及其中的技术难点分析。

2、小助手会根据大家近期遇到的技术难题，在群内发布话题，引导大家讨论。来看看群友们的热烈讨论：

3、技术专家不定期线上分享，关于容器技术，也关于程序员的职业思考。下一次分享时间 11 月 21 日（本周四）晚上 20:00，关于 KubeEdge 的云边协同设计原理.

4、我们也会发布学习计划，鼓励思考和愿意分享的同学在群内分享自己的技术经验，并与 4000+ 开发者在线交流。

创作场景

快速搞懂容器技术的核心要点