Janakiram MSV is a principal analyst at Janakiram & Associates and an adjunct faculty member at the International School of Information Technology. He is also a Google Qualified Developer, Amazon Certified Solution Architect, Amazon Certified Developer, Amazon Certified SysOps Administrator and Microsoft Certified Azure Professional.

Janakiram is an ambassador for the Cloud Native Computing Foundation and one of the first Kubernetes certified administrators and Kubernetes certified application developers. He has worked at Microsoft, AWS, Gigaom Research and other well-known companies.

Kubernetes is looking for a way from the cloud to the edge through the data center. Earlier, Kubernetes was considered a very large workload running on a public cloud. In recent years, enterprises have begun to apply Kubernetes to their data centers. It ultimately becomes a consistent and unified infrastructure layer for running workloads in hybrid and cloudy environments.

The rise of the Internet of Things and artificial intelligence has prompted the industry to move computing power closer to data, which has become the edge computing layer.

Edge computing is the intermediary between edge devices and the cloud/data center. It extracts device data based on business logic while providing real-time analysis. It acts as a conduit between the data source and the cloud, greatly reducing the latency that can occur due to traveling to and from the cloud. The edge also reduces bandwidth costs because it can process and filter data that needs to be sent to the cloud. Finally, edge computing will help enterprises achieve data localization and data management sovereignty through local processing and storage.

Edge computing leverages cloud platform infrastructure services such as data extraction, data processing, flow analysis, storage, device management, and machine learning reasoning.

Kubernetes is fast becoming the infrastructure of choice for edge computing. The promise of agility, scale, and security is increasingly being extended to edge infrastructure. Modern software delivery mechanisms based on CI/CD and GitOps make it easy to manage applications running on the edge. Tens of thousands of Kubernetes clusters deployed at edge locations are managed by management platforms such as Anthos, Arc, Tanzu and Rancher.

Composition of edge

In fact, users who plan to run Kubernetes on the edge don’t have much choice; they must assemble stacks from the best open-source and commercial software in the cloud native ecosystem.

The commercial Kubernetes distribution is not optimized for resource-constrained environments. Kubernetes distributions deployed on the edge should take up less space and not affect API consistency and compatibility.

Edge storage is one of the key building blocks of the infrastructure. It must support the various requirements for handling stateful workloads of unstructured data sets, NoSQL databases, and shared file systems. It should have the ability to take periodic snapshots of data and store them in the cloud. Advanced capabilities such as migration and disaster recovery can make edge computing layers resilient.

The network layer should provide security and isolation for workloads running at the edge. In most cases, edge infrastructure is shared by multiple groups. For example, in a smart building use case, the same edge cluster might run the workload for each floor. The cluster administrator should be able to apply network policies to prevent applications running in one namespace from accessing application data in another namespace. And the network layer should provide security through intrusion detection and declarative policies.

K3s: Kubernetes distribution for the edge

K3s by Rancher Labs is a lightweight Kubernetes distribution optimized for edge scenarios. Although K3s is a simplified, mini-version of Kubernetes, it does not affect the consistency and functionality of the API.

From Kubectl to Helm to Kustomize, almost all of the tools in the cloud native ecosystem work seamlessly with K3s. In fact, K3s is a CNCF certified, compliant Kubernetes distribution that can be deployed in a production environment. Recently, K3s was donated to CNCF as a sandbox project. Almost all workloads running in clusters based on upstream Kubernetes distributions are guaranteed to run on K3s clusters.

K3s effectively solves the computing layer problem by coordinating infrastructure and workloads running at the edge.

Portworx: container cloud native storage layer

Portworx is a software-defined storage platform built for containers and microservices. It abstracts multiple storage devices to expose a unified, overlaying storage layer for cloud native applications.

One of Portworx’s key differentiators is container granular storage volumes. Unlike other storage products, Portworx exposes a unified overlay storage layer that can be adapted to different use cases. For example, a storage administrator can define a storage class designed to run a NoSQL database in high-availability mode while creating another storage class for a shared volume. Both solutions are based on the same storage back end without the need to manage two different storage tiers.

The edge computing layer handles a variety of workloads, including streaming, data storage, analytics, complex event processing, and AI reasoning. Some of these workloads require dedicated storage volumes, while others require shared volumes. For example, multiple pods serving AI reasoning will share the same storage volume filled with ML models. At the same time, Message Broker needs a dedicated volume to persist messages.

Portworx eliminates the pain of managing multiple storage tiers through a unified approach. Some of these features, such as snapshot, scheduled backup, migration, integrated RBAC, and predictive capacity planning, make Portworx an ideal choice for the edge.

Currently, the latest Portworx 2.6 has official support for K3s.

Calico Project: Secure Networks at the Edge

Calico brings a fine-grained network strategy to Kubernetes. Although Kubernetes has extensive support for role-based access control (RBAC), the default network stack provided in upstream Kubernetes distributions does not support fine-grained network policies. Calico provides fine-grained control by allowing and denying traffic for Kubernetes workloads.

It is common practice for DevOps to group applications logically into the Kubernetes namespace. In an edge computing scenario, a K3s cluster might run multiple namespaces separated workloads. Calico implements strong namespace isolation through declarative policies. Through these policies, data streamed by sensors will be extracted and processed by authorized applications.

Calico comes with built-in intrusion detection to identify suspicious activity. Multi-cluster management of multi-cloud Federation enables easy management of distributed edge infrastructure from a unified management interface. And with a few modifications to the installation process, Calico can easily integrate with K3s.

In the next tutorial, I’ll walk you through how to configure edge clusters based on K3s, Portworx, and Calico. In subsequent sections, we will also explore AIoT deployment using this solution stack. Stay tuned!

IO/how-k3S-por…