对于新安装的Kubernetes，经常出现的问题是Service无法正常运行。你已经通过Deployment（或其他工作负载控制器）运行了Pod，并创建Service，但是当你尝试访问它时，没有任何响应。
在Pod中运行命令对于这里的许多步骤，你可能希望知道运行在集群中的Pod看起来是什么样的。最简单的方法是运行一个交互式的alpinePod：
$kubectlrun-it--rm--restart=Neveralpine--image=alpinesh
说明：如果没有看到命令提示符，请按回车。
如果你已经有了你想使用的正在运行的Pod，则可以运行以下命令去进入：
kubectlexecPOD-NAME-cCONTAINER-NAME--COMMAND设置
为了完成本次实践的任务，我们先运行几个Pod。由于你可能正在调试自己的Service，所以，你可以使用自己的信息进行替换，或者你也可以跟着教程并开始下面的步骤来获得第二个数据点。
kubectlcreatedeploymenthostnames--image=k8s.gcr.io/serve_hostnamedeployment.apps/hostnamescreated
kubectl命令将打印创建或变更的资源的类型和名称，它们可以在后续命令中使用。让我们将这个deployment的副本数扩至3。
kubectlscaledeploymenthostnames--replicas=3deployment.apps/hostnamesscaled
请注意这与你使用以下YAML方式启动Deployment类似：
apiVersion:apps/v1kind:Deploymentmetadata:labels:app:hostnamesname:hostnamesspec:selector:matchLabels:app:hostnamesreplicas:3template:metadata:labels:app:hostnamesspec:containers:-name:hostnamesimage:k8s.gcr.io/serve_hostname
"app"标签是kubectlcreatedeployment根据Deployment名称自动设置的。
确认你的Pods是运行状态:
kubectlgetpods-lapp=hostnamesNAMEREADYSTATUSRESTARTSAGEhostnames--bbpiw1/1Running02mhostnames--ly40y1/1Running02mhostnames--tlaok1/1Running02m
你还可以确认你的Pod是否正在提供服务。你可以获取PodIP地址列表并直接对其进行测试。
kubectlgetpods-lapp=hostnames\-ogo-template={{range.items}}{{.status.podIP}}{{"\n"}}{{end}}10..0...0...0.7
用于本教程的示例容器仅通过HTTP在端口上提供其自己的主机名，但是如果要调试自己的应用程序，则需要使用你的Pod正在侦听的端口号。
在Pod内运行：
forepin10..0.5:937..0.6:937..0.7:;dowget-qO-$epdone
输出类似这样：
hostnames--bbpiwhostnames--ly40yhostnames--tlaok
如果此时你没有收到期望的响应，则你的Pod状态可能不健康，或者可能没有在你认为正确的端口上进行监听。你可能会发现kubectllogs命令对于查看正在发生的事情很有用，或者你可能需要通过kubectlexec直接进入Pod中并从那里进行调试。
假设到目前为止一切都已按计划进行，那么你可以开始调查为何你的Service无法正常工作。
Service是否存在？细心的读者会注意到我们实际上尚未创建Service-这是有意而为之。这一步有时会被遗忘，这是首先要检查的步骤。
那么，如果我尝试访问不存在的Service会怎样？假设你有另一个Pod通过名称匹配到Service，你将得到类似结果：
wget-O-hostnamesResolvinghostnames(hostnames)...failed:Nameorservicenotknown.wget:unabletoresolvehostaddresshostnames
首先要检查的是该Service是否真实存在：
kubectlgetsvchostnamesNoresourcesfound.Errorfromserver(NotFound):services"hostnames"notfound
让我们创建Service。和以前一样，在这次实践中-你可以在此处使用自己的Service的内容。
kubectlexposedeploymenthostnames--port=80--target-port=service/hostnamesexposed
重新运行查询命令，确认没有问题：
kubectlgetsvchostnamesNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGEhostnamesClusterIP10.0.1.none80/TCP5s
现在你知道了Service确实存在。
同前，此步骤效果与通过YAML方式启动Service一样：
apiVersion:v1kind:Servicemetadata:name:hostnamesspec:selector:app:hostnamesports:-name:defaultprotocol:TCPport:80targetPort:
为了突出配置范围的完整性，你在此处创建的Service使用的端口号与Pods不同。对于许多真实的Service，这些值可以是相同的。
Service是否可通过DNS名字访问？通常客户端通过DNS名称来匹配到Service。
从相同命名空间下的Pod中运行以下命令：
nslookuphostnamesAddress1:10.0.0.10kube-dns.kube-system.svc.cluster.localName:hostnamesAddress1:10.0.1.hostnames.default.svc.cluster.local
如果失败，那么你的Pod和Service可能位于不同的命名空间中，请尝试使用限定命名空间的名称（同样在Pod内运行）：
nslookuphostnames.defaultAddress1:10.0.0.10kube-dns.kube-system.svc.cluster.localName:hostnames.defaultAddress1:10.0.1.hostnames.default.svc.cluster.local
如果成功，那么需要调整你的应用，使用跨命名空间的名称去访问它，或者在相同的命名空间中运行应用和Service。如果仍然失败，请尝试一个完全限定的名称：
nslookuphostnames.default.svc.cluster.localAddress1:10.0.0.10kube-dns.kube-system.svc.cluster.localName:hostnames.default.svc.cluster.localAddress1:10.0.1.hostnames.default.svc.cluster.local
注意这里的后缀："default.svc.cluster.local"。"default"是我们正在操作的命名空间。"svc"表示这是一个Service。"cluster.local"是你的集群域，在你自己的集群中可能会有所不同。
你也可以在集群中的节点上尝试此操作：
说明：10.0.0.10是集群的DNS服务IP，你的可能有所不同。
nslookuphostnames.default.svc.cluster.local10.0.0.10Server:10.0.0.10Address:10.0.0.10#53Name:hostnames.default.svc.cluster.localAddress:10.0.1.
如果你能够使用完全限定的名称查找，但不能使用相对名称，则需要检查你Pod中的/etc/resolv.conf文件是否正确。在Pod中运行以下命令：
cat/etc/resolv.conf
你应该可以看到类似这样的输出：
nameserver10.0.0.10searchdefault.svc.cluster.localsvc.cluster.localcluster.localexample.
