Several architectures for large-scale IoT edge container cluster management - 1-Rancher+K3s

Review above

Introduction to several architectures for large-scale IoT edge container cluster management - 0-edge containers and architectures

📚️Reference:
IoT Edge Computing series

Rancher + K3s

Brief introduction

• Rancher: Kubernetes unified management platform, Rancher is a complete software stack for teams adopting containers. It addresses the operational and security challenges of managing multiple Kubernetes clusters while providing DevOps teams with integrated tools to run containerized workloads.
• K3s: Perfect for the edge, K3s is a highly available, certified Kubernetes distribution designed for production workloads in unattended, resource-constrained remote locations or within IoT devices. K3s are packaged into one <60MB, reducing the dependencies and steps required to install, run, and automatically update a production Kubernetes cluster. Both ARM64 and ARMv7 are supported, and binaries and multi-architecture images are available. K3s works well on servers as small as the Raspberry Pi and as large as AWS a1.4xlarge 32GiB.

Reference architecture

This solution takes advantage of the Kubernetes ecosystem, and is 100% open source, no locking, convenient plug-in extension, and also provides UI entry to provide a good user experience. And the core is completely based on Kubernetes, with a very good crowd base.

• A set of Rancher clusters is deployed in the “cloud”, Rancher is responsible for managing all K3s clusters in the “edge” of its subordinates, and business applications in the cloud can be deployed in the Rancher cluster at the same time, responsible for synchronizing with the edge side business system, and issuing data or instructions.
• The lightweight operating system MicroOS (an immutable OS, which is not the focus of this article, will not be expanded) is installed in the “edge” device, and the business application of the “edge” is deployed in K3s for “end” connections.
• As the edge of a business application, the “end” connects the “edge” to complete the service networking and form a service application centered on the “edge”.

Program advantages

• Cloud-edge collaboration: When the network between the cloud-side Rancher and the edge-side K3S cluster (a websocket tunnel is established through the rancher-cluster-agent), you can manage all subordinate K3S clusters through Rancher, such as observing the running status of each K3S cluster and the operation status of business applications on it. At the same time, the cloud business applications deployed in Rancher’s cluster can send data or instructions to the edge side business applications.
• Edge autonomy: Regardless of the network, the edge-side K3s cluster can run itself (that is, a set of streamlined K8s), without relying on cloud Rancher, to achieve edge autonomy of the running environment; The edge business applications running on it can run normally without relying on cloud applications, and the edge autonomy of the business can be achieved.
• Lightweight K8s: Using the lightweight K8s solution K3s as the running environment, K8s-based container services can be provided under the condition of tight hardware resources, so that services can enjoy the technical dividends of K8s.
• 100% open source: 100% open source, no locking
• Native Kubernetes ecosystem: With a fully Kubernetes-compatible ecosystem, plugin extensions are easy and available out of the box: flannel, load balancer service, Traefik, coredns…
• The UI is beautiful: UI entry is provided to provide a good user experience
• GitOps: Rancher integrates with the GitOps tool - Fleet by default, providing a GitOps automation experience.
• Simple operation and maintenance: Rancher and K3s are well-documented and provide many handy operational automation tools.
• Full enterprise functionality: Such as: authentication, authentication, single sign-on, API…

Scheme disadvantages

• K3s still takes up slightly more resources than pure containers
• rancher-cluster-agent occupies a lot of resources: In my experience, the agent may consume > 1G of memory, which is unbearable on the edge side.
• The network is complex and weak: K3s CNI defaults to flannel, which is not further optimized and adapted to complex network conditions at the edge. If the edge is a K3s server, the end is a K3s agent, and the edge network is also unstable, the ability of K3s based on the native K8s network cannot be well coped with in this case. Compared with Kubeedge, the edge network adaptability is weak. Compared with pure container solutions, flannel/load balancer service, Traefik, coredns, etc. are more complex.

Keep reading

1. Several architectures for large-scale IoT edge container cluster management - 2-HashiCorp solution Nomad
2. Several architectures for large-scale IoT edge container cluster management - 3-Portainer
3. Several architectures for large-scale IoT edge container cluster management - 4-Kubeedge
4. Several architectures for large-scale IoT edge container cluster management - 5 - Summary

Reference documentation

• SUSE Edge 2.0: A Cloud Native Solution to Manage Edge | SUSE Communities