DEV Community: Anas Alloush

Balancing Flexibility & Responsibility: The Shift to Openness in Telcos, At What Cost?

Anas Alloush — Wed, 07 May 2025 19:38:05 +0000

The Past:

For decades, Telecommunication operators built and ran their networks using closed, proprietary solutions, products, protocols, data schemas and practices from a few dominant Telco vendors. These systems were delivered as turnkey solutions, often described as "black boxes" where the operator had little visibility or control over the internal workings.

For example in the Core domain (2G/3G/4G) vendors provided complete EPC solutions as monolithic systems. Customization was minimal, and operators depended on the vendor for upgrades, integration, and even basic configuration.

Another example would be the RAN domain, where monopoly was even higher. RAN Solutions came as vertically integrated hardware-software bundles. Vendor's X baseband units (BBU) only worked with their radios and software, and had no chance to integrate it with Vendor' Y similar solutions.

This was the paradigm for the las 4 decades, which had its pros and cons:

Pros:

Single Vendor, E2E support. Simplicity for Operator's teams.
Less expertise level required. Operators only operate. They don't self-develop, self-optimize or self-integrate..
Clear product SLAs with robust definitions.
The internals of the solution are well integrated, tested and optimized.

Cons:

Operators had to adapt their operations to the vendor's products, not the other way around.
Limiting operators’ ability to mix and match components, or diversify their supply chain, which would increase competition and lower prices
Solution's changes were often costly. Costly Change Requests sometimes are more expensive than the solution itself.
Vendor lock-in, limited innovation, and slow adaptability to new technologies.

Recent Openness Movement

Today, a significant shift is sweeping the Telco industry. A multi-dimensional change is taking shape in different Telco classical domains. From Core and RAN to configuration and automation. A change of the whole Telco Ops mindset is happening, and it is GOOD!.

Disaggregation was/is the Motto of this revolution.

5G standards came with drastic changes from what the Telco business were used to. HTTP? REST APIs? completely out-of-the-box for a Telco veteran who used to wrestle with SS7 and Diameter headers.

Simultaneous shift was happening with the HW/SW disaggregation. Why buying a specialized costly piece of Metal to operate the MME if I can containerize it and run it on a COTs server with 1/6th of the cost?

Mixing & matching between different vendor's CNFs and VNFs started to gain interest as well. More competition, less monopoly..

And suddenly, Cloud Native technologies with all its practices and methodologies like DevOps, GitOps, ZTP ,, etc started finding its way to the Telco landscape.

Standard bodies started to flourish: OpenRAN, ONAP, ETSi NFV,,etc. Although many of them had already existed for a while but they were not that relevant in the closed-monolith solutions era.

Telco Operators starting leveraging community-driven innovation power (something happening in IT since many decades) and invested in the movement.

Less Infra Capex, smaller maintenance windows, faster TTM with new products, leveraging cloud powers ,, all loved and adopted by Telco operators.

But was it all roses and butterflies? as anything in life; No!

Challenges

This newfound freedom came with some challenges, mainly the increased responsibility which is new to the Telcos business..

Embracing open standards and open-source demands a deeper understanding of the underlying technologies. Disaggregating means more vendors to deal with and that requires - among other things - well defined SLAs to avoid pointing-finger games.

Here are some of the main challenges that are facing Telcos in the Disaggregation era:

1. Integration Complexity:
Unlike turnkey proprietary solutions, open standards require operators to stitch together multiple components. Ensuring interoperability between vendors increases testing and validation efforts.

2. Risk of Performance Bottlenecks:
Due to mismatched integrations and the long list of variables to be tweaked between different products, performance can easily suffer if integration was not tight.

3. Talent Shortage & Expertise Gaps
Open ecosystems require skills in cloud-native technologies, automation, orchestration and open-source tooling. Telco operators often lack in-house expertise, and retraining legacy staff on new technologies adds time and cost.

Also, Competition with tech giants for software engineers, DevOps, and cloud specialists makes hiring difficult and expensive.

4. Impact on SLAs & Operational Responsibility
With proprietary systems, vendors took full accountability for performance and outages. Now, operators own the integration, and demand disaggregation, making them "virtually" responsible for E2E service reliability.

Meeting strict Service-Level Agreements (SLAs) requires deeper control over the entire stack, increasing operational pressure. (Telco likes multis 9's SLAs😉 )

5. Complex Troubleshooting
When issues arise across multi-vendor, open-source stacks and environments, troubleshooting required multiple teams setting together reviewing different stacks and trying to correlate telemetry and connecting the dots to find out the root cause of the issue. Again require deep expertise and full cooperation between different domains.

Suggestions

Abandoning the openness and disaggregation is not an option. Finding the right strategic balance between the flexibility offered by open approaches while building the internal capabilities and processes necessary to manage the associated responsibilities is the way forward.

Should I mention AI here? 😀 ,, Sure AI is key to navigate the complexity of disaggregated multi-vendor networks, but there is still a long way to utilize it efficiently without harming the delegate balance of Telcos annual TCO..

Closing words; transition is not easy, and Telcos need to be real and fact-check themselves to what level can they handle disaggregation based on their conditions.

Each Telco as an individual case and finding this sweet spot is key to foster innovation, reduce costs, and ultimately deliver better services in the evolving digital landscape.

Run DeepSeek locally on BareMetal via K8s

Anas Alloush — Sun, 09 Mar 2025 20:31:11 +0000

What is DeepSeek?

Just as OpenAI has the ChatGPT chatbot, DeepSeek also has a similar chatbot, and it comes with two models: DeepSeek-V3 and DeepSeek-R1.

**DeepSeek-V3 **is the default model used when we interact with the DeepSeek app. It’s a versatile large language model (LLM) that stands out as a general-purpose tool that can handle a wide range of tasks.

DeepSeek-R1 is a powerful reasoning model built for solving tasks that require advanced reasoning and deep problem-solving. It works great for coding challenges that go beyond regurgitating code that has been written thousands of times and logic-heavy questions.

What gave DeepSeek the blazing fame, was the mathematical tricks used to enhance efficiency and compensate for the performance improvements of Nvidia’s GPU and Collective Communications Library (NCCL)

In short, DeepSeek used smart math to avoid using expensive HW like Nvidia’s H100 GPU for training large datasets.
Also affected how the model can be run and used, hence we can run it on local servers with normal (no GPU) compute powers.

DeepSeek’s Mathematical Tricks for Computational Efficiency:

1. Low-Rank Approximations for Faster Computation
One of DeepSeek’s key optimizations is low-rank matrix approximations, which reduce the number of operations needed in matrix multiplications. Instead of performing full-rank matrix multiplications, these methods approximate matrices with lower-dimensional representations, significantly reducing computational cost.

2. Grouped Query Attention (GQA) for Memory Savings
GQA restructures how attention is computed in transformer models, reducing the memory bandwidth required for attention operations. Instead of computing attention for each query separately, GQA allows multiple queries to share the same key-value pairs, leading to:

Lower memory consumption
Faster inference speeds
Reduced redundant computations

3. Mixed-Precision Training for Speed and Efficiency
DeepSeek utilizes mixed-precision training, where computations use FP16/BF16 instead of FP32, reducing memory footprint and accelerating training. However, to maintain numerical stability, loss scaling techniques are applied, ensuring that small gradients are not lost due to precision truncation.

4. Quantization for Reduced Computational Complexity
Beyond mixed-precision, DeepSeek also benefits from quantization, where tensors are represented using lower-bit precision (e.g., INT8). This allows for faster matrix multiplications and reduced memory bandwidth consumption, making training more efficient.

5. Stochastic Rounding to Maintain Accuracy
When using lower-precision floating-point formats, stochastic rounding is employed to mitigate the accumulation of rounding errors, ensuring the model maintains high accuracy despite using reduced precision.

DeepSeek’s mathematical optimizations allowed for cheaper training and lighter models that we can run on servers/PCs with minimum HW.

Why would someone run a LLM model locally?

Running a large language model (LLM) locally offers several advantages, depending on the use case and requirements. Here are some key reasons why someone might choose to run an LLM locally:

1. Data Privacy and Security

Sensitive Data: When working with confidential or sensitive information (e.g., medical, legal, or proprietary business data), running the model locally ensures that the data never leaves your environment, reducing the risk of exposure or breaches.
Compliance: Local deployment can help meet regulatory requirements (e.g., GDPR, HIPAA) that mandate data to remain on-premises.

2. Control and Customization

Full Control: Running an LLM locally gives you complete control over the model, its configuration, and the infrastructure it runs on.
Customization: You can fine-tune or modify the model to better suit specific needs, which might not be possible or cost-effective with cloud-based APIs.

3. Cost Efficiency

Reduced API Costs: Cloud-based LLM services often charge based on usage (e.g., per token or API call). Running the model locally can be more cost-effective for high-volume or continuous usage.
No Subscription Fees: Local deployment avoids recurring subscription costs associated with cloud-based LLM services.

4. Performance and Latency

Lower Latency: Local deployment eliminates network latency, which is especially important for real-time applications or when low response times are critical.
Predictable Performance: You can optimize the hardware and software stack to ensure consistent performance, without being affected by external factors like cloud service outages or throttling.

5. Offline Accessibility

No Internet Dependency: Running the model locally allows you to use it in environments without reliable internet access, such as remote locations or secure facilities.
Disaster Recovery: Local deployment ensures that the model remains accessible even during internet outages or cloud service disruptions.

6. Transparency and Debugging

Model Transparency: Running the model locally allows you to inspect its behavior, outputs, and intermediate steps, which can be crucial for debugging or understanding its decision-making process.
Error Analysis: You can log and analyze errors or unexpected outputs more effectively when the model is under your control.

7. Long-Term Sustainability

Avoid Vendor Lock-In: By running the model locally, you are not dependent on a specific cloud provider or service, reducing the risk of vendor lock-in.
Future-Proofing: Local deployment ensures that you can continue using the model even if the cloud service changes its pricing, terms, or discontinues the service.

8. Research and Development
Researchers and developers can experiment with the model’s architecture, training data, or fine-tuning processes without restrictions imposed by cloud providers.

Hands-On Stuff:

There are many ways you can run DeepSeek locally.
As a fan of K8s and containers, I chose the containerized way.

Here I’m running DeepSeek-R1 model locally on a Kubernetes cluster. This cluster is running on a VM which is running on a personal Laptop. One might argue that such setup is not really a BareMetal setup which is correct, but the same K8s configuration can be used on BareMetal directly. In my case I ran it within a VM for convenience..

Setup specifications:

1 VM with 32G RAM & 16 Cores / intel i9–9880H CPU @ 2.30GHz.
No GPUs used.
50 GB Storage allocated to the VM.
Ubuntu 22.04.5 LTS.
Minikube K8s.
DeepSeek-r1 with 7-billion parameters (Ollama Docker Image).
Open Web UI.

Practical Steps:
1- Install any K8s distribution you feel comfortable working with.
Here I’m using Minikube K8s and allocating 14 vCPUs & 28GB Memory for the cluster.
minikube start - cpus=14 - memory=28672

2- Prepare K8s Persistence Volumes (PVs) of any type (Static or Dynamic), as later it will be consumed by 2 PersistentVolumeClaims (PVCs).

Note: If you are using a Minikube K8s, you can simply use the storage-provisioner-gluster add-on as explained here

3- Go to https://ollama.com/ and choose the model you want .. Here I’m choosing DeepSeek-R1 with 14 billion parameters. Choose less parametrs model depending on your machine resources.

4- Once you have a running K8s setup, run the below yaml configuration via kubectl..
It will download and run the images:

DeepSeek-R1 14b model.
open-webui.

It will also prepare the volumes required, and expose the Open-Webui GUI via port 11434 to interact with the model..

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: open-webui-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ollama-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: open-webui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: open-webui
  template:
    metadata:
      labels:                                                                                                                                                            
        app: open-webui                                                                                                                                                  
    spec:
      containers:
        - name: open-webui
          image: ghcr.io/open-webui/open-webui:latest
          env:
            - name: OLLAMA_BASE_URL
              value: "http://127.0.0.1:11434"
          volumeMounts:
            - mountPath: /app/backend/data
              name: open-webui-storage
      volumes:
        - name: open-webui-storage
          persistentVolumeClaim:
            claimName: open-webui-storage
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      containers:
        - name: ollama
          image: ollama/ollama:latest
          volumeMounts:
            - mountPath: /root/.ollama
              name: ollama-storage
      volumes:
        - name: ollama-storage
          persistentVolumeClaim:
            claimName: ollama-storage
---
apiVersion: batch/v1
kind: Job
metadata:
  name: ollama-pull-llama
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: ollama-pull-llama
          image: ollama/ollama:latest
          command: ["/bin/sh", "-c", "sleep 3; OLLAMA_HOST=127.0.0.1:11434 ollama pull deepseek-r1:7b"]
          volumeMounts:
            - mountPath: /root/.ollama
              name: ollama-storage
      volumes:
        - name: ollama-storage
          persistentVolumeClaim:
            claimName: ollama-storage

Depending on your internet connection, It will take around 2 min to pull all required images (~4.5GB) and run them on your K8s cluster.

Note: Before start using the model, the Ollama Pull job must be on Complete status. All other pods must be in Running status.

Moment of Truth — Test ,, Test

Now that we have a locally ready setup including a running model, its storage and an exposed port. lets start testing:

1st Questions: What is a Transistor?
Thinking and writing the answer took around ~50Sec

2nd Question: How many (A) letters is there in the name (Anas)?
Some models struggle with such questions. In my DeepSeek-r1 local setup it took around ~80Sec to reason, think and answer correctly.

Below is a snapshot from my linux VM with all allocated CPU going wild trying to run the model while answering the questions..

Happy Learning!

Top Lightweight Open Source Kubernetes Distros for Learning and Testing

Anas Alloush — Sun, 05 Jan 2025 14:31:59 +0000

If you are a beginner looking to learn Kubernetes basics or an experienced developer, DevOps, SRE or a Platform engineer looking for a quick and “clean” setup to test new features or perform specific tests, choosing the right Kubernetes distribution is crucial.
In this article, I’m listing the Best-in-Class free and open-source Kubernetes distributions available for learning and testing.
Deploying K8s clusters via kubeadm, is a good way to learn the outs & abouts of K8s itself, but it is also the hard way and the time-consuming way (+30 min for beginners to set-up a working cluster).
Therefore, when I want to test something quickly, I just spin off a K8s cluster using one of the lightweight distributions mentioned in this article depending on the purpose and use-case I have in mind. Although for complex tests I have a fully automated kubeadm based environment, but this is for another article.

My criteria to choose the K8s distribution for quick testing is:

Time to set up a functioning cluster.
Ease of setup and use.
Resource requirements (CPU, RAM, Storage).
Flexibility and customization options.
Documentation Clarity
Community Support.
Suitability & Usage.

Note1: I included a “Quick Guide” Subsection in each K8s project section, but it is advisable to always have a look at the official project installation page (Link Provided) as the installation steps tend to vary from time to time depending on the project evolution, your OS type and your point of time reading it.

Note2: You are advised to have a good read at the “known issues” section of each project to prevent running in cycles in case encountering an issue/bug/problem before submitting a PR or ask ChatGPT ;)

Note3: This is not an exhaustive list and not an ordered best-to-worse kinda list. It is rather a randomly ordered list based on my own experience dealing with K8s almost on daily basis since 6 years.

1- Minikube

Quick glance:
A project maintained as part of the Kubernetes project under the Cloud Native Computing Foundation (CNCF) which is considered the Go-To K8s distro for absolute beginners.
Minikube is a very lightweight K8s distribution designed to help developers and learners to run a local Kubernetes cluster on their personal computers.
The default setup creates a single-node Kubernetes cluster, which includes a master and worker node in one instance. (Multi-Node Clusters can be configured as well)
Minikube creates a virtualized or containerized environment (depending on the driver used) that runs Kubernetes components.

Time to Set Up:
~2–5 mins

Ease of setup and use:
Very straight forward and easy steps. Installation page here

Quick Setup Guide:

1.Install the latest Minikube stable release (Assuming you have a x86–64 Linux and using Debian package):

curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube_latest_amd64.deb
sudo dpkg -i minikube_latest_amd64.deb

2.Start your cluster
From a terminal with administrator access (but not logged in as root), run:

minikube start

3.Interact with your cluster
Minikube already downloads kubectlif it is not already installed on your machine. Interact with your cluster

minikube kubectl - get po -A

Resource Required & Prerequisites:

• Minimum Resources: 2 CPUs , 2GB RAM with ~4GB Storage.

• As Prerequisite: Minikube requires a container or a VM manager, such as: Docker, QEMU, Hyperkit, Hyper-V, KVM, Parallels, Podman or VirtualBox

Flexibility & Customization Options:
Minikube Supports enabling add-ons that provide quick configurations for things like:
• K8s dashboard
• ingress
• metrics-server
• Loadbalancer
• Persistent Volumes

Such add-ons otherwise would take some time and require some K8s knowledge to deploy & configure them.
It also supports all popular CNIs (Cilium, Calico, Flannel ,, etc) and popular CRIs (Docker, Containerd and CRI-O)

Documentation:
Very user friendly, written in clear text and suitable for absolute beginners as it includes step-by-step guides for various use cases.

Community Support:
• Large community support with +29.7k stars on GitHub
• All created issues are actively followed and resolved by contributors.
• Large collection of community-created tutorials and guides are available online in text and video forms.

Suitability & Usage:
Very useful for:
• Spinning off a quick K8s cluster on your local machine
• Learning the basics and following up with tutorials.
• Testing small scale and simple scenarios.
• In General, it is very recommended as a starting point for absolute beginners.

Not recommended for:
• Complex networking scenarios
• Performance testing or testing low latency workloads
• HA scenarios, and Loadbalancing tests
• complex large Stateful applications

2- KinD (Kubernetes in Docker)

Quick Glance:
KinD is a lightweight tool designed to run local Kubernetes clusters using Docker containers as “nodes”. Therefore, it simplifies creating multi-node clusters on a single machine without requiring virtualization or specialized hardware.
Under the Hood, KinD uses kubeadm to bootstrap the Kubernetes cluster inside the containers fully automatically.

Time to Set Up:
~5–10 min depending on your internet connection speed as creating a KinD Cluster requires downloading multiple Docker images.

Ease of setup and use:
Very straight forward. Installation page here

Quick Setup Guide:
Assuming you are using Linux AMD64 / x86_64

1.Install the package:

[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.26.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

2.Create a Kubernetes cluster

kind create cluster

3.Interact with the Cluster:
By default, the cluster access configuration is stored in ${HOME}/.kube/config
Note: KinD does not require kubectl to interact with the cluster.
If you want kubectl, you need to install kubectl binaries yourself as KinD package does not install them for you. kubectl Installation page here
All project known issues are documents in a clear way here

Resource Required & Prerequisites:
•Minimum Resources: 2 CPUs or more & 2GB of free memory with ~4GB Storage (Additional resources depends on the number of nodes).
•The only Prerequisite to be installed is Docker.

Flexibility & Customization Options:
A KinD Cluster can be fully defined via YAML files, making it highly customizable and portable.
It Supports all popular CNIs (Cilium, Calico, Flannel ,, etc) and popular CRIs (Docker, Containerd and CRI-O)
Note that there are no built-in add-ons like Minikube to quickly deploy an Ingress controller or a LoadBalancer.
KinD helps you by lowering the bar with some of these tasks, but you need to take care of the majority of the steps yourself.

Documentation:
Clear, easy, and beginner-friendly documentation.

Community support:
•Large community support with +13.7k stars on GitHub
•All created issues are actively followed and resolved by contributors.
•Also many community-created tutorials and guides are available online in text and video forms

Suitability & Usage:
Extremely useful for:
• Testing CI/CD pipelines integration with K8s environment.
• Testing multi-node Cluster configurations and HA scenarios.
• Learning topics that are a bit above the basics
Not recommended for:
• Networking Complexity: Advanced networking setups can be tricky to configure.
• Performance testing or testing low latency workloads
• Complex large Stateful applications
• Production-Like environment deployments

3- K0s

Quick glance:
Pronounced "kay-zero-ess", Z0s is a zero-friction, lightweight Kubernetes distribution designed to simplify the deployment and management of Kubernetes clusters in environments where resource efficiency is critical.
k0s bundles all the necessary Kubernetes components into a "single binary". This binary includes the Kubernetes control plane components (API server, scheduler, controller manager, etc.), worker node components (kubelet, kube-proxy), and optional add-ons (e.g., CNI plugins, metrics server).

Time to Set Up:
With ~2–3min, K0s is one of the fastest Kubernetes distributions to set up.

Ease of setup and use:
Installation page here .. For a quick setup guide continue reading.

Quick setup Guide:

1.Download k0s
Run the k0s download script to download the latest stable version of k0s and make it executable from /usr/local/bin/k0s

curl - proto '=https' - tlsv1.2 -sSf https://get.k0s.sh | sudo sh

2.Install k0s as a service
Run the following command to install a single node k0s that includes the controller and worker functions with the default configuration:

sudo k0s install controller - single

3.Start the k0s as a service ( and wait a couple minutes)

sudo k0s start

4.Access your cluster using kubectl (K0s installs it for you)

sudo k0s kubectl get nodes
NAME   STATUS   ROLES    AGE    VERSION
k0s    Ready    <none>   4m6s   v1.21.2-k0s1

Note1: If you are installing a multi-node setup, using the previous command you will not see the Control-Plane node, and that does Not mean your setup is broken.

Note2: In case you are not happy with the default installation way and would like to install K0s via k0sctl ,, Consider installing the k0sctltool on the Jumphost machine and not on the machines that you want to run K8s on

k0sctl.yaml file example below:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s-cluster
spec:
hosts:
- role: controller
ssh:
address: 10.0.0.1 # replace with the controller's IP address
user: root
keyPath: ~/.ssh/id_rsa
- role: worker
ssh:
address: 10.0.0.2 # replace with the worker's IP address
user: root
keyPath: ~/.ssh/id_rsa

Project known issues are documented here

Resource Required & Prerequisites:
•Minimum Resources: 1 CPU, 1GB RAM and ~2GB Storage per node for small clusters. (Additional resources depends on the number of nodes).
More sophisticated system requirements are explained here

•As Prerequisite, k0s has ZERO external dependencies other than a compatible Linux OS. It does not require Docker or any other container runtime to be pre-installed.

Flexibility & Customization Options:
K0s is highly customizable. It enables the user to configure advanced networking, storage, and security settings , Enable or disable specific Kubernetes components.
All can be done via the k0sctl.yaml file via the k0sctltool.

Documentation:
Beginner to Intermediate level of documentation clarity, some sections have excellent explanations with diagrams, others require some Pre-knowledge in some topics like storage or security.
Also Includes guides for single-node, multi-node, and high-availability setups.

Community support:
•The project is backed by Mirantis, a well-known Kubernetes contributor.
•Their GitHub Repo is stared with +4.1k, which is relatively great measured to the project lifetime.
•K0s has less community-created tutorials compared to the previous options (KinD & Minukube) as it is the newest lightweight K8s distro compared to others.

Suitability & Usage:
K0s shines with IoT deployments as it is a very lightweight single-binary ..
Very recommended for:
• Edge computing and IoT deployments
• Air-gapped deployments
• Testing CI/CD pipelines integration with K8s environment.
• Testing multi-node Cluster configurations and HA scenarios.
• Learning topics that are a bit above the basics
Not recommended for:
• Networking Complexity: Advanced networking setups can be tricky to configure.
• Performance testing or testing low latency workloads
• Complex large Stateful applications
• Big Production-Like environment deployments

4- MicroK8s

Quick glance:
A very lightweight, minimalistic Kubernetes distribution developed by Canonical, the company behind Ubuntu.

It packages all the essential components of Kubernetes into a single, easy-to-install package, allowing users to run a Kubernetes cluster on a single machine or across multiple nodes with minimal effort.

It uses Dqlite (a lightweight distributed SQLite) for high availability in multi-node setups, reducing the resource overhead compared to traditional etcd-based clusters.

Time to Set Up:
~ 5–7 min for simple single Node clusters

Ease of setup and use:
Installation page here .. For a quick setup guide continue reading:

Quick setup Guide:

1.Install MicroK8s binaries

sudo snap install microk8s - classic

2.Join MicroK8s group
MicroK8s creates a Linux group to enable seamless usage of commands which require admin privilege. To add your current user to the group and gain access to the .kube caching directory, run:

sudo usermod -a -G microk8s $USER
mkdir -p ~/.kube
chmod 0700 ~/.kube

Re-enter the session for the group update to take place:

su - $USER

3.Access your K8s cluster
MicroK8s bundles its own version of kubectlfor accessing the cluster:

microk8s kubectl get nodes

Resource Required & Prerequisites:
Minimum Resources: 2 CPU, 4GB RAM and ~2GB Storage per node for small clusters. (Additional resources depends on the number of nodes).

For Prerequisites:
• An Ubuntu 22.04 LTS, 20.04 LTS, 18.04 LTS or 16.04 LTS environment to run the commands (or
• Other Linux distributions can be used as well but they must support supports snapd
• If you don’t have a Linux machine, you can use Multipass (see Installing MicroK8s with Multipass).

Flexibility & Customization Options:
•MicroK8s provides Add-ons like Helm, Istio, DNS, or MetalLB that can be enabled as needed.
•It supports single-node and multi-node clusters, allowing users to test HA scenarios
•Users can customize their clusters by enabling or disabling add-ons, configuring networking, and integrating with other tools and services.

Documentation:
•The project has a comprehensive and well-organized documentation, making it easy for users to get started and troubleshoot issues. But the absolute beginner may struggle a bit with certain pages as a bit of Linux knowledge is required to customize or configure your MicroK8s cluster (which is a must anyway for anyone learning K8s)

•Official documentation covers installation, add-ons, multi-node setups, and advanced configurations.
•Tutorials and examples are provided for common use cases, such as deploying applications, enabling ingress, and setting up storage.

Community support:
•Large community support with +8.6K stars on GitHub
•All created issues are actively followed and resolved by contributors.
•Also many community-created tutorials and guides are available online in text and video forms

Suitability & Usage:
Very recommended for:
• Edge computing and IoT deployments
• Testing CI/CD pipelines integration with K8s environment.
• Testing multi-node Cluster configurations and HA scenarios.
• Learning topics for K8s beginners

Not recommended for:
• Big Production-Like environment deployments
• Performance testing or testing low latency workloads
• Complex large Stateful applications

5- K3s

Quick glance:
K3s is developed and maintained by Rancher (now part of SUSE) and is ideal for edge, IoT, and resource-constrained environments

It is packaged as a single binary (~100 MB) that includes all necessary components (The API server, controller manager, scheduler, and kubelet)

It is designed for running Kubernetes clusters in resource-constrained devices like Raspberry Pis, therefore it bundles lightweight alternatives like SQLite instead of etcd (however etcd, MySQL, and PostgreSQL are also supported for high-availability setups).

Time to Set Up:
~ 5–7 min

Ease of setup and use:
K3s provides an installation script to install it as a service on systemdor openrc based systems.

K3s package includes tools like kubectl, crictl, and ctrout of the box, reducing the need for additional installations.

Note: It is not recommended to use snap based Docker packages. The “known issues” section here mention it.

Installation page here .. Default installation summarized in the next section

Quick Setup Guide:
Get the installation script which installs (kubectl , crictl, ctr, k3s-killall.sh, and k3s-uninstall.sh)

curl -sfL https://get.k3s.io | sh -

A kubeconfig file will be written to /etc/rancher/k3s/k3s.yaml and the
kubectl tool is installed by K3s will automatically use it —
And you are READY To GO

Resource Required & Prerequisites:
•Minimum Resources: 2 CPUs , 2GB RAM with ~4GB Storage.
•For Prerequisite, Only Linux e.g OpenSUSE, Ubuntu ,, etc is needed

Flexibility & Customization Options:
•K3s is highly modular and customizable.
•Users can customize components like the container runtime, networking, or storage to suit your needs.
•Multi-Node Clusters mode is supported, but K3s is often used for single-node setups.
•With a config.yaml file created at /etc/rancher/k3s/k3s.yaml users can customize many deployment options like CNI, CRI and Storage options.

Documentation:
K3s has a well-organized and easy to follow documentation with many explanations, F&Qs and examples for common use cases, such as deploying applications or setting up multi-node clusters.

Community support:
It is best known of its use with Raspberry Pis for Edge and IoT Use Cases where resources are limited.
Very recommended for:
• Edge computing and IoT deployments.
• Air-gapped deployments.
• Testing CI/CD pipelines integration with K8s environment.
• Learning topics that are a bit above the basics.

Not recommended for:
• Big Production-Like environment deployments.
• Testing multi-node Cluster configurations and HA scenarios.
• Networking Complexity: Advanced networking setups can be tricky to configure.
• Performance testing or testing low latency workloads.
• Complex large Stateful applications.

Happy Learning!
Anas Alloush
Telco Cloud Specialist