Gremlin Scenario: Kubernetes TLS/SSL certificate expiration

How it works

How this Scenario works

This Scenario advances the system clock within your Kubernetes pods forward by one day, one week, and one month. This triggers certificate validation logic and reveals any TLS/SSL certificates that will expire within those time windows—including certificates managed by cert-manager, mounted as Kubernetes secrets, or used by ingress controllers.

Use cases

Why run this Scenario?

Proactively identify expiring certificates across your Kubernetes environment before they cause outages.
Test cert-manager and other Kubernetes certificate automation workflows under time-based pressure.
Verify that Kubernetes secrets containing TLS certificates are being rotated correctly.
Validate that ingress controller certificates and service mesh mTLS certificates are covered by your renewal process.

Result

What to expect when you run it

If a TLS certificate expires without renewal, the Kubernetes service fails gracefully and alerts trigger immediately.

Keep going

More Scenarios to try

Kubernetes packet loss

Ensure your Kubernetes systems can detect and route around resources that fail health checks. This Scenario gradually increases packet loss to validate liveness/readiness probe and load balancer behavior.

Container packet loss

Ensure your containerized systems can detect and route around resources that fail health checks. This Scenario gradually increases packet loss to validate health check and load balancer behavior.

Windows packet loss

Ensure your Windows systems can detect and route around resources that fail health checks. This Scenario gradually increases packet loss to validate health check and load balancer behavior.

Kubernetes TLS/SSL certificate expiration