0

私のgce kube-clusterでは、LoadBalanceの代わりにNodePortで「nginx-ingress」を使用して、Google Load Balancerの代わりにnginx ingress controllerを使用しています:gce nginix-ingressタイプNodePortとポート:80接続が拒否されました

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

"conroller.service.type = NodePort" として展開nginxのコントローラは、nodePortsが開かれたので/割り当て(SVCを取得kubect)、また外部IP 104.196.xxx.xxxを得ました。 この時点で、nginx-ingress-controllerはkube-clusterで実行されており、クラウドロードバランサが作成されていないコンソール "ネットワーク/負荷分散"で確認されています。 ":;:31462 TCP 31181 TCP"

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 

は、この後、 "ネットワーク/ファイアウォールは、" ノードのポートを許可するコンソールで新しいファイアウォールルールを作成しました。 ブラウザ/カールを使用して " http://104.196.xxx.xxx:31181"または " https://104.196.xxx.xxx:31462"に到達すると、ngnixコントローラからの応答が得られます。

しかし、ポート80経由のポートアクセスは機能しません。私は "http://104.196.xxx.xxx:80" にカールないとき、取り戻すの接続は以下のように断った: ファイアウォールルールを持って、

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

ノート "デフォルト - 許可 - のhttp" の "TCP:80" ngnix-進入バージョン= nginx-進入-0.8.5 KUBE-サーバー・バージョン=主要: "1"、マイナー: "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"} 

"https://104.196.xxx.xxx:80は"「ポート80を取得し、なぜすべてのアイデア:接続「https://104.196.xxx.xxx:31462」は問題なく動作していますか?

Thx。

答えて

0

NodePortを使用する場合、非常に明確NodePort documentationに記載されているように、それはService、ノード自体に使用すること高い3万範囲内のランダム(+/-)ポートにServiceポート番号を変換します。

Servicealphaがポート80でリッスンしたい場合、その中にそれを考えると、Servicebetaが同時にクラスタ内に存在することができなかった翻訳メカニズムalphabetaせずに、ポート80でリッスンしたいと考えています。クラスタ内の他のポートは、Serviceが宣言されている限り、これらのポートでリッスンしません。この2つのポート(31181は80、31462は443)はServiceに割り当てられます。

関連する問題