1

我有一个简单的 Express.js 服务器 Dockerized，当我运行它时：

docker run -p 3000:3000 mytag:my-build-id

http://localhost:3000/响应很好，如果我使用我的工作站的 LAN IP，比如http://10.44.103.60:3000/

现在，如果我使用如下服务部署声明将其部署到 MicroK8s：

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: my-service
spec:
  type: NodePort
  ports:
  - name: "3000"
    port: 3000
    targetPort: 3000
status:
  loadBalancer: {}

和像这样的吊舱规格（更新2019-11-05）：

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  name: my-service
spec:
  replicas: 1
  selector:
    matchLabels:
      name: my-service
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        name: my-service
    spec:
      containers:
      - image: mytag:my-build-id
        name: my-service
        ports:
        - containerPort: 3000
        resources: {}
      restartPolicy: Always
status: {}

并获取暴露的 NodePort viakubectl get services为 32750 并尝试在 MicroK8s 主机上访问它，如下所示：

卷曲http://127.0.0.1:32750

那么请求就会挂起，如果我尝试从我的工作站访问 MicroK8s 主机的 LAN IP，地址为 http://192.168.191.248:32750/ ，那么请求会立即被拒绝。

但是，如果我尝试使用

kubectl port-forward my-service-5db955f57f-q869q 3000:3000

然后http://localhost:3000/工作得很好。

因此，pod 部署似乎运行良好，并且 microbot-service 等示例服务在该集群上运行良好。

我确保 Express.js 服务器监听所有 IP

app.listen(port, '0.0.0.0', () =>  ...

那么可能是什么问题？

4

2 回答 2

2

您需要为您的服务添加一个选择器。这将告诉 Kubernetes 如何找到您的部署。此外，您可以使用 nodePort 指定服务的端口号。完成此操作后，您将能够卷曲您的 MicroK8s IP。

您的服务 YAML 应如下所示：

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: my-service
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30001
  selector: 
    name: my-service      
status:
  loadBalancer: {}
于 2019-11-05T14:56:18.990 回答
1

我工作站上 MicroK8s 主机的 LAN IP

那是你误解的主要根源；localhost,127.0.0.1和您机器的 LAN IP 与显然是运行 microk8s 的虚拟机无关（将这些信息实际包含在您的问题中，而不是我们不得不从一个埋藏的句子中推断出来，这将是无限有价值的）

我确保 Express.js 服务器监听所有 IP

根据你后来的报道：

在http://192.168.191.248:32750/然后请求立即被拒绝。

那么看起来你的快递服务器实际上并没有在所有接口上监听。这就解释了为什么您可以成功将端口转发到 Pod（这会导致流量出现在 Pod 的本地主机上）但不能从 Pod“外部”到达它

您还可以通过使用集群内的另一个 Pod 到curl端口 3000 上的 Pod IP 来测试该理论（为了避开服务和 NodePort 部分）

Pod您错误配置和关系的可能性很小Service，但由于您没有发布您的PodSpec，并且您所描述的行为听起来更像是一种明确的错误配置，我们将继续这样做，直到我们有相反的证据

于 2019-11-05T04:31:45.410 回答