Whenever you try to show your techy skills, most of times you either spend money, time or both looking for a way to show off your portfolio. This could vary from content creation, web development, software, data science and Cloud. Most of us tend to share safely our content through static-site generators (SSG) like Github Pages, or a Content Site Management (CMS) like the infamous Wordpress.
However this two may look a bit coupled and limitating specially when working with authentication, authorization, dynamic data, or custom content, even though both are getting more and more plugins to fill the gaps. Another plausible option could be application platforms like Heroku or Vercel that let us deploy full stack applications even containerized ones that should fit 99% of the cases.
But if you run multiple apps that can be dependent of others, and don't want to spend much on a platform probably you would end up hosting your own platform. This may sound weird to you at first but with a bunch of raspberry pis and some ssd you can host your own domain, get SSL on literally everything, run your own VPN for remote access, unlimited storage, pipeline orchestration, fault tolerance, you name it. Disclaimer: you may need to known that nothing's free and so it comes with a cost, opening the 443 port of your router.
So despite the fact of the actual pandemy, a raspberry pi 4b base model is at 35$ and top 8Gb ram model at 75$. and the good news is that you can boot Linux from an SSD now. It is also well known that raspberry runs ARM architecture, the same as latest Apple M1 Processor Family, and that ARM was acquired last year by Nvidia. Indeed you may run ARM on your mobile phone too. Thus, ARM officially seems to be in bloom.
Having said that, let me introduce some of the main features a self hosted platform may need.
First, a domain should be owned, so that tls can be applied to all our subdomains.Second, the root of our domain should point to our public IP so that it can redirect HTTPS traffic to our router.Third, our router should forward both our domain to our cluster.Fourth, our cluster will reserve range of IP addresses from our LAN network so it can be reachable. For this, an external Load Balancer will assign the IP addresses when needed, and Ingress/Egress will act as proxy middlewares for redirection. And an internal loadbalancer will be in charge of regulating the load of the deployments.
All this, is the cluster state which is kept in some form of database, usually in etcd. Some of our physical hardware will be elected as master, in charge of the control plane, and rest as workers for the data plane.And nodes will get workloads as statefulsets, deployments, replicaset and pods. Being a pod a deployment of one replicaset. Those workloads will be accessed by Services, and those services can be exposed to the outisde by ingresses.
Self hosting a platform is not an easy task and you may probably think even less on a few raspberry pi. Though you may have noticed it, our desired platform looked a lot like Kubernetes Engine.
Kubernetes is an Open Source Cloud Native Orchestration created by Google, which resembles many concepts from containers and orchestration tools.
Every major cloud vendor has its own Kubernetes implementation, Amazon uses EKS, Google uses GKE, Azure has AKS, Digital Ocean has DOKS, etc.
Rancher made its own lightweight implementation taking away most of the cloud platform vendor integrations and named it after K3S, which was the first kubernetes distribution for ARM. And yet, getting popular by the day, releasing its HA dockerized version k3d and an alpine linux OS for K3s named K3OS.
Google also released its own lightweight distro, minikube, which is great too but this flavour lack of multi-arch compatibility in some of their stack, such as Istio. Canonical launched microk8s, which allows to create several nodes on the same machine using some hypervisor like KVM or VirtualBox installed from the snap package installer. Kubernetes IN Docker (kind) from kubernetes itself. K0s from mirantis quite similar to k3s bundled in a binary, minishift from RedHat, etc.
In Kubernetes, the minimal unit of deployment is called a Pod. 1/N pods form a replicaset, and 1/N replicaset form a deployment. Deployments are stateless, which means that don't depend on the storage, and can be spin up and down easily. On the other hand deployments that need to be synced, or have an UUID for reconciliation, like a database, a message queue system, are meant to be statefulsets.
The pods are usually accessed through services, and those services are enabled by an ingress controller.
K3s uses Traefik as Ingress Controller, Klipper as internal Load Balancer, and CoreDNS for internal naming resolution. Whereas Klipper will be replaced by MetalLB, setting Address Resolution Protocol (ARP) for IPv4 and Neighbour Discovery Protocol (NDP) for IPv6 making IPs reachable from LAN network when a service is created as Load Balancer. It uses Containerd virtualization by default, flannel as the Container Network Interface plugin and Etcd as the key-value store for kubernetes. Rancher also provides a system upgrade controller to upgrade k3s version and integrations with Rancher products.
This way we can set up some internal dns in our LAN so our ingress controller can be accessed outside of kubernetes.
In this series I will cover how can you spin up your own platform orchestration using Cloud Native Open Source tools and make a comparison with Cloud Platforms vendors.
Tags