VMware TKG と Harbor – インターネット非接続環境で内部レジストリを用意する意味

VMware TKG などの Kubernetes クラスタを閉域またはプロキシ環境で使う場合、Harbor のような内部コンテナレジストリが重要になります。この記事では、TKG 向けに Harbor を用意した当時の作業を、内部レジストリ設計の観点から整理します。

インターネットへ直接出られる環境では、Kubernetes ノードが外部レジストリからイメージを取得するだけで済みます。しかし企業ネットワーク、プロキシ環境、閉域環境ではそうはいきません。クラスタ構築に必要なイメージを、あらかじめ内部へ持ち込む必要があります。

閉域 Kubernetes において Harbor は補助ツールではありません。クラスタが必要なイメージを安定して取得するための前提基盤です。

参考
書籍

参考書籍

作って理解する仮想化技術 ── ハイパーバイザを実装しながら仕組みを学ぶ

VMware、KVM、Proxmox などの製品差分を見る前に、ハイパーバイザ、CPU 仮想化支援、メモリ仮想化、仮想デバイスの仕組みを押さえるための参考書籍です。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

なぜ Harbor が必要になるのか

TKG や Kubernetes クラスタは、構築時点から多くのコンテナイメージを必要とします。コントロールプレーン、CNI、CSI、監視、Ingress、レジストリ連携など、クラスタを構成する部品の多くがコンテナイメージとして配布されるためです。

外部レジストリへ直接到達できない環境でイメージを配布する
クラスタ構築時に必要なイメージを内部にミラーする
プロジェクト単位でイメージを管理し、認証や権限を分ける
Kubernetes ノードが参照するレジストリを内部に固定する
外部サービスの障害や通信制限にクラスタ構築を依存させない

特に TKGm のように vSphere 上に Kubernetes クラスタを作る場合、Bootstrap 環境、vSphere、Kubernetes ノード、内部レジストリが一体で動く必要があります。Harbor の準備が不完全だと、クラスタ構築そのものが進まなくなります。

全体構成

要素	役割
Photon OS	Harbor 実行用 OS として使った VMware 系の軽量 Linux
Harbor	TKG / Kubernetes が利用する内部コンテナレジストリ
TLS 証明書	Kubernetes ノードや Docker / containerd から信頼される HTTPS 接続を提供する
プロキシ設定	外部取得が必要な処理だけをプロキシへ出し、内部通信は除外する
TKG / Kubernetes ノード	Harbor から必要なイメージを pull する側

この構成で重要なのは、Harbor を単独で立てることではありません。Kubernetes ノードが名前解決でき、TLS 証明書を信頼し、認証でき、必要なイメージを取得できるところまで確認する必要があります。

Photon OS を使う意味

元記事では Harbor の実行基盤として Photon OS を使っていました。Photon OS は VMware 由来の軽量 Linux で、VMware 環境上で扱いやすい選択肢でした。

ただし、Harbor そのものは Photon OS 専用ではありません。現在の視点では、OS の種類よりも、Docker またはコンテナランタイム、永続ストレージ、TLS、バックアップ、監視、アップデート手順をどう安定させるかの方が重要です。

hostnamectl set-hostname harbor.example.local
tdnf update -y
tdnf install -y docker docker-compose wget tar openssl
systemctl enable --now docker

プロキシ環境での Docker 設定

プロキシ配下では、シェルの環境変数だけでは不十分です。Docker daemon 側にもプロキシを設定する必要があります。一方で、Harbor、Kubernetes API、ノード間通信、内部ネットワークは NO_PROXY に含めて、プロキシを経由しないようにします。

mkdir -p /etc/systemd/system/docker.service.d
cat <<'EOF' > /etc/systemd/system/docker.service.d/proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy.example.local:3128"
Environment="HTTPS_PROXY=http://proxy.example.local:3128"
Environment="NO_PROXY=localhost,127.0.0.1,harbor.example.local,10.0.0.0/8,192.168.0.0/16"
EOF

systemctl daemon-reload
systemctl restart docker
systemctl show --property=Environment docker

ここで NO_PROXY の設計を雑にすると、内部通信までプロキシへ向かってしまい、レジストリ接続、クラスタ API、ノード間通信の切り分けが難しくなります。閉域環境では、プロキシ設定は単なる通信設定ではなく、ネットワーク設計の一部です。

Harbor の導入

Harbor の導入自体は、インストーラを取得し、設定ファイルを作成して実行する流れです。ただし、実運用では harbor.yml の内容、TLS 証明書、ストレージ、バックアップ、管理者パスワード、外部 URL、プロキシ、ログ出力をきちんと決める必要があります。

wget https://github.com/goharbor/harbor/releases/download/v2.10.0/harbor-online-installer-v2.10.0.tgz
tar xzf harbor-online-installer-v2.10.0.tgz
cd harbor
cp harbor.yml.tmpl harbor.yml

./prepare
./install.sh
docker compose ps

この例はあくまで構成の考え方を示すものです。実際に構築する場合は、利用する Harbor のバージョン、OS、Docker / Docker Compose の扱い、証明書、バックアップ方針を現在の環境に合わせて確認する必要があります。

Kubernetes ノード側の確認

Harbor を立てただけでは、Kubernetes から使えるとは限りません。ノード側では、名前解決、TLS 信頼、レジストリ認証、イメージ pull の確認が必要です。

curl https://harbor.example.local/
docker login harbor.example.local
docker pull harbor.example.local/library/test-image:latest

本来は curl -k で証明書検証を無視して成功させるより、ノード側に正しく CA 証明書を配置して、通常の TLS 検証で通る状態にするべきです。閉域環境では自己署名証明書や社内 CA を使うことが多いため、ここを運用設計に含める必要があります。

TKGm Bootstrap との関係

前段の TKGm Bootstrap 環境は、クラスタ構築を実行する起点でした。一方 Harbor は、構築されるクラスタが必要なイメージを取得するための供給元です。どちらか一方だけ整っていても、閉域環境の Kubernetes 構築は成立しません。

部品	責務
TKGm Bootstrap	クラスタ作成コマンド、構成ファイル、vSphere 接続、初期操作の起点
Harbor	クラスタが必要とするコンテナイメージを内部で配布する基盤
プロキシ	外部取得が必要な通信を制御する境界
証明書	内部レジストリとノード間の信頼関係を作る
DNS	Bootstrap、Harbor、Kubernetes API、ノード間の名前解決を成立させる

いま読む場合の注意点

この記事は、当時の VMware TKG 環境で Harbor を用意した記録を再整理したものです。Harbor、TKG、Photon OS、Docker Compose のバージョンや推奨構成は時間とともに変わります。

そのため、今から同じコマンドをそのまま実行するための記事ではなく、閉域 Kubernetes 基盤で内部レジストリがなぜ必要になるのかを理解するための記事として読むのが自然です。実際に構築する場合は、現在利用する製品バージョンの公式ドキュメントを確認する必要があります。

まとめ

TKG や閉域 Kubernetes 環境では、Harbor は補助的なツールではなく前提基盤です。クラスタ構築手順より先に、内部レジストリ、TLS、プロキシ、名前解決を安定させる必要があります。

特に VMware TKGm のように、vSphere、Bootstrap 環境、内部レジストリ、プロキシ、証明書が絡む構成では、Harbor の完成度がクラスタ構築の成否に直結します。Kubernetes を閉域で使うということは、単に外部通信を止めることではなく、必要な依存物を内部で管理できる状態を作ることです。

なぜ Harbor が必要になるのか

全体構成

Photon OS を使う意味

プロキシ環境での Docker 設定

Harbor の導入

Kubernetes ノード側の確認

TKGm Bootstrap との関係

いま読む場合の注意点

まとめ

関連する記事

コメントを残すコメントをキャンセル

VMware TKG と Harbor – インターネット非接続環境で内部レジストリを用意する意味

なぜ Harbor が必要になるのか

全体構成

Photon OS を使う意味

プロキシ環境での Docker 設定

Harbor の導入

Kubernetes ノード側の確認

TKGm Bootstrap との関係

いま読む場合の注意点

まとめ

関連する記事

Related posts:

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル