Kubernetes

[!IMPORTANT] Remember to create a custom image including iscsi-tools when using the Synology CSI driver Set up CLI environment and set databases to maintenance mode export TALOS_CP="192.168.100.107" export TALOS_W1="192.168.100.245" export TALOS_W2="192.168.100.60" export TALOS_W3="192.168.100.228" # Set databases to maintenance mode k cnp maintenance set --all-namespaces [!WARNING] Use the --preserve flag on single-node control plane clusters. Only needed for the control plane node. Upgrade path from 1.7.5 to 1.7.7 from 1.7.7 to 1.8.2 Upgrade 1 export TALOS_IMAGE='factory.talos.dev/installer/c9078f9419961640c712a8bf2bb9174933dfcf1da383fd8ea2b7dc21493f8bac:v1.7.7' talosctl upgrade --preserve --nodes $TALOS_CP -e $TALOS_CP --image $TALOS_IMAGE talosctl upgrade --wait --debug --nodes $TALOS_W1 -e $TALOS_CP --image $TALOS_IMAGE talosctl upgrade --wait --debug --nodes $TALOS_W2 -e $TALOS_CP --image $TALOS_IMAGE talosctl upgrade --wait --debug --nodes $TALOS_W3 -e $TALOS_CP --image $TALOS_IMAGE Upgrade 2 export TALOS_IMAGE='factory.talos.dev/installer/c9078f9419961640c712a8bf2bb9174933dfcf1da383fd8ea2b7dc21493f8bac:v1.8.2' talosctl upgrade --preserve --nodes $TALOS_CP -e $TALOS_CP --image $TALOS_IMAGE talosctl upgrade --nodes $TALOS_W1 -e $TALOS_CP --image $TALOS_IMAGE talosctl upgrade --nodes $TALOS_W2 -e $TALOS_CP --image $TALOS_IMAGE talosctl upgrade --nodes $TALOS_W3 -e $TALOS_CP --image $TALOS_IMAGE Kubernetes Upgrade [!WARNING] Make sure to upgrade the Talos CLI before proceeding. “It is advisable to use the same version of talosctl as the version of the boot media used.” - Talos Docs ...

I upgraded my homelab cluster using Talos Linux today. I made a mistake and forgot to use the custom-built image using iscsi-tools. Learning the hard way. Here are my notes: Talos upgrade [!IMPORTANT] Remember to create a custom image including iscsi-tools Set up CLI environment and set databases to maintenance mode export TALOS_CP="192.168.100.107" export TALOS_W1="192.168.100.245" export TALOS_W2="192.168.100.60" k cnp maintenance set --all-namespaces [!WARNING] Use the --preserve flag on single-node control plane clusters. Only needed for the control plane node. ...

Just realized I never posted on the blog that I achieved the CKS a month ago. I even created a study guide for it: Links: 202406152006

When solving a killercoda challenge I ran into some confusion. Even though my solution worked, there was a difference which I wanted to get clear on. I wrote this: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: np namespace: space1 spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: space2 - to: ports: - protocol: TCP port: 53 - protocol: UDP port: 53 But the provided course solution was this: ...

There are two things which I’m dreading most for the CKS exam: writing Network Policies and configuring RBAC under heavy time pressure. I’ve heard from colleagues that the exam has many questions of this nature, so it will be a good way of scoring points. However, regardless of the exam, the fact that I’m dreading these topics also shows that I’m not familiar enough with them and therefore this is a point where I should improve. It’s not only about the exam, but also my growth of expertise as a Kubernetes Engineer. ...

It seems like I will have a couple of hours a day which I can allot to study in the coming month. This will be the perfect moment to start working on a goal I’ve had for a long time: getting my Certified Kubernetes Security Specialist certification. t’s not going to be easy. I’m quite intimidated by all of the new things I’ll have to learn. But that’s a good sign. It’s the way it works. Everybody would be doing this if it was easy, and I can only grow by doing hard things that seem intimidating at first. ...

In a recent analysis, I explored two notable solutions for synchronizing secrets from Azure Key Vaults to AKS (Azure Kubernetes Service) clusters: akv2k8s and the Azure Key Vault Provider for the Secret Store CSI Driver. Here, I present my findings and recommendations based on the functionality, maintenance requirements, and integration capabilities of these tools. Akv2k8s, maintained by Sparebanken, is an open-source tool designed for the synchronization of secrets. Being dependent on an external tool for Kubernetes secrets synchronization is an undesirable situation and poses several challenges. Notably, the latest version of akv2k8s has been problematic, especially concerning the deployment of Postgres databases on our AKS clusters using the EDB operator. Akv2k8s alters the SecurityContext of pods in a way that causes them to fail. ...

This document is the result of my research into the Gateway API. It aims to briefly describe the Gateway API for Kubernetes, a typical implementation of ingress traffic using NGINX in AKS and how this setup could benefit from implementing the Gateway API. Introduction Gateway API is an official Kubernetes project focused on L4 and L7 routing in Kubernetes. This project represents the next generation of Kubernetes Ingress, Load Balancing, and Service Mesh APIs. From the outset, it has been designed to be generic, expressive, and role-oriented. ...

I always thought that Persistent Volume Claims where deleted when you delete the pod which they are associated with. I was wrong. The lifecycle of PVCs is independent of Pods, and their behavior is largely governed by the Reclaim Policy set on the PVs. Here’s what you need to know: PVCs: These are requests for storage, akin to how Pods request resources like CPU and memory. They exist independently and can be bound to Pods when needed. PVs: Provisioned by administrators or dynamically through Storage Classes, PVs provide the actual storage resources. Their lifecycle is not tied to any specific Pod. Understanding Reclaim Policies The Reclaim Policy on a PV dictates its fate after a PVC is released. There are three policies to be aware of: ...

In this video I set up Flux running in a local cluster on my MacBook by following the getting started guide. Then I learn about how to structure the repo according to Flux methodology. I implement this structure in my homelab repo and deploy flux to my homelab cluster. Then I manage to configure Grafana and the Weave UI to be accessbible via ingress using a custom fake domain. ...