DevOps KB Pages

In Kubernetes, the usual pattern for a container that “runs once and exits” is not a Deployment but rather a Job (or a CronJob for scheduled runs). A Deployment is designed to keep a given number of replicas running continuously, restarting pods if they exit. By contrast, a Job is specifically designed for run-to-completion workloads. Here’s why this matters and how you can set it up: Why not a Deployment for “run once, then exit”? Deployments expect long-running pods. If your container exits successfully, the Deployment’s ReplicaSet controller will see that the number of running pods is below the desired replica count (e.g., 1), so it will spin up a new pod. You’ll end up in an endless cycle of your “job” container repeatedly starting and exiting. Deployments do not retain “completed” pods. When a pod in a Deployment terminates, Kubernetes treats it as “unavailable” and immediately attempts to create a new one. The right approach: a Job (or CronJob) Jobs create pods that...

Health: 80% eating, 20% exercising Wealth: 80% habits, 20% math Happiness: 80% purpose, 20% fun Achieving: 80% listening, 20% speaking Talking: 80% listening, 20% speaking Improving: 80% persistence, 20% ideas Learning: 80% understanding, 20% reading Relationships: 80% giving, 20% receiving "Prioritize the 80%, and the rest will fall into place."  

Explanation of the Flow Cluster : The top-level structure that contains all Kubernetes components. API Server (Pod/Container) : The control plane component that communicates with the cluster. Kubelet : A node agent running on each node, ensuring that pods are running. Container Runtime (containerd, Docker, CRI-O) : Manages container execution. Containers (Pods) : The actual application workloads running inside the cluster. This hierarchy shows the relationship between each component in a Kubernetes environment. Let me know if you need any modifications!

Fixing Kubernetes API Server and Kubelet Issues After Expired Certificates Backup Existing Kubernetes Configuration Create a backup of Kubernetes certificates and configuration files Copy /etc/kubernetes/pki/ and /etc/kubernetes/*.conf to a backup directory Renew Expired Certificates Check expired certificates using kubeadm certs check-expiration Renew all certificates with kubeadm certs renew all Restart kubelet and container runtime using systemctl restart kubelet and systemctl restart containerd or systemctl restart docker Regenerate bootstrap-kubelet.conf if Missing Run kubeadm init phase kubelet-start to regenerate it If still missing, manually copy admin.conf to kubelet.conf Restart kubelet using systemctl restart kubelet Fix Unauthorized Errors Ensure kubectl is using the correct kubeconfig Copy /etc/kubernetes/admin.conf to ~/.kube/config and set proper ownership and permissions Check kubelet logs for authentication errors with journalctl ...

By default the kubelet looks into /etc/cni/net.d to discover the CNI plugins. This will be the same on every controlplane and worker nodes. Default Behavior of kubelet and CNI Plugins: Location of CNI Configuration: By default, the kubelet looks in /etc/cni/net.d for the CNI configuration files. This is where the CNI plugin's configuration files (like 10-weave.conf , 10-calico.conf , etc.) are stored. If this directory contains valid configuration files, the kubelet uses the plugin(s) specified there. Location of CNI Plugin Executables: The actual CNI binaries (executables) are typically stored in /opt/cni/bin by default. These binaries implement the networking logic (e.g., Calico, Weave Net, Flannel). Consistency Across Nodes: The /etc/cni/net.d directory must have consistent CNI configurations across all control plane and worker nodes . This ensures that all nodes in the cluster handle pod networking in a consistent manner. Similarly, the required binaries (in /opt/cni/bin ...

Behavior-Driven Development (BDD) is a collaborative approach to software development that emphasizes communication between developers, testers, and business stakeholders. It bridges the gap between technical and non-technical team members by using plain language to describe the behavior of the software. BDD focuses on creating clear and shared understanding of how a system should behave, enabling the creation of software that aligns closely with business goals. Core Principles of BDD Collaboration : Encourages close collaboration between technical and non-technical stakeholders. User-Focused : Focuses on delivering features that bring value to the end-user. Shared Language : Uses a ubiquitous language to describe software behavior in plain English. Living Documentation : BDD artifacts double as documentation that stays current with the software. BDD Workflow Discovery Phase : Team members work together to understand and define the desired behavior of the system. User stories and examp...

 Once upon a time, in the ever-evolving world of technology, there was an extraordinary hypervisor called ESXi , crafted by the visionary team at VMware. It was a masterpiece of innovation, transforming data centers and delighting IT professionals everywhere. ESXi was efficient, reliable, and beloved, serving countless happy customers who relied on it to power their businesses. It seemed unstoppable, the jewel in VMware’s crown. But the tech world is not without its storms. As ESXi flourished and VMware thrived, a powerful corporation named Broadcom set its sights on the company. Broadcom was not content to simply compete; they wanted to own the crown. They decided the best way to assert control was through acquisition. And so, Broadcom made a bold move: they announced their plan to acquire VMware. At first, the industry watched in suspense. Surely, this would bring even more resources and innovation to VMware's beloved products. But Broadcom had other plans. Once the deal was in ...