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.

KubeEdge v1.3: A major upgrade for maintainability​

On May 15th, the KubeEdge community is proud to announce the availability of KubeEdge 1.3. This release includes a major upgrade for maintainability, which includes:

• Collecting logs from pods at edge in cloud

• Edge node and container monitoring

• High availability of KubeEdge cloud components

• Automated TLS bootstrapping for edge nodes

• CRI-O and Kata Containers runtime support

• 25+ bug fixes and enhancements.

Please refer to https://github.com/kubeedge/kubeedge/blob/master/CHANGELOG-1.3.md for a full list of features in this release

Release Highlights​

Collecting logs from pods at edge in cloud​

In most edge computing scenarios, the edge node is in a private network, and the pod logs running on the edge node cannot be directly pulled from the cloud, resulting issues for maintenance and debugging.

KubeEdge v1.3 includes a built-in streaming data channel which enables cloud to easily obtain edge application container logs via the kubectl logs command, without having to build another VPN server to solve private network access problems.

In addition, the KubeEdge community plans to provide a kubectl exec command support for edge containers in subsequent versions, so that users can easily connect to the edge application container from the cloud for debugging purposes.

See more feature details: https://docs.kubeedge.io/en/latest/setup/kubeedge_install_source.html

Edge node and container monitoring​

KubeEdge v1.3 provides a monitoring interface for edge nodes. Users can obtain edge node and its container information, and integrate it with third-party monitoring systems. This feature is enabled by default. Users have the option to disable this built-in monitoring module through the EnableMetrics item during configuration.

In the next version, KubeEdge will support the aggregation of edge node and application container monitoring information in the cloud.

See more feature details: https://github.com/kubeedge/kubeedge/pull/1573

High availability of KubeEdge cloud components​

In previous releases, the availability of KubeEdge cloud components rely on the automatic recovery mechanism of Kubernetes Deployment. In some extreme cases, this recovery can take a long time to recover from failures.

KubeEdge v1.3 has a built-in high-availability for the KubeEdge cloud component, CloudCore. When the CloudCore instance fails, a standby CloudCore instance is automatically switched on to minimize the impact of cloud component failures.

In subsequent versions, the KubeEdge community will further optimize the high concurrency of cloud components to improve throughput in large-scale edge nodes scenarios.

Automated TLS bootstrapping for edge nodes​

KubeEdge v1.3 introduced automated TLS bootstrapping for edge nodes, which simplifies the operation for users to configure cloud-edge secure channels and improves ease-of-use.

By default, KubeEdge generates a self-signed certificate for users, which is used for encrypted communication between cloud components and edge nodes. For scenarios that require an unified management of certificates, users can also use certificates issued by designated trust authorities.

For future releases, the KubeEdge community will support automatic renewal of the node's certificate after expiration.

See more feature details: https://github.com/kubeedge/kubeedge/blob/master/docs/setup/kubeedge_configure.md

More container runtime support​

KubeEdge v1.3 adds support of CRI-O and Kata Containers as container runtime.

• CRI-O, a CNCF incubation project, is a lightweight container, taking up to 30MB memory, and is in compliance with OCI standards.

• Kata Containers is an open source container runtime based on lightweight virtual machines. It is designed to combine the security advantages of virtual machines (VMs) with the speed and the manageability of containers.

With v1.3, KubeEdge has official support for all mainstream container runtimes including Docker, containerd, CRI-O and Kata Containers.

See more feature details: https://github.com/kubeedge/kubeedge/blob/master/docs/setup/kubeedge_cri_configure.md

25+ bug fixes and enhancements​

In addition to the above new features, KubeEdge v1.3 also includes the following enhancements:

• Added the support for keadm to install KubeEdge on CentOS systems

• EdgeMesh no longer depends on initContainer, and will take over traffic on the host during startup

• Fixed the issue that some pods in “the terminating state” cannot be deleted

Future Outlook​

With the release of v1.3, KubeEdge provides more complete edge application monitoring and management capabilities, a more stable and reliable cloud-side collaborative transmission mechanism, a more friendly user experience, and a more friendly community contributor experience. Thanks to Huawei, China Unicom, Zhejiang University SEL Lab, ARM and other organizations for their contributions, as well as all community contributors for their support!

The community plans to further improve the user experience and the stability of KubeEdge in subsequent versions and create the best “open source” intelligent edge computing platform for everyone to freely use. Please refer to the roadmap document for future release plans:

https://github.com/kubeedge/kubeedge/blob/master/docs/getting-started/roadmap.md

For more details regarding KubeEdge, please follow and join us here:

https://kubeedge.io

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 v1.2 release of KubeEdge.​

On February 9th, the KubeEdge community is proud to announce the availability of KubeEdge 1.2. This release includes a major upgrade on reliability, which includes more reliable message delivery from cloud to edge, component Config API, edge nodes auto-registration, Kubernetes v1.17.1 support, and 30+ fixes.

Please refer to https://github.com/kubeedge/kubeedge/blob/release-1.2/CHANGELOG-1.2.md for a full list of features in this release, and the following for some highlights.

A major upgrade on Cloud-Edge transmission reliability​

In an Edge Computing scenario, the instability of edge network could cause the reliability issues of edge’s communication to cloud, which could further cause data loss during communication. To improve Cloud-Edge transmission reliability, KubeEdge v1.2 includes following update：

1. Added a verification mechanism for application layer message sending. There is a handshake mechanism built in to acknowledge (via ACK message) the successful state synchronization between cloud and edge. If the acknowledgement fails due to some reason, the application layer loop will trigger the retransmission mechanism to re-synchronize the state.
2. Implemented persistent cloud side collaborative messages. During the cloud-edge status synchronization process, cloud will record in real time the latest message version number (ResourceVersion) of each edge node that is successfully synchronized, and persist it to Kubernetes in the form of CRD. This mechanism can ensure the order and the continuity of message after a cloud failure or an edge node offline restart, avoiding cloud/edge inconsistent status caused by resending old messages.
3. Implemented a periodic check for cloud-edge data to ensure consistency. Based on the above two features, KubeEdge 1.2 includes a new module that synchronizes Controller to CloudCore. This module periodically checks the synchronization status of edge nodes, compares the information of resources in Kubernetes, and synchronizes states, and ensure the ultimate state consistency between cloud and edge.

See more details here: https://github.com/kubeedge/kubeedge/blob/master/docs/proposals/reliable-message-delivery.md

Component Config API​

An important improvement that KubeEdge v1.2 offers is the ability to update configuration of all components such as CloudCore, EdgeCore, EdgeSite, etc. by using the Kubernetes style Component Config API, and API versions to support backward compatibility.

In previous KubeEdge versions, the configuration of KubeEdge components were scattered in separate files for each module, so the maintenance was cumbersome. In this release, the team has aggregated all configurations, so users need to only update a configuration file, and the path of the configuration file can be easily set by using "- -config".

This release also offers two options for configuration: default configuration and minimum configuration. Users can use either option to generate configuration files and deploy KubeEdge quickly.

See more details here: https://github.com/kubeedge/kubeedge/pull/1172

Edge Nodes Auto-registration​

In previous versions, users needed to create a Node object on the cloud side first, and then start EdgeCore on the edge side when adding an edge node.

In release v1.2, KubeEdge provides the ability of automating edge node registration on the cloud side. This feature is enabled by default to improve ease of use. Users can turn it off by setting the "registerNode" configuration of EdgeCore to "false".

See more details here: https://github.com/kubeedge/kubeedge/pull/1401

Kubernetes v1.17.1 support​

KubeEdge v1.2 supports Kubernetes v1.17.1, so users can use the most recent Kubernetes application management, storage management etc.

Here is the full compatibility table: https://github.com/kubeedge/kubeedge

Other Fixes​

• Fixed CPU usage issues when EdgeCore runs multiple PODs
• Moved Beehive, Viaduct sub-projects under Staging directory for more friendly development experience
• More checks to insure EdgeCore and Kubelet are not running on the same host

Summary​

KubeEdge V1.2 offers a more stable and reliable cloud-edge transmission, enhanced edge application management and device management capabilities, a better user experience, and a more friendly community contributor experience.

A big “thank you” to all the community contributors and we hope to continue this momentum. Future releases of KubeEdge will further enhance KubeEdge user experience, better intelligent edge computing platform, and other advanced features to make KubeEdge a high performing, reliable, and intelligent solution to Connect Cloud to Edge.

For more details regarding KubeEdge, please follow and join us here: https://kubeedge.io .

We are very pleased to share that we received a very good response from community for KubeEdge contribution competition that started on 23rd April 2019. Participants were given challenge to either fix issues, raise issues, add code towards feature development, requirement identification, promote KubeEdge by writing blogs or create a sample application using KubeEdge. During this period 156 commits and 66 issues were added in the repository. We thank all the community members for making this event a grand success. We believe that community will continue contributions to KubeEdge with same enthusiasm in the future as well. Each and every contribution is of great worth and to honor top contributors KubeEdge team have selected below members as winners of this competition.

Hearty Congratulations to all the winners. We will reach out to the winners soon via email.

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