Spring Boot on GCP
  • Introduction
  • Getting Started
    • Google Cloud Platform
    • Cloud Shell
    • gcloud CLI
    • Hello World!
      • Cloud Shell
      • App Engine
      • Cloud Run
      • Kubernetes Engine
      • Compute Engine
      • Cloud Functions
  • Application Development
    • Development Tools
    • Spring Cloud GCP
    • Cloud Services
      • Databases
        • Cloud SQL
        • Cloud Spanner
        • Cloud Firestore
          • Datastore Mode
          • Native Mode
      • Messaging
        • Cloud Pub/Sub
        • Kafka
      • Secret Management
      • Storage
      • Cache
        • Memorystore Redis
        • Memorystore Memcached (beta)
      • Other Services
    • Observability
      • Trace
      • Logging
      • Metrics
      • Profiling
      • Debugging
    • DevOps
      • Artifact Repository
  • Deployment
    • Runtime Environments
    • Container
      • Container Image
      • Secure Container Image
      • Container Awareness
      • Vulnerability Scanning
      • Attestation
    • Kubernetes
      • Kubernetes Cluster
      • Deployment
      • Resources
      • Service
      • Health Checks
      • Load Balancing
        • External Load Balancing
        • Internal Load Balancing
      • Scheduling
      • Workload Identity
      • Binary Authorization
    • Istio
      • Getting Started
      • Sidecar Proxy
  • Additional Resources
    • Code Labs
    • Presentations / Videos
    • Cheat Sheets
Powered by GitBook
On this page
  • Spring Boot Actuator
  • Clone
  • Add Dependencies
  • Build
  • Containerize
  • Liveness Probe
  • Readiness Probe

Was this helpful?

  1. Deployment
  2. Kubernetes

Health Checks

Learn how Kubernets checks the application health, and how to use liveness probes and readiness probes.

PreviousServiceNextLoad Balancing

Last updated 4 years ago

Was this helpful?

This section continues from the previous section - make sure you do the tutorial in sequence.

Spring Boot Actuator

can provide some basic health checking mechanisms via the /actuator/health endpoint. However, which endpoint you use depends on the Spring Boot version.

Spring Boot 2.3 and above, .

Spring Boot < 2.3 and below, it's best to create a simple endpoint that simply returns HTTP 200 response status instead of using the Spring Boot Actuator's /actuator/health endpoint. This is because /actuator/health by default may fail if an external dependency fails.

Spring Boot Version

Liveness Probe

Readiness Probe

>= 2.3

/actuator/health/liveness

/actuator/health/readiness

< 2.3

Any endpoint that simply returns 200

/actuator/health

Clone

git clone https://github.com/saturnism/jvm-helloworld-by-example
cd jvm-helloworld-by-example/helloworld-springboot-tomcat

Add Dependencies

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    
    ...
  </dependencies>
  ...
</project>

Build

./mvnw package

Containerize

Use Jib to containerize the application:

PROJECT_ID=$(gcloud config get-value project)

./mvnw compile com.google.cloud.tools:jib-maven-plugin:2.4.0:build \
  -Dimage=gcr.io/${PROJECT_ID}/helloworld

Liveness Probe

Kubernetes can automatically detect application issues using a Liveness Probe. When the Liveness Probe check fails, Kubernetes will automatically restart the container, in case restarting your application helps it to recover. If the container continues to fail the Liveness Probe, Kubernetes will go into a Crash Loop and backs off the restart exponentially.

Liveness Probe failure indicates to Kubernetes that the failure can be recovered after a restart.

If your Liveness Probe checks an endpoint that fails due to an external dependency, but the external dependency cannot recover simply because your container restarts, then it's not a good check! This type of checks may cause catastropic cascading failures.

k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: helloworld
  name: helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      containers:
      - image: gcr.io/.../helloworld
        name: helloworld
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 256Mi
        # Configure the liveness probe
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 10

Notice the additional initialDelaySeconds configuration. If your application starts slowly (e.g., 1 minute to start), and the livenessProbe starts the check early (e.g., 10 seconds), then the livenessProbe might never succeed - causing the application to always getting restarted.

When configuring a livenessProbe, always consider the initial delay needed for your application.

Readiness Probe

Even if your application is alive, it doesn't mean that it's ready to receive traffic. For example, during the startup, the application is alive, but it needs to pre-load data, or warmup caches, before it's ready to accept traffic. A Readiness Probe will let Kubernetes know when your application is ready to receive traffic, and only then will the instance be enlisted into the load balancer as a backend to serve requests (i.e., a Service's Endpoint).

k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: helloworld
  name: helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      containers:
      - image: gcr.io/.../helloworld
        name: helloworld
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 256Mi
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
        # Configure the readiness probe
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080

You should always configure a readinessProbe. Even if you don't use Spring Boot Actuator, you can point the probe to / or some endpoint that indicates the traffic is ready serve.

Learn different ways to containerize a Java application in the section.

In addition to httpGet, you can also configure different type of probes such as exec to execute a command to perform a non-HTTP check, or use tcpSocket to simply check if a port is listening. See Kubernetes for more details.

Service
Spring Boot Actuator
Spring Boot Actuator has dedicated support for Liveness Probe
Container Image
Configure Liveness, Readiness, and Startup Probes documentation