Kubernetesのプロキシー

このページではKubernetesと併用されるプロキシーについて説明します。

プロキシー

Kubernetesを使用する際に、いくつかのプロキシーを使用する場面があります。

  1. kubectlのプロキシー:

    • ユーザーのデスクトップ上かPod内で稼働します
    • ローカルホストのアドレスからKubernetes apiserverへのプロキシーを行います
    • クライアントからプロキシー間ではHTTPを使用します
    • プロキシーからapiserverへはHTTPSを使用します
    • apiserverの場所を示します
    • 認証用のヘッダーを追加します
  2. apiserverのプロキシー:

    • apiserver内で動作する踏み台となります
    • これがなければ到達不可能であるクラスターIPへ、クラスターの外部からのユーザーを接続します
    • apiserverのプロセス内で稼働します
    • クライアントからプロキシー間ではHTTPSを使用します(apiserverの設定により、HTTPを使用します)
    • プロキシーからターゲット間では利用可能な情報を使用して、プロキシーによって選択されたHTTPかHTTPSのいずれかを使用します
    • Node、Pod、Serviceへ到達するのに使えます
    • Serviceへ到達するときは負荷分散を行います
  3. kube proxy:

    • 各ノード上で稼働します
    • UDP、TCP、SCTPをプロキシーします
    • HTTPを解釈しません
    • 負荷分散機能を提供します
    • Serviceへ到達させるためのみに使用されます
  4. apiserverの前段にあるプロキシー/ロードバランサー:

    • 実際に存在するかどうかと実装はクラスターごとに異なります(例: nginx)
    • 全てのクライアントと、1つ以上のapiserverの間に位置します
    • 複数のapiserverがあるときロードバランサーとして稼働します
  5. 外部サービス上で稼働するクラウドロードバランサー:

    • いくつかのクラウドプロバイダーによって提供されます(例: AWS ELB、Google Cloud Load Balancer)
    • LoadBalancerというtypeのKubernetes Serviceが作成されたときに自動で作成されます
    • たいていのクラウドロードバランサーはUDP/TCPのみサポートしています
    • SCTPのサポートはクラウドプロバイダーのロードバランサーの実装によって異なります
    • ロードバランサーの実装はクラウドプロバイダーによって異なります

Kubernetesユーザーのほとんどは、最初の2つのタイプ以外に心配する必要はありません。クラスター管理者はそれ以外のタイプのロードバランサーを正しくセットアップすることを保証します。

リダイレクトの要求

プロキシーはリダイレクトの機能を置き換えました。リダイレクトの使用は非推奨となります。