K8s でよく使われる IP アドレスの種類をいくつ知っていますか?

みなさんこんにちは。私は次男です。

なぜこの号でこのトピックについて書くのでしょうか? K8s には非常に多くの IP タイプがあるため、使用時に混乱するかもしれません。今回は、(仮想の) 例を使用して、K8s を使用するときにどのような種類の IP アドレスが関係するかを確認します。

1. 例の紹介

この例に関係する主なモジュールは、クライアント、L4 ロードバランサ、Nginx-Ingress、k8s 環境、外部サービス (https://api.bank.com) です。

クライアントがアクセスしたいサービスは https://api.2ge.com/pathA です。 K8s 内では、front-end.lance.svc.cluster.local と bill.lance.svc.cluster.local の 2 つのサービスが順番にこの要求を処理します。前者の役割はその名前からわかるとおりで、後者は請求関連の処理に使用されます。もちろん、お金に関しては常に銀行とやり取りする必要があるため、サービス請求書では、さらなる処理のために外部銀行が提供するサービス https://api.bank.com も呼び出されます。次の図は、上記のモジュールの構成と呼び出しチェーン全体を示しています。負荷分散が機能する OSI ネットワーク モデルのレベルに応じて、戻りパスは元のノードを通過するか、元のノードをバイパスして三角形の伝送モードを形成するため、この図では戻りパスは描かれていません。

2. L4 LB IP

①当然、クライアントはまずDNS経由でFQDN api.2ge.comのIPアドレスを取得します。クライアントが知らないのは、このアドレスが L4 ロード バランサ (LB) にバインドされていることです。ここでの IP アドレスはパブリック IP です。クラウド サービスを使用している場合、その LB を使用すると固定パブリック IP を取得するのは非常に簡単になります。ここでの LB は L3/L4 で動作します。いわゆる 4 層負荷分散では、主にパケットの 4 層情報 (src/dst ip、src/dst port、proto) と負荷分散デバイスによって設定されたサーバー選択方法を使用して、最終的な内部サーバーを決定します。 IP+ポートに基づく負荷分散方式です。ここで言及されているサーバー選択方法は、実際にはラウンドロビン、ランダム、応答時間などの戦略です。簡単に言うと、負荷分散の 2 つの主要な役割は、「ユーザー要求を処理するサーバーを選択すること」と「ユーザー要求を転送すること」です。 LB がリクエストを背後のサービスに転送することを決定した場合、まずネットワーク パケットの送信元 IP アドレスと宛先 IP アドレスを変更する必要があります。つまり、送信元アドレスを自身の IP に変更し、宛先 IP アドレスを図の Nginx-Ingress が所有するプライベート IP に変更します。

3. 入力IP

② リクエストパスに沿って、Ingressに注目します。ここではNginx-Ingressを使用します。 192.168.5.20/16 などのプライベート IP アドレスを割り当てます。つまり、ここでの Ingress は L4 LB の背後でのみ機能します。

パブリック IP を介して Ingress をインターネットに直接公開してみませんか?答えはもちろんイエスです。 L4 LB は単にパケットを転送するだけであり、このプロセスではアップストリームとダウンストリームとの接続を確立する必要はありません。 Nginx と比較すると、負荷耐性が強く、パフォーマンスが高く (F5 または A10 のハードウェア パフォーマンスに比較的近い)、メモリと CPU リソースの消費が比較的少ないという特徴があります。ここから、マルチレベル ハイブリッド ロード バランシングを使用する場合、OSI ネットワーク モデルの下位層で動作するロード バランシングは通常は前面に配置され、上位層で動作するロード バランシングは背面に配置されることにも気づくでしょう。 Ingress は L7 で動作するため、アプリケーション層プロトコルをよりよく理解します。たとえば、HTTP リクエスト内のパスを理解し、そのパスに基づいてさらにルーティングを実行できます。

4. サービスIP

③ Ingress は HTTP をよりよく理解するため、クライアントのリクエスト パスが /pathA であることを認識すると、リクエストを内部サービス front-end.lance.svc.cluster.local にリダイレクトする必要があることを認識します。

ステップ ③ ここで TCP 接続が確立されるため、Ingress とサービス間の 3 ウェイ ハンドシェイク、データ通信、4 ウェイ ハンドシェイクがすべて必要になります。ステップ①とステップ②の間の純粋な IP 転送と比較すると、これらの追加ステップは明らかにはるかに面倒です。しかし、この世に絶対的なメリットやデメリットは存在しません。 ③がアクセスによって要求されたパスを知ると、通信内容をよりよく理解できるようになり、当然発言力も高まり、よりスマートで複雑なトラフィック監視ができるようになります。たとえば、アクセストラフィック、レイテンシ、エラー率などをカウントするための粒度として REST API を使用できます。ステップ 3 は、HTTP プロキシまたは HTTPS プロキシに基づくことができます。私の次兄が「手元にあるトンネルについてどれだけ知っていますか」という記事で HTTPS プロキシについて詳しく説明していますので、ぜひお読みください。 K8s サービスを作成するときは、サービス タイプを選択する必要があります。実際、現在選択できるのは、NodePort、ClusterIP、LoadBalancer、ExternalName です。選択内容によって IP タイプが異なります。

（１）ノードポート

NodePort タイプを選択すると、ノード上で開かれたポートを使用してノード独自の IP アドレスを使用してサービスにアクセスできることになります。次の図は、クライアントが Node1 の IP アドレス (ポートは表示されていません) にリクエストを開始するプロセスを示していますが、サービスは最終的に Node2 の Pod B によって提供されます。図では、kube-proxy は完全な NAT を使用してこのようなトラフィック制御を実装しています。リクエストの発信元が K8s クラスター境界外にあるため、クライアント IP がノード 1 の IP に変更されない場合、Pod B から返されたデータはクライアントに直接送信されます。クライアントは、このデータを受信した後、Pod B の IP に直接リクエストを送信したことがないため、ためらうことなくデータを破棄します。

（２）クラスターIP

ClusterIP タイプを選択すると、作成するサービス IP は K8s クラスター内でのみ機能することになるため、Cluster IP という名前が付けられます。次の図は、kube-proxy が DNAT を使用してこのタイプのトラフィック制御を実装する方法を示しています。ここでは、DNAT とリバース DNAT の両方が同じノード上で実行され、リクエストを開始したポッドも実行されていることがわかります。つまり、ClusterIP は K8s 境界外で直接サービスを提供することはできません。対照的に、前の図では、クライアントは K8s 境界の外側にあります。

（３）ロードバランサー

LoadBalancer タイプを選択すると、このサービスをロード バランサーとして使用することを意味します。パブリック クラウドによって提供される K8s サービスを使用している場合、LoadBalancer タイプのサービスを表示すると、EXTERNAL-IP フィールドがなくなることがわかります。この時点で、クラウド プロバイダーは LoadBalancer サービスにパブリック IP アドレスを割り当てます。なぜ私がそれを知っているのかは聞かないでください。しかし、価格が安くないことは確かです。有料の商品は、人々に深い印象を残しやすいものです。

 lance@2ge : ~ $ kubectl get svc - n lancehbzhang
名前 タイプ クラスタ- IP 外部- IP ポート( S )年齢
prom -サービス NodePort 10.110 .115 .27 <なし> 8080 : 30000 / TCP 14 d
 lance@2ge : ~ $ kubectl get svc - n lancehbzhang
名前 タイプ クラスタ- IP 外部- IP ポート( S )年齢
フロントサービス LoadBalancer 10.110 .115 .27 220.181 .38 .148 8080 : 30000 / TCP 14d

次の図は、kube-proxy が DNAT を使用して LoadBalancer サービス タイプでトラフィック制御を実装する方法を示しています。

• まず、LoadBalancer は K8s クラスターの境界外でサービスを提供できることがわかります。
• LoadBalancer の実装は NodePort サービスに依存します。
• プロセス全体では DNAT と完全な NAT の両方が使用されます。

(4) 外部名

優雅にスキップしてください。

5. ポッドIP

そのまま進んでいき、ステップ④に進みます。これは私たち全員がよく知っている分野です。ポッドごとに 1 つの IP。ネットワーク ポリシーの介入なしに、K8s クラスター内のすべてのポッドが相互接続され、L2 にある大きなフラット レイヤーが形成されます。

Pod が必要な作業を完了したら、作業の一部をサービス bill.lance.svc.cluster.local に引き渡す必要があります。明らかに、ここでは DNS が関与する必要があります。しかし、待ってください。ステップ 3 では DNS が必要ですか?いいえ。Ingress には、背後にある Pod アドレスを知るための手がかりとしてサービスを使用する他の方法があります。ステップ ⑤ では、Pod は請求サービスの Cluster-IP を学習しますが、これで十分です。ステップ⑥はリクエストを開始するプロセスを示しています。記事の冒頭で、請求書サービスが業務を完了するには、依然として外部の銀行のサービスの支援が必要であると述べたことを覚えていますか?手順⑦と⑧はこのプロセスを示しています。記事「Pod から Baidu にアクセスするときに VTEP が使用されますか?」 Pod が Baidu へのリクエストを開始するプロセスについて詳しく説明します。おそらく、ステップ ⑧ に含まれるプロセスは理解できるでしょう。

6. プレビュー

上記のさまざまな種類の IP を割り当てる責任者は誰ですか? IP 範囲を決定するのは誰ですか?次回の記事もお楽しみに。