Springboot & Kubernetes

To set up a basic Spring Boot application for Kubernetes, you must integrate the Spring Boot Actuator module, which serves as the internal engine connecting the application’s state to the Kubernetes orchestration platform. Youtube video link https://youtu.be/7sKsXZah4io

1. Spring Boot Application Setup

To enable health probes, follow these steps to configure your application:

• Dependency Management: Add the spring-boot-starter-actuator dependency to your project. This provides the necessary infrastructure to track availability states and expose them via web endpoints.

• Enable Probes: Spring Boot possesses “cloud-native” intelligence; it automatically activates liveness and readiness health indicators when it detects it is running in a Kubernetes environment. For local testing outside of Kubernetes, you can manually enable them in your application.properties file:

• Default Endpoints: Once enabled, Actuator provides two dedicated health groups:

    ◦ Liveness: /actuator/health/liveness (returns 200 OK when the internal state is stable).

    ◦ Readiness: /actuator/health/readiness (returns 200 OK when the application is ready to handle traffic).

2. Kubernetes YAML Configuration

In your Kubernetes deployment manifest, you should define three types of probes within the container specification to ensure high availability and self-healing.

Example Configuration

spec:
  containers:
  - name: basic-springboot-app
    image: your-image:latest
    ports:
    - containerPort: 8080
    
    # Startup Probe: Protects the app during the intensive JVM boot phase
    startupProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      failureThreshold: 30
      periodSeconds: 10 # Gives the app 300 seconds to start
      
    # Liveness Probe: Detects if the app is deadlocked or unrecoverable
    livenessProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080
      initialDelaySeconds: 0 # Handled by startupProbe
      periodSeconds: 10
      
    # Readiness Probe: Determines if the app should receive network traffic
    readinessProbe:
      httpGet:
        path: /actuator/health/readiness
        port: 8080
      initialDelaySeconds: 0
      periodSeconds: 10

3. Key Concepts and Best Practices

• The Three-Probe Strategy: Always use all three probes for JVM workloads. The Startup Probe is crucial because it suppresses liveness and readiness checks until the application has finished initializing. This prevents the “restart loop” where Kubernetes kills a slow-starting container before it can become healthy.

• Liveness Independence: The liveness probe should never depend on external systems like databases or web APIs. If an external database fails and your liveness probe fails as a result, Kubernetes will restart all your application instances, potentially causing a cascading failure across the platform.

• Readiness Judgment: Readiness probes may include external checks if the application cannot function without them. If the readiness probe fails, Kubernetes simply stops routing traffic to that pod instead of restarting it.

• Resource Timing: Be cautious with aggressive timeouts. A default timeoutSeconds of 1 second can be too short if the JVM experiences garbage collection pauses or CPU throttling, leading to false-positive failures. Increasing this to 3–5 seconds is often recommended for stability.

——————————————————————————–

Analogy for Understanding Probes: Think of a Liveness Probe as a doctor checking for a heartbeat; if it stops, the system tries to “resuscitate” the app by restarting it. The Readiness Probe is like a “Back in 5 Minutes” sign on a shop door; the shop is still there (it doesn’t need to be rebuilt), but it isn’t ready to serve customers yet. Finally, the Startup Probe is like a “Grand Opening Coming Soon” sign, telling the landlord (Kubernetes) not to evict the tenant just because they haven’t started selling products while they are still setting up the shelves.