Kubernetes

ETCD ID Mismatch in Kubernetes ETCD is the key-value store used by Kubernetes to keep cluster state. Sometimes you may see the following error in ETCD logs: 2025-11-11 12:13:10.134330 E | rafthttp: request cluster ID mismatch (got fc5dec74b3dcf6fa want 4e38d7b9b94fe83c) It usually happens when a member of the ETCD cluster has a different ID than what the cluster expects. Causes Restoring a backup incorrectly. Copying ETCD data directories between nodes. Node reinstallation without cleaning old ETCD state. Cluster misconfiguration after scaling or failover. How to Fix Step 1: Identify the problem member ...

What is a Headless Service in Kubernetes? In Kubernetes, a Service is typically used to provide a stable IP address and DNS name for a set of Pods. By default, Kubernetes assigns a ClusterIP to the Service, and traffic is load balanced between available Pods. But sometimes you don’t want load balancing — you want direct DNS records for each Pod. That’s where a Headless Service comes in. How It Works A Headless Service is created by setting: ...

Helm Error: UPGRADE FAILED - Another Operation in Progress When working with Helm in Kubernetes, you might encounter the following error: Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress This usually happens when a Helm release is already in the middle of an action, but another upgrade or rollback is triggered. Common Pending States Helm releases can get stuck in several states: pending-install — Helm started installing, but something went wrong before it finished. pending-upgrade — Helm tried to upgrade, but the process didn’t complete. pending-rollback — A rollback started but got stuck in the middle. These states prevent you from running another helm upgrade or helm rollback. ...

By default, Kubernetes does not automatically restart a Deployment when its ConfigMap changes. This can lead to situations where your pods keep running with outdated configuration until you trigger a rollout manually. Fortunately, there are common patterns to solve this. Why It Happens Kubernetes mounts ConfigMaps into pods as files or environment variables, but the Deployment controller does not track changes in ConfigMap content. That means no automatic restart. Solution Checksum annotations: Add a hash of the ConfigMap into the Deployment’s pod template annotations. Example in Helm: ...

Changing the IP addresses of Kubernetes nodes is rarely a good idea — it can lead to broken networking, node unavailability, or even complete cluster failure. This article explains why you should avoid it, and provides a step-by-step recovery plan if you must do it. 1. Why Node IPs Matter Kubernetes heavily relies on the IP addresses of nodes for: Scheduling and node identity kubelet and API server communication CNI and network overlays DNS and service discovery TLS certificates tied to node IPs Changing an IP breaks all these associations — kubelet may fail to register, Pods may not communicate, and the control plane may mark the node as NotReady. ...