17 篇博文 含有标签「kubernetes edge computing」

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

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!