サービス名を使用してkubernetesクラスタ内のサービスにアクセスする方法。

Question

私はkubernetesにはかなり新しく、Googleコンテナエンジンにクラスタをセットアップしました。 私のクラスタには、dropwizardで開発されたバックエンドapi、ノードjsで開発されたフロントエンド、mysqlデータベースがあります。 すべてがクラスタにデプロイされ、動作しています。ノードコンテナーとバックエンドの外部IPを設定した後でこれを実行すると、リモートでアクセスできますが、フロントエンドからサービス名私のバックエンドはクラスタ内のバックエンド・アピアと呼ばれます。 http://backendapi:8080これを実行して、クラスタにデプロイされたときに休憩サービスを呼び出すことはできません。 私にとってのキャッチは、クラスタにデプロイするときに、フロントエンドが外部IPを使用してバックエンドにヒットしないようにするためです。外部IPアドレスを経由せずにクラスタ内で接続する必要があります。ポッドに接続してbackendapiにpingを実行すると、結果が返されますが、フロントエンドを展開してラベル名を使用すると動作しません。何ができますか？

Answer 1

に住んでいる。しかし、私はこの backendapi.default.svc.cluster.localに変更したときに問題 はそれでも：8080。他の ポートを使って内部的にマップされていて、私のフロントエンドのWebページはbackendapi.default.svc.cluster.localという というメッセージを残しています：32208/api/v1/auth/login net :: ERR_NAME_NOT_RESOLVED。面白いのは、 フロントエンドポッドからカールしたときです。しかし、自分のウェブを使ってアクセスしているときには、ブラウザ が表示されません。

これはクラスタ内でのみ解決できるためです。私は外部IPを公開するので

が、これは次のようになります（KUBE-DNSでのみK8Sクラスタはアドオンのでドメイン名backendapi.default.svc.cluster.localを変換することができ、それへの8080は、対応するIPアドレスです）サービスのためにも 。

いいえ、ドメイン名backendapi.default.svc.cluster.localは、ランダムマシンのランダムブラウザではなく、クラスタ内でのみ解決できるためです。あなたが何をしたか

ソリューション

は、サービスの外部IPを露出し、ソリューションの1つです。 IPを使用しない場合は、入力を作成して（クラスタ内の入力コントローラを使用して）、マイクロサービスを公開することができます。あなたはGCPを利用しているので、潜在的なIPアドレスを公開するのではなく、APIゲートウェイを利用することができます。

注：マイクロサービスがユーザーに公開されると、認証/承認を追加することを忘れないでください。

別ソリューション

プロキシすべてのバックエンドは、あなたが避けることができますあなたのWebアプリ（nginxの/ nodejsなど）

利点このアプローチはあるのを提供していますサーバーを介して呼び出し、すべて同一生成元ポリシー/ CORSの頭痛では、あなたのマイクロサービス（明示的）認証の詳細がユーザーのブラウザから抽出されます。 （これは必ずしも利点ではない）。このアプローチの

欠点は、バックエンドmicroserviceは（あなたがそれを見てどのように応じて、またはその逆）のフロントエンドとの緊密な結合を持つことになり、これは、フロントエンドにバックエンド依存のスケーリングを行います。あなたのバックエンドは公開されていません。だから、別の消費者がいれば（単にアンドロイドアプリと言う）、あなたのサービスにアクセスすることはできません。

ハイブリッドソリューション

プロキシすべてのバックエンドは、あなたのAPIは、あなたのWebアプリケーションのドメインを継承するように、あなたのWebアプリ（nginxの/ nodejsなど）を提供サーバーを介して呼び出します。そして、他の消費者（もしあれば）がそれを利用できるように、（必要に応じて）バックエンドサービスを公開してください。

類似の質問の種類：https://stackoverflow.com/a/47043871/6785908

Answer 2

限りkube-dnsは（私は「あなたはそれを無効にしない限り、常に」であると信じている）が実行されている、すべてのサービスオブジェクトは、クラスタ内のservice_name +"."+ service_namespace + ".svc.cluster.local"の DNS名をを持っているように他のすべてのものはとdefault名前空間にあなたのbackendapiに対処します（あなたのポート番号付きの例を使用する）http://backendapi.default.svc.cluster.local:8080。その事実は、Kubernetesがすべての識別子を "dns compatible"（下線やその他のぎこちない文字ではない）の名前にする理由です。

あなたはKUBE-DNSを実行しているないは、全てのサービス名およびポートはまた、単にだろうドッキングウィンドウのようなポッドの環境に注入されているので、環境変数が${BACKENDAPI_SERVICE_HOST}:${BACKENDAPI_SERVICE_PORT}さえ（サービスの中にクラスタIPが含まれます場合でもenv-varは "host"という名前です）と "default"のサービスポート（あなたの例では8080）があればそれだけです。

DNS名または環境変数ipのどちらを使用するかは、ログ出力やエラーメッセージに「読み取り可能な」名前を付けるかどうか、DNSルックアップをスキップするかどうかスピードは向上しますが、読みやすさのためにサービスIPアドレスを使用してください。彼らは同じ振る舞い同じです。

全体的な話はin the services-networking concept documentation