Guide for updating the Kubernetes cluster –
part 3
- March 2 2025
In this article, you will learn:
- how to prepare the Blackbox Exporter update in a Kubernetes cluster using Helm, ArgoCD and a values.yaml file,
- why it is worth comparing manifests with the current cluster state before synchronizing the application,
- how to update Control Plane nodes using kubeadm, kubelet and kubectl,
- how to safely update worker nodes with Ansible playbooks while maintaining service availability.
In this article, we will discuss the key steps and recommendations for implementing and upgrading the component in the Blackbox Exporter cluster and upgrading the actual Kubernetes. MetalLB, ArgoCD, Portworx and prometheus-stack were discussed in the first and second parts of the article.
Blackbox Exporter
For the present cluster, upgrading the Blackbox Exporter version was essential to maintain the stability and efficiency of monitoring services. The Blackbox Exporter update process is not significantly different from the one for the application, but here there was no need to create a separate application before implementing changes.
When it comes to the monitoring architecture, Blackbox Exporter plays a key role, enabling the collection and analysis of data on the status and availability of services. For this reason, it is worth using the existing monitoring application, which has been designed and adapted to for the update of the entire range of monitoring tools, including prometheus-stack.
With the monitoring application that has already been configured and optimized for requirements, the Blackbox Exporter update process could be carried out efficiently and the risk of possible complications or incompatibilities in the monitoring environment was minimized. This way, we ensured smooth monitoring operations and high-quality services by the cluster.
Setting up the manifest
To set up the manifest for the update of Blackbox Exporter, it is advised to rely on the values.yaml file as well as the Helm tool.
To generate the manifest, use the following command:
In the previous command, {{target-version}} corresponds to the current version of Blackbox on the cluster, based on the values-blackbox.yml file.
Thanks to this operation, we obtained a manifest ready to be implemented and that takes into account the specifications of the monitoring environment and ensures compliances with the clusters’ requirements.
Comparing ArgoCD to the cluster
Like with the previous versions, it is essential to precisely adapt the file to the requirements and configuration of the cluster. In order to identify the essential changes, it is worth using the AppDiff tool available in ArgoCD, that will allow you to compare te repository with the current state of the cluster.
The goal is to compare the ArgoCD manifest with the real state of the cluster, to verify that the configuration are compatible. This operation is not very different from the previous ones.
After identifying the differences and implementing the essential changes, the new manifest should be added to the /prometheus-stack/base/kustomization.yml file.
The final structure of the file in the main folder should look as follows:
After having compared the repository with the current state of the environment, we can proceed to the synchronization of the application with the help of ArgoCD. This way, we have a restore point and we ensure consistency and coherence of the application’s configuration with the requirements and expectations related to the cluster.
Updating Kubernetes – update of the Control-Plane nodes
Po zaktualizowaniu wszystkich komponentów, należy przystąpić do aktualizacji Kubernetesa. Pierwszym krokiem jest aktualizacja węzłów kontrolnych.
Updating the kubeadm tool
To perform the update, you must first determine the appropriate version that you want to install. Then, after selecting the appropriate version, you can install it by:
After installing the appropriate version of the kubeadm tool, it is time to prepare the upgrade plan by executing this command:
Updating the Kubernetes cluster
Następnie, trzeba wykonać aktualizację klastra Kubernetesa poprzez:
After the upgrade of the kubeadm tool, you also need to update kubelet and kubectl. Before the update, it is best to deactivate their wall, and to reactivate it after the update. To update kubelet and kubectl, follow these steps:
After the node was designated for updating, it was eliminated from the tasks and the correctness of the information was ensured.
Then we updated kubelet and kubectl.
After installing the new versions, restart the kubelet service:
Ultimately, it is worth verifying that the node was put back to work with the help of the following command. Additionally, check that <node-to-drain> is the name for the nodes that have been updated earlier.
Nody worker
Updating the worker nodes is made possible with the Ansible playbook, which is separated into 2 files:
- update-node-k8s.yml – responsible for the update of Kubernetes,
- update-node-os.yml – responsible for the update of the operation system and for the restart of the server.
Please note, that those operations should be executed one by one, node by node, to ensure the continuity of the service availability.
Conclusion
This article ends the series on updating the Kubernetes cluster from the 1.25 version to the 1.26 one. We encourage you to read the first and second part.
In the newest version of the Kubernetes cluster, the PodSecurityPolicy (PSP) mechanism was switched to a more flexible and modern method, called Pod Security Admission (PSA). It is a significant change, that requires careful preparation and strict adherence to procedures during the implementation and updating process of tools in the cluster. The article presented the key steps to complete before updating the cluster, focusing on the services that used rely on PSP.
In summary, the article provides a comprehensive overview of the key aspects related to the update of the Kubernetes cluster, emphasizing the importance of taking into account changes in the security mechanism and complying with the update procedures for each of the cluster components. Please refer to the previous parts of the series to fully understand the migration process and to avoid potential issues during the upgrade.
FAQ
Updating Blackbox Exporter is important because this component is responsible for monitoring the availability and status of services in a Kubernetes cluster. A newer version helps maintain monitoring stability, compatibility with the current environment and high-quality operation of monitoring services.
A manifest for Blackbox Exporter can be prepared using Helm and a values.yaml file. This makes it possible to generate a configuration tailored to the requirements of the monitoring environment and the current version of the component running in the cluster.
ArgoCD allows teams to compare the manifest with the current cluster state using the AppDiff feature. This helps identify differences, apply the necessary corrections and only then synchronize the application. Such an approach reduces the risk of errors and helps maintain configuration consistency.
The Kubernetes update process starts with the Control Plane nodes, where components such as kubeadm, kubelet and kubectl are updated. Then the worker nodes are updated, usually one by one, using Ansible playbooks. This approach helps reduce the risk of service downtime.
As Vice President of Core Logic, Konrad is responsible for developing technology solutions that support the business growth of clients. He has over 20 years of experience in the IT industry, including leading ambitious projects focused on building, scaling, and securing IT infrastructure. He specializes in DevOps, microservices, and cloud solutions. Konrad combines a technological perspective with a business-oriented approach, enabling him to translate complex organizational needs into stable, secure, and efficient systems.
Let's have a chat!
Are you ready to start your digital journey? Fill in this form or contact us directly by phone.