Kubevirt - Running VMs under Kubernetes
Intro
Kubevirt.io is a (CNCF) project to make it possible to run virtual machines as containerized workloads on a k8s cluster. We'll have a look at it by deploying it to a Rancher k3s cluster and spinning up a Debian guest VM.
We're using version v0.34.2 of Kubevirt and a three node 1.19.3+k3s2 cluster on bare metal.
Tags
- Read more about Kubevirt - Running VMs under Kubernetes
- Log in to post comments
Setting up a bare-metal cluster - part 2
The story so far
In the first part (part1) we set up and provisioned three servers to serve as nodes in the cluster. We have a virtual ip managed by Keepalived and a HA etcd cluster that we will be using as external datastore for the k3s cluster. Some other stuff was installed and configured using ansible as well; we have docker installed, though in principle we could have simply let k3s use the default containerd.
Tags
- Read more about Setting up a bare-metal cluster - part 2
- Log in to post comments
Setting up a bare-metal cluster - part 1
Introduction
We are going to setup a Kubernetes cluster on bare-metal. Specifically a HA instance of Rancher's k3s using etcd and a virtual ip on three small form factor Thinkcentre machines. The main purpose is to create a simple home lab to explore Kubernetes, do local development and also to host several in-house workloads. The underlying OS is Debian Buster. We'll also look at Ansible to do the initial provisioning of the servers.
Versions used:
- Read more about Setting up a bare-metal cluster - part 1
- Log in to post comments
Jupyterhub on Kubernetes
Introduction
Deploying Jupyterhub to a kubernetes cluster allows multiple users an easy way to develop, run and test their notebooks. The hub takes care of spawning Jupyter instances for each user and pruning their pods when not in use anymore. Each new user gets their own volume (through a persistent volume claim), containing all their notebooks, files and working environment. More information on https://zero-to-jupyterhub.readthedocs.io/en/latest/index.html
- Read more about Jupyterhub on Kubernetes
- Log in to post comments
Buildkit-cli for kubectl
Building images on the cluster
Developing and testing on a kubernetes cluster usually means building a new image, pushing it to your registry, then pulling and redeploying your containers. Especially for local clusters, like on premises or even on your own workstation in a vm, it would be nice to be able to build your images directly on the nodes, making turn around much faster. Buildkit already exists, but now a new github project makes this even easier by giving you a kubectl extension to build directly on your cluster using regular kubectl commands.
- Read more about Buildkit-cli for kubectl
- Log in to post comments
Switching to 64 bit kernel
Introduction
The Hollyberry cluster has been running on Raspian's standard 32 bit kernel, which means we can only use armv7 images. The latest beta release however allows us to use a 64 bit kernel. Although the distribution itself will stay 32 bit for now, switching to 64 bt will allow us to use armv8 images next to armv7. To switch we'll update the firmware on the Raspberry pi's, (re)-enable some configurations and reboot.
Tags
- Read more about Switching to 64 bit kernel
- Log in to post comments
Migrating to a static site
Migrating the old site
The old site was hosted on Drupal 6 and when we were planning to redesign it and move to Drupal 8, the question arose what to do with the old site. We decided to archive it and host it as a static site, for nostalgic reasons. Below is a description of how we did this using a combination of Httrack, Docker and Kubernetes. The end result is a static site that is build in a CI/CD pipeline and deployed on a Kubernetes cluster using Helm.
Check out the end result: old.happyconsultancy.com
- Read more about Migrating to a static site
- Log in to post comments
Zabbix remote monitoring
Introduction
When we have a Zabbix server monitoring on-premises servers, we can use both active and passive zabbix-agents, connecting to the Zabbix server over the local network. However, for remote servers with only public IP addresses, we would need to open up the ports for Zabbix on either the Zabbix server (10051/tcp for active checks) or the monitored host (10050/tcp for passive checks). This isn't ideal of course, so it would be better to tunnel these connections over SSH.
Tags
- Read more about Zabbix remote monitoring
- Log in to post comments