Kubernetes Nginx Ingress-Controller auf Azure nicht erreichbar

Question

Ich bin sehr neu in Azure, Kubernetes, sogar Docker selbst, und spielt mit dem System zu lernen und für eine mögliche Bereitstellung später zu bewerten. Ich habe meine Dienste bisher dockert und erfolgreich implementiert und das Web-Frontend mit einem Service vom Typ LoadBalancer öffentlich sichtbar gemacht.

Jetzt möchte ich TLS Terminierung hinzufügen und habe gelernt, dass ich dafür eine Ingress-Controller mit dem am häufigsten genannten Nginx-Ingress-Controller konfigurieren soll.

Streng monkey Beispiele und dann nachher versuchen, auf die Dokumente zu lesen Ich bin bei einem Setup angekommen, das interessant aussieht, aber nicht funktioniert. Vielleicht kann eine gute Seele auf meine Fehler hinweisen und/oder mir Hinweise geben, wie man das tut und wo man mehr darüber lesen kann.

Ich habe kubectl apply'd die folgende Datei:

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 

Das gab mir zwei Schoten:

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 

Auch zwei neue Dienste. Beachten Sie, dass ich auch den Standard-http-Backend-Dienst mit dem folgenden Typ konfiguriert habe: LoadBalancer, dies dient nur zum Debuggen. Ich habe meine Web-Frontend enthalten, die WebCMS genannt wird:

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 

Und schließlich ein Eindringen:

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 

Keine Fehler, die ich sofort erkennen kann. Ich ging dann zum Azure Dashboard und schaute auf den Loadbalancer und seine Regeln und das sieht meinem (ernsthaft untrainierten) Auge gut aus. Ich habe diese nicht berührt, der Loadbalancer und die Regeln wurden vom System erstellt. Es gibt einen Screenshot hier:

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

Aber leider funktioniert es nicht.

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> 

Aber weder Standard-http-Backend noch das Eindringen Arbeit:

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 

(Eintritt gibt das gleiche mit einem anderen IP)

Wenn Sie mir meinen WebCMS-Service locken Lesen Sie weiter: Vielen Dank für Ihre Zeit und ich würde mich über Hinweise freuen.

Marian

Answer 1

Art eine triviale Sache, aber es wird Ihnen einige $$$ sparen: die default-http-backend nicht nach außen gerichtete zu sein, entworfen und somit nicht type: LoadBalancer haben sollte - es ist merely designed to 404 so die Ingress Controller kann universell /dev/null Verkehr für Pod-less Services.

---

leicht nach oben der Trivialität Leiter bewegen, und für extreme Klarheit: Ich glaube nicht, was Sie haben, ist falsch aber ich wollte Sie etwas bieten, um zu entscheiden, ob Sie ändern möchten. Normalerweise besteht der Vertrag für den Container eines Pods darin, dem Port einen Namen in idealer natürlicher Sprache zu geben ("http", "https", "prometheus", was auch immer), der in den Port des zugrundeliegenden Bildes mappt.Setzen Sie dann targetPort: im Service auf den Namen und nicht die Nummer, die dem Container die Möglichkeit bietet, die Portnummer zu verschieben, ohne den Service-zu-Pod-Vertrag zu unterbrechen. The nginx-ingress Deployment's container:ports: stimmt mir hier zu.

---

Nun, lassen Sie uns in die Teile, die dazu beitragen, dass Ihr System sich nicht so verhält, wie Sie es wünschen.

Ich kann es jetzt nicht beweisen, aber die Anwesenheit von containers:hostPort: ist verdächtig ohne hostNetwork: true. Ich bin wirklich überrascht kubectl nicht weinen, weil diese Konfiguration Kombinationen ein wenig seltsam sind.

Ich denke, der Fehlerbehebungsschritt wäre, auf die Node (das heißt, etwas innerhalb des Clusters, der kein Pod ist - Sie könnten es mit einer separaten VM innerhalb des gleichen Subnetzes wie Ihre Node auch tun, wenn Sie wünschen) und kräuseln Sie dann zum Hafen 31452 des Node, auf dem der nginx-ingress-controller Pod läuft.

kubectl get nodes werden alle verfügbaren Node s Liste, und

kubectl get -o json pod nginx-ingress-controller-deployment-4106313651-v7p03 | jq -r '.items[0].status.hostIP' sollten die spezifischen VM die IP-Adresse herzustellen, wenn Sie nicht bereits kennen. Err, ich habe gerade festgestellt, dass Sie wahrscheinlich keine jq haben - aber ich kenne PowerShell nicht gut genug, um seine JSON-Abfragesyntax zu kennen.

Dann von jedem Node: curl -v http://${that_host_IP_value}:31452 und sehen, was sich materialisiert. Es kann etwas sein, oder es kann das gleiche "Was ?!" das der LoadBalancer Ihnen gibt.

---

Was die Ingress Ressource speziell, wieder Standard-http-Backend sollte keine Ingress Ressource haben - ich weiß nicht, ob es etwas weh tut, weil ich es nie versucht habe, aber ich d wetten auch $ 1, es ist nicht helfen Ihre Situation, entweder.

Da Sie bereits bekannt haben Arbeits Service mit default:webcms, würde ich empfehlen, eine Ingress-Ressource in der default Namespace mit so ziemlich zu schaffen genau das, was Ihre aktuelle Ingress Ressource, sondern zeigte auf webcms statt default-http-backend. Auf diese Weise hat Ihr Ingress-Controller tatsächlich etwas zum Ziel, das nicht das Standard-Backend ist.

Wenn Sie nicht schon gesehen, adding --v=2 wird der Pod bewirken, dass die tatsächlichen diff seiner nginx Konfigurationsänderung emittieren, die unglaublich hilfreich beim Aufspüren von Konfigurations Missverständnisse können

---

I‘ Es tut mir so leid, dass du mit Azure, Ingress-Controllern und der Dokumentation für deinen ersten Kontakt mit Kubernetes kämpfen musst. Es ist wirklich erstaunlich, wenn man alle Dinge richtig aufgebaut hat, aber es ist sicherlich ein ziemlich kompliziertes Maschinenstück.