--- title: "Kubernetes Health Probes: Liveness, Readiness, Startup & Self-Healing" lang: "en" author: "Mohammad Abu Mattar" canonical: https://mkabumattar.com/post/kubernetes-health-probes-self-healing --- ![Blog post image for Kubernetes Health Probes: Building Self-Healing Applications - How Kubernetes liveness, readiness, and startup probes turn your application state into signals the control plane acts on, the misconfigurations that cause cascading outages, and how to wire zero-downtime rollouts with readiness gates and preStop drains.](/_astro/hero.i-e7H395_Z1MO4a.webp) [Home](/)›[Blog](/blog)›[All Categories](/blog/categories)›[Kubernetes](/blog/categories/kubernetes) Blog [Prev in KubernetesThe Resilience of Timbernetes: An Analysis of In-Place Pod Vertical Scaling in Kubernetes 1.35](/blog/post/kubernetes-1-35-in-place-pod-vertical-scaling-guide)[Next in KubernetesKubernetes Networking Demystified: CNI Plugins, Network Policies, and Pod-to-Pod Communication](/blog/post/kubernetes-networking-cni-plugins-policies-guide) [Kubernetes](/blog/categories/kubernetes)[Site Reliability Engineering](/blog/categories/site-reliability-engineering) # Kubernetes Health Probes: Building Self-Healing Applications [Mohammad Abu Mattar](/authors/mohammad-abu-mattar)Published: 15 Aug 2026Updated: 15 Aug 202608 Mins read11 Mins listen [Markdown for AI(opens in a new tab)](/post/kubernetes-health-probes-self-healing/index.md "Open the plain-Markdown version of this page, for pasting into an AI tool") TL;DR How Kubernetes liveness, readiness, and startup probes turn your application state into signals the control plane acts on, the misconfigurations that cause cascading outages, and how to wire zero-downtime rollouts with readiness gates and preStop drains. Series [Containers & Kubernetes](/series/containers--kubernetes)4/4 [PreviousKubernetes Networking Demystified: CNI Plugins, Network Policies, and Pod-to-Pod Communication](/blog/post/kubernetes-networking-cni-plugins-policies-guide) All posts in this series (4) Blog4 1. [Becoming an AWS Pro: A Deep Dive into Amazon Elastic Container Service](/blog/post/aws-ecs-deep-dive) 2. [Service Mesh Deep Dive: Istio vs. Linkerd](/blog/post/service-mesh-istio-vs-linkerd) 3. [Kubernetes Networking Demystified: CNI Plugins, Network Policies, and Pod-to-Pod Communication](/blog/post/kubernetes-networking-cni-plugins-policies-guide) 4. [Kubernetes Health Probes: Building Self-Healing ApplicationsYou are here](/blog/post/kubernetes-health-probes-self-healing) ### Kubernetes Health Probes: Building Self-Healing Applications Contents [What self-healing actually means](#what-self-healing-actually-means)[The three probes, and what each one controls](#the-three-probes-and-what-each-one-controls)[How a probe failure turns into an action](#how-a-probe-failure-turns-into-an-action)[The misconfigurations that cause outages](#the-misconfigurations-that-cause-outages)[Checking your database in a liveness probe](#checking-your-database-in-a-liveness-probe)[Thresholds and timeouts that are too aggressive](#thresholds-and-timeouts-that-are-too-aggressive)[Writing the probe handlers](#writing-the-probe-handlers)[When you actually need a startup probe](#when-you-actually-need-a-startup-probe)[Zero-downtime rollouts](#zero-downtime-rollouts)[The load balancer registration gap](#the-load-balancer-registration-gap)[Readiness gates close the gap](#readiness-gates-close-the-gap)[The preStop hook and draining](#the-prestop-hook-and-draining)[Frequently asked questions](#frequently-asked-questions)[References](#references) Kubernetes has a reputation for keeping applications online, but it is not magic. Out of the box, the cluster is blind to what happens inside your container. If your application deadlocks or exhausts its database connection pool, the process is often still running. To Kubernetes, a running process looks like a healthy pod, so it keeps forwarding traffic to an endpoint that stopped responding minutes ago. To get a genuinely self-healing application, you have to translate your app’s internal state into signals the control plane understands. That is what health probes are for. Configure them well and the cluster routes traffic away from overwhelmed pods and restarts frozen ones on its own. Configure them badly and you hand yourself a new failure mode: cascading restarts that take down the whole service at once. Worth knowing Probes are cheap to add and easy to get subtly wrong. The rest of this post is as much about the mistakes as the mechanics, because a bad liveness probe is worse than no probe at all. ## [What self-healing actually means](#what-self-healing-actually-means) Self-healing is the cluster automatically detecting, isolating, and replacing unhealthy workload instances with no human in the loop. Pods and containers are meant to be disposable. Instead of nursing one fragile server, Kubernetes uses higher-level controllers (Deployments, StatefulSets) to constantly compare the current state of the cluster against the state you declared. The local node agent, the kubelet, runs a continuous polling loop to track container health. If a container process crashes and exits with a non-zero code, the kubelet notices right away and restarts it per the pod’s `restartPolicy`. The harder problem is that modern systems fail quietly. A background thread panics, a memory leak triggers endless garbage-collection pauses, an upstream API stops answering. The process never exits, so the kubelet sees nothing wrong. Probes are how you give the kubelet the diagnostics to catch those invisible failures and act, either by pulling the pod out of rotation or by terminating and replacing it. The kubelet continuously runs your probes, compares the result against the desired state, and acts: restarting a container that fails its liveness probe or pulling a pod out of the Service endpoints when it fails readiness. ## [The three probes, and what each one controls](#the-three-probes-and-what-each-one-controls) Kubernetes gives you three probe types. Each answers a different question and triggers a very different action on failure. Mixing up their jobs is a leading cause of cluster instability. Probe The question it answers Action on failure Use it for Startup Has the app finished booting? Kill the container, trigger `restartPolicy` Shielding slow-starting apps from premature liveness kills Liveness Is the process wedged in an unrecoverable state? Kill the container, trigger `restartPolicy` Deadlocks, memory leaks, frozen event loops Readiness Can it process traffic right now? Remove the pod’s IP from Service endpoints Cache warmups, dropped DB connections, temporary overload When a pod launches, the kubelet checks whether a startup probe is defined. If it is, liveness and readiness checks are paused until the startup probe succeeds, which gives your code time to initialize. Once the startup probe passes, the kubelet begins running the liveness and readiness probes periodically. The startup probe runs first and holds off the others until the app has booted. Once it passes, the liveness and readiness probes take over for the rest of the pod's life, deciding restarts and traffic independently. ## [How a probe failure turns into an action](#how-a-probe-failure-turns-into-an-action) The two failure paths are handled by different parts of the cluster, and the difference matters. When a **liveness** probe fails `failureThreshold` times in a row, the kubelet treats the container as unhealthy and starts terminating it: it sends `SIGTERM`, waits out `terminationGracePeriodSeconds`, and issues `SIGKILL` if the container refuses to exit. Then it restarts the container behind an exponential backoff that starts at 10 seconds and grows up to 300 seconds, so a fast crash loop cannot melt the node’s CPU. When a **readiness** probe fails, nothing gets killed. The kubelet sets the pod’s `Ready` condition to `False`. The Endpoints controller watches those conditions, and the moment a pod goes unready it removes the pod’s IP from the `EndpointSlice` for that Service. `kube-proxy` on each node picks up the update and rewrites the local network rules, so new traffic stops going to the struggling pod. Established TCP connections usually stay put; new requests route cleanly to healthy replicas. That is the whole point of keeping the two separate: readiness is a reversible “step out of the line for a moment,” liveness is a final “you are broken, start over.” ## [The misconfigurations that cause outages](#the-misconfigurations-that-cause-outages) Probes are simple, but a couple of architectural misunderstandings turn them into self-inflicted incidents. ### [Checking your database in a liveness probe](#checking-your-database-in-a-liveness-probe) This is the most dangerous probe mistake there is. The tempting move is to point both liveness and readiness at one generic `/health` endpoint that checks the database, the Redis cache, and a couple of third-party APIs. Picture a service that talks to PostgreSQL. The database fails over to a new primary, and queries fail for about 30 seconds. If your liveness probe pings the database, liveness fails, and the kubelet kills the container. Every pod loses database connectivity at the same instant, so Kubernetes restarts your entire fleet at the same instant. A 30-second blip becomes a full cascading outage, even though your application runtime was perfectly fine. When the database comes back, it is immediately hit by a thundering herd of restarting pods each opening fresh connection pools, which frequently knocks the database over again. Careful here Liveness probes should test only the process itself, never its external dependencies. If a dependency is down, that is a readiness concern (step out of rotation and wait), not a liveness concern (restart). Restarting a healthy pod because a database hiccuped never helps. ### [Thresholds and timeouts that are too aggressive](#thresholds-and-timeouts-that-are-too-aggressive) `timeoutSeconds` is how long the kubelet waits for the probe handler to answer. Under CPU pressure an app might take two or three seconds to respond to a health check. If `timeoutSeconds` is 1 and `failureThreshold` is low, a single slow response or one dropped packet evicts and restarts the pod. Give probes enough headroom to survive a busy moment. ## [Writing the probe handlers](#writing-the-probe-handlers) Kubernetes supports four handler mechanisms. You configure them inside `spec.containers`. **HTTP** is the common choice for web services. The kubelet sends a `GET` and treats any status from 200 to 399 as success. ``` 1livenessProbe:2 httpGet:3 path: /healthz/live4 port: 80805 httpHeaders:6 - name: X-Custom-Auth7 value: internal-probe8 periodSeconds: 159 failureThreshold: 3 ``` **TCP socket** suits non-HTTP apps. The kubelet just opens a connection on the port; if the socket opens, the probe passes. ``` 1readinessProbe:2 tcpSocket:3 port: 54324 initialDelaySeconds: 55 periodSeconds: 10 ``` **Exec** runs a command inside the container and passes on exit code 0. Handy for apps that write a status file, but it is the most expensive option because the runtime spawns a process for every check. ``` 1readinessProbe:2 exec:3 command:4 - cat5 - /tmp/healthy6 periodSeconds: 5 ``` **gRPC** used to require bundling a separate health-check binary and calling it through an exec probe. Kubernetes now speaks the standard gRPC Health Checking Protocol natively. ``` 1livenessProbe:2 grpc:3 port: 500514 periodSeconds: 10 ``` ## [When you actually need a startup probe](#when-you-actually-need-a-startup-probe) Before startup probes existed, health-checking apps with unpredictable boot times was painful. A legacy Spring Boot monolith might download config, run database migrations, and warm caches before it can serve anything. The old workaround was a large `initialDelaySeconds` so liveness would not kill the app mid-boot. That created a nasty blind spot: if the app booted fine in 30 seconds but deadlocked two minutes later, Kubernetes would not notice until the whole padded initial delay elapsed. The startup probe fixes this by separating “still booting” from steady-state health, so liveness can stay tight without risking a premature kill during a slow start. ## [Zero-downtime rollouts](#zero-downtime-rollouts) True zero-downtime deploys need Kubernetes internal routing to stay in sync with external infrastructure, and that is exactly where naive rollouts drop requests, especially behind a cloud load balancer like an AWS ALB. ### [The load balancer registration gap](#the-load-balancer-registration-gap) During a rolling update the Deployment controller brings up a new pod. As soon as its readiness probe returns success, Kubernetes marks the pod `Ready`, adds it to the Service endpoints, and sends `SIGTERM` to an old pod to scale down. But the external load balancer runs on its own schedule: the target group may take another 10 to 15 seconds to register the new IP, run its own checks, and start routing. In that window the old pod is going away and the new pod is not receiving traffic yet, so users get dropped requests and 502s. During a rolling update, a new pod only starts receiving traffic once its readiness probe passes. The old pod keeps serving until then, so there is never a moment where requests hit a pod that is not ready. ### [Readiness gates close the gap](#readiness-gates-close-the-gap) A readiness gate says the pod cannot be marked `Ready` until an external controller confirms it, even after every container readiness probe passes. The ALB controller flips that condition once target registration is done. ``` 1apiVersion: apps/v12kind: Deployment3metadata:4 name: payment-service5spec:6 template:7 spec:8 readinessGates:9 # The ALB controller flips this once target registration completes10 - conditionType: 'target-health.alb.k8s.aws'11 containers:12 - name: app13 image: payments:v2.114 readinessProbe:15 httpGet:16 path: /actuator/health/readiness17 port: 8080 ``` With the gate in place, Kubernetes will not terminate the old pods until the load balancer signals that the new pods are actually taking traffic. ### [The preStop hook and draining](#the-prestop-hook-and-draining) At the end of a pod’s life the kubelet removes its IP from the endpoints and sends `SIGTERM` at the same time. Because endpoint removal takes a moment to propagate through iptables rules and external load balancers, in-flight requests can still arrive for a few seconds after shutdown begins. A `preStop` hook runs synchronously before `SIGTERM`, so a short `sleep` pauses shutdown long enough for the removal to propagate everywhere. ``` 1lifecycle:2 preStop:3 exec:4 command: ['/bin/sh', '-c', 'sleep 15'] ``` Careful here The `preStop` hook counts against `terminationGracePeriodSeconds`. If `preStop` sleeps 15 seconds and the app needs another 20 seconds to drain connections, set `terminationGracePeriodSeconds` to at least 40, or the kubelet will `SIGKILL` the pod mid-drain. ## [Frequently asked questions](#frequently-asked-questions) Liveness answers “is this process wedged?” and its failure restarts the container. Readiness answers “can this pod take traffic right now?” and its failure only removes the pod from the load balancer without restarting it. Readiness is reversible and temporary; liveness is a last resort that throws the container away. Because a database blip would then restart your whole fleet at once. A liveness failure kills the container, so if every pod’s liveness pings a database that just failed over, every pod restarts simultaneously and then stampedes the recovering database with new connections. Dependency health belongs in a readiness probe (step out of rotation and wait), not liveness (restart). No. You need one when boot time is slow or unpredictable (migrations, cache warmups, heavy frameworks). It lets you keep liveness thresholds tight for steady-state without risking a premature kill during a long start. For apps that boot in a second or two, a small `initialDelaySeconds` is enough. Endpoint removal is not instant. It has to propagate through kube-proxy on every node and out to external load balancers, which can lag by seconds. Without the pause, the pod receives `SIGTERM` while traffic is still being routed to it, so requests get dropped. The `preStop` sleep holds shutdown until the removal has spread everywhere. ## [References](#references) - [Pod lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/) - [Configure liveness, readiness and startup probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) - [Pod conditions and readiness gates](https://kubernetes.io/docs/concepts/workloads/pods/pod-condition/) - [Container lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) - [gRPC probes now in beta](https://kubernetes.io/blog/2022/05/13/grpc-probes-now-in-beta/) - [Liveness and readiness probes with Spring Boot](https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot/) - [Kubernetes liveness probes are dangerous](https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html) - [Zero-downtime deployments on AWS EKS](https://glasskube.dev/blog/kubernetes-zero-downtime-deployments-aws-eks/) Was this useful? ## Tags [#Kubernetes](/blog/tags/kubernetes)[#Liveness probe](/blog/tags/liveness-probe)[#Readiness probe](/blog/tags/readiness-probe)[#Startup probe](/blog/tags/startup-probe)[#Self healing](/blog/tags/self-healing)[#Zero downtime deployment](/blog/tags/zero-downtime-deployment)[#Health check](/blog/tags/health-check)[#Kubelet](/blog/tags/kubelet) ## Share [Facebook](https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing "Share on Facebook")[Twitter](https://twitter.com/intent/tweet/?text=Kubernetes%20Health%20Probes%3A%20Building%20Self-Healing%20Applications&url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing "Share on Twitter")[LinkedIn](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing&title=Kubernetes%20Health%20Probes%3A%20Building%20Self-Healing%20Applications&summary=How%20Kubernetes%20liveness%2C%20readiness%2C%20and%20startup%20probes%20turn%20your%20application%20state%20into%20signals%20the%20control%20plane%20acts%20on%2C%20the%20misconfigurations%20that%20cause%20cascading%20outages%2C%20and%20how%20to%20wire%20zero-downtime%20rollouts%20with%20readiness%20gates%20and%20preStop%20drains.&source=https://mkabumattar.com "Share on LinkedIn")[WhatsApp](https://wa.me/?text=Kubernetes%20Health%20Probes%3A%20Building%20Self-Healing%20Applications%20https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing "Share on WhatsApp")[Telegram](https://t.me/share/url?url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing&text=Kubernetes%20Health%20Probes%3A%20Building%20Self-Healing%20Applications "Share on Telegram")[Reddit](https://www.reddit.com/submit?url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing&title=Kubernetes%20Health%20Probes%3A%20Building%20Self-Healing%20Applications "Share on Reddit")[Hacker News](http://news.ycombinator.com/submitlink?u=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing&t=Kubernetes%20Health%20Probes%3A%20Building%20Self-Healing%20Applications "Share on Hacker News")[Pinterest](https://pinterest.com/pin/create/button/?url=https%3A%2F%2Fmkabumattar.com%2Fblog%2Fpost%2Fkubernetes-health-probes-self-healing&media=&description=How%20Kubernetes%20liveness%2C%20readiness%2C%20and%20startup%20probes%20turn%20your%20application%20state%20into%20signals%20the%20control%20plane%20acts%20on%2C%20the%20misconfigurations%20that%20cause%20cascading%20outages%2C%20and%20how%20to%20wire%20zero-downtime%20rollouts%20with%20readiness%20gates%20and%20preStop%20drains. "Share on Pinterest")[Email]() ## Comments ## You might also enjoy More posts on similar topics [![Kubernetes Networking Demystified: CNI Plugins, Network Policies, and Pod-to-Pod Communication](/_astro/hero.DBYAk9LU_1DoLxE.webp)](/blog/post/kubernetes-networking-cni-plugins-policies-guide) ## [Kubernetes Networking Demystified: CNI Plugins, Network Policies, and Pod-to-Pod Communication](/blog/post/kubernetes-networking-cni-plugins-policies-guide) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Kubernetes](/blog/categories/kubernetes) - [Networking](/blog/categories/networking) - [Cloud Native](/blog/categories/cloud-native) - [Infrastructure](/blog/categories/infrastructure) If you've spent any time with Kubernetes, you know that networking is often the part that makes people's heads spin. It feels like magic until something breaks, and then you're staring at a maze of vi [#CNI](/blog/tags/cni)[#Calico](/blog/tags/calico)[#Cilium](/blog/tags/cilium)+7 tags [read more](/blog/post/kubernetes-networking-cni-plugins-policies-guide) [![Service Mesh Deep Dive: Istio vs. Linkerd](/_astro/hero.D85wlyeO_Z21RyyE.webp)](/blog/post/service-mesh-istio-vs-linkerd) ## [Service Mesh Deep Dive: Istio vs. Linkerd](/blog/post/service-mesh-istio-vs-linkerd) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Kubernetes](/blog/categories/kubernetes) - [Service Mesh](/blog/categories/service-mesh) - [Cloud Native](/blog/categories/cloud-native) - [Microservices](/blog/categories/microservices) - [Networking](/blog/categories/networking) So, you're getting into cloud-native, huh? Managing all those microservices can get pretty tricky. As you break your apps into smaller, independent pieces, making sure they talk to each other reliably [#Istio](/blog/tags/istio)[#Linkerd](/blog/tags/linkerd)[#Service Mesh](/blog/tags/service-mesh)+7 tags [read more](/blog/post/service-mesh-istio-vs-linkerd) [![Becoming an AWS Pro: A Deep Dive into Amazon Elastic Container Service](/_astro/hero.ia7tHPKE_ZlnALL.webp)](/blog/post/aws-ecs-deep-dive) ## [Becoming an AWS Pro: A Deep Dive into Amazon Elastic Container Service](/blog/post/aws-ecs-deep-dive) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [AWS](/blog/categories/aws) - [Cloud Computing](/blog/categories/cloud-computing) - [DevOps](/blog/categories/devops) - [Containerization](/blog/categories/containerization) - [ECS](/blog/categories/ecs) Introduction If you're working on container orchestration on AWS, Amazon Elastic Container Service (ECS) is worth understanding well. This guide covers ECS in depth and answers the most common que [#AWS ECS](/blog/tags/aws-ecs)[#Amazon EKS](/blog/tags/amazon-eks)[#AWS Fargate](/blog/tags/aws-fargate)+7 tags [read more](/blog/post/aws-ecs-deep-dive) [![GitOps vs. Traditional IaC for Kubernetes: A Comparative Analysis](/_astro/hero.B-RmFsqr_57hBt.webp)](/blog/post/gitops-vs-traditional-iac-kubernetes-deployment) ## [GitOps vs. Traditional IaC for Kubernetes: A Comparative Analysis](/blog/post/gitops-vs-traditional-iac-kubernetes-deployment) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [DevOps](/blog/categories/devops) - [Infrastructure as Code](/blog/categories/infrastructure-as-code) - [GitOps](/blog/categories/gitops) - [Kubernetes](/blog/categories/kubernetes) - [Cloud Native](/blog/categories/cloud-native) If you're managing modern cloud-native applications, especially with Kubernetes, you know it can be a real puzzle. Getting containers to work together, handling all those configurations, and scaling t [#GitOps](/blog/tags/gitops)[#Infrastructure as Code](/blog/tags/infrastructure-as-code)[#IaC](/blog/tags/iac)+9 tags [read more](/blog/post/gitops-vs-traditional-iac-kubernetes-deployment) [![Chaos Engineering: Testing Resiliency with Chaos Monkey and Gremlin](/_astro/hero.D_hw4oVT_2tz3eD.webp)](/blog/post/chaos-engineering-resiliency-testing-monkey-gremlin) ## [Chaos Engineering: Testing Resiliency with Chaos Monkey and Gremlin](/blog/post/chaos-engineering-resiliency-testing-monkey-gremlin) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [Chaos Engineering](/blog/categories/chaos-engineering) - [System Reliability](/blog/categories/system-reliability) - [DevOps](/blog/categories/devops) - [Site Reliability Engineering](/blog/categories/site-reliability-engineering) - [Testing](/blog/categories/testing) Modern software systems are incredibly complex. They're spread across massive networks with countless moving parts. Because of this complexity, unexpected failures are inevitable. Servers crash. Netwo [#Chaos Engineering](/blog/tags/chaos-engineering)[#Chaos Monkey](/blog/tags/chaos-monkey)[#Gremlin](/blog/tags/gremlin)+10 tags [read more](/blog/post/chaos-engineering-resiliency-testing-monkey-gremlin) [![QuenchWorks: A Zero-CVE, Built-From-Source Replacement for the Bitnami Catalog](/_astro/hero.DloumiN1_Z1RwvV3.webp)](/blog/post/quenchworks-zero-cve-bitnami-alternative-wolfi) ## [QuenchWorks: A Zero-CVE, Built-From-Source Replacement for the Bitnami Catalog](/blog/post/quenchworks-zero-cve-bitnami-alternative-wolfi) - [Mohammad Abu Mattar](/authors/mohammad-abu-mattar) - [DevOps](/blog/categories/devops) - [Containers](/blog/categories/containers) - [Supply Chain Security](/blog/categories/supply-chain-security) - [Kubernetes](/blog/categories/kubernetes) - [Open Source](/blog/categories/open-source) If you run anything on Kubernetes, there's a good chance you were pulling Bitnami images without even thinking about it. bitnami/postgresql, bitnami/redis, bitnami/nginx, the whole Helm charts l [#Wolfi](/blog/tags/wolfi)[#Apko](/blog/tags/apko)[#Melange](/blog/tags/melange)+9 tags [read more](/blog/post/quenchworks-zero-cve-bitnami-alternative-wolfi) 6 related posts