KubeEdge 1.6发布：可靠的K8s原生边云API
北京时间2月27日，KubeEdge发布了新的特性版本v1.6.0。
本次发布的1.6版本在系统可扩展性、生态兼容性等方面带来了重大升级，包括：新增可靠、自治的边缘Kube-API原生接口支持，自定义边云消息路由支持，自动配置边缘离线应用不迁移，OPC-UA设备协议驱动OPC-UA Mapper，并修复了24处问题。
可靠的K8s原生边云API接口支持
KubeEdge 1.6版本在边缘端新增了可靠、自治的Kube-API接口，为依赖于Kubernetes API、CRD的第三方插件和应用在边缘节点运行提供原生API 访问支持，包括List、Watch、Create、Update、Patch等操作。
原生的K8s中，KubeClient与Kube-Apiserver通过list-watch机制通信，在节点位于高时延网络、边缘频繁与云断链场景中，大量的re-list请求会给云边的通信链路造成额外的负担，影响系统的性能与稳定性。
本次新增的Kube-API接口基于KubeEdge的可靠性云边消息通信和边缘离线自治能力，在保证对原生API 访问支持兼容的同时，避免了上述re-list的问题。云边网络断开重连时，边缘不会发送re-list请求。而这个过程中，边缘运行KubeClient一直保持与本地的Kube-API接口连接，不会受到任何影响。
对希望集成使用特定版本Kubelet、Kube-Proxy、CNI、CSI的用户来说，这一特性的引入无疑是激动人心的。值得一提的是，该版本提供的Kube-API接口也提供了对边缘访问CRD的可靠支持，用户可以轻松的将各类Operator、插件在边缘运行。
注：该特性目前是alpha特性，欢迎大家试用。
用户自定义边云消息传输支持
边缘计算不仅仅是将应用部署在边缘，并对其进行自动化的监控和运维。在许多应用场景里，边缘和云上应用需要进行特定的消息传输、数据交换等，以完成边云协同的业务处理。例如，用户需要从云端发送命令至边缘的应用来触发特定的业务，或者边缘设备需要将采集的业务信息上传至云端处理。
KubeEdge v1.6版本增加了自定义边云消息传输的支持，用户可以根据场景，借助Rule和RuleEndpoint两个新增API来自定义的边云消息传输设置，为需要边云通信的业务组件或第三方插件屏蔽底层网络环境差异。
后续计划：v1.6版本支持自定义云端REST与边缘MQTT的双向消息传输，1.7版本将提供对边云双向REST消息传输的支持。
自动配置边缘离线应用不迁移
原生K8s中，如果节点出现离线状态并超过容忍时间，node controller默认会将节点上的应用驱逐，以重新运行在其他正常节点上。
驱逐的本质原理为，节点离线后node controller会将如下taints添加到节点上：
其中effect为NoExecute的taint会触发驱逐该节点上运行的应用(Pod)。但如果应用(Pod)容忍该taint，则不会被驱逐。
对于每个Pod，系统会默认添加如下两个toleration：
Key为”node.kubernetes.io/unreachable”的toleration可以容忍上述taint，但其容忍时间为300s，超时之后仍然会被驱逐。如果用户希望在断开与云端连接后将应用(Pod)长时间保留在边缘节点上，只需将容忍时间延长或置空（无限长）即可。
在KubeEdge 1.6版本中，用户只需为pod添加如下标签：
app-offline.kubeedge.io=autonomy
KubeEdge将自动配置应用的tolerations，使得节点离线后应用不被迁移。
OPC-UA设备协议驱动OPC-UA Mapper
OPCUA是一个工业软件接口规范，是企业制造模型的统一对象和架构定义，具有跨平台、增强命名空间、 支持复杂数据内置、大量通用服务等新特点，被看作是面向未来的下一代工业通讯规范。
KubeEdge v1.5版本发布了新的Mapper参考架构设计，继Bluetooh、Modbus协议支持后，本次发布了Go语言版本的OPC-UA Mapper，进一步丰富了设备接入生态。
OPC-UA Mapper地址：https://github.com/kubeedge/mappers-go/tree/main/pkg/opcua
结语
随着v1.6版本的发布，KubeEdge提供了更好的系统可扩展性、生态兼容性，未来KubeEdge将持续以云原生生态为基础，围绕边缘计算独特场景不断升级！
感谢华为、谐云科技、浙江大学SEL实验室、中国移动、中国联通、KubeSphere、旷世科技、时速云、ARM等组织的贡献，也感谢每一位社区贡献者！
附：KubeEdge社区贡献和技术交流地址
