kubectl get svc -A -o wide
kubectl get nodes -o wide

TARGET_IP="10.244.1.23"
kubectl get pods -A -o wide | grep "$TARGET_IP"

1TARGET_IP="10.244.1.23"
2
3kubectl get pods -A \
4  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.status.podIP}{"\n"}{end}' \
5| awk -v ip="$TARGET_IP" '$3==ip {print $1, $2}' ``` This returns namespace and pod name only when the IP matches exactly. That is much safer than relying on loosely formatted column output in a script. ## Use Field Selectors When Available Some clusters support selecting pods directly by `status.podIP`. ```bash kubectl get pods -A \ --field-selector=status.podIP=10.244.1.23 \ -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,IP:.status.podIP' ``` This is cleaner than client-side filtering, but field-selector behavior can vary by resource and cluster version. If it does not work in your environment, fall back to structured output filtering. ## Query the Kubernetes API for Automation For repeatable tools or incident bots, use the Kubernetes API rather than shell parsing. ```python from kubernetes import client, config config.load_kube_config() v1 = client.CoreV1Api() target_ip = "10.244.1.23" pods = v1.list_pod_for_all_namespaces(watch=False) for pod in pods.items: if pod.status.pod_ip == target_ip: print(f"{pod.metadata.namespace}/{pod.metadata.name}") ``` For in-cluster automation, use `config.load_incluster_config()` instead of loading the local kubeconfig file. ## Remember That Pod IPs Are Ephemeral A pod IP is useful for incident lookup, but it is not a durable identity. Pods can restart, move, or be replaced by a new pod with a different UID and IP. If you need long-term correlation, capture more than the IP: - cluster - namespace - pod name - pod UID - owner object such as Deployment or StatefulSet That is much more reliable than treating the IP as a stable identifier over time. ## Follow the Lookup with Pod Inspection Once you find the pod name, the next step is usually to inspect the pod and its owner. ```bash kubectl -n my-namespace describe pod my-pod-name kubectl -n my-namespace get pod my-pod-name -o yaml ``` That often reveals restarts, probe failures, scheduling issues, or owner references that explain why the pod was involved in the incident. ## Common Pitfalls The biggest pitfall is trying to look up a service IP in the pod list and assuming the lookup is broken when it returns nothing. Another common issue is searching only one namespace when the pod lives elsewhere. Incident tooling should usually search across all namespaces unless you already know the scope. People also over-trust pod IPs as long-lived identifiers even though they are temporary by design. ## Summary - First verify that the target address is actually a pod IP and not a service or node IP. - Use `kubectl` with JSONPath or field selectors for reliable shell-based lookup. - Use the Kubernetes API for repeatable automation. - Treat pod IP as an incident lookup key, not as a durable identity. - After finding the pod, inspect its namespace, owner, and recent events to continue the investigation.