Kubernetes でSQL Server インスタンスをネイティブに作成して管理します。
SQL Serverを、Kubernetes によって管理される Docker コンテナーにデプロイします。 Kubernetes では、クラスター ノードで障害が発生した場合に、SQL Server インスタンスを持つコンテナーが自動的に回復する可能性があります。
SQL Server 2017 では、Kubernetes にデプロイできる Docker イメージが導入されています。 Kubernetes の永続ボリューム要求 (PVC) を使用して、イメージを構成できます。 Kubernetes は、コンテナー内のSQL Server プロセスを監視します。 プロセス、ポッド、コンテナー、またはノードで障害が発生した場合、Kubernetes は自動的に別のインスタンスをブートストラップし、ストレージに再接続します。
Kubernetes 上SQL Server インスタンスを持つコンテナー
Kubernetes 1.6 以降では、ストレージクラス、永続ボリュームクレーム、およびAzure ディスクボリュームの種類がサポートされています。
この構成では、Kubernetes はコンテナー オーケストレーターの役割を果たします。
上の図では、mssql-server は、pod 内のSQL Server インスタンス (コンテナー) です。
レプリカ セットによって、ノード障害が発生した後でポッドが自動的に復旧されます。 アプリケーションがサービスに接続します。 このケースでは、サービスは、mssql-server の障害後も変化しない IP アドレスがホストされているロード バランサーを表します。
Kubernetes により、クラスター内のリソースが調整されます。 SQL Server インスタンス コンテナーをホストしているノードが失敗すると、SQL Server インスタンスを使用して新しいコンテナーがブートストラップされ、同じ永続ストレージにアタッチされます。
SQL Server on Linuxでは、Kubernetes、OpenShift、DH2i 上のコンテナーがサポートされます。
関連するコンテンツ
- SQL Server Linux コンテナーにデプロイして接続します
クイックスタート: Azure または Red Hat OpenShift で SQL Server コンテナー クラスターをデプロイする方法 - チュートリアル: DH2i DxEnterprise を使用して 3 ノード Always On 可用性グループを設定する