(cluster-access)=
# クラスタにアクセスする
概して言えばIncusのクラスタは単独のIncusサーバーと同じように振る舞います。

クライアントはクラスタ内の任意のサーバーと通信し同一の体験を得ることができます。
リクエストはAPIを使って特定のサーバーに届けられますが、そのサーバーへの直接の接続は必要ありません。

```{note}
特定のサーバーをターゲットにするのはAPIでは`?target=SERVER`で、CLIレベルでは`--target`でできます。
```

クラスタからクライアントが受け取る証明書はすべてのサーバーで同じものを使っています。
これにより手動でフィンガープリントをチェックすることなく、クライアントに有効なHTTPSエンドポイントを公開するのが簡単にできます。

`incus cluster update-certificate`を使ってクラスタ全体で使うためにあなたが用意したTLS証明書をロードすることもできますし、ACMEを使ってクラスタ全体で使う証明書を自動的に発行と配置することもできます（{ref}`authentication-server-certificate`参照）。

## 認証
### HTTPSとTLS
これがリモートのIncusクラスターを使う場合のデフォルトの認証方法です。

これはクラスタではうまく機能しますが、クラスタに自身のTLS接続を必要とする一部のプロキシやロードバランサーでは問題になるかもしれません。

詳細は{ref}`authentication-tls-certs`を参照してください。

### HTTPSとOpenID Connect (OIDC)
IncusのOpenID Connect認証は外部のOpenIDアイデンティティ・プロバイダー（Identity Provider）を必要としますが、クラスタにきめ細かな認証を提供し、アクセスの管理と監査と容易にするという利点があります。

OpenID Connectが適切に動くためには、クラスタはDNSレコード、有効な証明書とOpenIDアイディンティ・プロバイダーへ接続できることが必要です。

詳細は{ref}`authentication-openid`を参照してください。

### ローカルアクセス
クラスタ内の任意のサーバーに接続し、そのサーバー上で動いているローカルのIncusデーモンと話すことでクラスタとやりとりできます。

## 高可用性
クラスタ上のIncus APIの高可用性を実現するためには、クライアントのリクエストを常に最低1つの応対可能なサーバーに届ける必要があります。

これに対処するにはよくあるいくつかの方法は以下のとおりです。

### DNSラウンドロビン
DNSは複数のサーバーにAPIトラフィックをバランスさせる非常に簡単な方法です。
クラスタ内の各サーバーに対する`A`または`AAAA`のDNSレコードを作るだけでよいです。

設定するのが簡単な一方、サーバーがすぐに接続を拒否した場合にしか別のサーバーにフォールバックできません。
詰まったサーバーがあると接続タイムアウトになるまで待ってから別のサーバーに繋ぐまことになるのでクライアントにかなりの遅延をもたらすかもしれません。

### 外部のロードバランサー

わりと簡単な解決方法はロードバランサーを動かすことです。`haproxy`のようなものをセルフホストするか、お使いの既存のネットワークやクラウドインフラストラクチャーで提供されるものを使います。

これらのロードバランサーはサービスの健康状態をモニターし、現在反応があるサーバーだけにリクエストを送ることもよくあります。
Incusは`haproxy`のプロキシプロトコルヘッダーをサポートしますのでオリジナルのクライアントIPアドレスがログは監査メッセージに記録されます。

```{note}
TLSクライアント証明書認証はTCPレベルで動作するロードバランサーでしか使えません。

TLSセッションを終端し、Incusへの自身のセッションを確立するロードバランサーはOIDC認証でしか使えません。
```

### 動的IPアドレス
追加の動的IPとともにIncusを使うことができます。これは実質的に1つのサーバーでだけ有効な仮想IPになります。
これはすべてのクライアントのAPIトラフィックを単一のサーバーに集中させますが、環境によっては管理がよりしやすくなります。

このためにはすべてのサーバーをすべてのインターフェース（例 `core.https_address=:8443`）でリッスンさせ、ローカルのファイアウォールを外部のクライアントが仮想IPアドレスに接続できるようにする必要があります。

仮想IPアドレスを扱うよくあるソリューションは（`frr`などを使って）`VRRP`と`corosync/pacemaker`です。

### ECMP
それぞれの個別のホストにBGPを使って完全なL3ネットワークインフラストラクチャーを動かしている環境では、Incusのクライアントのトラフィックに使用するためにIPアドレスを広告することができます。

このIPアドレスはネットワーク設定（IPv4なら`/32`またはIPv6なら`/128`）ですべてのサーバーに追加されルーターに広告されます。
この結果ルーターがクラスタ内のすべてのサーバーにIPアドレスを同じコストで持つことになります（ECMP）。

トラフィックはすべてのサーバー間で均等に振り分けられ、サーバーがダウンしたらすぐにそのサーバーへのルートは消失しトラフィックは残りのサーバーに向かいます。

```{note}
フォールバックの遅延を最小化するには、BGPに加えてBFDを使うことにより1秒以下のフォールバックタイムを実現できます。
```