Kubernetes ノード上のコマンドはシェルのプロキシを使用できますが、そのノード上の Pod にはプロキシ環境がありません。コンテナの環境は、そのイメージと Pod の構成によって決まります。

これらの変数をサポートするアプリケーションでは、既存のコンテナエントリに env リストを追加します。

env:
  - name: HTTP_PROXY
    value: http://proxy.example:8080
  - name: HTTPS_PROXY
    value: http://proxy.example:8080
  - name: NO_PROXY
    value: localhost,127.0.0.1,kubernetes.default.svc,.svc,.cluster.local

Deployment では、これは spec.template.spec.containers 内の該当するコンテナの下に置きます。新しい Pod が受け取るように、通常のロールアウトを通じてワークロードを更新します。実際のクライアントが要求する場合は、小文字の名前も指定します。

バイパスリストは出発点の例であり、クラスタのすべてのルートの一覧ではありません。クラスタの実際の DNS サフィックスと内部の宛先を使用してください。サービス IP を使用するアプリケーションでは、クライアントが対応する構文で実際のサービス範囲が必要になる場合があります。

init コンテナには独自のコンテナ仕様があります。外部ダウンロードを行う場合は、そこに目的の構成を追加します。公開 HTTP ダウンロードでは、HTTP プロキシリストのエンドポイントが、これらのコンテナ環境値の候補になります。

イメージの取得はアプリケーションが実行される前に行われ、ノードのコンテナランタイムによって実行されます。Pod の env では、その以前のレジストリ接続を構成できません。

最後に、HTTP プロキシ変数はそれを使用するクライアントにのみ影響します。Pod からの任意のデータベース、UDP、その他のソケットトラフィックをリダイレクトするものではありません。

関連記事