Kubernetes Azure上无法访问Kubernetes nginx入口控制器

Question

我对Azure，Kubernetes，甚至是Docker本身都很陌生，并且在系统中学习和评估以后可能的部署。到目前为止，我已经对我的服务进行了docker化，并成功部署了它们，并使用类型为LoadBalancer的服务将Web前端公开为可见。

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

严格歪理邪说的例子，然后试图阅读文档我已经到达了一个看起来很有趣但不起作用的设置。也许某种灵魂可以指出我的错误，或者给我指出如何调试以及在哪里阅读更多信息。

我kubectl apply'd以下文件：

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配置了default-http-backend-service，这仅用于调试。我已经包括了我的网络的前端被称为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

不过遗憾的是它不工作。我可以卷曲我webcms服务：

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 - 它是merely designed to 404所以入口控制器可以通用地为/dev/null无通道服务通信。

---

稍微移动了琐碎的阶梯，并为超级清晰：我不认为你有什么是错但我想给你提供的东西来决定，如果你想改变。通常，Pod容器的合同是为映射到底层映像端口的端口（“http”，“https”，“prometheus”，无论）提供一个理想的自然语言名称。然后，将服务中的targetPort:设置为该名称而不是号码，它使容器能够移动端口号而不中断服务到Pod合同。 The nginx-ingress Deployment's container:ports:对此表示赞同。

---

现在，让我们进入可能对系统作出贡献的部分，而不是按照您的意愿行事。

我现在还不能证明它，但containers:hostPort:的存在是可疑的，没有hostNetwork: true。我真的很惊讶kubectl没有发牢骚，因为这些配置组合有点奇怪。

我想故障排除的步骤是获得Node（也就是说，群集内不是Pod的东西 - 你可以在与你的Node相同的子网中使用独立的虚拟机您希望），然后卷曲到运行nginx-ingress-controller Pod的Node的端口31452。

kubectl get nodes将列出所有可用的Node s和

kubectl get -o json pod nginx-ingress-controller-deployment-4106313651-v7p03 | jq -r '.items[0].status.hostIP'应该产生特定虚拟机的IP地址，如果你不已经知道了。 Err，我刚刚从提示中意识到，您可能没有jq - 但我不知道PowerShell足够了解它的JSON查询语法。

然后，从任何Node：curl -v http://${that_host_IP_value}:31452，看看有什么物化。它可能是某种东西，也可能是相同的“wha ?!” LoadBalancer正在给你。

---

至于入口资源具体地说，再次默认-HTTP-后端是不是应该有一个入口资源 - 我不知道这是否会伤害任何东西，因为我从来没有尝试过，但我d也打赌$ 1它不是帮助您的情况，要么。

既然你已经有一个已知的与default:webcms工作Service，我会建议建立在default命名空间的入口资源与非常当前的入口资源是什么，但在webcms而不是default-http-backend指出。这样，您的Ingress控制器实际上会有一些目标，而不是默认的后端。

如果你还没有已经看过了，adding --v=2将导致吊舱发射其nginx的配置变化的实际差异，这可能是在跟踪配置误解难以置信有用

---

我m非常抱歉，您必须与Azure，Ingress控制器以及与Kubernetes第一次联系时的粗略文档进行交锋。当你把所有的事情设置正确的时候真的很棒，但它确实是一个非常复杂的机器。