Kubernetes クラスタとレジストリ
作業によってはマシンが 1 台では足りません。Kubernetes にデプロイするサービス、ある場所でビルドして別の場所で動かすイメージ、テスト相手となるクラウド API などです。Bromure Agentic Coding はそのインフラをあなたのために、この Mac 上で、あなたのマシン（設定エディタでは「ワークスペース」）の隣で動かせます。
- Kubernetes クラスタは k3s を動かすノード VM の集まりで、複製ストレージ、ロードバランサ、Ingress コントローラ、ローカルのクラウドエミュレータを任意で備えます。許可したマシンは、それを
~/.kube/configのコンテキストとして受け取ります。 - レジストリは専用の小さな VM の中にあるプライベートな Docker レジストリです。許可したマシンはそこへプッシュでき、どのクラスタもそこからプルできます。
どちらも共有リソースです。1 つのクラスタやレジストリが複数のマシンに使われ、それらのエージェントはインフラの MCP サーバーを通じてその存在を知ります。
注： これらのクラスタを、マシンの認証情報ペインの Kubernetes 認証情報と混同しないでください。あちらはどこか別の場所に存在するクラスタ（EKS、GKE、職場のクラスタ）のコンテキストを取り込み、その認証情報をワイヤー上で仲介するものです。この章のクラスタは、Bromure がこの Mac 上に作って動かす VM です。
どこにあるか
- **ワークスペース › インフラ › Kubernetes クラスタを作成…とレジストリを作成…**が作成用のシートを開きます。リモート Mac のミラーウィンドウが前面にある場合、これらの項目はその Mac 上にクラスタやレジストリを作ります（リモートアクセスを参照）。
- 1 つでも存在すると、サイドバーの仮想マシンセクションに Kubernetes の一覧とレジストリの一覧が加わり、それぞれ + でもう 1 つ作れます。行には状態のドット、名前、1 行の状況が出ます。クリックするとそのダッシュボードがステージに出ます。⋯ メニューには開始、または実行中なら再起動と停止、ワークスペースのアクセス…、**削除…**があります。
クラスタを作る
新規クラスタのシートには 6 つのペイン — 一般、ノード、ストレージ、ネットワーク、アドオン、アクセス — のサイドバーがあり、マシンの設定エディタと同じ形です。シートが妥当になるまで作成は無効で、その隣の短い行が理由を示します（たとえば「クラスタに名前を付けてください。」）。
一般
| 項目 | 既定 | 意味 |
|---|---|---|
| 名前 | Kube cluster | ノードのホスト名、kubeconfig のコンテキスト、ディスク上のフォルダはすべてここから導かれます。ノードは k8s-<名前>-1、-2、… と名付けられます。 |
| Bromure と一緒に起動 | オン | アプリの起動時にクラスタをブートします。 |
概要には、選んだノード、ストレージ、ロードバランサ、アドオンが並びます。
ノード
| 項目 | 範囲 | 既定 |
|---|---|---|
| ノード | 1–8 | 1 |
| ノードあたりの vCPU | 1–16 | 2 |
| ノードあたりのメモリ | 2–64 GB | 4 GB |
ノードが 1 つなら、コントロールプレーンとあなたのワークロードを一緒に動かします。複数なら、ノード 1 がコントロールプレーン（それでもワークロードも動かします）で、他はワーカーとして参加します。ペインには合計 RAM が出て、クラスタが他のすべてに 4 GB 未満しか残さない場合は「この Mac の M GB のうち N GB です — ワークスペースにも余裕が必要です。」と警告します。
ストレージ
- Longhorn 分散ストレージ（既定でオン）— 専用のノードあたりのデータディスク（既定 40 GB、10〜2000 GB）から iSCSI で提供される複製ブロックボリューム。ディスクはスパースで、書き込まれたブロックだけが Mac 上の容量を使います。Longhorn は最大 3 レプリカを保ちますが、ノード数を超えることはありません。ストレージクラスは
bromure-longhornで、クラスタの既定です。オフにすると、k3s のノードローカルなlocal-pathクラスだけが残り、ポッドはそのノードに固定されます。 - Synology NAS — Synology の CSI ドライバ経由で、あなたの NAS 上に永続ボリュームを置きます。DSM アドレス、ポート、HTTPS、DSM ユーザー、DSM パスワード、任意のボリューム（たとえば
/volume1, /volume3）、プロトコル — iSCSI（ブロック LUN）または SMB（共有フォルダ） — そしてファイルシステムを入力します。ボリュームを指定しなければ、DSM が空きのあるものを選び、クラスはbromure-synologyになります。ボリュームを指定すると、それぞれに 1 つのクラス（bromure-synology-volume1、…）ができます。最初の Synology クラスがクラスタの既定になり、Longhorn は名前で引き続き使えます。DSM のアカウントにはストレージマネージャの権限が必要です。パスワードはこの Mac 上で暗号化して保存され、クラスタ自身の Secrets 以外に置かれることはありません。
ネットワーク
ロードバランサは、LoadBalancer 型の Service がどうアドレスを得るかを選びます。
| 選択 | 挙動 |
|---|---|
| MetalLB、VM ネットワークのみ（既定） | レイヤー 2 の MetalLB が VM ネットワークからアドレスを配ります。クラスタの構築時に、VM サブネットの上端の 20 アドレスが予約されます。マシンとこの Mac から到達できますが、あなたの LAN には何も公開されません。 |
| Bromure LAN ロードバランサ | 各 Service のポートがこの Mac の LAN アドレス上に公開され、ホストがそれをクラスタへ中継します。任意の LAN アドレスプール（たとえば 10.0.0.20-10.0.0.29、10.0.0.32/28、またはカンマ区切りのリスト）を指定すると、各 Service が代わりに自分の空き LAN アドレスを得て、Mac がネットワーク上でそれに応答します（ARP）。MetalLB のような形です。あなたの LAN、この Mac、マシンから到達できます。 |
| なし（NodePort のみ） | LoadBalancer の Service は保留のままです。NodePort か ClusterIP を使ってください。 |
Bromure LAN ロードバランサでは、2 つの Service アノテーションが Service ごとに既定を変えます。bromure.io/scope: vm はそれを非公開に保ち（VM ネットワーク上のアドレスで、マシンとこの Mac 専用）、bromure.io/loadBalancerIP は特定のアドレスを要求します。
Traefik Ingress コントローラ（既定でオン）は k3s に同梱の Ingress を残します。LAN ロードバランサと組み合わせると、この Mac 上でポート 80 と 443 を公開します。
警告： Bromure LAN ロードバランサは、クラスタのサービスをあなたのネットワーク上の誰からでも到達可能にします。意図して選んでください。既定の MetalLB はすべてをこの Mac にとどめます。
アドオン
オープンソースの floci ファミリーのローカルなクラウドエミュレータです。それぞれが自分のポートの LoadBalancer Service で、データはクラスタの既定ストレージクラスに置かれます。
| スイッチ | ポート | エミュレートするもの（一部） |
|---|---|---|
| AWS エミュレータ (floci) | 4566 | S3、DynamoDB、SQS、SNS、Lambda、API Gateway、Step Functions、EventBridge、Cognito |
| Azure エミュレータ (floci-az) | 4577 | Blob・Queue・Table Storage、Cosmos DB、Key Vault、Service Bus、Event Hubs、Event Grid、Functions、Azure SQL、App Configuration |
| Google Cloud エミュレータ (floci-gcp) | 4588 | Cloud Storage、Pub/Sub、Firestore、Datastore、Secret Manager、Cloud KMS、Cloud Run、Cloud Functions、Cloud Tasks、Cloud SQL、BigQuery |
| Oracle Cloud エミュレータ (floci-oci) | 4599 | Object Storage、Queue、Streaming、Vault、KMS、Secrets、Functions、Identity、OKE |
有効にした各エミュレータには プロジェクト バージョンの項目が付きます。空（最新リリース）にすると、クラスタの構築時に Docker Hub 上の最新リリースが使われます。タグ（2.1.0）や完全なイメージ参照を入力すると固定できます。Docker Hub に到達できない場合は latest タグが使われます。コンテナを起動するサービス（Lambda、Cloud Run など）はノードの Docker を使い、ベストエフォートです。
アクセス
どのマシンがこのクラスタを受け取るか：
- すべてのワークスペース（新規も含む）（既定）、または
- これらのワークスペースのみ。マシンごとにチェックボックスが付きます。「少なくとも 1 つのワークスペースはアクセスを保たなければなりません。」
一覧にあるマシンは、~/.kube/config にこのクラスタを受け取り（コンテキスト名はクラスタ名）、インフラの MCP を通じてそれを見ます。あとからダッシュボードで変更できます。
作成をクリックしてください。プロビジョニングには数分かかります。ダッシュボードのログタブが各ステップを示します。
クラスタのダッシュボード
ダッシュボードのヘッダーには、クラスタ名、フェーズのピル、そして概要（ノード数、1 ノードあたりの vCPU とメモリ、k3s のバージョン、稼働時間）が出て、開始、または再起動と停止、そしてクラスタの操作メニュー（kubeconfig をコピー、ワークスペースのアクセス…、Bromure と一緒に起動、クラスタを削除…）が並びます。
一覧用のフィルタフィールドを備えた 6 つのタブがあります。
| タブ | 表示するもの |
|---|---|
| 概要 | ノード、ポッド、メモリ、ストレージ、ロードバランサのカード。クラウドエミュレータごとのカードには、この Mac と LAN から／ワークスペースからに分けたエンドポイント、そのクラウドの CLI と SDK をそこへ向ける貼り付け用の 1 行、受け付けるテスト用認証情報が入ります。加えてロードバランサの公開ポート（バインドに失敗したものは理由付きで）、ノード、最近の警告。 |
| ワークロード | Deployment とポッド、準備状況と再起動回数。 |
| サービス | Service とその外部アドレス（割り当てられるまでは外部 IP：保留中）。 |
| ストレージ | Longhorn の容量とボリューム、Synology ドライバの状態、そしてボリュームクレーム。 |
| アクセス | ワークスペースのアクセス — シートと同じ選択です。 |
| ログ | プロビジョニングとライフサイクルのログ。 |
クラスタを削除…「すべてのノードを停止し、そのディスクを削除します。すべての Longhorn ボリュームも含みます。ワークスペースは kubeconfig からこのクラスタを失います。これは取り消せません。」
マシンからクラスタを使う
許可されたマシンでは、kubectl はそのまま動きます。クラスタのコンテキストは ~/.kube/config にあり、kubectl は VM ネットワーク越しにコントロールプレーンのノードと直接話します。この通信はホストの傍受プロキシを通りません — ノードのアドレスはマシンのプロキシ設定から除外されています — そのためマシンのトレースには現れません。
kubeconfig をコピーの操作は、Mac 自身のツール向けに独立した kubeconfig を渡します。ノードの VM は CLI からも到達できます。たとえば bromure-cli vm exec k8s-dev-1 -- kubectl get nodes です（CLI、API、MCPを参照）。
レジストリ
レジストリを作る
**レジストリを作成…**はシートを開きます：「専用の VM の中のプライベートな Docker レジストリ：ワークスペースでビルドし、ここへプッシュし、クラスタで動かします。VM ネットワーク上の素の HTTP で、この Mac を出ることはありません。」
| 項目 | 範囲 | 既定 |
|---|---|---|
| 名前 | — | registry |
| Bromure と一緒に起動 | — | オン |
| メモリ | 1–16 GB | 1 GB |
| イメージ用ストレージ | 10–2000 GB | 40 GB |
| プッシュのアクセス | すべてのワークスペース（新規も含む） / これらのワークスペースのみ | すべて |
イメージのディスクはスパースで、プッシュされたレイヤーだけが容量を使います。どのクラスタもどのレジストリからもプルできます。プッシュのアクセスはマシンごとです。
レジストリのダッシュボード
ヘッダーにはレジストリのアドレス（<ip>:5000）、メモリとディスク、開始 / 再起動 / 停止、そしてアドレスをコピー、ワークスペースのアクセス…、Bromure と一緒に起動、レジストリを削除…のメニューが出ます。タブはイメージ（リポジトリ、ディスク、アドレスのカード、ワークスペースからプッシュのスニペット、そしてイメージとタグの一覧）、アクセス、ログです。
プッシュのアクセスを持つマシンでは、Docker はすでにレジストリのアドレスを信頼していて、$BROMURE_REGISTRY がそれを保持しています（複数のレジストリにアクセスできる場合は最初のもの）。ですからすぐにプッシュできます。
docker build -t $BROMURE_REGISTRY/myapp:dev .
docker push $BROMURE_REGISTRY/myapp:dev
kubectl run myapp --image=$BROMURE_REGISTRY/myapp:dev
クラスタはどのレジストリからも自動でプルするよう構成されます。レジストリが作られたり、移動したり、削除されたりすると、実行中のクラスタが更新されます。レジストリが停止している間は、そこからのプルは他のレジストリ障害と同じように失敗します。
レジストリを削除…「レジストリの VM を停止し、そこにあるすべてのイメージを削除します。ワークスペースとクラスタはそのアドレスを信頼しなくなります。これは取り消せません。」
エージェントとインフラ MCP
どのマシンのエージェントも bromure-infrastructure MCP サーバー（vsock ポート 5834）を得ます。範囲はそのマシンが使えるクラスタとレジストリに限られます。そのツールは次のとおりです。
| ツール | 何をするか |
|---|---|
infrastructure_overview | このマシンが使えるすべて — クラスタ（コンテキスト名、状態、ノード、ストレージクラス、ロードバランサ、Ingress）とレジストリ（アドレス、プッシュの方法）— を、使い方の説明とともに返します。 |
cluster_status | あるクラスタのライブな詳細：フェーズ、ノード、ポッド、Service とその外部アドレス、ストレージ、警告、最近のログ行。 |
cluster_create | シートと同じオプションでクラスタを作ります。 |
cluster_start | 停止中のクラスタをブートします。 |
registry_status | あるレジストリ：アドレス、応答するか、そのイメージ、ディスク使用量。 |
registry_create | レジストリを作ります。 |
registry_start | 停止中のレジストリをブートします。 |
エージェントが作ったクラスタやレジストリは、すべてのマシンに共有され（すべてのワークスペース）、Bromure と一緒に起動します。
ライフサイクル
- アプリを終了すると、クラスタのノードとレジストリはサスペンドされ（メモリのスナップショット）、次の起動で再開します。復元できないスナップショットは、新しいブートに切り替わります。
- 停止は VM の電源を切る前に k3s とコンテナをきれいに落とし、マシンごとに最大 60 秒を認めます。
- ノードやレジストリの VM がブート時にファイルシステム検査に失敗すると、Bromure がそれを検出して VM を止め、システムディスクとデータディスクを修復し、もう一度ブートします。
- 最初の構築が完了しなかったクラスタは、次回の起動時にもう一度構築されます。
- マシンを削除すると、すべてのアクセス一覧からそれが外れます。空になってしまう一覧は、すべてのマシンに切り替わります。
- クラスタとレジストリは、他のすべてと同じようにリモート Mac のミラーウィンドウにも現れます（リモートアクセスを参照）。
クラスタの記録は ~/Library/Application Support/BromureAC/kube/clusters.json にあります。各クラスタのノードディスクは ~/Library/Application Support/BromureAC/kube/<クラスタ id>/ の下です。