Skip to content

Installation Considerations - MicroK8s⚓︎

Deploying Expeto xCore on MicroK8s can be an efficient way to manage private and public 4G/5G networks within a lightweight Kubernetes environment. However, MicroK8s’ design choices, such as a simplified architecture, snap-based lifecycle management, and its focus on small-scale or edge deployments, may present challenges during installation and configuration.

This document outlines the most common challenges you might encounter when using MicroK8s as the Kubernetes platform for xCore. By understanding these potential issues upfront, you can proactively address them to ensure a smoother deployment experience. Each section categorizes and explains these challenges to help you better prepare and adapt the deployment process to MicroK8s’ environment.

Networking Challenges⚓︎

Port Range Adjustments⚓︎

  • NodePort traffic for xCore requires configuring a custom port range (e.g., 30000-38413). MicroK8s updates or reboots may reset these configurations, necessitating reapplication.

Load Balancer⚓︎

  • MicroK8s does not include a native load balancer. Deploying MetalLB or similar solutions is required for external traffic. Misconfigured BGP routes or IP pools can result in connectivity issues.

Network Policy Enforcement⚓︎

  • MicroK8s does not enforce network policies by default. This could lead to security vulnerabilities or unintentional exposure of services. Users should define explicit network policies for xCore.

Advanced Networking (Multus)⚓︎

  • Multus requires manual configuration of NetworkAttachmentDefinitions. Misconfigurations may prevent xCore pods from utilizing additional network interfaces effectively.

Persistent Storage Issues⚓︎

Default Storage Class⚓︎

  • The hostpath-storage add-on (microk8s enable hostpath-storage) is not production-grade and unsuitable for shared access in multi-node environments. Users should configure external storage solutions like NFS, Ceph, or dynamic storage classes.

Storage Reset on Updates⚓︎

  • Snap-based updates may reset storage configurations, potentially leading to data loss if external storage is not configured.

Resource Limitations⚓︎

Default Resource Allocation⚓︎

  • MicroK8s’ lightweight design may allocate insufficient CPU, memory, or storage resources. Users must ensure nodes meet xCore’s minimum requirements (4 CPUs, 8 GB RAM per node).

Scaling Challenges⚓︎

  • Adding nodes in MicroK8s is a manual process, requiring careful configuration to maintain consistent resource availability and avoid scheduling issues.

Cluster Lifecycle Management⚓︎

Snap Updates⚓︎

  • Automatic updates to MicroK8s may disrupt xCore deployments by altering configurations or introducing Kubernetes version mismatches. Users should disable automatic updates or carefully monitor updates.

Node Restarts⚓︎

  • Custom configurations like service-node-port-range or SCTP kernel module enablement may not persist across reboots. Users should create startup scripts to reapply these settings.

SCTP Kernel Module⚓︎

Manual Enablement⚓︎

  • SCTP support is required for private radio integrations (e.g., gNodeB/eNodeB) but must be manually enabled (modprobe sctp). Users should also configure persistence across reboots.

Kernel Compatibility⚓︎

  • Certain kernel versions may lack SCTP support, requiring updates or custom builds.

RBAC and Helm Configuration⚓︎

RBAC Permissions⚓︎

  • MicroK8s uses a simplified RBAC setup. Missing service accounts or role bindings for Helm deployments can lead to failed installations of xCore components.

Helm Repository Access⚓︎

  • Network issues, proxy restrictions, or outdated Helm versions may block access to Expeto’s private Helm repositories. Users should validate connectivity and Helm configurations before deployment.

Ingress and TLS Certificates⚓︎

Certificate Management⚓︎

  • While MicroK8s includes a built-in cert-manager (microk8s enable cert-manager), it may conflict with Helm-based configurations. Users may need to manually install cert-manager via Helm for xCore.

TLS Certificate Handling⚓︎

  • Integrating custom TLS certificates often requires additional steps, such as importing certificates into the cluster or modifying ingress configurations.

Validation and Debugging⚓︎

Cluster Readiness⚓︎

  • Users may skip verifying that all MicroK8s components (e.g., ingress, storage) are in a Ready state. Running microk8s inspect can help identify common issues.

Testing Configurations⚓︎

  • Skipping validation steps like helm template or kubectl apply --dry-run can result in unnoticed syntax or logic errors in values.yaml.

Log Access⚓︎

  • Debugging MicroK8s components (e.g., ingress) can be challenging due to limited logging by default. Users may need to enable verbose logging or access component-specific logs for troubleshooting.

Service Discovery⚓︎

  • Users should test service connectivity between xCore components using tools like kubectl exec and ping to identify potential networking or DNS issues early.

Advanced Optimizations⚓︎

Kernel and Network Tuning⚓︎

  • High-throughput deployments require optimized kernel parameters (sysctl). Users can apply these changes using nodeConfig in values.yaml.

Resource Requests and Limits⚓︎

  • Users must review resource requests and limits in values.yaml to ensure they align with the cluster’s capacity. Misaligned settings can lead to resource contention or pod evictions.

Horizontal Pod Autoscaling⚓︎

  • If autoscaling is configured, users should verify it is functioning (kubectl get hpa) and adjust thresholds based on expected load.