2026 / 02
このラボ全体を支えるクラスターの運用
成果登録アプリケーション全体で単一の配信経路と内部名前解決を使用。各アプリケーションは自分のリポジトリから検出され、退役も同じ経路で行われます。公開アイデンティティ方針を明示し、既存メトリクスは読まれずに眠るのではなくアラートを上げます。
概要
Kubernetes v1.37.0 を動かすベアメタル 3 ノード。2026-09-09 の観測では ArgoCD 39 アプリケーションが Healthy / Synced。アプリケーションは手作業ではなくリポジトリから検出され、テスト、ビルド、スキャン、配信タグを更新する別コミットという同じ経路を通ります。
背景
同じクラスターで外部リクエストと再現可能なアプリケーション配信の両方を扱います。
システム
Synced is not always deployed.
課題
kubectl debug Pod の内部からノードをデバッグすることは、ノード自体をデバッグすることと同じではありません。chroot /host はデバッグ Pod 自身のマウント／PID 名前空間のスナップショットであり、ホストのライブ状態ではありません——/proc は空を返し、内部で実行した mount/umount は実際のホストのマウントテーブルに反映されません。これを信じてしまうかどうかが、NAS 再構築中のクリーンな修正と実際の障害発生の分かれ目でした。
調査
最初の仮説
デバッグコンテナはライブなホストを示し、ArgoCD の Synced は対象ビルドのデプロイ完了を示すと考えました。
ホストの本当に最新の状態に依存する操作（マウント後の書き込み、既にマウント済みかの確認など）は、デバッグ Pod のスナップショット内で直接実行するのではなく、ホスト自身のサービスマネージャへ委譲する必要があります。この「便利な代理ではなく本物の状態を確かめる」という習慣はクラスター全体で現れます。二段階 GitOps パイプライン（push がビルドをトリガーし、別の後続コミットがデプロイ済みイメージタグを更新）では、自分のコミットに対する ArgoCD の Synced+Healthy 状態を確認しても、そのコミットがイメージ参照に触れていなければ何も証明しません——実際のタグ更新コミットを待つ必要があります。同じ習慣が効いた例がその後 2 つ出ました——認証チェックへリダイレクトする *前* にセッション cookie を発行していたパスワード関門（リダイレクトに従わなければ全部開く。あれは提案であって関門ではなかった）、そして実際には収集されていないメトリクス名に対して書かれたアラート規則。どちらも推論ではなく計測で見つかりました。
証拠
# delegated to the host service manager, not run inside the debug containerデバッグ Pod は別の namespace のスナップショットで、ビルドコミットの後には別のタグ更新コミットが存在しました。
判断
ホスト状態に依存する処理はデバッグコンテナではなくホスト自身のサービスマネージャへ委譲し、タグ更新コミットをデプロイの基準にしました。
結果
ラボ全体のワイルドカード DNS（dnsmasq）と Cloudflare Zero Trust のプライベートルーティングにより、LAN 内でもリモートでも内部の *.local ホスト名にアプリごとの再設定なしで同じ方法でアクセス可能——生のクラスター IP を公開する代替案として意図的に採用したものです。
次に変えること
現在の制約: ベアメタル 3 台でもなお小さな障害領域であり、うち 1 台は専用の taint を持つため、1 ノードが落ちるとスケジュール先を失うワークロードが出る。保守には引き続き順序設計が必要です。
次の一手: 復旧手順の演習と、基盤レベルのサービス目標を整備します。