Devops on Apurv Kiri | Tech Notes

Kubernetes - Cluster Rebalancing with Descheduler

Fri, 07 Mar 2025 01:55:15 +0530

This post is part of our ongoing series of posts for Kubernetes. This post focuses on how Kubernetes Descheduler helps rebalance clusters for better performance and resource utilization. As clusters evolve—pods start or terminate, nodes join or leave, or resource demands shift—the initial pod placement may no longer be optimal for current conditions.

Descheduler addresses this challenge by identifying and relocating pods that no longer align with current cluster requirements, enabling Kubernetes to redistribute them more efficiently across the available infrastructure.

Kubernetes - Automating ConfigMap and Secret Reloads with Reloader

Thu, 06 Mar 2025 01:55:15 +0530

This post is part of our ongoing series of posts for Kubernetes. In this post, we will explore how to automate the reloading of ConfigMaps and Secrets in your Kubernetes clusters using Reloader, a powerful tool designed to streamline application configuration updates without manual intervention.

When working with applications that rely on configuration data or sensitive information stored in ConfigMaps and Secrets, manually restarting pods to apply changes can be tedious, error-prone, and disruptive to service availability. Reloader elegantly solves this problem by automatically detecting configuration changes and triggering rolling updates for the associated deployments, ensuring your applications always run with the latest configurations while maintaining high availability.

Kubernetes - Replicate Secrets with Reflector

Wed, 05 Mar 2025 01:55:15 +0530

This post is part of our ongoing series of posts for Kubernetes. In this post, we will dive into replicating secrets across namespaces using Reflector, a powerful tool for ensuring consistency and security in your Kubernetes environment.

By default, Kubernetes secrets are scoped to individual namespaces. However, there are common use cases where sensitive information, such as API tokens, database credentials, or container registry credentials, needs to be shared across multiple namespaces. Manually managing these secrets can be error-prone and time-consuming.

Kubernetes GitOps with FluxCD - Part 7 - Resource Optimization and Automated Version Management with Github Actions

Tue, 04 Mar 2025 01:55:15 +0530

In our previous post, we set up push based reconciliation using webhooks. Building on what we’ve learned so far—basic FluxCD setup, SOPS-based secret management, image update automation, Helm chart automation, alerts and push based reconciliation — this article focuses on critical day-two operational concerns: optimizing FluxCD resource allocation and establishing automated version management through Github Actions.

1. Sizing FluxCD Containers

By default, FluxCD components are provisioned with the following resource configurations for CPU and memory:

 1kubectl -n flux-system get pods -o json | jq -r '["container", "cpu_requests", "cpu_limits", "memory_requests", "memory_limits"], (.items[].spec.containers[] | [.image, .resources.requests.cpu, .resources.limits.cpu, .resources.requests.memory, .resources.limits.memory]) | @csv' | column -t -s,
 2
 3
 4"container"                                           "cpu_requests"  "cpu_limits"  "memory_requests"  "memory_limits"
 5"ghcr.io/fluxcd/helm-controller:v1.2.0"               "100m"          "1"           "64Mi"             "1Gi"
 6"ghcr.io/fluxcd/image-automation-controller:v0.40.0"  "100m"          "1"           "64Mi"             "1Gi"
 7"ghcr.io/fluxcd/image-reflector-controller:v0.34.0"   "100m"          "1"           "64Mi"             "1Gi"
 8"ghcr.io/fluxcd/kustomize-controller:v1.5.0"          "100m"          "1"           "64Mi"             "1Gi"
 9"ghcr.io/fluxcd/notification-controller:v1.5.0"       "100m"          "1"           "64Mi"             "1Gi"
10"ghcr.io/fluxcd/source-controller:v1.5.0"             "50m"           "1"           "64Mi"             "1Gi"

For our environment with a smaller cluster footprint, these default limits are unnecessarily generous and could lead to resource contention. We’ll refine these allocations by modifying cluster/default/flux-system/kustomization.yaml to better align with our actual resource capacity and workload requirements:

Kubernetes GitOps with FluxCD - Part 6 - Push-based Reconciliation with Webhook Receivers

Mon, 03 Mar 2025 01:55:15 +0530

In our previous post, we set up Discord alerts to get notifications about our cluster’s status. Building on what we’ve learned so far—basic FluxCD setup, SOPS-based secret management, image update automation, Helm chart automation, and alerts—this article focuses on webhook receivers.

By default, FluxCD polls Git repositories at the configured frequency to detect changes. With webhook receivers, your Git provider can notify FluxCD immediately when changes occur, ensuring the reconciliation process doesn’t have to wait for the next scheduled polling interval. This significantly expedites deployments and enhances overall cluster efficiency.