01
Read all three port declarations correctly
A Service port is the endpoint clients use. Its targetPort identifies the destination port on selected Pods. A containerPort declaration documents a container port but does not cause the application to listen there.
In our test the Pod was Ready and the Service had a ready endpoint. Requests still failed while targetPort pointed at 8081, because the process listened on 8080. Backend readiness and a correct destination socket were separate facts.
kubectl -n your-namespace get service your-service -o yaml
kubectl -n your-namespace get endpointslices \
-l kubernetes.io/service-name=your-service -o yaml02
Confirm the listener independently
Inspect the application configuration and startup output to identify the actual listen port and address. From an approved diagnostic Pod, request the application’s Pod IP and port. Use its actual protocol rather than an HTTP test against a non-HTTP server.
Our diagnostic Pod received the expected HTTP response directly from the application Pod on 8080 while the Service path failed. That comparison narrowed the investigation to the path between the Service definition and the backend socket.
# In an approved diagnostic Pod that already has curl:
curl --fail http://ACTUAL_POD_IP:8080/
# Then compare the Service path from the same Pod:
curl --fail http://your-service.your-namespace.svc.cluster.local/03
Correct only the backend mapping
For this example, clients can continue using Service port 80 while targetPort changes to 8080. Update the mapping in the source of truth. Do not change the application listener, DNS records, and Service selector simultaneously without evidence that they are wrong.
This fragment assumes the selected application really listens on 8080. If targetPort is a name, verify that the corresponding named container port resolves as intended across the selected Pods.
spec:
ports:
- name: http
port: 80
targetPort: 808004
Wait for the updated endpoints and repeat the request
Inspect the resulting EndpointSlice port and make the same Service request again. Account for controller propagation rather than interpreting an immediate retry as a stable result. Keep the same requesting Pod and URL for a useful comparison.
After the lab Service changed from targetPort 8081 to 8080, the request through its name returned HTTP 200 and the expected marker. The application Pod and its listener were unchanged. That was the narrowly tested repair.
05
Distinguish remaining transport and protocol failures
If the direct Pod request also fails, return to process binding, readiness, network policy, and routing. If both direct and Service requests work but an external URL fails, investigate the next component in that route.
A TLS name mismatch or application authentication error after the port repair may show that traffic now reaches a server. Continue at that layer instead of undoing a correct TCP mapping. Keep the successful minimal request as a reference for the next stage.
Sınırları bil
Tested with Kubernetes v1.32.2, a ClusterIP Service on port 80, and a Python HTTP process listening on 8080. The incorrect targetPort was 8081. This lab does not establish the behavior of every CNI, NetworkPolicy, or external load balancer.
Kaynaklar ve ileri okuma
CoreTrailKit tarafından hazırlanan teknik yayın.
Bütün yazıları keşfet