Helm Kubernetes

Helm is a Kubernetes package manager that helps you find, share, and use software built for Kubernetes. With Helm Charts, you can bundle Kubernetes deployments into a single package you can install by running a single command. At Apica, we use Helm Charts regularly. One of our favorite Helm Charts is Apica – the same Helm Chart we use for quick deployments of the Apica observability platform for customers, prospects, and folks who’d love to know more about what we’re building. 

This article will explain how you can deploy your favorite Helm Chart on MicroK8s in under 5 minutes. 

What is MicroK8s?

MicroK8s is a lightweight, pure-upstream Kubernetes aiming to reduce entry barriers for K8s and cloud-native application development. It comes in a single package that installs a single-node (standalone) K8s cluster in under 60 seconds. While MicroK8s has all the Kubernetes core components, it is also opinionated, which means that many of the add-ons you would typically look for in Kubernetes, such as DNS, Helm, registry, storage, etc. are all a single command away.

What is Apica?

Apica is a complete observability platform for monitoring, log aggregation, and analytics with an infinite storage scale that aims to bring simple and powerful logging to the masses. Apica uses AWS S3 (or S3-compatible storage) for data at rest and allows the sending of logs from Kubernetes, on-prem servers, or cloud VMs with ease. 

The Apica platform includes:

  • A User Interface (UI)
  • command-line toolkit
  • A monitoring stack for time-series metrics, and;
  • A log analytics stack for log data.

Now that you’re acquainted with MicroK8s and Apica and their awesomeness, why don’t we jump right into the integration?

The Setup

In this demo, we’ll use the Apica Helm Chart. You can also use your own favorite Helm Chart that you’d like to try out. Let’s also assume that you have access to the Linux operating system.

Installing MicroK8s

As a first step, let’s install MicroK8s on your machine by running the following commands:

sudo apt-get -y update
sudo snap install core
sudo snap install microk8s --classic
sudo usermod -a -G microk8s $USER
sudo chown -f -R $USER ~/.kube
sudo microk8s config > ~/.kube/config

Now, let’s check whether MicroK8s is up and running or not with the command:

sudo microk8s status

Enabling add-ons

Now that we have MicroK8s up and running, let’s set up your cluster and enable the add-ons that MicroK8s readily provides, like Helm, DNS, ingress, storage, and private registry. These add-ons can be enabled and disabled at any time, and most are pre-configured to work without any additional setup.

Run the following commands to enable add-ons:

microk8s enable helm
microk8s enable storage
microk8s enable dns
microk8s enable ingress
microk8s enable registry
microk8s.kubectl config view > $HOME/.kube/config

Provisioning an IP address

We need an endpoint or an IP address to access the application we’re spinning up. This endpoint can either be within or outside our cluster. For this, let’s leverage MetalLB – a Kubernetes-aware solution that can monitor for services with the type LoadBalancer and assign them an IP address. Alternatively, you can also set an IP address while enabling add-ons. 

While provisioning an IP address, you can use your local machine’s IP address, which pulls up the stack at IP-address:80. If you do not know your local machine’s IP address, run the ifconfig command as shown below and use the output of the command: 

ifconfig:
wlp60s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.27 netmask 255.255.255.0 broadcast 192.168.1.255

Next, enable MetalLB by running:

microk8s enable metallb
Enabling MetalLB
Enter each IP address range delimited by comma (e.g. '10.64.140.43-10.64.140.49,192.168.0.105-192.168.0.111'): 192.168.1.27-192.168.1.27

Note: If you’re spinning up an EC2 instance from AWS, MetalLB might not work due to private/public IP configuration. We’ll take a closer look at and resolve this issue in another article.

Bring in the Helm Chart

Now that the configuration bits are in place, it’s time to bring in your Helm Chart. As mentioned above, we’re using the Apica Helm Chart and Helm 3 in the following commands. You can replace the Helm Chart repo URL in the following command with your own Helm Chart’s repo URL if you’re trying another chart. 

Run:

helm repo add Apica-repo https://Apicaai.github.io/helm-charts
helm repo update

Bringing up Apica

Next, let’s create a namespace called Apica for the stack to spin up from and start running with the command:

microk8s kubectl create namespace Apica

And then run helm install with the storage class set to the microk8s-hostpath as shown below:

helm install Apica -n Apica --set global.persistence.storageClass=microk8s-hostpath Apica-repo/Apica -f values.yaml  --debug --timeout 10m

Note: The values.yml file used in the command above is customized to suit our cluster’s configuration. You can download the values.yml file from docs.apica.io and edit it to suit your cluster’s needs, and then run the above command. 

Apica is now ready to go! Before we get to the UI, let’s inspect the pods in your cluster by running the following command in the Apica namespace you created:

microk8s kubectl get pod -n Apica

We can now access the Apica UI by hitting the MetalLB endpoint we defined earlier in this article. To find the endpoint, let’s search for the LoadBalancer service that knows which IP address MicroK8s exposes. 

Run the command:

microk8s kubectl get service -n Apica |grep -i loadbalancer
Apica-kubernetes-ingress  LoadBalancer   10.152.183.45  192.168.1.27

80:30537/TCP,20514:30222/TCP,24224:30909/TCP,24225:31991/TCP,2514:30800/TCP,3000:32680/TCP,514:32450/TCP,7514:30267/TCP,8081:30984/TCP,9998:31425/TCP     18m

Now, using a web browser of your choice, navigate to the IP address shown by the LoadBalancer service above: http://192.168.1.27:80

And voila! Our Apica deployment using a Helm Chart is up and running!

The Apica login screen

On a side note, we wanted to talk about how cumbersome logging is. Most of the logging solutions out there hold data in proprietary databases that use disks and volumes to store their data. What’s wrong with that, you ask? Well, disks and volumes need to be monitored, managed, replicated, and sized. Throw in clustering in the mix and your log analytics project is now working on someone else’s software and is a storage nightmare. For these reasons, we built the Apica observability platform – to bring easy logging to everyone who needs it. Using Apica, you can ingest log data from Kuberneteson-prem servers, or cloud VMs, applications, and several other data sources, helping you gain complete visibility over your infrastructure and applications without burning a massive hole in your pocket.

We love making logging easy. To show you how easy it is to get going with the Apica platform, our next article will show you how to automate the Apica platform’s deployment on AWS using Helm Charts on MicroK8s using a CloudFormation template. Meanwhile, if you have questions about Apica and would like to know more, please visit our website and reach out!