Networking Kubernetes吊舱wget-qO-某些服务失败，但并非所有服务都失败

在我复习最近的实验时，我复习了笔记，用Kubernetes为后端和前端服务设置重新创建了一个相对简单的设置。在我的场景中，这两个服务都需要公开，目前我正在使用NodePort进行公开

大约一周前，这一切都很顺利，但我想我把事情搞砸了，这让我发疯了。结果是，我似乎无法通过该服务访问我的后端播客。我已经按照调试服务文档（）进行了操作，事情很快就乱了套

这是我当前的yaml文件：

apiVersion: v1
kind: Service
metadata:
  name: test
spec:
  type: NodePort
  ports:
  - name: default
    protocol: TCP
    port: 80
    targetPort: 8080
  selector:
    app: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
spec:
  selector:
    matchLabels:
      app: test
  replicas: 1
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: test
        image: jan/test:v1.0.0
        ports:
        - containerPort: 8080
          protocol: TCP

应用程序启动良好-它在日志中报告它已准备好接受请求。（这是一个Java/Grizzly应用程序）。下面是我试过的东西的清单

检查kubectl服务：它在那里（本例中为172.17.0.4）

执行官进入吊舱（阿尔卑斯山）

• ifconfig-172.17.0.4127.0.0.1
• nslookup测试10.96.0.10-工程 （注意，如果没有nameservice，将返回 无法解析“（null）”：名称未解析
• ping 127.0.0.1-工程
• wget-反应良好
• ping 172.17.0.4-工程
• wget-立即失败，连接被拒绝
• wget-qO-测试-一段时间后失败，操作超时

exec进入另一个（busybox）吊舱

• ifconfig-172.17.0.8127.0.0.1
• nslookup测试-工作
• ping至pod 172.17.0.4-工程
• wget-立即失败，连接被拒绝
• wget-qO-测试-立即失败，连接被拒绝

最重要的是，我认为

wget-qO-{service}

需要开始报告它的pod，而目前它没有。再次，我浏览了调试服务文档的场景，完成时没有问题

---

那么，

wget-qO-

失败还有什么不对呢？

那么，让我们看看……你在一个忙碌箱中

ifconfig-172.17.0.8127.0.0.1

wget-立即失败，连接被拒绝

你在这里干什么？这就像是做

localhost:8080

。当然你的连接被拒绝了。busybox的8080端口上没有任何服务

wget-qO-测试-立即失败，连接被拒绝

这里也一样。现在您在busybox的端口80上执行请求，这同样没有任何服务

这种配置绝对不可能工作。您所做的只是从busybox中向自己发出请求

---

您需要向指向您的应用程序或直接指向包含您的应用程序的pod的服务发出请求。

我删除了输入应用程序的一个重要属性。因此，实际上问题根本不在K8S级别。本质上，我是在使部署的应用程序“不可见”。

感谢您的响应！是的从busybox pod进行的测试有点笨拙。事实上，问题出在部署文件的后期编辑中。最初，我将

status.podIP

作为参数提供给应用程序。我无意中删除了该参数，使应用程序返回到其本地/默认IP地址。这导致了问题。我已更正该问题。n现在一切又开始了。