Kubernetes Liveness and Readiness Probes

All Corda worker pods are configured with Kubernetes A powerful tool for managing containerized applications at scale, making it easier for teams to deploy and manage their applications with high reliability and efficiency. liveness and readiness probes. These poll the status of the worker’s internal component registry.

If any component reports that it is in an error state, the liveness probe fails and Kubernetes eventually restarts the pod. During normal operation, pods should not cause failures of the liveness probe and the Cluster Administrator should monitor for failures in the Kubernetes events stream.

The readiness probe fails if any Corda components report that they are down. During worker startup, this is expected behavior and all the components should eventually report that they are up, resulting in the pod being marked as ready. Failures in the readiness probe after a worker has started successfully are typically the result of issues with downstream services (for example, Kafka The means by which Corda workers communicate, acting as a central message bus between the worker processes. or Postgres). These situations should be recoverable, but a Cluster Administrator should monitor for Kubernetes pods that are not marked as ready as these will not be processing work. In regard to workers that expose HTTP endpoints (the gateway worker A worker designed to communicate with external Corda clusters via HTTPS. They have restricted access only to specific topics on the Kafka bus and view only the minimum information needed for their role. and P2P Link Manager worker A worker that manages the secure transmission of packets to peers. The main functional component is the Link Manager, which establishes end-to-end secure sessions for virtual nodes to communicate over. ), Kubernetes will not route HTTP requests to a worker that is not ready.