KubeEdge released a new feature version v1.6.0 on February 27, Beijing time.
The 1.6 release brings significant upgrades to system scalability and ecological compatibility, including: Added reliable and autonomous edge Kube-API native interface support, custom edge cloud message routing support, automatic configuration of edge offline applications without migration, OPC-UA device protocol driver OPC-UA Mapper, and fixed 24 problems.
Reliable K8s native edge cloud API support
KubeEdge 1.6 adds a reliable and autonomous Kube-API interface to the edge, providing native API access support for third-party plug-ins and applications that rely on Kubernetes API and CRD to run on edge nodes. The operations include List, Watch, Create, Update, and Patch.
In the native K8s, KubeClient communicates with Kube-Apiserver through the list-watch mechanism. In the scenario where nodes are located in high-delay networks and edge is frequently disconnected with cloud, a large number of re-list requests will cause additional burden to the communication link of cloud side, affecting the performance and stability of the system.
The newly added KuBE-API interface is based on KubeEdge’s reliability cloud-side message communication and edge offline autonomy, which ensures the compatibility of native API access and avoids the above re-list problems. When the cloud – side network is disconnected and reconnected, the edge does not send re-list requests. In this process, the edge running KubeClient stays connected to the local Kube-API without any impact.
The introduction of this feature is certainly exciting for users who want to integrate with specific versions of Kubelet, Kube-Proxy, CNI, and CSI. It is worth mentioning that the kube-API provided by this version also provides reliable support for edge access CRD. Users can easily run various operators and plug-ins on the edge.
Note: This feature is currently alpha and you are welcome to try it out.
User – defined edge cloud messaging support
Edge computing is more than just deploying applications to the edge and monitoring and operating them automatically. In many application scenarios, edge and on-cloud applications need to carry out specific message transmission and data exchange to complete the business processing of edge cloud collaboration. For example, users need to send commands from the cloud to edge applications to trigger specific services, or edge devices need to upload the collected service information to the cloud.
KubeEdge V1.6 adds support for customized edgecloud message transmission. Users can customize edgecloud message transmission Settings according to scenarios by using two new apis Rule and RuleEndpoint to shield underlying network environment differences for business components or third-party plug-ins that need edgecloud communication.
Future plans: v1.6 will support bidirectional messaging between custom cloud REST and edge MQTT, while 1.7 will provide bidirectional REST messaging support for edge cloud.
Automatic configuration edge offline applications do not migrate
In native K8s, if a node goes offline for longer than the tolerated time, the Node Controller by default evicts the application from the node so that it can run again on another normal node.
The essential principle of expulsion is that the node controller adds the following taints to the node after the node is offline:
Taint with Effect NoExecute triggers expulsion of applications (pods) running on that node. However, if the application (Pod) tolerates the TAINt, it will not be expelled.
For each Pod, the following two toleration toleration are added by default:
Key for “node. Kubernetes. IO/toleration can tolerate the taint of unreachable”, but the tolerance time of 300 s, after the timeout will be evicted. If the user wants to keep the application (Pod) on the edge node for an extended period of time after disconnecting from the cloud, simply extend or empty the tolerance (for an infinite length).
In version 1.6 of KubeEdge, users simply add the following tag to pod: app-Offline.kubeed.io = Autonomy
KubeEdge will automatically configure the app’s tolerations so that the app doesn’t migrate when the node goes offline.
Opc-ua Drives the OPC-UA Mapper
OPCUA is an industrial software interface specification, is a unified object and architecture definition of enterprise manufacturing model, with cross-platform, enhanced namespace, support for complex data built-in, a large number of common services and other new features, is regarded as a future-oriented next-generation industrial communication specification.
KubeEdge V1.5 released the new Mapper reference architecture design, following Bluetooh, Modbus protocol support, this release of Go language version of OPC-UA Mapper, further enrich the device access ecosystem.
Opc-ua Mapper address: github.com/kubeedge/ma…
conclusion
With the release of v1.6, KubeEdge provides better system scalability and ecological compatibility. In the future, KubeEdge will continue to be based on cloud native ecology, and continue to upgrade around edge computing unique scenarios!
Thanks to Huawei, Harmonic Cloud Technology, SEL Lab of Zhejiang University, China Mobile, China Unicom, KubeSphere, Kuanshi Technology, Speed Cloud, ARM and other organizations for their contributions, and also thanks to every community contributor!
Attached: KubeEdge community contribution and technical exchange address
Website: kubeedge. IO
Github address: github.com/kubeedge/ku…
Slack: kubeedge.slack.com
Mailing list: groups.google.com/forum/#! The for…
Weekly community meeting: zoom.us/j/416723730…
Twitter: twitter.com/KubeEdge
The document address: docs. Kubeedge. IO/en/latest /