問題タブ [istio]

hostnetworkポッドが開始され80、443ポートが見つからなかった後、展開の構成オプションが有効になりません

現在、mesos/marathon クラスター内のアプリケーションが、mesos/marathon クラスターに存在する場合と存在しない場合があるサービスにアクセスしたいという設定があります。クラスターへの外部トラフィックのイングレスは、Traefik インスタンスのクラスターの前にある Amazon ELB を介して行われます。次に、適切なコンテナー インスタンスのセットを選択し、受信 HTTP ホスト ヘッダーを介して負荷分散します。 - 特定のコンテナー インスタンスに対する構成済みホスト ヘッダーの 1 つの関連付け。内部から内部へのトラフィックも、実際にはこの同じルートによって処理されます。これは、特定のサービスに関連付けられている DNS レコードが、メソ/マラソン クラスターの内部と外部の両方で同じ ELB にマップされているためです。また、同じコンテナ セットを指す複数の DNS レコードを持つ機能も提供します。

このセットアップは機能しますが、コンテナまたは別のコンポーネント内のアプリケーションが、呼び出したいサービスがそれらが含まれていた特定の mesos/marathon クラスターを呼び出し、一連のコンテナーの前にあるクラスターの内部にある何か、または特定のコンテナー自体に直接、適切な呼び出しを行います。

私が Kubernetes について理解していることから、Kubernetes はサービスの概念を提供します。これは基本的に、サービスが一致するポッドの構成に基づいて一連のポッドのフロントとして機能できます。ただし、ネットワーク トラフィックをサービス IP に転送することを Kubernetes クラスター内のアプリケーションに透過的に認識させるメカニズムについては、完全にはわかりません。Envoy プロキシ トラフィックをサービス名などに使用することで、この問題の一部を解決できると思います<application-name>.<cluster-name>.company.comが、以前の DNS エントリ (たとえば ) にマップする CNAME がある場合、<application-name>.company.comどのようにクラスタの終了を回避できます。

両方のケースを解決する良い方法はありますか? アプリケーションのロジックが、特定のクラスター内にあることを理解しなければならず、ルーティングを適切に実行するためにアプリケーションの外部のコンポーネントを優先することを回避しようとしています。

特定のコンポーネントを根本的に誤解している場合は、訂正していただければ幸いです。

Kubernetes 1.7.9 で初めて Istio をインストールします。自動サイドカーインジェクションでインストール。サンプル アプリケーションを試すと、サイド カーとアプリケーション コンテナーが開始され、「実行中」の状態になっていますが、proxy_init は PodInitializing でスタックし、Pod の全体的な状態は Init:0/1 です。

初期化子が有効になっています:

istio-Proxy ログから、

しかし、proxy_init は待機状態でスタックしています。