はじめまして。VMware の伊藤です。Tanzu 製品のプラットフォームアーキテクトとして働いており、開発と運用双方の経験があります。この記事では HTTP プロキシがある環境で TKG 1.3.0 をインストールする手順を紹介します。
HTTP プロキシが存在する環境ではインターネットへのアクセスはプロキシ経由で実施されます。TKG のインストールはインターネット上からコンテナイメージを取得したりしますので、HTTP プロキシが存在する環境では HTTP プロキシの設定が必要です。この記事ではおおまかに以下の2つの設定を扱います。
- bootstrap マシン（tanzu コマンドのインストールホスト）に HTTP プロキシの設定を実施
- マネージメントクラスタの構築UIでHTTPプロキシの設定を実施
ご注意頂きたいのは後者は製品の機能でサポートされるものの、前者は現時点ではサポートされない非公式の手段となることです（将来的に正式サポートの計画はあります）。TKG 1.3.0 リリース時における HTTP プロキシ環境下での公式なデプロイ手法は「bootstrap マシンは HTTP プロキシがない直接インターネットに出れる環境に存在すること」を前提としています。
なお、この記事の内容は「インターネットに直接出れる環境で TKG 1.3.0 をインストールする方法」を知っていることを前提に記載します。通常の環境でのインストール方法は以下の記事でとりあげていますので、まだ確認されていない場合は先に以下の記事を一読ください。
vSphere環境への TKG 1.3.0 with NSX-ALB の簡易展開手順
ネットワーク構成
この記事では以下のネットワーク構成を利用します。
このテスト環境の構成で重要なのが L3 Switch （Cisco Catalyst 3560 を利用）の Access Control List （ACL） です。ACL にたいしてどのような通信を通したり落としたりするかを定義し、それをネットワークのインターフェースにたいして適用することで通信の制御をおこないます。これを設定することで「HTTP プロキシがないと外部と通信できない」という状況を作成しています。
今回はACLに以下のルールをもうけています。
- 内部ネットワーク（192.168.0.0/16）宛の通信は全て許可
- 192.168.64.0-15は全ての宛先への通信を許可 （上記 squid からインターネットへの通信はフィルタされない）
- 名前解決の通信は全て許可
- 全ての通信をドロップさせる
通信パケットにたいして上記のルールを上から適用していき、許可（permit）であればパケットを通し、拒否（deny）であればパケットを落とします。そして、このルールを「dp-mgmt-64」と「dp-data-80」からスイッチの SVI（VLANインターフェス）へのIN（入力）通信にたいして適用しています。
これをまとめると「全ホストはインターネット上での名前解決ができ、内部ネットワークへの通信は可能。ただし、インターネットと通信できるのは上記では HTTP Proxy（192.168.64.7）と ACL が適用範囲外の192.168.0.31の bootstrap のみ」となります。図で「proxy 設定必要」と書かれている192.168.64.31の bootstrap 及び、TKG のノード全ては HTTP Proxy を経由しないとインターネット上とやりとりできません。
図の HTTP Proxy には ubuntu 20.04 上の squid を利用しています。設定はほぼデフォルトのままですが、プライベートアドレスからの通信をポート 3128 で認証などなしに利用できる設定としています。以下に参考情報として squid の設定を記載します。
Bootstrap マシンの HTTP Proxy 対応化 （非公式手順）
最初に Bootstrap マシンを HTTP Proxy 対応化する設定を実施します。本記事の冒頭で扱いましたが、この手法は現時点の TKG 1.3.0 で「動く」というだけであり、サポートされる利用法ではありません。
まずそもそもこの設定が必要かということですが、さきほどのネットワーク図のどの bootstrap を使うかで話は変わります。
具体的には以下となります。
- 192.168.0.31 の Bootstrap: HTTP プロキシが不要なため、対応不要
- 192.168.64.31 の Bootstrap: HTTP プロキシが必要なため、対応が必要
現時点では 192.168.0.31 のように HTTP プロキシを必要としない Bootstrap を作成することが正しい対応です。ただし、組織のネットワークポリシーによっては HTTP プロキシ不要な Bootstrap を作成することが難しい場合があること、およびこれから紹介する手順は破壊的な操作ではない（つまり失敗してもダメージなし）ので、HTTP プロキシを利用する Bootstrap の構築手順をご紹介します。
おおまかには以下の手順です。
- ~/.bashrc に環境変数 HTTP_PROXY, HTTPS_PROXY, NO_PROXY を設定してロード
- 確認: wgetでプロキシが有効かチェック
- docker のインストール
- docker にプロキシの設定をする
- docker をリロードして設定を反映
- 確認: docker で image 取得可能かチェック
- kind をインストール
- kind k8s cluster をたちあげる
-
確認: kindにHTTP Proxy関連の環境変数があるかチェック
- 確認: kind 上で image 取得可能かチェック
-
tanzu cli および kubectl のインストール（省略。冒頭で紹介したインストール記事を参照ください）
- bootstrap サービスを上記の kind を使って起動する
- bootstrap の UI 上の設定（後述）
以下に順に説明していきます。
まず、TKG 以前の話としてマシンである Ubuntu 20.0.4 と Docker（後述する kind をコンテナとして起動）を HTTP プロキシに対応させる必要があります。上記流れのステップ1から3までの手順の実行サンプルを記載します。
UbuntuをグローバルレベルでHTTP Proxyに対応させるために、環境変数「http_proxy」「https_proxy」「no_proxy」を設定しています。マシンを再起動しても永続するように bash の起動時に読まれるスクリプト ~/.bashrc に定義をしています。次回の bash 起動時にこれらの設定は勝手に読み込まれるのですが、この bash のセッションでは読まれていないので source コマンドで読んでいます。これはあくまでも一例ですので、環境変数の設定のしかたはお使いの環境にあわせて実施してください。
ここで気をつけてほしいことは「必ず no_proxy の設定でローカルネットワークを除外する」ということです。これを指定しないと、たとえばノード間の通信や bootstrap クラスタとマネージメントクラスタ間の HTTP 通信もプロキシ経由となってしまいます。
その次に proxy の設定が効いているか wget で google にアクセスを試し、特に問題なければ apt で必要なパッケージを入手しています。今回は docker をインストールするために docker-compose （compose 自体は bootstrap に不要なものの、関連ツールをまとめてインストールできるので便利なため）と、のちほど gzip を展開するので gzip コマンドをいれています。docker のインストール後に有効化と起動もしています。
bootstrap は docker 上で「kind」と呼ばれるミニ k8s クラスタを起動します。この kind のイメージを取得できるようにするために上記のグローバルな HTTP プロキシの設定とは別に docker 用の HTTP プロキシ設定を加えます。以下に実行サンプルを記載します。
Docker の HTTP プロキシ設定は「/etc/systemd/system/docker.service.d/http-proxy.conf」におこないます。そのディレクトリを作成し、プロキシ設定ファイルを作成しています。
http-proxy.conf の書き方については以下のドキュメントをご参照ください。
設定が完了したら、それを有効化するためにデーモンの設定を再読み込みします。そして、docker を再起動し、docker の設定が反映されているかを確認します。設定に問題がなければ念のために busybox などの軽量イメージを試しに pull して正常にインターネット上から取得できるか確認します。
kindを使うには「kindコマンド」をインストールします。具体的な手法については以下を参照ください。
kindコマンドがインストールできたら、イメージを指定して kind k8s クラスタを作成します。上記サンプルではクラスタ名が bootstrap でイメージが kindest/node:v1.20.2 となります。この kind のクラスタ名はこれから作成するマネージメントクラスタとは関係ないので好きに名付けてください。
kind クラスタが構築できたら、docker としての操作で、kind クラスタのノードに HTTP プロキシ関連の環境変数がセットされているか確認します。上記サンプルを見るとわかるようにホストに設定したプロキシ設定が継承されており、no_proxyに関しては「kind 自体がプロキシしてはいけない内部のアドレスなど」が勝手に追加されています。
最後に念の為に kind でポッドを起動することでイメージの取得が HTTP プロキシ経由で正常に実施されるか確認します。上記では nginx ポッドを起動できているので、プロキシ経由でのイメージ取得に成功していることがわかります。確認に使った pod は消しておいてください。
以上で bootstrap クラスタの HTTP プロキシ対応のための事前準備は終了です。
意図せず手動作成した kind クラスタが動作していることを防止するために、これから説明するマネージメントクラスタのデプロイ完了後に docker コマンドを使って kind クラスタを stop/rm して消しておいてください。
BootstrapによるHTTP Proxyの設定
ここからの手順は上記のお手製 kind の利用以外は VMware のドキュメントに記載される設定項目となります。
まずは以下のドキュメントに沿って Tanzu コマンドおよび kubectl コマンドを bootstrap のホストにインストールしてください。冒頭に提示した別記事で解説を実施しています。
コマンドの準備ができたら、マネージメントクラスタのインストーラー UI を起動します。
上記例にあるパターン1が先ほど作成したカスタマイズされた kind を利用しない場合です。具体的には 192.168.0.31 の HTTPプロキシ設定が不要な Bootstrap を利用した場合はこのようなオプションを指定します。なお、「-b 192.168.0.31:8080」はどの IP とポートでサービスを公開するかの指定であり、GUI 付きの Bootstrap を利用する場合は指定不要です。今回は GUI のない ubuntu を使っているため、この IP とポートでインストーラー UI を外部に公開しています。
その下のパターン2がカスタマイズした kind を使う例です。オプションで「–use-existing-bootstrap-cluster」を指定することで、既存の kind の bootstrap cluster （k8s） を使いますので、これは先ほど確認したように HTTP プロキシに対応しています。
このようにしてインストーラー UI を起動したら、GUIの設定画面の「Step6. Kubernetes Network」まで HTTP プロキシなしの場合と同様に設定を進めてください。このステップ6で HTTP プロキシの設定をおこないます。
デフォルトでチェックがついていない「Proxy Settings」にチェックをいれることでHTTP プロキシの設定が有効化され、パラメーターを埋めます。設定するパラメータは上記のような一般的なものですが、「NO PROXY」に組織内のネットワーク（特に重要なのはクラスタを展開するワークロードネットワーク）を追加することです。これを追加しないとノード間の通信などが HTTP プロキシ経由となってしまい、おそらくマネージメントクラスタのデプロイに失敗します。
この設定を済ませたら HTTP プロキシなしの設定と同様に進めていき、デプロイを完了させてください。
上記の手順の詳細は以下のドキュメントの「Configure the Kubernetes Network and Proxies」にあります。
Deploy Management Clusters with the Installer Interface
この手順で構築されたマネージメントクラスタ、およびマネージメントクラスタのパラメータを利用するワークロードクラスタは上記の UI で設定されたプロキシの設定がほどこされています（逆に言えば、kind に設定したプロキシ設定は反映されていません）。そのため、クラスタを構成するノード群に手をいれなくてもプロキシ経由でインターネットにアクセスでき、イメージの取得などを実行することができます。
以下にワークロードクラスタ上で nginx ポッドをデプロイする例を記載します。
もしノード上の HTTP プロキシの設定に不備があればインターネット上から nginx イメージを取得できず、「image pull backoff」などで展開に失敗します。展開に成功しているので HTTP プロキシ設定が有効であることがわかります。
