Category

Akraino

Where the Edges Meet: Public Cloud Edge Interface

By Akraino, Akraino Edge Stack, Blog

Written by Oleg Berzin, Ph.D., a member of the Akraino Technical Steering Committee and Senior Director Technology Innovation at Equinix

Introduction

Why 5G

5G will provide significantly higher throughput than existing 4G networks. Currently, 4G LTE is limited to around 150 Mbps. LTE Advanced increases the data rate to 300 Mbps and LTE Advanced Pro to 600Mbps-1 Gbps. The 5G downlink speeds can be up to 20 Gbps. 5G can use multiple spectrum options, including low band (sub 1 GHz), mid-band (1-6 GHz) and mmWave (28, 39 GHz). The mmWave spectrum has the largest available contiguous bandwidth capacity (~1000 MHz) and promises dramatic increases in user data rates. 5G enables advanced air interface formats and transmission scheduling procedures that decrease access latency in the Radio Access Network by a factor of 10 compared to 4G LTE.

The Slicing Must Go On

Among advanced properties of the 5G architecture, Network Slicing enables the use of 5G network and services for a wide variety of use cases on the same infrastructure. Network Slicing (NS) refers to the ability to provision a common physical system to provide resources necessary for delivering service functionality under specific performance (e.g. latency, throughput, capacity, reliability) and functional (e.g. security, applications/services) constraints.

Network Slicing is particularly relevant to the subject matter of the Public Cloud Edge Interface (PCEI) Blueprint. As shown in the figure below, there is a reasonable expectation that applications enabled by the 5G performance characteristics will need access to diverse resources. This includes conventional traffic flows, such as access from mobile devices to the core clouds (public and/or private) as well as the general access to the Internet, edge traffic flows, such as low latency/high speed access to edge compute workloads placed in close physical proximity to the User Plane Functions (UPF), as well as the hybrid traffic flows that require a combination of the above for distributed applications (e.g. online gaming, AI at the edge, etc). One point that is very important is that the network slices provisioned in the mobile network must extend beyond the N6/SGi interface of the UPF all the way to the workloads running on the edge computing hardware and on the Public/Private Cloud infrastructure. In other words, “The Slicing Must Go On” in order to ensure continuity of intended performance for the applications.


The Mobile Edge

The technological capabilities defined by the standards organizations (e.g. 3GPP, IETF) are the necessary conditions for the development of 5G. However, the standards and protocols are not sufficient on their own. The realization of the promises of 5G depends directly on the availability of the supporting physical infrastructure as well as the ability to instantiate services in the right places within the infrastructure.

Latency can be used as a very good example to illustrate this point. One of the most intriguing possibilities with 5G is the ability to deliver very low end to end latency. A common example is the 5ms round-trip device to application latency target. If we look closely at this latency budget, it is not hard to see that to achieve this goal a new physical aggregation infrastructure is needed. This is because the 5ms budget includes all radio/mobile core, transport and processing delays on the path between the application running on User Equipment (UE) and the application running on the compute/server side. Given that at least 2ms will be required for the “air interface”, the remaining 3ms is all that’s left for the radio/packet core processing, network transport and the compute/application processing budget. The figure below illustrates an example of the end-to-end latency budget in a 5G network.

The Edge-in and Cloud-out Effect

Public Cloud Service Providers and 3rd-Party Edge Compute (EC) Providers are deploying Edge instances to better serve their end-users and applications, A multitude of these applications require close inter-working with the Mobile Edge deployments to provide predictable latency, throughput, reliability, and other requirements.

The need to interface and exchange information through open APIs will allow competitive offerings for Consumers, Enterprises, and Vertical Industry end-user segments. These APIs are not limited to providing basic connectivity services but will include the ability to deliver predictable data rates, predictable latency, reliability, service insertion, security, AI and RAN analytics, network slicing, and more.

These capabilities are needed to support a multitude of emerging applications such as AR/VR, Industrial IoT, autonomous vehicles, drones, Industry 4.0 initiatives, Smart Cities, Smart Ports. Other APIs will include exposure to edge orchestration and management, Edge monitoring (KPIs), and more. These open APIs will be the foundation for service and instrumentation capabilities when integrating with public cloud development environments.

Public Cloud Edge Interface (PCEI)

Overview

The purpose of Public Cloud Edge Interface (PCEI) Blueprint family is to specify a set of open APIs for enabling Multi-Domain Inter-working across functional domains that provide Edge capabilities/applications and require close cooperation between the Mobile Edge, the Public Cloud Core and Edge, the 3rd-Party Edge functions as well as the underlying infrastructure such as Data Centers, Compute hardware and Networks. The Compute hardware is optimized and power efficient for Edge such as the Arm64 architecture.

The high-level relationships between the functional domains are shown in the figure below:

The Data Center Facility (DCF) Domain. The DCF Domain includes Data Center physical facilities that provide the physical location and the power/space infrastructure for other domains and their respective functions.

The Interconnection of Core and Edge (ICE) Domain. The ICE Domain includes the physical and logical interconnection and networking capabilities that provide connectivity between other domains and their respective functions.

The Mobile Network Operator (MNO) Domain. The MNO Domain contains all Access and Core Network Functions necessary for signaling and user plane capabilities to allow for mobile device connectivity.

The Public Cloud Core (PCC) Domain. The PCC Domain includes all IaaS/PaaS functions that are provided by the Public Clouds to their customers.

The Public Cloud Edge (PCE) Domain. The PCE Domain includes the PCC Domain functions that are instantiated in the DCF Domain locations that are positioned closer (in terms of geographical proximity) to the functions of the MNO Domain.

The 3rd party Edge (3PE) Domain. The 3PE domain is in principle similar to the PCE Domain, with a distinction that the 3PE functions may be provided by 3rd parties (with respect to the MNOs and Public Clouds) as instances of Edge Computing resources/applications.

Architecture

The PCEI Reference Architecture and the Interface Reference Points (IRP) are shown in the figure below. For the full description of the PCEI Reference Architecture please refer to the PCEI Architecture Document.

Use Cases

The PCEI working group identified the following use cases and capabilities for Blueprint development:

  1. Traffic Steering/UPF Distribution/Shunting capability — distributing User Plane Functions in the appropriate Data Center Facilities on qualified compute hardware for routing the traffic to desired applications and network/processing functions/applications.
  2. Local Break-Out (LBO) – Examples: video traffic offload, low latency services, roaming optimization.
  3. Location Services — location of a specific UE, or identification of UEs within a geographical area, facilitation of server-side application workload distribution based on UE and infrastructure resource location.
  4. QoS acceleration/extension – provide low latency, high throughput for Edge applications. Example: provide continuity for QoS provisioned for subscribers in the MNO domain, across the interconnection/networking domain for end-to-end QoS functionality.
  5. Network Slicing provisioning and management – providing continuity for network slices instantiated in the MNO domain, across the Public Cloud Core/Edge as well as the 3Rd-Party Edge domains, offering dedicated resources specifically tailored for application and functional needs (e.g. security) needs.
  6. Mobile Hybrid/Multi-Cloud Access – provide multi-MNO, multi-Cloud, multi-MEC access for mobile devices (including IoT) and Edge services/applications
  7. Enterprise Wireless WAN access – provide high-speed Fixed Wireless Access to enterprises with the ability to interconnect to Public Cloud and 3rd-Party Edge Functions, including the Network Functions such as SD-WAN.
  8. Distributed Online/Cloud Gaming.
  9. Authentication – provided as service enablement (e.g., two-factor authentication) used by most OTT service providers 
  10. Security – provided as service enablement (e.g., firewall service insertion)

The initial focus of the PCEI Blueprint development will be on the following use cases:

  • User Plane Function Distribution
  • Local Break-Out of Mobile Traffic
  • Location Services

User Plane Function Distribution and Local Break-Out

The UPF Distribution use case distinguishes between two scenarios:

  • UPF Interconnection. The UPF/SPGW-U is located in the MNO network and needs to be interconnected on the N6/SGi interface to 3PE and/or PCE/PCC.
  • UPF Placement. The MNO wants to instantiate a UPF/SPGW-U in a location that is different from their network (e.g. Customer Premises, 3rd Party Data Center)

UPF Interconnection Scenario

UPF Placement Scenario

UPF Placement, Interconnection and Local Break-Out Examples

Location Services (LS)

This use case targets obtaining geographic location of a specific UE provided by the 4G/5G network, identification of UEs within a geographical area as well as facilitation of server-side application workload distribution based on UE and infrastructure resource location.

 

Acknowledgements

Project Technical Lead: Oleg Berzin

Committers: Suzy GuTina Tsou Wei Chen, Changming Bai, Alibaba; Jian Li, Kandan Kathirvel, Dan Druta, Gao Chen, Deepak Kataria, David Plunkett, Cindy Xing

Contributors: Arif , Jane Shen, Jeff Brower, Suresh Krishnan, Kaloom, Frank Wang, Ampere

LF Edge Member Spotlight: HPE

By Akraino, Akraino Edge Stack, Blog, Member Spotlight

The LF Edge community is represents a diverse set of member companies and people that represent the IoT, Enterprise, Cloud and Telco Edge. The Member Spotlight blog series highlights these members and how they are contributing to and leveraging open source edge solutions. Today, we sat down with Rohit Arora, Enterprise Architect at Hewlett Packard Enterprise (HPE) to discuss the importance of open source, leading Multi Access Edge Computing (MEC) initiatives, participating in the Technical Advisory Committee (TAC) and collaborating with the LF Edge ecosystem.

Can you tell us a little about your organization?

HPE is a global, edge-to-cloud Platform-as-a-Service company. HPE solutions connect, protect, analyze, and act on data and applications wherever they live, from edge to cloud, so insights can be turned into outcomes at the speed required to thrive in today’s complex world.

Why is your organization adopting an open source approach?

We at HPE believe in innovation and open source encourages innovation by bringing communities together to build common platform. HPE has been involved in various open source projects.

Why did you join LF Edge and what sort of impact do you think LF Edge has on the edge, networking, and IoT industries?

We joined LF edge because it aligns with HPE’s direction of edge to cloud. Edge computing is creating a major transformation in most industries and we believe initiatives driven by LF edge are critical for this digital transformation

What do you see as the top benefits of being part of the LF Edge community?

There are many benefits of being part of LF edge but we believe the biggest is to be part of a community which is driving the innovation for the next gen networks at the edge.

What sort of contributions has your team made to the community, ecosystem through LF Edge participation?

HPE has contributions on the LF Edge Governing Board and TAC, HPE has also made some contributions to the infrastructure requirements for LF Edge. HPE is also actively involved in LF edge projects such as Akraino and process adoption.

What do you think sets LF Edge apart from other industry alliances?

There are two main reasons LF Edge is different from other industry alliances

  1. A wide set of different community members: There is a wide variety of community members in LF edge from telco services providers, NEPs to chip manufacturers. This provides different viewpoints and provides the right level of expertise that is needed.
  2. Projects execution: The community really believes in executing and we have seen some projects coming from idea to development and then testing at a very fast pace.

How will  LF Edge help your business?

HPE is leading infrastructure provider and have wide variety of solutions for the edge. We are also leading MEC (Multi Access Edge Computing) initiatives with some major telcos. By being part of LFEdge we get access to latest innovations and resources in edge computing. This can help us build our solution to fit industry needs.

What advice would you give to someone considering joining LF Edge?

There are so many projects LF Edge is driving, the best place to start would be to pick a project which aligns with your company’s directions and see how you can drive innovation with your contributions for the project. There are many resources available and all the community members are very helpful to provide any info you need.

To find out more about LF Edge members or how to join, click here.

Additionally, if you have questions or comments, visit the  LF Edge Slack to share your thoughts and engage with community members. 

 

Akraino’s AI Edge-School/Education Video Security Monitoring Blueprint

By Akraino, Akraino Edge Stack, Blog, Use Cases

Written by Hechun Zhang, Staff Systems Engineer, Baidu; Akraino TSC member, and PTL of the AI Edge Blueprint; and Tina Tsou, Enterprise Architect, Arm and Akraino TSC Co-Chair

In order to support end-to-end edge solutions from the Akraino community, Akraino uses blueprint concepts to address specific Edge use cases. A Blueprint is a declarative configuration of the entire stack i.e., edge platform that can support edge workloads and edge APIs. In order to address specific use cases, a reference architecture is developed by the community.

The School/Education Video Security Monitoring Blueprint belongs to the AI Edge Blueprint family. It focuses on establishing an open source MEC platform that combined with AI capacities at the Edge. In this blueprint, latest technologies and frameworks like micro-service framework, Kata container, 5G accelerating, and open API have been integrated to build a industry-leading edge cloud architecture that could provide comprehensive computing acceleration support at the edge. And with this MEC platform, Baidu has expanded AI implementation across products and services to improve safety and engagement in places such as factories, industrial parks, catering services, and classrooms that rely on AI-assisted surveillance.

Value Proposition

  • Establish an open-source edge infrastructure on which each member company can develop its own AI applications, e.g. video security monitoring.
  • Contribute use cases which help customers adopt video security monitoring, AI city, 5G V2X, and Industrial Internet applications.
  • Collaborate with members who can work together to figure out the next big thing for the industry.

Use cases

Improved Student-Teacher Engagement

 

Using deep learning model training for video data from classrooms, school management can evaluate class engagement and analyze individual student concentration levels to improve real-time teaching situations.

Enhanced Factory Safety and Protection

Real-time monitoring helps detecting factory workers who might forget security gadgets, such as helmets, safety gloves, and so on, to prevent hazardous accidents in the workplace. Companies can monitor safety in a comprehensive and timely way, and used findings as a reference for strengthening safety management.

Reinforced Hygiene and Safety in Catering

Through monitoring staff behavior in the kitchen, such as smoking breaks and cell phone use, this solution ensures the safety and hygiene of the food production process.

Advanced Fire Detection and Prevention

Linked and networked smoke detectors in densely populated places, such as industrial parks and community properties, can help quickly detect and alert authorities to fire hazards and accidents.

Network Architecture

OTE-Stack is an edge computing platform for 5G and AI. By virtualization it can shield heterogeneous characteristics and gives a unified access of cloud edge, mobile edge and private edge. For AI it provides low-latency, high-reliability and cost-optimal computing support at the edge through the cluster management and intelligent scheduling of multi-tier clusters. And at the same time OTE-Stack makes device-edge-cloud collaborative computing possible.

Baidu implemented video security monitoring blueprints on the Arm infrastructure, including cloud-edge servers, hardware accelerators, and custom CPUs designed for world-class performance. Arm and Baidu are members of the Akraino project and use edge cloud reference stack of networking platforms and cloud-edge servers built on Arm Neoverse. The Arm Neoverse architecture supports a vast ecosystem of cloud-native applications and combines AI Edge blueprint for an open source mobile edge computing (MEC) platform optimized for sectors such as safety, security, and surveillance.

“Open source has now become one of the most important culture and strategies respected by global IT and Internet industries. As one of the world’s top Internet companies, Baidu has always maintained an enthusiastic attitude in open source, actively contributing the cutting edge products and technologies to the Linux foundation. Looking towards the future, Baidu will continue to adhere to the core strategy of open source and cooperate with partners to build a more open and improved ecosystem.” — Ning Liu, Director of AI Cloud Group, Baidu

In the 5G era, OTE-Stack has obvious advantages in the field of edge computing:

  • Large scale and hierarchical cluster management
  • Support third cluster
  • Lightweight cluster controller
  • Cluster autonomy
  • Automatic disaster recovery
  • Global scheduling
  • Support multi-runtimes
  • Kubernetes native support

For more information about this Akraino Blueprint, click here.  For general information about Akraino Blueprints, click here.

MicroMEC now available with the Akraino R3 Release!

By Akraino, Akraino Edge Stack, Blog

Written by Tapio Tallgren, Technical Leader at Nokia Mobile Networks, Community Sub-Committee Chair of Akraino TSC,Ferenc Szekely, Program Manager, SUSE, Committer of Micro MEC blueprint of Akraino TSC and Tina Tsou, Enterprise Architect, Arm, Akraino TSC Co-Chair

The MicroMEC platform started life as a platform to run applications at the very edge of the network, like in a light pole. We joined the LF Edge’s Akraino project from the very beginning.

To find out what the use cases would be first, we participated in the IoThon hackathon in 2019 where we built a miniature city with sensors, cameras and small servers — also known as Raspberry Pis. Our plan was that we will provide APIs to enable developers to access the sensors, cameras, or other independent hardware devices attached to our small servers, ie. the MicroMEC nodes. It was clear that we wanted to deploy all the APIs as well as the apps in containers. We needed a tool like Kubernetes to help us build and manage the MicroMEC cluster. As we targeted “small” devices, with max 4GB of RAM -at that time- and low power consumption we looked into alternatives to k8s. That is how we picked k3s. 

By the autumn of 2019 we had our lab running Raspberry Pi 3B+ and 4B nodes with k3s. We had a successful hackathon – Junction 2019 – in Finland where the teams presented solutions utilizing the MicroMEC cluster. We also added OpenFaaS Cloud (OFC) into the mix and a developer UI to the platform. This allowed developers to write serverless applications for the MicroMEC cluster and deploy them with ease. They could concentrate on their core business: developing apps while MicroMEC with OFC took away the burden of cluster management, deployment etc.

Right after Junction, we were at the Akraino 5G MEC Hackathon in the USA. For this event MicroMEC had to become more “MEC”. This implied the implementation of MEC-11 interfaces and the UI to manage those apps that our MEC-11 implementation made discoverable for customers near the MicroMEC cluster. The MEC cluster runs on Arm architecture based hardware.

With all this activity, we missed the first two Akraino releases, but now we are very happy to join the Akraino R3 release! For this, we had to figure out what is the easiest way to install the stack on the device with a MMC card. The easiest way is to not install anything on the fragile card, but boot the stack from a network server. Eventually we made all MicroMEC nodes to boot from a network server using PXE and the storage of each node was attached via iscsi. This requires a fast enough LAN, but thankfully cheap gigabit switches are widely available these days. 

Learn more about Akraino here.

 

LF Edge’s Akraino Project Release 3 Now Available, Unifying Open Source Blueprints Across MEC, AI, Cloud and Telecom Edge

By Akraino, Announcement, LF Edge

    • 6 New R3 Blueprints (total of 20)  covering use cases across Telco, Enterprise, IoT, Cloud and more
    • Akraino Blueprints cover areas including MEC, AI/ML, Cloud, Connected Vehicle, AR/VR, Android Cloud Native, smartNICs, Telco Core & Open- RAN, with — ongoing support for R1-R2 blueprints and more
    • Community delivers open edge API specifications — to standardize across devices, applications (cloud native), orchestrations,  and multi-cloud — via new white paper

SAN FRANCISCO  August 12, 2020LF Edge, an umbrella organization within the Linux Foundation that aims to establish an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating system, today announced the availability of Akraino Release 3 (“Akraino R3”).  Akraino’s third and most mature release to date delivers fully functional edge solutions– implemented across global organizations– to enable a diversity of edge deployments across the globe. New blueprints include a focus on  MEC, AI/ML, and Cloud edge. In addition, the community authored the first iteration of a new white paper to bring common open edge API standards to align the industry.

Launched in 2018, and now a Stage 3 (or “Impact” stage) project under the LF Edge umbrella, Akraino Edge Stack delivers an open source software stack that supports a high-availability cloud stack optimized for edge computing systems and applications. Designed to improve the state of carrier edge networks, edge cloud infrastructure for enterprise edge, and over-the-top (OTT) edge, it enables flexibility to scale edge cloud services quickly, maximize applications and functions supported at the edge, and to improve the reliability of systems that must be up at all times. 

“Akraino has evolved to unify edge blueprints across use cases,” said Arpit Joshipura, general manager, Networking, Automation, Edge and IoT, the Linux Foundation. “With a growing set of blueprints that enable more and more use cases, we are seeing the power of open source impact every aspect of the edge and how the world accesses and consumes information.”  

About Akraino R3

Akraino Release 3 (R3) delivers a fully functional open source edge stack that enables a diversity of edge platforms across the globe. With R3, Akraino brings deployments and PoCs from a swath of global organizations including Aarna Networks, China Mobile, Equinix, Futurewei, Huawei, Intel, Juniper, Nokia, NVIDIA, Tencent, WeBank, WiPro, and more.

Akraino enables innovative support for new levels of flexibility that scale 5G, industrial IoT, telco, and enterprise edge cloud services quickly, by delivering community-vetted and tested edge cloud blueprints to deploy edge services.  New use cases and new and existing blueprints provide an edge stack for Connected Vehicle, AR/VR, AI at the Edge, Android Cloud Native, SmartNICs, Telco Core and Open-RAN, NFV, IOT, SD-WAN, SDN, MEC, and more. 

 Akraino R3 includes  6 new blueprints for a total of 20,  all tested and validated on real hardware labs supported by users and community members — the Akraino community has established a full-stack, automated testing with strict community standards to ensure high-quality blueprints. 

The 20 “ready and proven” blueprints include both updates and long-term support to existing R1 & R2 blueprints, and the introduction of six new blueprints:

      • The AI Edge – School/Education Video Security Monitoring 
      • 5G MEC/Slice System–  Supports Cloud Gaming, HD Video, and Live Broadcasting
      • Enterprise Applications on Lightweight 5G Telco Edge (EATLEdge)
      • Micro-MEC (Multi-access Edge Computing) for SmartCity Use Cases
      • IEC Type 3: Android Cloud Native Applications on Arm®-based  Servers on the Edge 
      • IEC Type 5: Smart NIC: Edge hardware acceleration 

More information on Akraino R3, including links to documentation, code, installation docs for all Akraino Blueprints from R1-R3, can be found here. For details on how to get involved with LF Edge and its projects, visit https://www.lfedge.org/

API  White Paper

The Akraino community published the first iteration of a  new white paper to bring common open edge API standards to the industry. The new white paper makes available, for the first time, generic edge APIs for developers to standardize across devices, applications (cloud native), orchestrations,  and multi-cloud. The paper serves as a stepping stone for broad industry alignment on edge definitions, use cases, APIs. Download the paper here: https://www.lfedge.org/wp-content/uploads/2020/06/Akraino_Whitepaper.pdf

Looking Ahead

The community is already planning R4, which will include more implementation of open edge API guidelines, more automation of testing, increased alliance with upstream and downstream communities, and development of public cloud standard edge interfaces. Additionally, the community is expecting new blueprints as well as additional enhancements to existing blueprints. 

Don’t miss the Open Networking and Edge Summit (ONES) virtual event happening September 28-29, where Akraino and other LF Edge communities will collaborate on the latest open source edge developments. Registration is now open!

Ecosystem Support for Akraino R3

Arm
“The demands on compute, networking, and storage infrastructure are changing significantly as we connect billions of intelligent devices, many of which live at the edge of the 5G network,” said Kevin Ryan, senior director of software ecosystem development, Infrastructure Line of Business, Arm. “By working closely with the Akraino community on the release of Akraino R3, and through our efforts with Project Cassini for seamless cloud-native deployments, Arm remains committed to providing our partners with full- edge solutions primed to take on the 5G era.”

AT&T 
Mazin Gilbert, VP of Technology and Innovation, AT&T, said: “As a founding member of the Akraino platform, AT&T has seen first-hand the remarkable progress as a result of openness and industry collaboration. AI and edge computing are essential when it comes to creating an intelligent, autonomous 5G network, and we’re proud to work together with the community to deliver the best possible solutions for our customers.”

Baidu
In the 5G era, AI+ Edge Computing is not only an important guarantee for updating the consumer and industrial Internet experience (such as video consumption re-upgrading, scene-based AI capabilities, etc.), but also a necessary infrastructure for the development of the Internet industry,” said Ning Liu, Director of AI Cloud Group, Baidu. “Providing users with AI-capable edge computing platforms, products and services is one of Baidu’s core strategies. Looking towards the future, Baidu will continue to adhere to the core strategy of open source and cooperate with partners to build a more open and improved ecosystem.” 

China Unicom
“Commercial 5G is going live around the world. Edge computing will play an important role for large bandwidth and low delay services in the 5G era. The key to the success of edge computing is to provide integrated ICT PaaS capabilities, which is beneficial for the collaboration between networks and services, maximizing the value of 5G,” said Xiongyan Tang, Chief Scientist and CTO of the Network Technology Research Institute of China Unicom. “The PCEI Blueprint will define a set of open and common APIs, to promote the deep cooperation between operators and OTTs, and help to build a unified network edge ecosystem.”  

Huawei 
“High bandwidth, low latency, and massive connections are 5G typical features. Based on MEC’s edge computing and open capabilities, 5G network could build the connection, computing, and capabilities required by vertical industries and enables many applications. In the future, 5G MEC will be an open system that provides an application platform with rich atomic capabilities,” said by Bill Ren, Huawei Chief Open Source Liaison Officer. “Managing a large number of applications and devices on the MEC brings great challenges and increases learning costs for developers. We hope to make 5G available through open source, so that more industry partners and developers can easily develop and invoke 5G capabilities. Build a common foundation for carriers’ MEC through open source to ensure the consistency of open interfaces and models. Only in this way can 5G MEC bring tangible benefits to developers and users.”

Juniper Networks
“Juniper Networks is proud to have been an early member of the Akraino community and supportive of this important work. We congratulate this community for introducing new blueprints to expand the use cases for managed edge cloud with this successful third release,” said Raj Yavatkar, Chief Technology Officer at Juniper Networks. “Juniper is actively involved in the integration of multiple blueprints and we look forward to applying these solutions to evolve edge cloud and 5G private networks to spur new service innovations – from content streaming to autonomous vehicles.”

Tencent
“The new generation network is coming, IoT and Edge Computing are developing rapidly. At the same time, it also brings great challenges to technological innovation. High performance, low latency, high scalability, large-scale architecture is a must for all applications. TARS has released the latest version to meet the adjustment of 5G and Edge Computing. Massive devices can easily use TARS Microservice Architecture to realize the innovation of edge applications. The Connect Vehicle Blueprint and AR/VR Blueprint in Akraino are all using the TARS Architecture,” said Mark Shan, Chairman of Tencent Open Source Alliance, Chairman of TARS Foundation, and Akraino TSC Member. “The blueprints on the TARS Architecture solve the problem of high throughput and low latency. TARS is a neutral project in the Linux Foundation, which can be easily used and helped by anyone from the open-source community.”

Zenlayer
“We are proud to be part of the Edge Cloud community. Zenlayer is actively exploring edge solutions and integrating the solutions to our bare metal product. We hope the edge products will empower rapid customer innovation in video streaming, gaming, enterprise applications and more,” said Jim XU, chief engineering architect of Zenlayer.

About the Linux Foundation
Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

EdgeX Foundry on ELIOT Blueprint

By Akraino, Blog, EdgeX Foundry, LF Edge

Written by Ramya Ranganathan, IOTG Validation Architect at Intel and EdgeX Foundry TSC member and EdgeX Test/QA WG Contributor

 

Background

In the recent past, EdgeX has experience challenges in running regression tests on different platforms. Some of the difficulty has been attributed to not running the EdgeX platform tests on While it could be attributed to a pre-validated OS/SW configuration.

Idea

By running on a pre-validated base platform, the hope was to eliminate the platform variabilities and limit the debug scope to EdgeX SW. This in turn would lead to a quicker debug, throughput and finally quicker time to market.

Why LF Edge Akraino Blue Print

Since LF Edge has been spearheading the Akraino Blue print effort to provide a holistic design of EdgeX suitable platforms with respect to scalability, availability, security using finite set of configurations, and ease of use by Zero-touch provisioning, a proposal was put forth by EdgeX QA/Test work group to use a light weight Akraino blue print as “pre-validated base platform” for EdgeX engineering activities. The motivation was that the team could leverage the results from Akraino’s blue print validation framework and use it as a stable base platform for EdgeX engineering activities. While the motivation was from within the EdgeX community, this also served as a testimony to LF Edge’s Akraino initiative and to the importance of the LF Edge umbrella project to provide wholistic solutions to the EdgeX and larger LF Edge communities.

Engineering Activity & Results

Akraino offers several Blue prints, so the first task was to identify the right blueprint for EdgeX needs. ELIOT blue print has been chosen by the EdgeX QA/Test WG for this initial feasibility study as it seems to have a light weight foot print as the name suggests and also it is supported on both ARM and x86 architectures. EdgeX QA/Test WG members got LF Edge accounts and access to the Thunder Pod2 ARM based system and were able to get the EdgeX tests up and running on ELIOT Blue print with minimal effort (which goes in line with the key principle behind Akraino’s blue print goal).

Learn more about the Akraino ELIOT Blueprint: AkrainoELIOTBluePrint.pdf

Conclusion

This activity is an example of the early engagements between EdgeX and other LF Edge projects – one of mutual value to the engineers in both communities and demonstrating the value of a larger edge computing umbrella project.

For more information about Akraino Blueprints, click here: https://wiki.akraino.org/. To learn more about EdgeX Foundry, click here: https://wiki.edgexfoundry.org/. Or, join the conversation on the EdgeX Foundry Slack Channel.

Akraino Edge Stack Enables Connected Car, AR/VR, AI Edge, and Telco Access Edge Application Use Cases

By Akraino, Announcement

 

  • Akraino R2 delivers new levels of flexibility for scale, efficiency, and high availability while accelerating deployment of edge applications
  • Augments edge stacks delivered in R1 including Network Cloud, IoT Edge, Enterprise Edge, and Telecom Edge with new and enhanced tested and validated deployment-ready blueprints

SAN FRANCISCO  January 16, 2020LF Edge, an umbrella organization within the Linux Foundation that aims to establish an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating system, today announced the availability of Akraino Edge Stack Release 2 (“Akraino R2”).  Akraino’s second release furthers the power of intelligent edge with new and enhanced deployable, self-certified blueprints for a diverse set of edge use cases.

Launched in 2018, and now a Stage 3 (or “Impact” stage) project under the LF Edge umbrella, Akraino Edge Stack is creating an open source software stack that supports a high-availability cloud stack optimized for edge computing systems and applications. Designed to improve the state of edge cloud infrastructure for enterprise edge, over-the-top (OTT) edge, and carrier edge networks, it offers users new levels of flexibility to scale edge cloud services quickly, to maximize the applications and functions supported at the edge, and to help ensure the reliability of systems that must be up at all times.

“The Akraino community has grown rapidly in the past year, and now includes contributions from 70 percent of LF Edge Premium member companies and countless other ecosystem partners beginning to deploy the blueprints across the globe,” said Arpit Joshipura, general manager, Networking, Automation, Edge and IoT, the Linux Foundation. “With R2, strong community collaboration brings even more blueprints to the ecosystem that support current and future technology at the open source edge.”

About Akraino R2
Akraino Release 2 delivers the next iteration of open source edge cloud innovation for new levels of flexibility that scale 5G, industrial IoT, telco, and enterprise edge cloud services quickly, by delivering community-vetted edge cloud blueprints to deploy edge services. The blueprints address interoperability, packaging, and testing under open standards, which reduces users’ overall deployment costs and integration time. 

Akraino R2 includes 6 blueprint families and 14 blueprints, all tested and validated on real hardware labs supported by users and community members. This release enhances the edge stacks delivered in R1 for cross-disciplinary edge use cases as well as new edge stacks to support connected vehicles, AR/VR, NFV, Telco Access, integration with SDN solutions and project promotions to maturity, with rigorous community standards. 

The 14 “ready and proven” blueprints, include both updates to existing R1 blueprints, and the introduction of five new blueprints:

  • Connected Vehicle: This blueprint establishes an open source MEC platform to enable use cases such as accuracy of location, smarter navigation with real-time traffic updates, driver safety improvements, and traffic rule alerts. 
  • IEC type 4: AR/VR-oriented Edge Stack: Focused on focused on AR/ VR applications running on the edge, the blueprint builds the AR/VR infrastructure and introduces  a virtual classroom application, which improves online education experiences for teachers and students through a virtual classroom simulation. 
  • Integrated Cloud Native NFV/Application Stack (ICN): ICN addresses the overall challenges of edge deployments in a single deployment model that enables Edge Providers for Zero Touch Provisioning support in multi-cloud, multi-edge and multi-party orchestration. It integrates Kubernetes and ONAP4K8s for container run times and service orchestration and supports bare metal and virtual deployments. 
  • Network Cloud and Tungsten Fabric: This blueprint implements the Network Cloud with LF Networking’s Tungsten Fabric as an SDN Controller supporting cloud native integration for Kubernetes as well as the Neutron plugin for OpenStack, allowing operators to leverage Tungsten Fabric as a deployment tool and control infrastructure. 
  • SDN-Enabled Broadband Access (SEBA): Part of the the Telco Appliance blueprint family, SEBA provides an appliance tuned to support the SDN-enabled Broadband Access (SEBA) platform. The blueprint utilizes a reusable set of modules introduced by the Radio Edge Cloud (REC), introduced in Akraino R1.

More information on Akraino R2, including links to documentation, can be found here. For details on how to get involved with LF Edge and its projects, visit https://www.lfedge.org/

Looking Ahead
The community is already planning R3, which will include more new blueprints such as Edge AI/ML, 5G MEC/Slice, Time Critical Edge, and Micro-MEC and more, as well as enhancements to existing blueprints and tools for automated blueprint validations

Don’t miss the Open Networking and Edge Summit (ONES) North America, April 20-21 in Los Angeles, where Akraino and other LF Edge communities will be onsite to share the latest open source edge developments. 

About the Linux Foundation
Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Working towards moving the industry forward together

By Akraino, Akraino Edge Stack, Blog

By Alex Reznik, Chair of MEC ISG, HPE Distinguished Technologist and LF Edge member

This content original ran on the ETSI blog.

Quite some time has passed since my last blog entry, and while I thought about a new blog a number of times, a good topic – i.e. one which is appropriate for discussion in a short, informal and public format – just did not seem to present itself. That’s not for the lack of interest or activity in MEC. 2019 is shaping up to be a critical year in which many operators are now public about their plans for edge computing, initial deployments are appearing and, as expected, holes in what the industry has been working on are beginning to be found (witness the much publicized and excellent Telefonica presentation at last month’s Edge Compute Congress). It’s just that it’s hard to blog about on-going work, even when it is very active, much less about internal efforts of various players in MEC. After all, what would that look like “this is hard and we are working hard on it…”

Nevertheless, the time has come. Those of you who follow my random MEC thoughts on a semi-regular basis might recall the subject of that last post ages ago (I mean in February): the need for both a vibrant Open Source community and Standards development in a space like MEC; and how the two are complimentary in that the focus is, by definition, on complimentary problems. And, if you don’t follow me religiously, here is the link: https://www.etsi.org/newsroom/blogs/entry/do-we-still-need-standards-in-the-age-of-open-source, grab a coffee, tea, a…. whatever … and read up!

In a significant way, that post was in part a response to comments and questions like: “There is a lot of confusion in the market, what’s up with ETSI and Akraino and EdgeXFoundry. You guys all seem to compete.” To that, the post provides a rather direct answer of “no we do not – we address different needs.” However, these related questions often followed: “OK, but how well DO YOU actually work together?” To date, one failing of the various players in MEC space has been the lack of a more convincing answer than “well, we all talk and we are all aware of each other.

That’s now changed in a very significant way. On the heels of a formal cooperation agreement between ETSI and LF Edge (see, e.g. https://www.linuxfoundation.org/press-release/2019/04/etsi-and-the-linux-foundation-sign-memorandum-of-understanding-enabling-industry-standards-and-open-source-collaboration/), the MEC ISG within ETSI and LF Edge’e Akraino project have been working towards moving the industry forward together. The first fruit of this labor is about to ripen – an Akraino Mini-Hackathon, endorsed by ETSI, to be held in San Diego the day before KubeCon.

This event was designed to highlight the work Akraino is doing in putting forward solutions which take advantage of ETSI’s Standards, and to allow developers an experience in developing for MEC. The most notable thing about this Hackathon is the model of cooperation – Akraino (and Open Source community) provides implementations to the industry, while the use of ETSI MEC (Standards Org.) standards ensures interoperability across other standards-compliant implementations.

So… that’s it then. We have arrived at a working, standardized solution for MEC, right??? Well, no. If you are looking for that, the mini-hackathon will sorely disappoint you. However, it is a step – an important first step in a growing cooperation between two organizations which should be, over time delivering those operational, standardized components for MEC. The work ahead of ETSI MEC and Akraino is significant, and much of it will lack opportunities for fanfare – as work in our industry often does. Still, there will be more coming from our two organization, so stay tuned…

An Akraino Developer Use Case

By Akraino, Akraino Edge Stack, Blog

Written by technical members members of the Akraino Edge Stack project including Bruce Lin, Rutgers; Robert Qiu, Tencent; Hechun Zhang, Baidu; Tina Tsou, Arm; Ciprian Barbu, Enea; Allen Chen, Tencent; Gabriel Yang, Huawei; Feng Yang, Tencent; Jeremy Liu, Tencent ; Tapio Tallgren, Nokia; Cristina Pauna, Enea

More intelligent edge nodes are deployed in 5G era. This blog shares a developer use case out of the Akraino project that the community is working on, specifically Telco  Appliance Blueprint Family, Connected Vehicle Blueprint, ELIOT: Edge Lightweight and IoT Blueprint Family, Micro-MEC, The AI Edge Blueprint Family, and 5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint.

Telco Appliance Blueprint Family

Telco Appliance blueprint family provides a reusable set of modules that will be used to create sibling blueprints for other purpose tuned appliances.

Appliance model automates the installation, configuration and testing of:

  • Firmware and/or BIOS/UEFI
  • Base Operating System
  • Components for managing containers, performance, fault, logging, networking, CPU

The first blueprint integrated with TA is REC. Other appliances will be created by combining other applications with the same underlying components to create additional blueprints.

TA produces an ISO that, after being installed in the cluster, provides the underlying tools needed by the applications that come on top of it. The build of this ISO is automated in Akraino’s CI and it includes:

  • Build-tools: Based on OpenStack Disk Image Builder
  • Dracut: Tool for building ISO images for CentOS
  • RPM Builder: Common code for creating RPM packages
  • Specs: the build specification for each RPM package
  • Dockerfiles: the build specifications for each Docker container
  • Unit files: the systemd configuration for starting/stopping services
  • Ansible playbooks: Configuration of all the various components
  • Test automation framework

The image provides the following components, used during installation:

  • L3 Deployer: an OpenStack Ironic-based hardware manager framework
  • Hardware Detector: Used to adapt L3 deployer to specific hardware
  • North-bound REST API framework: For creating/extending blueprint APIs
  • CLI interface
  • AAA server to manage cloud infrastructure users and their roles
  • Configuration management
  • Container image registry
  • Security hardening configuration
  • A distributed lock management framework
  • Remote Installer: Docker image used by Regional Controller to launch deployer

The image provides the following components, usable by the applications:

  • CPU Pooler: Open Source Nokia project for K8s CPU management
  • DANM: Open Source Nokia project for K8s network management
  • Flannel: K8s networking component
  • Helm: K8s package manager
  • etcd: K8s distributed key-value store
  • kubedns: K8s DNS
  • Kubernetes
  • Fluentd: Logging service
  • Elasticsearch: Logging service
  • Prometheus: Performance measurement service
  • OpenStack Swift: Used for container image storage
  • Ceph: Distributed block storage
  • NTP: Network Time Protocol
  • MariaDB, Galera: Database for OpenStack components
  • RabbitMQ: Message Queue for Openstack components
  • Python Peewee: A Python ORM
  • Redis

Radio Edge Cloud (REC)

Akraino Radio Edge Cloud (REC) provides an appliance tuned to support the O-RAN Alliance and O-RAN Software Community‘s Radio Access Network Intelligent Controller (RIC) and is the first example of the Telco Appliance blueprint family.

  • RIC on Kubernetes on “bare metal” tuned for low latency round trip messaging between RIC and eNodeB/gNodeB,
  • Support for telco networking requirements such as SRIOV, dual POD interfaces, IPVLAN
  • Built from reusable components of the “Telco Appliance” blueprint family
  • Automated Continuous Deployment pipeline testing the full software stack (bottom to top, from firmware up to and including application) simultaneously on chassis based extended environmental range servers and commodity datacenter servers
  • Integrated with Regional Controller (Akraino Feature Project) for “zero touch” deployment of REC to edge sites
  • Deployable to multiple hardware models

In Akraino, the work on this blueprint will fully automate the deployment and testing on multiple hardware platforms in a Continuous Deployment system.

SDN Enabled Broadband Access (SEBA):

Here is SEBA user story.

As a Service Provider, I want to setup SEBA environment so that I can use ONF SEBA platform.

As an Administrator, I want to validate HOST OS environment so that I can install Kubernetes/SEBA.

As an Administrator, I want to validate Software environment so that I can install Kubernetes/SEBA

As an Administrator, I want to validate Virtual Machines for my Kubernetes/SEBA environment so that I can validate environment

As a Administrator, I want to validate services for my Kubernetes/SEBA environment so that validate working environment

SEBA validation on ARM – IEC Type 2

SEBA stands for SDN Enabled Broadband Access. It is an ONF/Opencord project which implements a lightweight platform, based on R-CORD. It supports a multitude of virtualized access technologies at the edge of the carrier network, including PON, G.Fast, and eventually DOCSIS and more.

SEBA is also an Akraino Blueprint, but in the context of the IEC Blueprint, the SEBA usecase is deployed and verified on an IEC Type 2 platform. IEC is also the main Akraino sub-project/blueprint which enables ARM architectures for Telco/Enterprise Edge applications.

For the purpose of validating SEBA on IEC Type 2, a SEBA compliant ARM64 lab has been setup at the Akraino Community Lab at the University of New Hampshire (UNH). The lab consists of two development PODs, using Marvel ThunderX2 networking processor equipped servers and Ampere HR330A servers.

The connectivity is provided by Edgecore 7816-64X TOR switches which fulfill the role of Fabric Switches in the SEBA Architecture.

For the validation work we have first ported and deployed BBSim on IEC for ARM64 and right now there is ongoing work for porting and verifying PONSim.

PONSim is also a central piece of SEBA-in-a-Box (SIAB) which is one of the main testing CI/CD projects in upstream Opencord Jenkins infrastructure.

There is ongoing work in Akraino IEC for replicating the SIAB setup by utilizing the same testing environments and facilities provided by Opencord.

Finally, recent collaboration with Opencord resulted in forming a Multiarch Brigade with the purpose of making SEBA seamlessly work on multiple architectures apart from the x86 servers. So far there has been some evident interest from the community and other parties for enabling multiarch support and perpetual verification in a CI/CD manner by adapting the Opencord infrastructure to support other architectures and ARM64 in particular.

Connected Vehicle Blueprint

Connected Vehicle Blueprint focuses on establishing an open source MEC platform, which is the backbone for V2X application.

From use cases perspectives,  the following are the use cases we have tested in our companies. More is possible in the future.

  • Accurate Location: Accuracy of location improved by over 10 times than today’s GPS system.Today’s GPS system is around 5-10 meters away from your reallocation, <1 meter is possible with the help of Connected Vehicle Blueprint.
  • Smarter Navigation: Real-time traffic information update, reduce the latency from minutes to seconds, figure out the most efficient way for drivers.
  • Safe Drive Improvement: Figure out the potential risks which can NOT be seen by the driver.
  • Reduce traffic violation: Let the driver understand the traffic rules in some specific area.For instance, change the line prior to narrow street, avoiding opposite way drive in the one way road, avoiding carpool lane when single driver etc.

From technology architecture perspective,  the blueprint consists of four major layers.

  • Hardware Layer: Connected Vehicle Blueprint runs on top of community hardware. Both Arm and x86 server are well supported.
  • IaaS Layer: Connected Vehicle Blueprint can be deployed in virtual environment as well.  Virtual Machine , Container as well as other IaaS mainstream software(like openstake, kubernates et al)  are supported.
  • PaaS Layer:Tars is the microservice framework of Connected Vehicle Blueprint. Tars can provide high performance RPC call, deploy microservice in larger scale-out scenario efficiently, provide easy-to-understand service monitor feature.
  • SaaS Layer: The latest v2x application depicted in upper use cases perspective.

From network architecture perspective,  the blueprint can be deployed in both 4G and 5G network. Two key points should be paid special attention to. One is offloading data to edge MEC platform.  The policy of data offload is configurable based on different applications.  The other is the ability that letting the edge talks to the other edges as well as remote data center. In some use cases, date process in one edge can NOT address the application’s requirements. We need to collect the data from different edges and figure out a “conclusion” for the application.

ELIOT: Edge Lightweight and IoT Blueprint Family

ELIOT AIoT in Smart Office Blueprint

This blueprint provides edge computing solutions for smart office scenarios. It manages intelligent devices, delivers AI training models and configures rules engine through cloud-edge  collaboration.

Services provided by cloud side:

  • Devices management
  • AI models training and deliver
  • Rules engine configuration
  • Third-party applications

Services provided by edge side:

  • Sending/Receiving devices data
  • Data analysis
  • AI models/Functions execution

Deployment environment:

  • Kubernetes
  • Container
  • VM
  • Bare Metal

Recently, we are still developing this project and Tencent will keep devoting great efforts to the research and development of this blueprint. In the near future, the project will also be open source. Any partners interested in this project are welcome to contact us and let’s work together to promote the application of edge computing in the field of smart office.

The AI Edge Blueprint Family

With this blueprint, teachers and school authorities could conduct a full evaluation of the overall class and the concentration of individual students, helping to fully understand the real time teaching situation. According to the concentration data of each course, teachers and school authorities can conduct knowledge test and strengthen.

The AI Edge Blueprint mainly focuses on establishing an open source MEC platform combined with AI capacities at the Edge, which could be used for safety, security, and surveillance sectors.

5G MEC/Slice System to Support Cloud Gaming, HD Video and Live Broadcasting Blueprint.

The purpose of the blueprint is to offer a 5G MEC networking platform to support delay sensitive, bandwidth consuming services, such as cloud gaming, HD video and live broadcasting. In addition, network slicing will be utilized to guarantee excellent user experience.

As a service provider of cloud gaming, I want to set up a computing platform to execute game rendering as well as video encoding, and deliver the compressed video to the player via a 4G/5G network.

As cloud gaming is sensitive to latency, the computing platform is required to be as close as possible to the network edge. Besides that, a mechanism to discover the service and direct players’ traffic to the platform is demanded.

To direct players’ traffic to the platform, I install an edge connector which is responsible for enabling flexible traffic offloading by interacting with EPC or 5GC, and subscribing the edge slice, which provisions a certain level of QoS between UE and edge application.

To interface with the user plane of 4G or 5G, I install an edge gateway (GW). In 5G SA, the edge GW is connected to a UPF, to manage the traffic from the mobile network. In 5G NSA or 4G, the edge GW is connected to an eNB or SGW, with an additional function of handling GTP-U, the tunneling protocol adopted by 4G and 5G.

When a player accesses a cloud gaming service hosted on the platform, the edge connector will establish an appropriate route between the mobile network and the edge GW. The compressed video and the player’s control data will be transferred between the gaming server and the user equipment, traversing the edge GW.

As a service provider of live broadcasting or HD video delivery, I want to set up a platform to transcode the video source to fit the bandwidth of the transport.

Similar to the cloud gaming use case, an edge connector is installed to direct the traffic to the computing platform, and an edge GW is installed to manage the mobile traffic and terminate GTP-U under 4G or 5G NSA. The computing platform will transfer the format of the video to be adapted to either the wireless link towards the mobile user or the transport towards the internet. The computing platform may be connected to a CDN to optimize the live broadcasting or HD video delivery.

Micro-MEC (µMEC)

 µMEC is a low-power, low-cost server at the edge of the network that supports Smart City use cases with different sensors (including cameras), is connected to Internet and telco networks, and allows third-party developers to create ETSI MEC applications to it.

So the µMEC focuses on Smart City use cases. If you had different smart sensors in a city, collecting data that is available for free, what could you make possible? That was the challenge that we gave in a developer hackathon in May. We used the Akraino uMEC platform and created a model city. Different sensors collected information and made it available through a database.

 

For the next hackathon, we want to make it very easy for developers to create applications that run on the µMEC device itself. For this, we are implementing ETSI MEC compliant interfaces and leverage the OpenFAAS serverless platform.

The µMEC platform that we are developing in Akraino will have a trusted computing stack, from trusted hardware to secure networking and signed containers.

Akraino will be hosting a MEC Hackathon on November 18 at Qualcomm. For more information or to register, visit the Akraino MEC Hackathon wiki.  For more informations about Akraino or blueprints, click here.

Running K8s Conformance Tests in Akraino Edge Stack

By Akraino, Blog

By Cristina Pauna, Bin Lu, Howard Zhang

Due to the large scale f its projects and various application scenarios, Akraino Edge Stack is complex when it comes to testing logistics;  normal integration or unit tests are not enough for testing the projects. To ensure that the full deployment is both functional and reliable, it needs to be tested at all layers of the stack, from hardware to application. To verify deployments based on Kubernetes at the platform layer, K8s conformance is a good way to do this job.

The k8s conformance tests are used in the CNCF vendor  Certified Kubernetes program. It integrates end-to-end (e2e) testing in Kubernetes which contains a wide range of test cases, and passing them proves a high level of common functionality of the platform.

K8s Conformance Tests in Akraino

General testing in Akraino is done using the Blueprint Validation Framework. The framework provides tests at different layers of the stack, such as hardware, operating system, cloud infrastructure, security, etc. Each layer has its own container image built by the validation project. The full list of images provided can be found in the project’s DockerHub repo. The validation project has an multi-arch approach. All images currently support both x86_64 and aarch64 architectures, and can be easily extended to other platform architectures in the future. This is implemented using docker manifest list so the same image name is used to pull regardless of the architecture of the System Under Test. Therefore the steps described in this article apply regardless of the architecture of the SUT.

The Kubernetes conformance tests are included in the k8s layer. The test suit can be run in a couple of ways, either by directly calling the e2e tool or though sonobuoy, which is a diagnostic tool that gathers logs and and stats in one archive. Regardless of how the tests are ran, it is possible to customise what test cases are included, which versions and even the container images within the tooling.

In Akraino, the conformance suite is run from a separate container, using the validation image built for the k8s layer: akraino/validation:k8s-latest. This image contains all of the tooling necessary for running tests on the k8s layer in Akraino, as well as the tests themselves. The tools that go into the image can be found in its Dockerfile. The container is designed to be started on a remote host that has access to the k8s cluster. Check the validation project User guide for more information on the setup.

The conformance suite is customized using the sonobuoy.yaml file. Some of the images used by sonobuoy in Akraino are built by the validation project in order to customize them to fit the community’s needs (e.g. akraino/validation:sonobuoy-plugin-systemd-logs-latest is based on the official gcr.io/heptio-images/sonobuoy-plugin-systemd-logs:latest but with added aarch64 support).

Prerequisites

Before running the image, copy the folder ~/.kube from your Kubernetes master node to a local folder (e.g. /home/ubuntu/kube) that will later be mounted in the container. Optionally, the results folder can be mounted in order to have the logs stored on the local server.

Run the tests

The Akraino validation project has a variety of tests for the k8s layer. To run just the conformance tests, follow the steps below:

  1. Clone the validation repo.
  2. Create a customized blueprint that will be passed to the container. The blueprint will contain just the conformance suite in it, like in the example below.

3. Fill in volumes.yaml file with the data that applies to your setup. The volumes that don’t have a local value set will be ignored. Do not modify the target part of each volume. These paths will be automatically created inside the container when started, and are fixed paths that the tools inside the container expect to exist as is.

In the example below, only the following volumes are set:

  • Location to the kube config files needed for access to the cluster
  • Location to the customized blueprint file
  • Location to where to store the results

4.  Run the tests

To run the tests, the blucon.py command is used which needs the name of the blueprint as input. The full suite takes around one hour to run, depending on the setup.

The sonobuoy containers can be seen running on the cluster on the heptio-sonobuoy namespace.

Get the results

The results are stored inside the container in the /opt/akraino/results folder. If a volume was mounted to this folder (e.g. /home/ubuntu/results) then they can be viewed from the host where the test was ran.

The results can be viewed with a browser, using the report.html file that the robot framework provides. In case of failures, the sonobuoy archive can be used to inspect all the logs.