DashboardとHeadlamp、根本的に異なる「アクセスの仕組み」
Kubernetes DashboardとHeadlampはどちらもクラスタ内で稼働しているものを可視化するツールですが、動作の仕組みは大きく異なります。公式ブログはこの違いを次のように整理しています（出典）。
| 項目 | Kubernetes Dashboard | Headlamp |
|---|---|---|
| 稼働場所 | クラスタ内のみ | デスクトップまたはクラスタ内 |
| 認証方式 | ベアラートークン（サービスアカウント由来が多い） | 既存のkubeconfig（ときにSSOも） |
| 複数クラスタ対応 | 基本的に1クラスタに1つ | 標準で複数クラスタを一画面表示 |
| リソース作成 | フォーム入力が中心 | YAML適用が中心 |
| 拡張性 | なし | プラグインで機能追加可能 |
Dashboardは「クラスタに住み着くUI」であるのに対し、Headlampは「自分のIDに従うUI」だ。
DashboardはHelmなどでクラスタ内にインストールし、kubectl port-forwardやIngress経由でアクセスするのが一般的です。一方Headlampはkubectlと同じようにkubeconfigを読み込むため、1つの画面で複数クラスタを横断的に確認できる点が大きな違いです（出典）。
移行前に「今の使い方」を棚卸しするチェックリスト
公式ブログは、移行時のつまずきを避けるための事前チェックリストを提示しています。
- 使用しているクラスタ（開発・ステージング・本番）の一覧化
- よく触るNamespaceの把握
- 普段の操作内容（閲覧・編集・スケール・削除・デバッグ）の整理
- 現在のDashboardへのアクセス方法（port-forwardかIngressか）
- 現在のログイン方法（サービスアカウントトークンとそのRBACバインディング）
ブラウズ・Namespace絞り込み・YAML/イベント/ステータスの確認・ログ閲覧といった基本的なワークフローは両者で共通していますが、ログイン方法がトークン貼り付けからkubeconfigへ変わる点、リソース作成がフォームから「YAML適用」中心に変わる点、複数クラスタ表示が標準機能になる点は明確な変化点です（出典）。
AI/MLワークロード向けのKubeflowプラグインも同時公開
同日には、Headlamp上でKubeflowのAI/ML関連ワークロードを可視化・管理できる新プラグインを紹介する記事も公開されました。Kubernetesは静かにAI/ML基盤のデフォルトプラットフォームになりつつあり、ノートブックサーバーの運用や分散学習ジョブのスケジューリング、ハイパーパラメータチューニング、複数ステップのMLパイプラインのオーケストレーションといった作業の多くがKubernetesクラスタ上で行われるようになっています。
Kubeflowはこうしたスタックを「Kubernetesネイティブ」な方法、つまりすべての機能をカスタムリソース定義（CRD）として公開する形で提供しています。この設計はクラスタ運用者にとって恩恵が大きい一方、ML専用ダッシュボードが下層のKubernetesレイヤーを隠してしまうため、ノートブックが固まったり学習ジョブが失敗したりした際に、結局kubectlでPodレベルの状況を調べ直す羽目になることが多いという課題があったといいます（出典）。
GKEでKubernetesクラスタを触っている身としては、複数クラスタを1画面で見られるようになるのは地味に嬉しい変化です。開発・ステージング・本番を行き来する作業が多いなら、移行前のチェックリストに沿って一度棚卸ししてみる価値はありそうだと感じます。
