VMware TKGm Bootstrap を振り返る – vSphere 上で Kubernetes 基盤を作る難しさ

この記事は、VMware Tanzu Kubernetes Grid multi-cloud、いわゆる TKGm の Bootstrap 環境を作った当時の作業メモを、いま読み直せる形に整理したものです。

当時の主題は、TKGm のマネジメントクラスタを構築するために、Bootstrap 用の端末または VM を用意し、必要な CLI、イメージ、プロキシ、内部レジストリを準備することでした。特にインターネットへ直接出られないプロキシ環境では、この準備がかなり面倒になります。

TKGm の難しさは、Kubernetes そのものだけではなく、vSphere、ネットワーク、プロキシ、コンテナイメージ、内部レジストリ、証明書を一つの構築フローにまとめる必要がある点にありました。

この記事の位置づけ

この記事は、現在の最新手順をそのまま示すものではありません。VMware 製品は買収や製品体系の変更を経ており、TKG / Tanzu 周辺の名称や提供形態も変わっています。ここでは、当時の TKGm Bootstrap 構築を題材に、VMware 環境で Kubernetes 基盤を作るときに何が複雑だったのかを整理します。

• TKGm Bootstrap 環境がなぜ必要だったのか
• プロキシ環境で Kubernetes 基盤構築が難しくなる理由
• Harbor や内部レジストリが重要になる理由
• vSphere 上の Kubernetes が単なる kubeadm 構築と違う点
• 現在の視点で、この記事をどう読むべきか

TKGm Bootstrap とは何だったのか

TKGm では、いきなり vSphere 上に Kubernetes クラスタを作るのではなく、まず構築作業を実行する Bootstrap 環境を用意します。Bootstrap 環境には、TKG CLI、kubectl、必要な構成ファイル、認証情報、クラスタ作成に必要なイメージ参照情報などを置きます。

Bootstrap 環境は、専用アプライアンスとして用意されるというより、Windows、macOS、Linux などの作業端末や VM に必要なツールを入れて作るものでした。元記事では CentOS 8 をベースにしています。

要素	役割
Bootstrap 環境	TKGm のクラスタ作成コマンドを実行する作業基盤
vSphere	Kubernetes ノードとなる VM を配置する仮想化基盤
TKG CLI	マネジメントクラスタやワークロードクラスタの作成を制御する CLI
kubectl	作成後の Kubernetes クラスタを操作する CLI
Harbor	プロキシ環境や閉域環境で必要なコンテナイメージを保持する内部レジストリ

なぜ Bootstrap 環境が重くなるのか

Bootstrap 環境は、単なる踏み台サーバーではありません。クラスタ構築に必要な情報とツールが集まるため、実質的には Kubernetes 基盤構築の起点になります。

• vSphere へ接続するための認証情報を持つ
• Kubernetes クラスタ定義を生成または保持する
• TKG CLI や kubectl を実行する
• プロキシや証明書の設定を持つ
• 内部レジストリに向けたイメージ参照を扱う
• マネジメントクラスタ作成後の初期操作にも使う

そのため、Bootstrap 環境が壊れるとすぐに既存クラスタが停止するわけではありませんが、構築、再構築、追加、トラブルシュートの起点を失います。作業端末のようでいて、実際にはかなり重要な運用部品です。

プロキシ環境で一気に難しくなる

元記事で重要だったのは、インターネットへ直接接続できない環境、つまりプロキシ環境で TKGm を構築していた点です。Kubernetes 系の構築では、外部レジストリ、GitHub、パッケージリポジトリ、証明書検証など、多くの通信が前提になります。

インターネットへ自由に出られる環境では見えにくいですが、閉域寄りの企業ネットワークやプロキシ環境では、ここが一気に構築難易度を上げます。

問題	なぜ面倒か
OS のプロキシ設定	シェル、パッケージ管理、CLI ごとに参照する環境変数や設定が異なる
コンテナイメージ	外部レジストリから直接 pull できないため、内部レジストリへのミラーが必要になる
証明書	社内 CA や自己署名証明書を各コンポーネントが信頼する必要がある
no_proxy	vSphere、内部 DNS、内部レジストリ、Kubernetes API をプロキシ除外にする必要がある
障害切り分け	ネットワーク、認証、証明書、イメージ取得失敗が似た症状に見える

つまり、TKGm の構築が面倒だったというより、Kubernetes 基盤を閉域寄りの VMware 環境へ持ち込むこと自体が面倒だったと言えます。

Harbor が重要になる理由

プロキシ環境やインターネット非接続環境では、Harbor のような内部コンテナレジストリが重要になります。Kubernetes クラスタは多くのコンテナイメージを必要とするため、外部レジストリへ直接アクセスできない環境では、必要なイメージをあらかじめ内部へ持ち込む必要があります。

VMware 環境では、Harbor や Photon OS といった VMware 由来の要素も登場します。元記事の流れでは、TKGm Bootstrap そのものよりも、実際には内部レジストリを整える作業の方が面倒だった印象があります。

• 外部レジストリへ直接出られない環境でもクラスタを構築できる
• 必要な Kubernetes / TKG 関連イメージを内部で管理できる
• イメージの取得元を制御し、監査しやすくなる
• プロキシやインターネット接続に依存しない構築がしやすくなる

vSphere 上の Kubernetes は kubeadm と違う

kubeadm で Kubernetes を構築する場合、主語は比較的シンプルです。OS、containerd、kubelet、CNI、コントロールプレーン、ワーカーノードを自分で組み立てます。

一方で、TKGm は vSphere の上に Kubernetes クラスタを作るため、vSphere 側のリソース、テンプレート、ネットワーク、データストア、権限、イメージ、ロードバランサー、内部レジストリが絡みます。Kubernetes の知識だけでも、VMware の知識だけでも足りません。

観点	kubeadm 的な構築	TKGm 的な構築
主な基盤	Linux ホスト	vSphere 上の VM
構築起点	各ノードと kubeadm	Bootstrap 環境と TKG CLI
ネットワーク	CNI とホストネットワーク中心	vSphere ネットワーク、ロードバランサー、CNI が絡む
イメージ管理	外部レジストリに直接依存しやすい	閉域では Harbor などの内部レジストリが重要
運用思想	自分で組み立てる Kubernetes	VMware 管理基盤と統合した Kubernetes

当時の構築ポイント

元記事では、CentOS 8 を Bootstrap 環境として使い、GUI ありの環境、プロキシ設定、OS 更新、EPEL、Docker、kubectl、TKG CLI、vSphere 接続などを順に準備していました。

現在の視点では、細かなコマンドをそのまま追うより、次の構成要素を押さえる方が重要です。

• Bootstrap VM または作業端末を安定した場所に用意する
• OS 全体、CLI、コンテナランタイムが正しくプロキシを参照できるようにする
• 内部ネットワークや Kubernetes API は no_proxy で除外する
• 社内 CA や自己署名証明書を OS とツール類に信頼させる
• 外部から取得するイメージを Harbor などの内部レジストリに集約する
• vSphere 側のネットワーク、データストア、テンプレート、権限を事前に整理する

いま読むなら何が価値になるか

この記事の価値は、古い TKGm 手順をそのまま再実行することではありません。価値があるのは、企業向け Kubernetes 基盤を作るときに、Kubernetes の外側で必要になる準備がどれだけ多いかを確認できる点です。

Kubernetes は、クラスタが起動した後だけを見ると YAML と API の世界に見えます。しかし実際の構築では、DNS、プロキシ、証明書、レジストリ、ロードバランサー、仮想化基盤、ストレージ、権限管理が必ず出てきます。

TKGm Bootstrap の作業は、その複雑さをかなり素直に露出していました。Kubernetes を企業基盤へ入れるということは、Kubernetes だけを入れる話ではない、ということです。

まとめ

VMware TKGm Bootstrap は、vSphere 上に Kubernetes 基盤を作るための起点でした。作業端末のように見えますが、実際には CLI、構成ファイル、プロキシ、証明書、レジストリ、vSphere 接続情報が集まる重要な構築基盤です。

特にプロキシ環境や閉域環境では、TKGm の構築は急に難しくなります。外部レジストリへ直接出られないため、Harbor のような内部レジストリが必要になり、証明書や no_proxy の設計も重要になります。

この当時の記録は、現在の最新手順として読むより、VMware 環境で Kubernetes を運用基盤へ組み込もうとしたときの複雑さを理解する記事として読むのが良いと思います。

関連する記事

• Broadcom による VMware 買収をどう見るか – 仮想化基盤の標準が変わるということ
• VMware TKG と Harbor – インターネット非接続環境で内部レジストリを用意する意味
• Kubernetes を前提とした仮想化アーキテクチャ – VM とコンテナをどう重ねるか
• Ubuntu 26.04 で Kubernetes コントロールプレーンを構築する
• Red Hat OpenShift Virtualization をどう見るか – Kubernetes 上で VM を扱う意味