早些时候，我们已经看到 Pod 是运行状态。我们可以再检查一下：
kubectl get pods -l app=hostnames NAME READY STATUS RESTARTS AGE hostnames-632524106-bbpiw 1/1 Running 0 1h hostnames-632524106-ly40y 1/1 Running 0 1h hostnames-632524106-tlaok 1/1 Running 0 1h-l app=hostnames 参数是在 Service 上配置的标签选择器。
"AGE" 列表明这些 Pod 已经启动一个小时了，这意味着它们运行良好，而未崩溃。
"RESTARTS" 列表明 Pod 没有经常崩溃或重启。经常性崩溃可能导致间歇性连接问题。 如果重启次数过大，通过调试 pod 了解相关技术。
在 Kubernetes 系统中有一个控制回路，它评估每个 Service 的选择算符，并将结果保存到 Endpoints 对象中。
kubectl get endpoints hostnames NAME ENDPOINTS hostnames 10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376这证实 Endpoints 控制器已经为你的 Service 找到了正确的 Pods。 如果 ENDPOINTS 列的值为 ，则应检查 Service 的 spec.selector 字段， 以及你实际想选择的 Pod 的 metadata.labels 的值。 常见的错误是输入错误或其他错误，例如 Service 想选择 app=hostnames，但是 Deployment 指定的是 run=hostnames。在 1.18之前的版本中 kubectl run 也可以被用来创建 Deployment。
Pod 正常工作吗？至此，你知道你的 Service 已存在，并且已匹配到你的Pod。在本实验的开始，你已经检查了 Pod 本身。 让我们再次检查 Pod 是否确实在工作 - 你可以绕过 Service 机制并直接转到 Pod，如上面的 Endpoint 所示。
说明： 这些命令使用的是 Pod 端口（9376），而不是 Service 端口（80）。
在 Pod 中运行：
for ep in 10.244.0.5:9376 10.244.0.6:9376 10.244.0.7:9376; do wget -qO- $ep done输出应该类似这样：
hostnames-632524106-bbpiw hostnames-632524106-ly40y hostnames-632524106-tlaok你希望 Endpoint 列表中的每个 Pod 都返回自己的主机名。 如果情况并非如此（或你自己的 Pod 的正确行为是什么），你应调查发生了什么事情。
kube-proxy 正常工作吗？如果你到达这里，则说明你的 Service 正在运行，拥有 Endpoints，Pod 真正在提供服务。 此时，整个 Service 代理机制是可疑的。让我们一步一步地确认它没问题。
Service 的默认实现（在大多数集群上应用的）是 kube-proxy。 这是一个在每个节点上运行的程序，负责配置用于提供 Service 抽象的机制之一。 如果你的集群不使用 kube-proxy，则以下各节将不适用，你将必须检查你正在使用的 Service 的实现方式。
kube-proxy 正常运行吗？确认 kube-proxy 正在节点上运行。 在节点上直接运行，你将会得到类似以下的输出：
ps auxw | grep kube-proxy root 4194 0.4 0.1 101864 17696 ? Sl Jul04 25:43 /usr/local/bin/kube-proxy --master=https://kubernetes-master --kubeconfig=http://www.likecs.com/var/lib/kube-proxy/kubeconfig --v=2下一步，确认它并没有出现明显的失败，比如连接主节点失败。要做到这一点，你必须查看日志。 访问日志的方式取决于你节点的操作系统。 在某些操作系统上日志是一个文件，如 /var/log/messages kube-proxy.log， 而其他操作系统使用 journalctl 访问日志。你应该看到输出类似于：
I1027 22:14:53.995134 5063 server.go:200] Running in resource-only container "/kube-proxy" I1027 22:14:53.998163 5063 server.go:247] Using iptables Proxier. I1027 22:14:53.999055 5063 server.go:255] Tearing down userspace rules. Errors here are acceptable. I1027 22:14:54.038140 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [10.244.1.3:53] I1027 22:14:54.038164 5063 proxier.go:352] Setting endpoints for "kube-system/kube-dns:dns" to [10.244.1.3:53] I1027 22:14:54.038209 5063 proxier.go:352] Setting endpoints for "default/kubernetes:https" to [10.240.0.2:443] I1027 22:14:54.038238 5063 proxier.go:429] Not syncing iptables until Services and Endpoints have been received from master I1027 22:14:54.040048 5063 proxier.go:294] Adding new service "default/kubernetes:https" at 10.0.0.1:443/TCP I1027 22:14:54.040154 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns" at 10.0.0.10:53/UDP I1027 22:14:54.040223 5063 proxier.go:294] Adding new service "kube-system/kube-dns:dns-tcp" at 10.0.0.10:53/TCP如果你看到有关无法连接主节点的错误消息，则应再次检查节点配置和安装步骤。
kube-proxy 无法正确运行的可能原因之一是找不到所需的 conntrack 二进制文件。 在一些 Linux 系统上，这也是可能发生的，这取决于你如何安装集群， 例如，你是手动开始一步步安装 Kubernetes。如果是这样的话，你需要手动安装 conntrack 包（例如，在 Ubuntu 上使用 sudo apt install conntrack），然后重试。