Archived content

Archive date: 2026-01-01

This content is no longer being updated or maintained. The content is provided “as is.” Given the rapid evolution of technology, some content, steps, or illustrations may have changed.

In Kubernetes (K8s) environments, maintaining the health and responsiveness of your applications is critical. Kubernetes probes specifically readiness, liveness, and startup probes serve as essential health checks that monitor the status of your applications, ensuring they run smoothly and recover from unexpected issues. This guide provides a step-by-step approach to configuring these probes, deploying IBM Sterling Order Management (OMS) containers on Kubernetes using operators, and using the latest updates (July 2024) for a seamless deployment experience.

Introduction to Kubernetes probes

Kubernetes provides three types of probes—readiness, liveness, and startup—to monitor the health and status of your containers. These probes ensure your applications are running smoothly and can recover from failures.

Readiness probe

A readiness probe determines if a container is ready to serve traffic. If the readiness probe fails, the container will be removed from the list of endpoints for the service, preventing it from receiving any traffic. This is particularly useful for applications that take some time to initialize before they can handle requests.

A readiness probe checks whether a container is prepared to handle traffic. If it fails, Kubernetes removes the container from the service's list of endpoints, ensuring it does not receive traffic. This is particularly useful for applications that need time to initialize before they can process requests.

Example configuration:

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 1
  failureThreshold: 3
  successThreshold: 1

Liveness probe

A liveness probe checks if a container is running correctly. If the probe fails, Kubernetes will restart the container. This is crucial for applications that may become unresponsive due to deadlocks or other unrecoverable errors.

Example configuration:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 1
  failureThreshold: 3

Startup probe

A startup probe is designed for containers that take longer to start. It monitors when a container has fully initialized. If the probe fails, Kubernetes kills and restarts the container. Startup probes disable the liveness and readiness checks until the application is fully started, preventing premature restarts.

Example configuration:

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 1
  failureThreshold: 3

Deploying OMS Containers on Kubernetes

IBM Sterling Order Management (OMS) can be deployed on Kubernetes clusters using operators, whether on Red Hat OpenShift Container Platform (RHOCP) or standard Kubernetes platforms. Operators provide a streamlined way to manage the lifecycle of applications on Kubernetes, including deployment, upgrades, backups, and recovery from failures.

Using Operators for deployment

Before the July 2024 release (Operator Version 17), the OMEnvironment Custom Resource Definition (CRD) did not support probe configurations. However, with the July 2024 release, a new parameter called probeConfigs has been introduced, allowing you to define configurations for readiness, liveness, and startup probes directly in the CRD.

Key considerations for probe configuration

When configuring probes, it's essential to understand and adjust the following parameters:

Initial delay: This defines the number of seconds before the probe starts. For example, the initialDelaySeconds parameter gives your application time to complete its startup process before the health checks begin. It's useful for containers that take longer to initialize.
Timeout and period: The timeoutSeconds parameter specifies how long Kubernetes should wait for a response before marking the probe as a failure. The periodSeconds parameter sets how often the probe is executed. Adjusting these values allows fine-tuning of the probe's frequency and response time to match your application’s performance.
Success and failure thresholds: These thresholds (successThreshold and failureThreshold) determine how many consecutive successes or failures are needed for Kubernetes to consider a probe successful or failed. Setting these appropriately prevents temporary issues from triggering unnecessary container restarts or traffic rerouting.

By default, these parameters are set to values suitable for most common scenarios, but they can be customized to meet your specific requirements. For more details on the default values and additional configuration options, refer to the official documentation.

Note that the probeConfigs parameter in the CRD is optional. If omitted, Kubernetes will apply the default values as outlined in the documentation. However, you can customize these configurations as necessary to better suit your deployment.

Enhanced probe configuration example

Here is an example of a more refined probe configuration, with multiple configurations tailored for different types of application servers.

Sample configuration

In this example, three different probe configurations are defined and assigned to different servers:

spec:
  probeConfigs:
    - name: fast-start    # Probe configuration for fast-starting applications
      liveness:
        initialDelaySeconds: 30
        periodSeconds: 30
        timeoutSeconds: 1
        failureThreshold: 3
      readiness:
        initialDelaySeconds: 5
        periodSeconds: 10
        timeoutSeconds: 1
        successThreshold: 1
        failureThreshold: 3
      startup:
        initialDelaySeconds: 0
        periodSeconds: 5
        timeoutSeconds: 1
        failureThreshold: 3

    - name: slow-start    # Probe configuration for slow-starting applications
      liveness:
        initialDelaySeconds: 120
        periodSeconds: 60
        timeoutSeconds: 5
        failureThreshold: 5
      readiness:
        initialDelaySeconds: 180
        periodSeconds: 90
        timeoutSeconds: 5
        successThreshold: 1
        failureThreshold: 3
      startup:
        initialDelaySeconds: 60
        periodSeconds: 30
        timeoutSeconds: 10
        failureThreshold: 10

    - name: moderate-start  # Probe configuration for moderately starting applications
      liveness:
        initialDelaySeconds: 60
        periodSeconds: 20
        timeoutSeconds: 2
        failureThreshold: 3
      readiness:
        initialDelaySeconds: 30
        periodSeconds: 15
        timeoutSeconds: 2
        successThreshold: 1
        failureThreshold: 2
      startup:
        initialDelaySeconds: 10
        periodSeconds: 20
        timeoutSeconds: 2
        failureThreshold: 5

  servers:
    - name: agent-activemq
      probeConfig: fast-start  # Assign the fast-start probe configuration
    - name: integration-server
      probeConfig: slow-start  # Assign the slow-start probe configuration
    - name: web-frontend
      probeConfig: moderate-start  # Assign the moderate-start probe configuration

Explanation of the example

In this configuration:

fast-start: Designed for applications that start quickly and require frequent health checks. This is ideal for lightweight services like caching layers or in-memory data stores.
slow-start: Suited for applications that take longer to initialize, such as those performing complex bootstrapping tasks, like loading large datasets or connecting to multiple external services.
moderate-start: A balanced configuration between fast and slow starts, perfect for applications with moderate startup times that still need some level of monitoring before becoming fully operational.

Each configuration is assigned to different servers (agent-activemq, integration-server, and web-frontend), demonstrating how probes can be tailored to meet specific application requirements.

Leveraging new Operator enhancements

With Operator Release 15, the probe check functionality has been enhanced. New checks for liveness, readiness, and startup probes have been introduced to ensure that pods can establish stable connections to both the database and message queues. These checks are performed at regular intervals, improving the reliability of the system.

Additionally, a new annotation, apps.oms.ibm.com/use-legacy-probe-check, was introduced. This allows users to switch back to the legacy probe checks if any issues arise with the new configurations, providing flexibility during transitions or troubleshooting.

Troubleshooting probes

If you encounter issues with failing liveness or readiness checks for pods, follow these steps:

Check default values: Ensure that the probe configurations are set according to your application requirements. Review the default values provided in the documentation for accuracy.
Review pod descriptions and logs: Run kubectl describe pod <pod-name> to check for events and kubectl logs <pod-name> to identify any errors or issues that might have caused the probe to fail.
Contact support: If the issue persists, reach out to support with the OMEnvironment configuration, pod description, and logs for further assistance.

Conclusion

Leveraging Kubernetes probes and the latest operator updates enables robust health checks and more effective management of containerized applications. Properly configuring probes is crucial to maintaining the health, performance, and availability of your services. For further details, refer to the official product documentation to ensure you are implementing best practices.

Configuring Kubernetes probes for IBM OMS Containers

Configuring Kubernetes probes for IBM OMS Containers