Upgrade for centos/rocky linux to new major versions is not supported. If you look for it there are procedures, but the changes between major versions can be so siginificant that this is not a good idea. Therefore, an approach I often use is to upgrade by installing the newer version next to the current version. Of course, I have also paritioned my old system to separate my home directory and other important directory into separate partitions so that the upgrade does not require copying user files.
This has some risks, since you might lose connectivity to the old linux version if the upgrade fails. Continue reading
When I setup my kubernetes cluster using kubeadm some years ago, I decided to use a simple non-HA setup of kubernetes, because (1) it simplifies the setup and (2) the cluster will be running on a single server anyway. In fact I am using kubernetes mainly for deployment flexibility and not as much for high availability. Now I am running a mix of centos 8 stream and centos 7 nodes which will all be end of life in June 2024. With kubernetes, doing such an upgrade should be easy:
- add a new controller node on a newer OS and join it to the cluster
- remove the old controller
- replace worker nodes one by one
However, the first two steps will give problems since in a non-HA setup, the IP address of the API server is used by all components that connect to the API server. This will make it impossible to switch over to the new controller node in a transparent way.
As part of a previous post, I described how I am running etcd in memory. This setup requires that regular backups are taken of etcd and this must be monitore.
Chat GPT sure knows a thing or two about kubernetes. Here is the output when I asked it to produce a rhyme about kubernetes (with one minor edit):
In the world of tech, there’s a tool so great
It’s called Kubernetes, it’s never too late
To learn how it works, it’s a valuable skill
For managing containers, it fits the bill
With Kubernetes, you can deploy with ease
Your apps and services, they’ll run with such breeze
Scaling and load balancing, it does it all
Ensuring your systems never stumble or fall
The clusters it creates are strong and secure
With backups and failovers,
it’s hard to workloads endure
A smoother experience, you’ll hardly find
Kubernetes is the key, to a peace of mind
So if you’re a techie, and want to succeed
Learn Kubernetes, it’s what you need
With its powerful features, you’ll never lose
It’s the tool to have, and it’ll never refuse.
I am experimenting currently with argocd with the aim to have an (almost) fully automated bootstrapping of my kubernetes cluster at home. One of the first things to do when experimenting is to have a test environment. There are different deployment options for argocd to consider:
- deploy argocd in the cluster that it is managing
- deploy argocd in another cluster
After setting up my kubernetes cluster at home back in June 2021, one of the first things I noticed was a lot more noise from the server. Apparently, it was just a lot of disk IO coming from kubernetes and in particular etcd. Therefore, I decided to fix this problem.
I got a new laptop last week for work and needed to get it ready. Now new laptops usually mean new hardware and that can spell problems if you are installing linux. This is because the latest hardware may be used and linux usually needs some time to catch up with the latest hardware. This started out with the graphical installation not working. Luckily though, rocky linux 9 also supports a VNC install. So this issue was solved by connecting the laptop to wired ethernet and using VNC from another laptop to do the installation. This all went without problems. Next up was the NVIDIA driver for which I am using the RPM packages from the NVIDIA CUDA repository. These usually work fine, however, this time there was a mismatch where the driver was installed in the wrong directory; easily fixed though by fooling the NVIDIA RPMs by creating a symbolic link in /lib/modules: 5.14.0-162.12.1.el9_1.x86_64 -> 5.14.0-162.12.1.el9_1.0.2.x86_64/.
Finally, there was the sanity check to verify all devices such as webcam, microphone, speakers etc.. This is where all the problems started.
I am starting a new job on March 1st 2023 and on this happy occasion, the traditional countdown timer is up again!
The timer appears each time something important is about to happen in my life, see also:
This post describes how to monitor logs in kubernetes with grafana and loki. This covers the use case of logging for troubleshooting purposes. That is, it allows analysing human readable logs coming from multiple systems in one aggregated log. Human readable logs are required for troubleshooting and optimization. It is the bare minimum of logging that is required.
One part of the migration of my old setup to kubernetes is the migration of an old Jira 6.1 instance. Unfortunately, running that same jira instance in a container did not work because of licensing issues, and apparently it is impossible to get new licenses for such an old jira instance. Also it seems no longer possible to run Jira at home for open source projects and only cloud hosting may be used. A prerequisite for what follows is that you have a cloud instance of Jira running at atlassian cloud with a valid license (open source or commercial). The description is not exhaustive and you will need atlassian documentation and support to get the full picture, but this post tries to describe some of the essential steps in the migration.
Untortunately migrating directory from such an old Jira instance to Jira cloud is impossible and must be done in steps.