0

Dans mon cluster gce kube, j'utilise nginx ingress controller au lieu de google load balancer, en utilisant "nginx-ingress" avec NodePort au lieu de LoadBalance comme ci-dessous :gce nginix-ingress type NodePort et port: 80 connexion refusée

helm install --name my-lb stable/nginx-ingress --set controller.service.type=NodePort 

Depuis nginx contrôleur déployé comme "conroller.service.type = NodePort", les nodePorts ont été ouverts/affectés (kubect obtenir svc), a également obtenu 104.196.xxx.xxx IP externe. À ce stade, nginx-ingress-controller s'exécute dans le cluster kube et confirme dans la console "networking/load balancing" qu'aucun équilibreur de charge cloud n'a été créé.

kubectl get svc 
NAME         CLUSTER-IP  EXTERNAL-IP PORT(S)      AGE 
my-lb-nginx-ingress-controller  10.39.249.242 <nodes>  80:31181/TCP,443:31462/TCP 15h 
my-lb-nginx-ingress-default-backend 10.39.246.94 <none>  80/TCP      15h 

Après cela, a créé une nouvelle règle de pare-feu dans la console "réseau/pare-feu" pour permettre les ports de noeud "tcp: 31181; tcp: 31462". Maintenant, en utilisant le navigateur/curl pour atteindre "http://104.196.xxx.xxx:31181" ou "https://104.196.xxx.xxx:31462" obtient une réponse des contrôleurs ngnix..fait bien. Mais, l'accès au port via le port 80 ne fonctionne pas. Quand je ne recroqueville sur "http://104.196.xxx.xxx:80", reprendre la connexion refusée comme ci-dessous:

* connect to 104.196.xxx.xxx port 80 failed: Connection refused 

Remarque, règles de pare-feu ont "default-allow-http" pour "tcp: 80" ngnix-infiltration version = nginx- entrée-0.8.5 Kube-server-version = Major: "1", mineure: "7", GitVersion: "v1.7.5"

helm ls 
NAME  REVISION UPDATED      STATUS  CHART    NAMESPACE 
my-lb  1   Fri Sep 22 23:05:30 2017 DEPLOYED nginx-ingress-0.8.5 default 


kubectl version 
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} 
Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.5", GitCommit:"17d7182a7ccbb167074be7a87f0a68bd00d58d97", GitTreeState:"clean", BuildDate:"2017-08-31T08:56:23Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} 

Toute idée pourquoi "https://104.196.xxx.xxx:80" obtient « port 80: Connexion refusé "tandis que" https://104.196.xxx.xxx:31462 "fonctionne bien?

Thx.

Répondre

0

Lorsque vous utilisez un NodePort, comme il est très clairement décrit dans le NodePort documentation, il traduit le numéro de port Service à un port aléatoire (+/-) dans le haut de gamme 30 000 qui que Service utilisera sur le nœud lui-même.

penser en que si Servicealpha veut écouter sur le port 80, et Servicebeta veut écouter sur le port 80, sans que le mécanisme de traduction alpha et beta ne pourrait pas exister dans le cluster en même temps. Ces deux ports (31181 pour 80, 31462 pour 443) sont affectés au Service - rien d'autre dans le cluster n'écoutera sur ces ports tant que Service est déclaré.