KubeEdge is a CNCF Sandbox project that extends K8s from Cloud to Edge. We would like to invite you to join us in furthering this project and making it useable for everyone. To make this contribution effort more fun, we're proposing a contribution competition. See below for details. May the best contributor win!

That's right, contribute and win! Contribution is not limited to code contribution only; it can also include documentation, blogging, testing/issue identification, requirement identification and others. See details below

How to participate ?​

1. Raise pull request (PR) either for feature development / test code development (may be unit test code, edge module test code or end to end test code) in repos kubeedge / beehive / viaduct / website.
2. Identify defects, raise issues in respective repos kubeedge / beehive / viaduct / website.
3. Resolving existing issues in repos kubeedge / beehive / viaduct / website.
4. Share requirements by creating issues in repo kubeedge.
5. Writing blogs about KubeEdge either in the KubeEdge website (on PR approved & merged, this gets published in kubeedge.io website blog) or in other technical blogging site. Please refer here to know how to write a KubeEdge blog. Submit your blog details here.
6. Create your own sample applications and demo examples to illustrate possible use case(s) of using KubeEdge in repo examples.

Who can participate ?​

Anyone is welcome!

How the winners are selected ?​

Contribution can be made in the following various ways. Please see below for contribution requirements and how we select winners.

• Code contribution: Any code contribution should follow the contribution flow to get accepted. We will review the code submitted along with PR(s) for feature / test case development or issue fix.

• Issue identification: we will check the severity of issue and the quality of description that reproduces the identified issue with sufficient details.

• Requirement identification: we will check the quality of the requirement description, the uniqueness and the value of the identified requirement in comparison to the other Edge Computing platforms in the industry.

• KubeEdge project promotion: For any blog/wechat messages/twitter tweets/white papers/articles written about KubeEdge, we will review the content & popularity of the content.

• Example contribution: For any example created, we will review the code and the documentation of the steps & user guide.

Any contribution is greatly appreciated and 3 winners will be selected!

Timeline​

How the winners are notified ?​

Winners' Github ID will be published in this section. Winners will receive an e-mail that is associated with his/her Github ID. Any question, please contact us via:

• mailing list
• slack

Resources​

• kubeedge

• viaduct

• beehive

• examples

• website

KubeEdge community Code of Conduct​

KubeEdge follows the CNCF Code of conduct.

Why SPIFFE for edge computing?​

Edge computing framework capabilities should be able to cloud-native design patterns and practices such as container orchestration, microservices, serverless computation which has led to increasing heterogeneous deployment environments. Conventional practices for securing heterogeneous deployments add complexity overhead to enforcing policies, prevention and detection of threats. Due to the increase in complexity, there is more scope of error in manageability and also, constraints the scalability of the applications across multiple production environments. In such cases, a common identity framework for workloads becomes necessary to avoid the pit-falls of conventional security policies (such as managing network policies that are based on rules for traffic between particular ip addresses) which affect implementation of distributed patterns.

This enables to build a security model which is application-oriented rather than infrastructure-oriented.

What is SPIFFE and SPIRE?​

The SPIFFE standard provides a specification for a framework capable of bootstrapping and issuing identity to services across heterogeneous environments and organizational boundaries.

SPIFFE specification standardizes the process of assigning identities to workloads , verifying and validation of workload identities and workload API to retrieve the identities.

https://github.com/spiffe/spiffe

SPIFFE identities are encompassed in a SVID (SPIFFE Verifiable Identity Document). SVID specification provides the requirement for properties that must be supported when implementing SVID. Following link provides more information on SVID based on X509 certificate.

https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md

SPIRE is a toolchain implementation for SPIFFE specification that enables establishing trust between workloads (using mTLS or JWT) across different deployment environments,issue SPIFFE IDs and workload API to retrieve workload SVIDs.

How does SPIRE work?​

Following information is extracted from Scytale presentations which gives informative and simplistic view on how SPIRE works.

What are the few desired security requirements for Kubeedge?​

Security is a paramount requirement for edge computing architecture as security breaches can make a complete organization to come to a halt (IIot) , data breach can lead to privacy issues and also control of the complete edge computing infrastructure. Few of the security requirements for deployment for kubeedge framework and edge application, but not limited to, are

• An identifiable edge node and workloads executing on the edge node.

• A method to verify the authenticity of the node and workloads executing on the node.

• Automated rotation of security credentials.

• Limit the affect of SPOF (in case of security-related events).

• Auditable security information about node and workloads in the environment.

• Limit access of user workloads to framework components and cloud.\

• Secure device provisioning.

• Device identity management and access control.

How SPIRE helps Kubeedge?​

• Node attestation: Only verifiable edge nodes can join the edge clusters. Every node is issued an identity on verification. In case of failed node attestations, no identity documents can be issued for services running on the node.

• Workload attestation: Only verifiable workload can run on edge nodes. In case of failed workload attestations, there are no identities issues for the workloads. All communications are blocked from unverified workloads.

• Certificate rotation: Short-lived certificates are generated and rotation policies can be configured for every service communication. There is no need for custom agents and reliance on specific orchestrators for certificate rotation configuration and management.

• Automated non-root CA certificate heirarchical deployments: Edge spire servers can be configured to not share any root CA chain for downstream nodes and workloads.

Example Demo​

In the present example PoC, there is no solution implemented for secure device provisioning and identity management. It will be added in the forthcoming versions. An example demo using SPIRE for secure deployment of edge node and sample applications can be found at

https://github.com/kubeedge/examples/tree/master/security-demo

The KubeEdge team presented their case for sandboxing at the CNCF TOC meeting on 12th March 2019.

Today we announce the acceptance of KubeEdge under the CNCF sandbox.​

KubeEdge becomes the first Kubernetes Native Edge Computing Platform with both Edge and Cloud components open sourced!​

Open source edge computing is going through its most dynamic phase of development in the industry. So many open source platforms, so many consolidations and so many initiatives for standardization! This shows the strong drive to build better platforms to bring cloud computing to the edges to meet ever increasing demand. KubeEdge, which was announced last year, now brings great news for cloud native computing! It provides a complete edge computing solution based on Kubernetes with separate cloud and edge core modules. Currently, both the cloud and edge modules are open sourced.

Unlike certain light weight kubernetes platforms available around, KubeEdge is made to build edge computing solutions extending the cloud. The control plane resides in cloud, though scalable and extendable. At the same time, the edge can work in offline mode. Also it is lightweight and containerized, and can support heterogeneous hardware at the edge. With the optimization in edge resource utlization, KubeEdge positions to save significant setup and operation cost for edge solutions. This makes it the most compelling edge computing platform in the world currently, based on Kubernetes!

Kube(rnetes)Edge! - Opening up a new Kubernetes-based ecosystem for Edge Computing​

The key goal for KubeEdge is extending Kubernetes ecosystem from cloud to edge. From the time it was announced to the public at KubeCon in Shanghai in November 2018, the architecture direction for KubeEdge was aligned to Kubernetes, as its name!

It started with its v0.1 providing the basic edge computing features. Now, with its latest release v0.2, it brings the cloud components to connect and complete the loop. With consistent and scalable Kubernetes-based interfaces, KubeEdge enables the orchestration and management of edge clusters similar to how Kubernetes manages in the cloud. This opens up seamless possibilities of bringing cloud computing capabilities to the edge, quickly and efficiently.

Based on its roadmap and architecture, KubeEdge tries to support all edge nodes, applications, devices and even the cluster management consistent with the Kuberenetes interface. This will help the edge cloud act exactly like a cloud cluster. This can save a lot of time and cost on the edge cloud development deployment based on KubeEdge.

KubeEdge provides a containerized edge computing platform, which is inherently scalable. As it’s modular and optimized, it is lightweight (66MB foot print and ~30MB running memory) and could be deployed on low resource devices. Similarly, the edge node can be of different hardware architecture and with different hardware configurations. For the device connectivity, it can support multiple protocols and it uses a standard MQTT-based communication. This helps in scaling the edge clusters with new nodes and devices efficiently.

You heard it right!​

KubeEdge Cloud Core modules are open sourced!

By open sourcing both the edge and cloud modules, KubeEdge brings a complete cloud vendor agnostic lightweight heterogeneous edge computing platform. It is now ready to support building a complete Kubernetes ecosystem for edge computing, exploiting most of the existing cloud native projects or software modules. This can enable a mini-cloud at the edge to support demanding use cases like data analytics, video analytics, machine learning and more.

KubeEdge Architecture: Building Kuberenetes Native Edge computing! The core architecture tenet for KubeEdge is to build interfaces that are consistent with Kubernetes, be it on the cloud side or edge side.

Edged: Manages containerized Applications at the Edge.

EdgeHub: Communication interface module at the Edge. It is a web socket client responsible for interacting with Cloud Service for edge computing.

CloudHub: Communication interface module at the Cloud. A web socket server responsible for watching changes on the cloud side, caching and sending messages to EdgeHub.

EdgeController: Manages the Edge nodes. It is an extended Kubernetes controller which manages edge nodes and pods metadata so that the data can be targeted to a specific edge node.

EventBus: Handles the internal edge communications using MQTT. It is an MQTT client to interact with MQTT servers (mosquitto), offering publish and subscribe capabilities to other components.

DeviceTwin: It is software mirror for devices that handles the device metadata. This module helps in handling device status and syncing the same to cloud. It also provides query interfaces for applications, as it interfaces to a lightweight database (SQLite).

MetaManager: It manages the metadata at the edge node. This is the message processor between edged and edgehub. It is also responsible for storing/retrieving metadata to/from a lightweight database (SQLite).

Even if you want to add more control plane modules based on the architecture refinement and improvement (for example enhanced security), it is simple as it uses consistent registration and modular communication within these modules.

Release 0.1 to 0.2 – game changer!​

KubeEdge v0.1 was released at the end of December 2018 with very basic edge features to manage edge applications along with Kubernetes API primitives for node, pod, config etc. In ~2 months, KubeEdge v0.2 was release on March 5th, 2019. This release provides the cloud core modules and enables the end to end open source edge computing solution. The cloud core modules can be deployed to any compute node from any cloud vendors or on-prem.

Now, the complete edge solution can be installed and tested very easily, also with a laptop.

Run Anywhere - Simple and Light As described, the KubeEdge Edge and Cloud core components can be deployed easily and can run the user applications. The edge core has a foot print of 66MB and just needs 30MB memory to run. Similarly the cloud core can run on any cloud nodes. (User can experience by running it on a laptop as well)

The installation is simple and can be done in few steps:

• Setup the pre-requisites Docker, Kubernetes, MQTT and openssl
• Clone and Build KubeEdge Cloud and Edge
• Run Cloud
• Run Edge
• The detailed steps for each are available at KubeEdge Setup

Future: Taking off with competent features and community collaboration​

KubeEdge has been developed by members from the community who are active contributors to Kubernetes/CNCF and doing research in edge computing. The KubeEdge team is also actively collaborating with Kubernetes IOT/EDGE WORKING GROUP. Within a few months of the KubeEdge announcement it has attracted members from different organizations including JingDong, Zhejiang University, SEL Lab, Eclipse, China Mobile, ARM, Intel to collaborate in building the platform and ecosystem.

KubeEdge has a clear roadmap for its upcoming major releases in 2019. v1.0 targets to provide a complete edge cluster and device management solution with standard edge to edge communication, while v2.0 targets to have advanced features like service mesh, function service , data analytics etc at edge. Also, for all the features, KubeEdge architecture would attempt to utilize the existing CNCF projects/software.

The KubeEdge community needs varied organizations, their requirements, use cases and support to build it. Please join to make a kubernetes native edge computing platform which can extend the cloud native computing paradigm to edge cloud.

How to Get Involved?​

We welcome more collaboration to build the Kubernetes native edge computing ecosystem. Please join us!

Edge Computing with KubeEdge

Cloud computing is far away from terminal devices (such as cameras, sensors, etc.). For real-time computing requirements, placing calculations on the cloud can cause long network delays, network congestion, and degradation of service quality. Terminal devices usually have insufficient computing power and cannot be compared to the cloud. In this case, edge computing came into being, extending the cloud computing power to the edge nodes close to the terminal device, which perfectly solved the above problem.

As the world's first open source edge computing platform for Kubernetes, KubeEdge relies on Kubernetes' container orchestration and scheduling capabilities to provide the ability to extend the application on the cloud to the edge by managing the edge nodes of the user, and to link the data on the edge side and the cloud to meet the requirements. Customer's remote control, data processing, analysis and decision-making, and intelligent appeal for edge computing resources. At the same time, it provides unified equipment/application monitoring, log collection and other operation and maintenance capabilities in the cloud, providing enterprises with complete edge computing solutions for integrated cloud and cloud services.

Device Health and KubeEdge Device Management

Speaking of IoT devices, one has to mention a concept called Device Twin. As a virtual mapping of IoT device metadata on the application platform, device twinning has become an important part of IoT device management. IoT devices usually contain two types of data: one is metadata that will not be changed, including the serial number, asset identifier, Mac address, etc., and the detailed information describing the device. It can also be called the static attribute of the device. The other type is the dynamic data of the device, including device-specific real-time data in a specific context, such as the on and off state of the lamp, which can also be called the Twin property of the device. Device twins have the same characteristics as physical devices, allowing for better communication between devices and applications. The command sent by the application first arrives at the device, and the device updates the status according to the Expected State set by the application. In addition, the IoT device feeds back its own Actual State in real time, and the device detects both the Actual State and the Expected State of the IoT device. This approach also allows the state of the device to be synchronized when the IoT device goes online again offline.

Device management is also a key feature of IoT scenarios in edge computing. KubeEdge is an open-source edge computing platform with both cloud and edge. In addition to implementing cloud application configuration and delivery, another important function is to manage IoT devices in the cloud and synchronize device state between cloud edges.

KubeEdge Device Management Component

The components related to KubeEdge device management are as follows:

DeviceController: An extended Kubernetes controller that manages device information in the cloud and synchronizes the cloud with edge devices.

CloudHub: The WebSocket server is responsible for monitoring cloud resource changes, caching and sending messages to EdgeHub.

EdgeHub: WebSocket client, including the ability to synchronize cloud resource updates, report edge nodes, and device information to the cloud.

DeviceTwin: Responsible for storing device status and synchronizing device status to the cloud.

EventBus: A client that interacts with the MQTT server Mosquitto to provide subscription and publish messages for other components.

Mapper: Used to connect and control end-side devices, such as turning lights on and off.

KubeEdge extends Kubernetes' API through CRD (Customer Resource Definition). The extended API resources include: Device and DeviceModel, so that we can perform CRUD operations on device resources in the cloud through Kubernetes command line tool Kubectl or other means. The Device resource maps devices associated with each edge node, such as sensors. DeviceModel is a template defined for a class of devices. It is convenient for users to perform batch operations on Device resources easily in the cloud based on the DeviceModel template.

Light up your home with KubeEdge

Light up your home in the clouds, let's see how KubeEdge does this interesting thing? A reference example of a device generation is as follows:

Here you need to use the above mentioned Device Twin. For example, the metadata information of the lamp is described above in Json format, including static attribute attributes and dynamic attribute twin. This defines a twin property called powerstatus, whose expected and actual values can be either ON or OFF. The device itself can report the actual value of the powerstatus to the cloud. The cloud can control the edge side lights to be turned on and off by changing to the expected value of the powerstatus attribute.

First we look at how to report the actual value of the powerstatus to the cloud:

The Mapper reports the actual status of the Actual State to the MQTT server Mosquitto in real time.

The EventBus receives a subscription message from Mosquitto, which contains the actual state of the device, Actual State.

EventBus sends the actual state of the device to Device Twin.

Device Twin updates the device's actual state to a lightweight database local to the edge node, such as SQLite.

Device Twin synchronizes the actual state to the WebSocket client EdgeHub.

EdgeHub sends a message to the WebSocket server CloudHub.

CloudHub returns a message to DeviceController.

DeviceController synchronizes the actual state of the Actual State to the Kubernetes API Server.

Finally, the user can query the actual value of the powerstatus of the device in the cloud to obtain the actual state of the light on and off on the edge device.

Join KubeEdge

Device management is undoubtedly a key feature in the edge computing IoT scenario. Currently, KubeEdge's device management features are still under development and will be released in version 0.3, so stay tuned.

As a 100% open source project, KubeEdge welcomes you. KubeEdge Github project address: Https://github.com/kubeedge/kubeedge

KubeEdge is an open source system extending native containerized application orchestration and device management to hosts at the Edge. It is built upon Kubernetes and provides core infrastructure support for networking, application deployment and metadata synchronization between cloud and edge. It also supports MQTT and allows developers to author custom logic and enable resource constrained device communication at the Edge.

Today we announce the v0.2 release of KubeEdge.​

Features added​

• Edge-controller which connects to Kubernetes api-server and sync node/pod status between edge and Kubernetes api-server.
• Cloudhub which is a websocket server in cloud part of KubeEdge.
• Internal MQTT mode in which MQTT broker is started with edge_core and removes dependency on external MQTT broker.
• Integration test framework for edge. Improved edge_core unit-test coverage.

Known issues​

• We do not have any e2e tests yet.
• Unit tests coverage should be improved for cloud part.

Features Work In Progress (Future release)​

• Describe device API via CRD.
• Edge to Edge Communication.
• Different Protocol support for KubeEdge like BLE, Zigbee,etc