Set Up MicroK8s to Run an Edge Application
We already know that Kubernetes is the world’s preferred orchestration platform for container-based applications, automating the deployment and scaling of these apps, and streamlining maintenance operations. However, Kubernetes comes with its own complexity challenges. So how can an enterprise take advantage of containerization to tackle Internet of Things complexity and not end up with yet more complexities of Kubernetes?
Canonical’s MicroK8s is a powerful, Cloud Native Computing Foundation-certified Kubernetes distribution. Here are some of the key reasons, I feel, why it has become a powerful enterprise edge computing platform:
- Delivered as snap packages: These are app packages for desktop, cloud, and IoT that are easy to install and secure with auto-updates and can be installed on any of the Linux distributions that support snaps. This makes MicroK8s ideal for running on the vast variety of hardware that comprises the IoT.
- Strict confinement: This ensures complete isolation from the underlying operating system and a tightly secured production-grade Kubernetes environment, all in a small footprint ideal for edge gateways.
- Production-grade add-ons: Istio, Knative, CoreDNS, Prometheus, Jaeger, Linkerd, Cilium, and Helm are available as add-ons these are simple to set up, with just a few lines of commands.
- Kubeflow is also available as an add-on to MicroK8s for improved artificial intelligence (AI) and machine learning (ML) capabilities.
With its ability to reduce complexity, MicroK8s is going to accelerate IoT and edge deployments. Treating IoT devices like distributed containerized applications allows developers to focus on applications rather than infrastructure and make life easier for operations teams.
MicroK8s lets you cluster Kubernetes installations together so they can form a single cluster and place workloads on one or more of these nodes. In this article, we will learn how to deploy onto a MicroK8s cluster an application based on Stateful Angular, Spring Boot, and Postgres, in which users can create a customer with attributes “Name” and “Age.”
If you’re new to Kubernetes, I recommend reading the following hands-on guides before reading this one
- Kubernetes – Introduction & key concepts
- Kubernetes tutorial – Create simple cluster & Deploy app
- Kubernetes tutorial – Create deployments using YAML file
- Get smallest, fastest, fully-conformant MicroK8s Kubernetes
Set up a MicroK8s Cluster
Image – Sample Application.
To deploy this application, we would be using PersistentVolume (PV) which is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned. PVs are volume plugins like Volumes but have a lifecycle independent of any individual pod that uses the PV.
PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany).
In the next section, we will look how to install and deploy our application on to MicroK8s cluster.MicroK8s is deployed via Snaps. Snaps are containerized (like Docker) software packages that are easy to create and install, they bundle their dependencies, they work on all major Linux systems without modification. Snaps auto-update and are safe to run. Also, note MicroK8s snap would be frequently updated to match each release of Kubernetes.
MicroK8s snap can be installed using the command below:
snap install microk8s --classic --beta
If you’re looking for detailed steps, please refer to this article.
At this point, we have installed MicroK8s, check whether the newly deployed node is in Ready state using the following command.
kubectl get nodes
Image – 2-node Microk8s Cluster
Deploy Postgres on Kubernetes using PersistentVolume
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 |
kind: PersistentVolume apiVersion: v1 metadata: name: postgres-pv-volume labels: type: local app: postgres spec: storageClassName: manual capacity: storage: 100Mi accessModes: - ReadWriteMany hostPath: path: "/var/lib/postgres" --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: postgres-pv-claim labels: app: postgres spec: storageClassName: manual accessModes: - ReadWriteMany resources: requests: storage: 100Mi --- apiVersion: apps/v1 kind: Deployment metadata: name: postgres spec: selector: matchLabels: app: postgres replicas: 1 template: metadata: labels: app: postgres spec: containers: - name: postgres image: postgres:10.4 imagePullPolicy: "IfNotPresent" ports: - containerPort: 5432 envFrom: - configMapRef: name: postgres-config volumeMounts: - mountPath: /var/lib/postgresql/data name: postgredb volumes: - name: postgredb persistentVolumeClaim: claimName: postgres-pv-claim --- apiVersion: v1 kind: Service metadata: name: postgres labels: app: postgres spec: type: NodePort ports: - port: 5432 selector: app: postgres |
We have created four resources in the above manifest file. A PersistentVolume, a PersistentVolumeClaim for requesting access to the PersistentVolume resource, a service for having a static endpoint for the Postgres database, and a deployment for running and managing the Postgres pod.
The Postgres container reads database credentials from environment variables using postgres-config ConfigMap.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: v1 kind: ConfigMap metadata: name: postgres-config labels: app: postgres data: POSTGRES_DB: postgresdb POSTGRES_USER: postgresadmin POSTGRES_PASSWORD: admin123 |
Let’s now deploy Postgres by applying the YAML configuration:
Image – Apply Postgres Deployment.
You can check all the resources created in the cluster using the following commands:
Image – Status of Postgres deployment.
Image – Postgres PV,PVC Deployments.
Deploy the Spring Boot app on Kubernetes
Now that we have the Postgres instance deployed, Let’s proceed with the deployment of the Spring Boot app.
The following is the deployment manifest for the Spring Boot app:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
apiVersion: apps/v1 kind: Deployment metadata: name: spring-boot namespace: default spec: selector: matchLabels: app: spring-boot replicas: 1 template: metadata: name: spring-boot labels: app: spring-boot spec: containers: - name: spring-boot env: - name: POSTGRES_USER valueFrom: configMapKeyRef: name: postgres-config key: POSTGRES_USER - name: POSTGRES_PASSWORD valueFrom: configMapKeyRef: name: postgres-config key: POSTGRES_PASSWORD - name: POSTGRES_HOST valueFrom: configMapKeyRef: name: hostname-config key: postgres_host image: karthi4india/orderapi:latest --- apiVersion: v1 kind: Service metadata: name: spring-boot labels: app: spring-boot spec: type: NodePort ports: - port: 8080 selector: app: spring-boot |
The above deployment uses the ConfigMaps stored in postgres-config that we created in the previous section.
Let’s apply the manifest file to create the resources
Image – Create SpringBoot Deployment.
You can check the created deployments like this:
Image – Status of the deployments.
Deploy the Angular App on Kubernetes
Next step is to deploy the Angular app using Kubernetes, here is the deployment manifest:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
apiVersion: apps/v1 kind: Deployment metadata: name: angular namespace: default spec: selector: matchLabels: app: angular replicas: 1 template: metadata: name: angular labels: app: angular spec: containers: - name: angular image: 'karthi4india/orderui:latest' imagePullPolicy: Always volumeMounts: - name: env-vars mountPath: /usr/local/apache2/htdocs/assets volumes: - name: env-vars configMap: name: angular-env-vars --- apiVersion: v1 kind: Service metadata: name: angular labels: app: angular spec: type: NodePort ports: - port: 4200 selector: app: angular |
Let’s apply the above manifest file to deploy the Angular app
Image – Create Angular Deployment
You can check all the created deployments like below:
Deploy Ingress
Final step is to deploy Ingress that provides external access to the services in a cluster.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-service annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/rewrite-target: /$1 spec: rules: - http: paths: - path: /?(.*) backend: serviceName: angular servicePort: 4200 - path: /api/?(.*) backend: serviceName: spring-boot servicePort: 8080 |
Let’s apply the above manifest file to deploy the Ingress service:
Image – Deploy Ingress service
You can check all the created ingress deployment like below:
Image – Ingress is created
You can check all the Services created using the command below:
Image – Services List
That’s it! Now, you’ll be able to use the frontend app. Here is how the app looks like:
Image – Create Customer
Image – Customer has been created
MicroK8s gives you troubleshooting tools to check out what has gone wrong. Be sure to check out the common issues section for help in resolving the frequently encountered problems.
With its ability to strengthen Kubernetes productivity, and reduce complexity MicroK8s is a uniquely positioned for accelerating IoT and edge deployments.
Useful Resources :
- MicroK8s Documentation
- Command Reference
- Services exposed and ports used