Investigate an internal Kubernetes service request.

Instruction: Trace the Service-to-Pod path, identify the correction supported by the evidence and explain how you would verify it.

Context:

In a fictional Kubernetes namespace shop, a caller resolves catalog.shop.svc.cluster.local to the Service IP, but its HTTP request fails. The following artifacts come from the same snapshot. A reviewed deployment intends the Service to target the current catalog Pods; there is no blue/green split.

apiVersion: v1
kind: Service
metadata:
  name: catalog
  namespace: shop
spec:
  selector:
    app: catalog-v1
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP
EvidenceObserved result
Pod labelscatalog-a and catalog-b: app=catalog-v2
Pod readinessBoth Ready=True
Service EndpointSlice endpoint listEmpty; no ready destination addresses
From the same caller to each Pod IP on 8080HTTP 200 from the expected catalog handler
App socket inside each Pod0.0.0.0:8080
Reviewed source of Service selectorStill app: catalog-v1

Do not assume every possible cluster failure has been excluded. State which boundary this evidence supports changing first.

Updated

Official answer available

Read the opening below, then unlock the full answer and practical guidance.

DNS reaches the Service, and the same caller can reach both application Pods directly on the target port...

Upgrade to view official answer

Related Questions