I was tired of bouncing between a dozen different sites just to format JSON or decode a JWT. One tab for a JSON formatter. Another for a Base64 decoder. Another for a DNS lookup. Another for an SPF validator. Browser full of bookmarks, half of them plastered with ads, most requiring an account to do anything useful. So I built MonkKit — a single place for all of them. 106 free developer tools across 10 categories.

Spring Boot’s Liquibase auto-run works fine for a single instance. In Kubernetes, where multiple pods start simultaneously, auto-run at application startup creates a race: every pod acquires DATABASECHANGELOGLOCK, one holds it, the rest wait, and if Kubernetes kills a pod mid-migration (because it failed its readiness probe while waiting on the lock), the lock remains set and blocks every subsequent pod. The solution is to run migrations exactly once, before application pods start, using either an init container or a Helm pre-upgrade Job.

Spring Boot Actuator exposes production-ready operational endpoints — health checks, metrics, environment info, thread dumps — out of the box. Combined with Prometheus and Grafana, you get a full monitoring stack with minimal configuration. This guide covers everything from initial setup to Kubernetes health probes, custom metrics, and securing your management endpoints. Setup Dependencies <dependencies> <!-- Actuator --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <!-- Micrometer Prometheus registry --> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> <scope>runtime</scope> </dependency> </dependencies> Basic configuration # application.

Kubernetes is the standard platform for running containerized microservices. Spring Boot integrates naturally with Kubernetes — Actuator probes map directly to Kubernetes probes, and Spring configuration maps to ConfigMaps and Secrets. Core Kubernetes Resources Deployment # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: order-service labels: app: order-service spec: replicas: 3 selector: matchLabels: app: order-service template: metadata: labels: app: order-service version: "1.2.3" spec: containers: - name: order-service image: devopsmonk/order-service:1.2.3 ports: - containerPort: 8080 name: http - containerPort: 8081 name: management # Resource limits — always set these resources: requests: memory: "256Mi" cpu: "250m" limits: memory: "512Mi" cpu: "1000m" # Environment from ConfigMap and Secret envFrom: - configMapRef: name: order-service-config - secretRef: name: order-service-secrets # Individual env vars env: - name: SPRING_PROFILES_ACTIVE value: prod - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.

Running Spring Boot on Kubernetes is not just packaging the app in a container and deploying it. You need to configure health probes correctly, handle graceful shutdown so in-flight requests don’t get dropped, manage configuration without baking secrets into images, and make sure the JVM respects container memory limits. This guide covers the production-critical Kubernetes configuration for Spring Boot applications. Health Probes Kubernetes uses three probe types to manage pod lifecycle:

When you build custom Helm charts for your organisation, you need somewhere to store and distribute them. Public registries like Artifact Hub are not suitable for internal charts. ChartMuseum is an open-source Helm chart repository server that you can run on your own infrastructure — with support for local storage, AWS S3, GCS, Azure Blob, and more. How It Fits Into Your Workflow flowchart LR Dev[Developer] -->|helm package| Chart[chart.tgz] Chart -->|curl POST| CM[ChartMuseum Server] CM -->|stores in| Storage[Local / S3 / GCS / Azure] CI[CI Pipeline] -->|helm install| CM Cluster[Kubernetes Cluster] -->|pulls chart| CI ChartMuseum exposes a standard Helm repository API — any Helm client can add it as a repository and install charts from it exactly like any public repo.

Helm is the package manager for Kubernetes — the same idea as apt on Ubuntu or npm in Node.js, but for deploying applications to your cluster. Instead of writing and maintaining dozens of raw Kubernetes YAML files per application, you define a chart once, parameterise it with values, and deploy it consistently across every environment. Note: Helm 4 was released in 2025 with breaking changes. This guide covers Helm 3, which remains widely used and supported.

The CKAD (Certified Kubernetes Application Developer) is a performance-based exam from the CNCF/Linux Foundation. Unlike multiple choice tests, you work in a live Kubernetes cluster — you must know your kubectl commands cold and be able to write YAML from memory under time pressure. Exam details (2024/2025): Duration: 2 hours Format: Performance-based, hands-on in a live cluster (Kubernetes v1.31+) Pass mark: 66% Cost: $395 (includes one free retake) Current Exam Domains Domain Weight Application Design and Build 20% Application Deployment 20% Application Environment, Configuration and Security 25% Application Observability and Maintenance 15% Services and Networking 20% The Environment, Configuration and Security domain carries the most weight — ConfigMaps, Secrets, SecurityContexts, and resource limits are tested heavily.