Kubernetes networking problems can be difficult to diagnose because the same application symptom can originate from many different layers.

An application might report:

1Connection refused
2Connection timed out
3No route to host
4Name or service not known
5502 Bad Gateway
6503 Service Unavailable

but the actual problem could be somewhere along this path:

 1Application
 2    |
 3Pod
 4    |
 5Pod Network
 6    |
 7Service
 8    |
 9EndpointSlice
10    |
11NetworkPolicy
12    |
13Ingress / Gateway
14    |
15Load Balancer
16    |
17DNS
18    |
19External Network

The most effective strategy is not to start changing configurations.

Instead, follow the connection one layer at a time until we can identify exactly where communication stops working.

In this third article of our Kubernetes Troubleshooting series, we will investigate:

• Pod-to-Pod connectivity;

• Services;

• EndpointSlices;

• DNS;

• ports and targetPort;

• NetworkPolicies;

• Ingress;

• Gateway API;

• LoadBalancers;

• CNI;

• outbound connectivity.

First, understand the Kubernetes network model

Before troubleshooting, we need to understand a few expectations of Kubernetes networking.

Each Pod receives its own IP address inside the cluster.

Under the Kubernetes network model, and unless intentional network segmentation prevents it, Pods should be able to communicate with other Pods even when those Pods are running on different nodes.

Containers within the same Pod share a network namespace and can communicate over:

1localhost

Services add another abstraction:

 1Client Pod
 2    |
 3    v
 4Service
 5    |
 6    v
 7EndpointSlice
 8    |
 9    +------ Pod A
10    |
11    +------ Pod B
12    |
13    +------ Pod C

The Service provides a stable access point while backend Pods can be created, deleted, or receive different IP addresses.

Our troubleshooting approach

For networking, we will use one simple rule:

Test the closest destination first, then move outward one layer at a time.

For example, if:

1https://api.example.com

does not work, we should not immediately start changing public DNS or restarting the Ingress Controller.

Instead test:

 1Application listening?
 2       |
 3       v
 4Pod IP reachable?
 5       |
 6       v
 7Service reachable?
 8       |
 9       v
10EndpointSlice correct?
11       |
12       v
13DNS working?
14       |
15       v
16NetworkPolicy allows traffic?
17       |
18       v
19Ingress / Gateway route?
20       |
21       v
22Load Balancer?
23       |
24       v
25Public DNS?

Every successful test eliminates possible causes.

1. Start with the Pods

Suppose we have:

1frontend
2   |
3   v
4api-service
5   |
6   v
7api Pods

and the frontend reports:

1connection refused

First inspect the backend Pods:

1kubectl get pods \
2  -n production \
3  -o wide

Look at:

• STATUS;

• READY;

• IP;

• NODE;

• restart count.

For example:

1NAME                      READY   STATUS    IP
2api-7cf8f76bcd-jx9pq      1/1     Running   10.244.1.23
3api-7cf8f76bcd-qt8fz      1/1     Running   10.244.2.15

Running does not guarantee that the application is accepting connections, but it gives us a starting point.

2. Is the application actually listening?

A surprisingly common Kubernetes networking problem is not a Kubernetes networking problem at all.

The application may not be listening on the expected port.

If the container image includes the necessary tools:

1kubectl exec \
2  -n production \
3  <pod> -- \
4  ss -lntp

We can also test the application locally:

1kubectl exec \
2  -n production \
3  <pod> -- \
4  curl -v http://127.0.0.1:8080/health

If this fails:

1Pod
2 |
3 X
4Application

there is little value in troubleshooting the Service yet.

First determine why the process is not accepting connections.

A classic problem: listening only on localhost

Suppose the application binds to:

1127.0.0.1:8080

Inside the container:

1curl http://127.0.0.1:8080

may work.

But other Pods reach the application using its Pod IP:

110.244.1.23:8080

If the process only listens on loopback, that connection can fail.

Applications running in Kubernetes commonly need to listen on:

10.0.0.0

or another appropriate Pod interface.

3. Test the Pod IP directly

From another Pod, test the backend address.

A temporary debugging Pod is useful:

1kubectl run network-debug \
2  -n production \
3  --rm -it \
4  --restart=Never \
5  --image=curlimages/curl \
6  -- sh

From inside it:

1curl -v http://10.244.1.23:8080

If this works:

1Debug Pod
2    |
3    v
4Pod IP
5    |
6    v
7Application
8    |
9    OK

we have verified:

• basic Pod networking;

• the destination port;

• the application.

Now we can move to the Service layer.

If it fails, investigate:

1Application
2Pod networking
3NetworkPolicy
4CNI
5Node networking

4. Investigate the Service

List Services:

1kubectl get svc \
2  -n production

Then inspect the affected Service:

1kubectl describe svc api-service \
2  -n production

Pay attention to:

1Selector
2Type
3IP Families
4ClusterIP
5Port
6TargetPort

A Service object can exist correctly in the Kubernetes API while still not providing working connectivity.

Service port vs targetPort

Consider:

1ports:
2  - port: 80
3    targetPort: 8080

The flow is:

1Client
2   |
3   | :80
4   v
5Service
6   |
7   | :8080
8   v
9Pod

port is the Service port exposed to clients.

targetPort identifies the backend port.

If the application listens on:

18080

but the Service uses:

1targetPort: 3000

DNS can work and the Service can exist, but traffic will not reach the expected application port.

5. EndpointSlices: does the Service have backends?

This is one of the most important checks.

Modern Kubernetes troubleshooting should primarily inspect EndpointSlices:

1kubectl get endpointslices \
2  -n production \
3  -l kubernetes.io/service-name=api-service

For more detail:

1kubectl describe endpointslice \
2  -n production \
3  -l kubernetes.io/service-name=api-service

EndpointSlice is the API Kubernetes uses to efficiently represent Service backends.

Conceptually:

1Service
2   |
3   v
4EndpointSlice
5   |
6   +--- 10.244.1.23:8080
7   |
8   +--- 10.244.2.15:8080

If endpoints exist, we can test those IP addresses directly.

What if there are no endpoints?

Suppose we have:

1Service
2   |
3   v
4EndpointSlice
5   |
6   X
7No backend Pods

One of the first things to inspect is the Service selector.

1kubectl get svc api-service \
2  -n production \
3  -o yaml

For example:

1selector:
2  app: api

Now inspect Pod labels:

1kubectl get pods \
2  -n production \
3  --show-labels

If the Pods have:

1app=backend-api

but the Service selects:

1app=api

there is no match.

The Service will not have the expected Pod backends.

Readiness matters too

Suppose the labels match correctly.

But:

1kubectl get pods -n production

shows:

1NAME           READY
2api-abc        0/1
3api-def        0/1

A failing readiness probe can prevent those Pods from being considered ready endpoints for normal Service traffic.

Check:

1kubectl describe pod api-abc \
2  -n production

Then inspect EndpointSlice conditions:

1kubectl get endpointslices \
2  -n production \
3  -l kubernetes.io/service-name=api-service \
4  -o yaml

EndpointSlices can expose conditions such as:

1ready
2serving
3terminating

These help consumers distinguish whether an endpoint is ready to receive traffic and whether it is terminating.

6. Test the Service from inside the cluster

Once backend endpoints are confirmed:

1kubectl run network-debug \
2  -n production \
3  --rm -it \
4  --restart=Never \
5  --image=curlimages/curl \
6  -- sh

Then:

1curl -v http://api-service

or:

1curl -v http://api-service:80

We can also test the ClusterIP directly:

1curl -v http://10.96.120.15:80

This creates a useful distinction.

Pod IP works, Service IP fails

1Client
2  |
3  +---- Pod IP --------> OK
4  |
5  +---- Service IP ----> FAIL

Now focus on:

1Service configuration
2EndpointSlice
3Service proxy implementation
4Node networking

Depending on the cluster networking architecture, Service traffic may be implemented by kube-proxy or another dataplane implementation.

Service IP works, Service DNS fails

1Service ClusterIP
2       |
3       OK
4
5Service name
6       |
7       FAIL

That points strongly toward DNS.

7. DNS troubleshooting

Kubernetes provides DNS-based Service discovery.

From a Pod in the same namespace we can normally use:

1api-service

From another namespace:

1api-service.production

or a fully qualified service name:

1api-service.production.svc.cluster.local

The cluster domain is configurable, so cluster.local is common but should not be treated as universal.

Test name resolution

From a Pod with DNS tools:

1nslookup api-service

Then:

1nslookup api-service.production

And:

1nslookup api-service.production.svc.cluster.local

Also inspect:

1cat /etc/resolv.conf

A typical configuration might include:

1search production.svc.cluster.local svc.cluster.local cluster.local
2nameserver 10.96.0.10
3options ndots:5

This helps explain why short names can resolve within one namespace but not another.

Check CoreDNS

If DNS is failing across several workloads:

1kubectl get pods \
2  -n kube-system \
3  -l k8s-app=kube-dns

Inspect the DNS Service:

1kubectl get svc \
2  -n kube-system

And logs:

1kubectl logs \
2  -n kube-system \
3  -l k8s-app=kube-dns

A production cluster can have several replicas or containers involved, so during an incident it is useful to identify exactly which instances are processing queries.

An important distinction

Consider:

1nslookup api-service
2        |
3       FAIL
4
5nslookup kubernetes.default
6        |
7       FAIL

This suggests a broader DNS problem.

But if:

1nslookup kubernetes.default
2        |
3        OK
4
5nslookup api-service
6        |
7       FAIL

investigate:

1Service name
2Namespace
3Service existence
4DNS record creation

before deciding that CoreDNS itself is completely unavailable.

8. NetworkPolicy

Another common scenario is:

1Pod A -> Pod B

worked before a networking policy change.

Start with:

1kubectl get networkpolicy -A

Then:

1kubectl describe networkpolicy \
2  <policy> \
3  -n production

Also inspect labels:

1kubectl get pods \
2  -n production \
3  --show-labels

because NetworkPolicy selects Pods using labels.

NetworkPolicies are additive

This behavior is important.

When multiple NetworkPolicies select the same Pod, they are not processed as ordered firewall rules where the first match wins.

Allowed traffic from applicable policies is combined.

For Pod-to-Pod communication:

1Source Pod
2    |
3    | Egress must allow
4    v
5Network
6    |
7    | Ingress must allow
8    v
9Destination Pod

When both sides are isolated, the source egress policy and destination ingress policy must both permit the connection.

Test a NetworkPolicy hypothesis

From the source Pod:

1kubectl exec \
2  -n frontend \
3  <frontend-pod> -- \
4  curl -v --connect-timeout 5 \
5  http://api-service.production:8080

Or test TCP connectivity:

1nc -vz \
2  api-service.production \
3  8080

If:

1DNS resolves
2       |
3       v
4Correct destination
5       |
6       v
7Connection timeout

NetworkPolicy, routing, or firewall filtering become stronger hypotheses.

Remember the CNI implementation

Creating a NetworkPolicy object does not automatically mean a cluster can enforce it.

The cluster networking implementation must support NetworkPolicy enforcement.

Therefore:

1NetworkPolicy exists
2        |
3        X
4does not necessarily mean
5traffic is being enforced

Actual behavior depends on the networking plugin.

9. Same-node communication works, cross-node communication fails

This is a valuable signal for CNI or infrastructure problems.

Suppose:

1Node A
2  |
3  +-- Pod A
4       |
5       | works
6       v
7  +-- Pod B

but:

1Node A                  Node B
2  |                       |
3Pod A -----------------> Pod C
4            FAIL

That significantly changes the investigation.

Check Pod placement:

1kubectl get pods \
2  -A \
3  -o wide

Then nodes:

1kubectl get nodes -o wide

Potential areas include:

• CNI agents;

• routing;

• encapsulation;

• firewall;

• MTU;

• node interfaces;

• IP address management.

Identify the networking stack

Different Kubernetes distributions use different networking components.

Start with:

1kubectl get pods \
2  -n kube-system \
3  -o wide

You might find implementations such as:

1Calico
2Cilium
3Flannel
4Antrea
5cloud-provider-specific networking

Each implementation has its own commands, metrics, and architecture.

Do not start using Calico- or Cilium-specific troubleshooting commands until you know which network implementation the cluster actually uses.

10. CNI and IP allocation failures

If newly created Pods cannot obtain working networking, Events can provide useful clues.

1kubectl describe pod <pod> \
2  -n production

Look for messages related to:

1sandbox creation
2network setup
3CNI
4IP allocation

Also review cluster Events:

1kubectl get events -A \
2  --sort-by='.lastTimestamp'

This can reveal whether several Pods or nodes began failing at approximately the same time.

11. MTU: the problem that can look random

Some networking failures look like:

1Small request
2     |
3     OK
4
5Large request
6     |
7     timeout

or:

1TCP connection
2     |
3     established
4     |
5TLS handshake / large response
6     |
7     FAIL

One possible cause is an MTU mismatch.

This can appear in networks using:

• overlays;

• VXLAN;

• VPNs;

• cloud networking;

• tunnels.

Inspect interfaces:

1ip link

and routing:

1ip route

MTU changes should only be made with an understanding of the CNI and underlying network.

Changing MTU values through trial and error can introduce additional failures.

12. Ingress troubleshooting

Suppose:

1curl http://api-service.production

works inside the cluster.

But:

1https://api.example.com

does not work externally.

That tells us:

1Pod       OK
2Service   OK
3DNS       OK
4         |
5         v
6Problem is farther upstream

Now investigate Ingress.

1kubectl get ingress -A

Then:

1kubectl describe ingress <name> \
2  -n production

Inspect:

1IngressClass
2Host
3Path
4Backend Service
5Backend Port
6TLS
7Events
8Address

Ingress requires a controller

Creating:

1kind: Ingress

does not by itself implement the traffic routing.

An Ingress Controller must watch those resources and configure the corresponding data plane.

Check:

1kubectl get ingressclass

Then identify the implementation used by the cluster.

Inspect its Pods and logs according to its namespace:

1kubectl get pods \
2  -n <ingress-controller-namespace>

1kubectl logs \
2  -n <ingress-controller-namespace> \
3  <controller-pod>

Do not assume that every Kubernetes cluster uses ingress-nginx.

502 vs 503

The exact meaning depends on the proxy or controller implementation, but these status codes can guide the investigation.

For example:

 1External Client
 2      |
 3      v
 4Ingress Controller
 5      |
 6      +---- backend unavailable
 7      |
 8      +---- backend connection failure
 9      |
10      +---- timeout

Always correlate:

• controller logs;

• EndpointSlices;

• application logs;

• latency metrics.

Do not diagnose solely from the HTTP status code.

13. Gateway API

For new designs, Gateway API should also be considered.

The Kubernetes project recommends Gateway rather than extending the older Ingress API.

Ingress remains supported, but its API is frozen.

A typical Gateway API traffic path might look like:

 1Client
 2   |
 3Gateway
 4   |
 5HTTPRoute
 6   |
 7Service
 8   |
 9EndpointSlice
10   |
11Pods

Depending on the installed API and implementation:

1kubectl get gateway -A

1kubectl get httproute -A

Then:

1kubectl describe gateway <gateway> \
2  -n <namespace>

1kubectl describe httproute <route> \
2  -n <namespace>

Gateway API also requires an appropriate implementation/controller. Kubernetes does not automatically provide a Gateway dataplane simply because Gateway resources exist.

14. LoadBalancer remains Pending

Another common problem is:

1kubectl get svc

showing:

1TYPE           EXTERNAL-IP
2LoadBalancer   <pending>

Ask:

1Service type LoadBalancer
2           |
3           v
4Who provides the load balancer?

In a cloud environment, this can involve:

• cloud controller;

• IAM or permissions;

• network configuration;

• quota;

• subnets;

• load balancer controllers.

In bare-metal and local environments, an additional load-balancer implementation may be required.

Kubernetes defines the LoadBalancer abstraction, but the surrounding infrastructure must fulfill it.

15. Public DNS

Suppose the load balancer works:

1Load Balancer
2      |
3      OK

but:

1api.example.com
2      |
3     FAIL

Check public DNS:

1dig api.example.com

or:

1nslookup api.example.com

Compare the result with the expected load balancer address.

A particularly useful test is:

1curl -v \
2  --resolve api.example.com:443:<IP> \
3  https://api.example.com

This allows us to test:

1HTTP
2TLS
3Host-based routing

against a specific IP without relying on normal DNS resolution.

16. TLS

A networking problem can actually be a TLS problem.

Start with:

1curl -vk https://api.example.com

For more detail:

1openssl s_client \
2  -connect api.example.com:443 \
3  -servername api.example.com

Inspect:

1certificate chain
2expiration
3SAN
4issuer
5SNI
6hostname

If Kubernetes stores the certificate in a Secret:

1kubectl get secret <tls-secret> \
2  -n production

and inspect the relevant Ingress or Gateway resource to confirm which certificate should be presented.

17. Pods cannot reach the Internet

Now investigate the opposite direction:

1Pod
2 |
3 v
4Internet
5 |
6 X

Start from inside the Pod:

1curl -v https://example.com

Then separate DNS from connectivity:

1nslookup example.com

If DNS succeeds but the connection fails:

1DNS
2 |
3 OK
4 |
5 v
6TCP connection
7 |
8 FAIL

investigate:

• NetworkPolicy egress;

• routing;

• NAT;

• firewall;

• proxy;

• cloud network controls;

• CNI.

DNS vs egress

For example:

1nslookup example.com

works.

But:

1curl https://example.com

times out.

DNS resolution is working, so restarting CoreDNS is unlikely to address the actual problem.

If:

1nslookup example.com
2     |
3     FAIL

then determine whether the Pod can reach its configured DNS server before moving to other networking layers.

18. Database connection timeout

The same methodology works for database connectivity.

Suppose an application reports:

1connection to database timed out

Break the connection into stages:

 1Application
 2    |
 3    v
 4DNS resolution
 5    |
 6    v
 7TCP connection
 8    |
 9    v
10TLS
11    |
12    v
13Authentication
14    |
15    v
16Database
17

DNS:

1nslookup database.example.internal

TCP:

1nc -vz \
2  database.example.internal \
3  5432

If the connection succeeds, we have already demonstrated that:

1DNS + routing + TCP path

work to some degree.

We can then investigate:

• TLS;

• credentials;

• database availability;

• connection limits;

• application connection pools.

Good networking troubleshooting is also about proving which layers are not broken.

19. Connection refused vs timeout

These symptoms can provide useful clues.

Connection refused

1Client
2  |
3  v
4Destination reached
5  |
6  v
7Nothing accepting connection

Possible causes include:

• process not listening;

• wrong port;

• proxy actively rejecting the connection.

Timeout

1Client
2  |
3  v
4Packets sent
5  |
6  ?
7  |
8No response

Possible causes include:

• NetworkPolicy;

• firewall;

• routing;

• unavailable destination;

• severe packet loss.

These are not absolute rules, but they help determine the next test.

20. Packet capture

When application-level tests are not enough, packet capture can show us what is happening on the wire.

Depending on permissions and environment:

1tcpdump -i any -nn \
2  host 10.244.2.15 \
3  and port 8080

Look for:

1SYN
2SYN-ACK
3RST
4retransmissions

For example:

1Client                  Server
2
3SYN -------------------->
4
5SYN -------------------->
6
7SYN -------------------->
8
9        no response

is very different from:

1Client                  Server
2
3SYN -------------------->
4
5    <-------------- RST

Packet capture helps determine how far traffic actually travels.

21. Debugging a specific node

Suppose:

1kubectl get pods -A -o wide

reveals:

1Pods on node-01 -> OK
2Pods on node-02 -> FAIL

Our hypothesis shifts away from a generic application failure toward something associated with:

1node-02
2CNI
3routes
4interfaces
5firewall

With appropriate permissions:

1kubectl debug node/node-02 \
2  -it \
3  --image=ubuntu

Then inspect:

1ip addr
2ip route
3ip link

For deeper incidents, inspect the relevant CNI agent logs and metrics as well.

22. Metrics

Not every networking incident causes a total outage.

Other symptoms include:

1Packet loss
2Latency
3Connection resets
4Retries
5Timeouts

Useful signals can include:

1request rate
2error rate
3request duration
4TCP resets
5packet drops
6retransmissions
7DNS latency
8DNS failures
9connection counts

Exact metrics depend on the CNI, ingress/gateway implementation, service mesh, cloud platform, and observability stack.

23. Distributed tracing

Consider:

 1Frontend
 2   |
 3   v
 4API
 5   |
 6   v
 7Payment Service
 8   |
 9   v
10Database

The user experiences a request taking:

15.2 seconds

A distributed trace might reveal:

1Frontend                  20 ms
2   |
3API                       35 ms
4   |
5Payment Service         5.1 sec
6   |
7Database                  25 ms

Now we know which dependency deserves further investigation.

Traces do not replace network tests, but they are extremely useful for identifying which hop in a distributed request path is slow or failing.

24. Logs

Networking incidents can require correlating logs from several layers:

1Application logs
2Ingress/Gateway logs
3CNI logs
4CoreDNS logs
5Cloud load balancer logs
6Firewall logs

Where possible, correlate using:

1timestamp
2request ID
3trace ID
4source IP
5destination
6status code

This creates a much more complete view than inspecting each component independently.

Complete troubleshooting flow

The process can be summarized as:

 1                Request fails
 2                     |
 3                     v
 4              Application alive?
 5                     |
 6                     v
 7             Listening on port?
 8                     |
 9                     v
10               Pod IP works?
11                     |
12                     v
13              Service works?
14                     |
15                     v
16          EndpointSlices correct?
17                     |
18                     v
19                DNS works?
20                     |
21                     v
22          NetworkPolicy allows?
23                     |
24                     v
25       Cross-node networking works?
26                     |
27                     v
28                  CNI healthy?
29                     |
30                     v
31          Ingress / Gateway works?
32                     |
33                     v
34             Load Balancer works?
35                     |
36                     v
37              Public DNS works?
38                     |
39                     v
40                   TLS works?
41                     |
42                     v
43                  Root cause

Not every incident requires every step.

Each test should eliminate possible causes and narrow the investigation.

Command reference

 1# Pods and nodes
 2kubectl get pods -A -o wide
 3kubectl get nodes -o wide
 4
 5# Services
 6kubectl get svc -A
 7kubectl describe svc <service> -n <namespace>
 8
 9# EndpointSlices
10kubectl get endpointslices \
11  -n <namespace> \
12  -l kubernetes.io/service-name=<service>
13
14kubectl get endpointslices \
15  -n <namespace> \
16  -l kubernetes.io/service-name=<service> \
17  -o yaml
18
19# Labels
20kubectl get pods \
21  -n <namespace> \
22  --show-labels
23
24# DNS
25nslookup <service>
26nslookup <service>.<namespace>
27cat /etc/resolv.conf
28
29# CoreDNS
30kubectl get pods \
31  -n kube-system \
32  -l k8s-app=kube-dns
33
34kubectl logs \
35  -n kube-system \
36  -l k8s-app=kube-dns
37
38# NetworkPolicy
39kubectl get networkpolicy -A
40kubectl describe networkpolicy \
41  <policy> \
42  -n <namespace>
43
44# Ingress
45kubectl get ingress -A
46kubectl describe ingress \
47  <ingress> \
48  -n <namespace>
49
50kubectl get ingressclass
51
52# Gateway API
53kubectl get gateway -A
54kubectl get httproute -A
55
56# Temporary debug Pod
57kubectl run network-debug \
58  -n <namespace> \
59  --rm -it \
60  --restart=Never \
61  --image=curlimages/curl \
62  -- sh
63
64# Node debugging
65kubectl debug node/<node> \
66  -it \
67  --image=ubuntu
68
69# Network tools
70curl -v <url>
71nslookup <hostname>
72dig <hostname>
73nc -vz <hostname> <port>
74ip addr
75ip route
76ip link
77tcpdump -i any -nn

What not to do

Avoid starting with actions such as:

1Service doesn't work
2       |
3       v
4Restart CoreDNS

or:

1502
2 |
3 v
4Restart Ingress Controller

or:

1Timeout
2  |
3  v
4Disable NetworkPolicy

These changes modify the system without demonstrating the root cause.

A better workflow is:

 1Symptom
 2   |
 3   v
 4Test one boundary
 5   |
 6   v
 7Record result
 8   |
 9   v
10Eliminate hypotheses
11   |
12   v
13Move one layer
14   |
15   v
16Find failure point
17   |
18   v
19Fix
20   |
21   v
22Validate

Conclusion

Kubernetes networking becomes much easier to understand when we stop treating it as a single component.

A request can pass through:

 1Client
 2   |
 3DNS
 4   |
 5Load Balancer
 6   |
 7Gateway / Ingress
 8   |
 9Service
10   |
11EndpointSlice
12   |
13Pod network
14   |
15Application

Each layer can be tested independently.

That is why one of the most useful questions during troubleshooting is:

How far do we know the connection works?

If we can prove:

1Pod IP       -> works
2Service IP   -> works
3Service DNS  -> works
4Ingress      -> fails

we have already eliminated a large part of the system from the investigation.

The objective is to replace trial-and-error troubleshooting with evidence.

In the next article we will investigate Kubernetes health checks in depth:

• readiness probes;

• liveness probes;

• startup probes;

• timeouts;

• thresholds;

• probe-induced restart loops;

• external dependencies in health endpoints;

• cascading failures caused by incorrectly designed probes.