Kubernetes nginx ingress-controller sur Azure inaccessible

Question

Je suis très nouveau sur Azure, Kubernetes, et même Docker lui-même, et je joue avec le système pour apprendre et évaluer un éventuel déploiement ultérieur. J'ai jusqu'ici dockerized mes services et les déployées avec succès et ai rendu l'interface Web publiquement visible en utilisant un service avec le type: LoadBalancer.

Maintenant, je voudrais ajouter la terminaison TLS et j'ai appris que pour cela je suis supposé configurer un contrôleur d'entrée dont le plus couramment mentionné est nginx-ingress-controller.

Strictement monkeying des exemples, puis après avoir essayé de lire sur les documents, je suis arrivé à une configuration qui semble intéressante mais ne fonctionne pas. Peut-être qu'une âme aimable peut signaler mes erreurs et/ou me donner des indications sur la façon de déboguer cela et où en lire plus à ce sujet.

Je kubectl apply'd le fichier suivant:

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 

Cela m'a donné deux gousses:

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 

aussi deux nouveaux services. Notez que j'ai également configuré le service default-http-backend avec le type: LoadBalancer, ceci est uniquement pour le débogage. J'ai inclus mon web-frontend qui est appelé 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 

Et enfin une entrée:

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 

Aucune erreur que je peux détecter immédiatement. Je suis ensuite allé à Azure Dashboard et j'ai regardé le loadbalancer et ses règles et ça a l'air bien pour mon oeil (sérieusement non formé). Je n'ai pas touché à ceux-ci, le loadbalancer et les règles ont été créés par le système. Il y a ici une capture d'écran:

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

Mais malheureusement, il ne fonctionne pas. Je peux courber mon WebCMS service:

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> 

Mais ni default-http-back-end, ni le travail d'entrée:

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 

(entrée donne la même chose avec une adresse IP différente)

Si vous lis jusqu'ici: Merci pour votre temps et j'apprécierais n'importe quels conseils.

Marian

Answer 1

genre d'une chose banale, mais ça va vous faire économiser $$$: le default-http-backend n'a pas été conçu pour faire face à l'extérieur, et donc ne devrait pas avoir type: LoadBalancer - il est merely designed to 404 de sorte que le Ingress contrôleur peut universellement /dev/null trafic pour les services sans pod.

---

Déplacement légèrement l'échelle de trivialité, et pour plus de clarté extrême: Je ne pense pas que ce que vous avez est mal mais je ne voulais vous offrir quelque chose à décider si vous voulez changer. Typiquement, le contrat pour un conteneur Pod est de donner un nom idéalement en langage naturel au port ("http", "https", "Prometheus", quel que soit) qui mappe dans le port de l'image sous-jacente.Et puis, définissez targetPort: dans le service à nom et non le numéro qui offre au conteneur la possibilité de déplacer le numéro de port sans rompre le contrat Service-to-Pod. The nginx-ingress Deployment's container:ports: est d'accord avec moi sur celui-ci.

---

Maintenant, passons aux parties qui peuvent contribuer à ce que votre système ne se comporte pas comme vous le souhaitez. Je ne peux pas le prouver pour le moment, mais la présence de containers:hostPort: est suspect sans hostNetwork: true. Je suis vraiment surpris kubectl n'a pas pleurnicher, parce que ces combinaisons de configuration sont un peu bizarre.

Je suppose que l'étape de dépannage serait d'obtenir sur le Node (c'est quelque chose dans le cluster qui n'est pas un Pod - vous pouvez le faire avec une VM distincte dans le même sous-réseau que votre Node, aussi, si vous souhaitez), puis bouclez sur le port 31452 du Node sur lequel le module nginx-ingress-controller est en cours d'exécution.

kubectl get nodes listera tous les Node disponibles s et

kubectl get -o json pod nginx-ingress-controller-deployment-4106313651-v7p03 | jq -r '.items[0].status.hostIP' devrait produire l'adresse IP de la machine virtuelle spécifique, si vous ne connaissez pas déjà. Err, je viens de réaliser à partir de votre invite que vous n'avez probablement pas jq - mais je ne connais pas suffisamment PowerShell pour connaître sa syntaxe de requête JSON.

Puis, à partir de Node: curl -v http://${that_host_IP_value}:31452 et voir ce qui se matérialise. Cela peut être quelque chose, ou peut-être le même "wha?!" que le LoadBalancer vous donne.

---

En ce qui concerne la ressource Ingress spécifiquement, par défaut-http-backend de nouveau n'est pas censé avoir une ressource Ingress - Je ne sais pas si ça fait mal quoi que ce soit parce que je ne l'ai jamais essayé, mais je d aussi parier $ 1 ce n'est pas aider votre situation, soit.

Puisque vous avez déjà connu travailler Service avec default:webcms, je recommande la création d'une ressource Ingress dans l'espace de noms default avec à peu près exactement ce que votre ressource actuelle est Ingress, mais a souligné à webcms au lieu de default-http-backend. De cette façon, votre contrôleur Ingress aura réellement quelque chose à cibler qui n'est pas le backend par défaut.

Si vous ne l'avez pas déjà vu, adding --v=2 forcera le Pod émette la diff réelle de son changement de configuration nginx, qui peut être incroyablement utile pour traquer les malentendus de configuration

---

Je Je suis tellement désolé que vous ayez à vous battre avec les contrôleurs Azure, Ingress et une documentation approximative pour votre premier contact avec Kubernetes. C'est vraiment incroyable quand tout est réglé correctement, mais c'est une machine assez complexe, c'est sûr.