Kubernetes nginx入口- Azure上的控制器不可及

Question

我对Azure，Kubernetes，甚至Docker本身都很陌生，我还在玩这个系统来学习和评估以后可能的部署。到目前为止，我已经对我的服务进行了对接，并成功地部署了它们，并使用类型为: LoadBalancer的服务使web前端公开可见。

现在，我想添加TLS终止，并了解到，为此，我应该配置一个入口控制器，其中最常见的一个是nginx入口控制器。

严格地修改示例，然后尝试阅读文档，我找到了一个看起来很有趣但不起作用的设置。也许某个善良的灵魂可以指出我的错误，或者给我指点如何调试它，以及在哪里读到更多关于它的内容。

我申请了以下文件：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend-deployment
  namespace: kube-system
spec:
  template:
    metadata:
      labels:
        app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: default-http-backend
          image: gcr.io/google_containers/defaultbackend:1.0
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend-service
  namespace: kube-system
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80  
  selector:
    app: default-http-backend
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller-conf
  namespace: kube-system
data:
  # enable-vts-status: 'true'
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller-deployment
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx-ingress-controller
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.13
          name: nginx-ingress-controller
          ports:
            - containerPort: 80
              hostPort: 80
            - containerPort: 443
              hostPort: 443
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-ingress-controller-conf
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-controller-service
  namespace: kube-system
spec:
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: 443
    - name: http
      port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx-ingress-controller
  sessionAffinity: None
  type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ingress
  namespace: kube-system
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: 
      http:
        paths:
          - path: /
            backend:
              serviceName: default-http-backend-service
              servicePort: 80

这给了我两个豆荚：

c:\Projects\Release-Management\Azure>kubectl get pods --all-namespaces

NAMESPACE     NAME                                                   READY     STATUS    RESTARTS   AGE
<some lines removed>
kube-system   default-http-backend-deployment-3108185104-68xnk       1/1       Running   0          39m
<some lines removed>
kube-system   nginx-ingress-controller-deployment-4106313651-v7p03   1/1       Running   0          24s

还有两项新服务。请注意，我还使用类型: LoadBalancer配置了默认的-http-后端服务，这仅用于调试。我已经包括了我的网络前端，它被称为webcms：

c:\Projects\Release-Management\Azure>kubectl get services --all-namespaces

NAMESPACE     NAME                               CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
<some lines removed>
default       webcms                             10.0.105.59    13.94.250.173   80:31400/TCP                 23h
<some lines removed>
kube-system   default-http-backend-service       10.0.106.233   13.80.68.38     80:31639/TCP                 41m
kube-system   nginx-ingress-controller-service   10.0.33.80     13.95.30.39     443:31444/TCP,80:31452/TCP   37m

最后一个入口：

c:\Projects\Release-Management\Azure>kubectl get ingress --all-namespaces

NAMESPACE     NAME            HOSTS     ADDRESS      PORTS     AGE
kube-system   nginx-ingress   *         10.240.0.5   80        39m

没有我能立即察觉到的错误。然后我去了Azure仪表盘，看了看负载平衡器和它的规则，在我的(严重未经训练的)眼里，这看起来很好。我没有碰这些，负载平衡器和规则是由系统创建的。这里有一个截图：

https://qvwx.de/tmp/azure-loadbalancer.png

但不幸的是，它不起作用。我可以卷起我的网页-服务：

c:\Projects\Release-Management\Azure>curl -v http://13.94.250.173
* Rebuilt URL to: http://13.94.250.173/
*   Trying 13.94.250.173...
* TCP_NODELAY set
* Connected to 13.94.250.173 (13.94.250.173) port 80 (#0)
<more lines removed, success>

但是，无论是默认的-http-后端还是入口工作：

c:\Projects\Release-Management\Azure>curl -v http://13.80.68.38
* Rebuilt URL to: http://13.80.68.38/
*   Trying 13.80.68.38...
* TCP_NODELAY set
* connect to 13.80.68.38 port 80 failed: Timed out
* Failed to connect to 13.80.68.38 port 80: Timed out
* Closing connection 0
curl: (7) Failed to connect to 13.80.68.38 port 80: Timed out

(入口与不同的IP相同)

如果你读了这么多:谢谢你抽出时间，我希望你能给我一些提示。

玛丽安

Answer 1

这是一件很小的事情，但它可以为您节省一些$$$：default-http-backend不是设计为面向外部的，因此不应该有type: LoadBalancer --它是仅仅设计为404，这样，入侵控制器就可以普遍地为无Pod服务的/dev/null流量。

稍微在琐碎的阶梯上移动，并且非常清晰:我不认为你有错，但我确实想给你提供一些东西来决定你是否想要改变。通常，Pod容器的合同是给端口指定一个理想的自然语言名称("http“、"https”、"prometheus“等)，然后映射到底层映像的端口。然后，将服务中的targetPort:设置为该名称，而不是使容器能够在不违反Service合同的情况下移动港口号的号码。在这个问题上，nginx入口部署的容器:港口：同意我的观点。

现在，让我们进入可能对您的系统有所贡献的部分，而不是您所希望的行为。

我现在无法证明这一点，但集装箱:主机端口：的存在在没有hostNetwork:真的情况下很可疑。我真的很惊讶kubectl没有抱怨，因为这些配置组合有点奇怪。

我想故障排除的步骤是进入Node (也就是说，集群中的某个东西不是Pod --如果您愿意的话，您也可以在与Node相同的子网中使用一个单独的VM )，然后卷曲到运行nginx-ingress-controller Pod的Node的31452端口。

kubectl get nodes将列出所有可用的Node，以及

如果您还不知道，kubectl get -o json pod nginx-ingress-controller-deployment-4106313651-v7p03 | jq -r '.items[0].status.hostIP'应该生成特定VM的IP地址。呃，我刚刚从您的提示符中意识到您可能没有jq --但是我还不太了解PowerShell，不知道它的JSON查询语法。

然后，从任意的Node：curl -v http://${that_host_IP_value}:31452中看到什么会成为现实。它可能是什么东西，也可能是同样的“什么？”LoadBalancer给你的。

具体而言，默认的http-后端不应该有一个宏资源-我不知道它是否有任何伤害，因为我从来没有尝试过，但我打赌1美元也无助于你的处境。

由于您已经有了一个使用Service的default:webcms，所以我建议在default命名空间中创建一个几乎完全正确的当前default:webcms资源，但它指向的是webcms而不是default-http-backend。这样，您的大会控制器实际上将有一些目标，这不是默认的后端。

如果您还没有看到它，unbelievably将导致Pod发出其nginx配置更改的实际差异，这有助于跟踪配置错误。

我很抱歉，你不得不做与Azure，侵入控制器，和粗糙的边缘文件，您的第一次接触库伯内特斯。当你把所有的东西都正确地设置好的时候，它真的很神奇，但是它是一个相当复杂的机器，当然。