← Middleware: understand and operate the chain
12 / 12 · 50 MIN

Releases, configuration, and operational acceptance

Validate configuration adoption, draining, and functional behavior before RUN handover.

Desired object and effective configuration

Configuration follows a path from definition to process use. In Kubernetes, a ConfigMap-derived environment variable does not automatically change in an existing container, and a subPath mount does not receive object updates. Even on an updated normal volume, the application may read the file only at startup. In an exercise, two replicas retain an old timeout through different mechanisms. Record consumption mode and effective value, plan supported activation, and verify each replica. ResourceVersion and checksum provide useful evidence for specific stages but do not replace observing active behavior.

Probes with appropriate actions

Readiness answers whether traffic can be accepted; liveness can trigger restart when failure meets defined criteria. A slow dependency does not necessarily mean restarting the application helps. In a scenario, all replicas restart when the database slows, lose caches, and increase reconnections, amplifying failure. Review signal, threshold, and action together and test the failure mode. Keep a distinction between a process unable to recover and a service temporarily unavailable for traffic. A probe result also does not establish completion of business operations already started.

Draining within the termination budget

The termination period must cover the hook and the process’s remaining work. With a normal sixty-second budget and fifteen-second preStop, do not assume another sixty seconds after the hook. If work requires fifty-two seconds, remaining headroom is insufficient without revising the plan. Removing traffic admission or cancelling subscription helps limit new operations but does not complete existing ones. Measure connections, handlers, and pending outcomes; prepare completion or recovery with identity preserved. Validate behavior under representative load and do not rely on incidental extensions as a safety mechanism.

Reload and worker coexistence

A responding service can still be using earlier configuration. During NGINX reload, the master checks and attempts to apply configuration; on failure it continues with the earlier one. On success, new workers can coexist with old workers finishing service for existing clients. In an exercise, inspect configuration-application errors, active revision, and old connections before declaring completion. Do not terminate workers merely because two generations exist; assess outstanding work and drain budget. The procedure should distinguish availability, adoption, and graceful exit, with measurable criteria for each stage.

Local certificate and actual TLS path

Inspecting the renewed certificate is only part of validation. In OpenSSL 3.5, checkend tests expiry within the stated window; it does not establish which certificate the active endpoint serves or client trust. In a scenario, the file passes that check while one replica still serves the old chain. Test the actual path with appropriate name, chain, and trust store, identifying each TLS termination point. Keep validation open until discrepancies are corrected or a controlled temporary state is explicitly accepted. Do not remove identity verification to turn a failure into apparent success.

Coexistence, gates, and RUN autonomy

A release must work during intermediate rollout states. If old consumers reject the new format, prepare compatible reading before enabling that format and validate all relevant combinations. Also define the flow demonstrating acceptance: error-free read queries do not replace a daily-close gate. At handover, provide active revision and values, excluded replicas, temporary controls, owners, deadlines, and reversal criteria. In an exercise, deployment finished while timeouts remain changed and a replica is out of service. RUN needs that actual state to operate and remove exceptions safely.

IN PRACTICE

The ConfigMap shows timeout=10 while the process still uses 30. Acceptance requires observing effective configuration and outcome beyond the changed API object.

Common pitfalls

Changed object as adopted configuration; readiness as restart; doubled grace budget; certificate file as validated endpoint.

Related topics: Operate TLS, certificates, and configuration · Manage queues, acknowledgements, and retries · Release, observe, and recover middleware

Take this idea with you

Distinguish delivery, adoption, and acceptance while retaining criteria for intermediate change states.

Create account

Reference: ConfigMaps · DR Middleware 2026.4; HotSpot JDK 25; JDBC 25; PostgreSQL 18; RabbitMQ 4.3; OpenSSL 3.5; explicitly scoped runtime references