Azure Kubernetes Services (AKS) を使用して Kubernetes に SQL Server コンテナーを配置するDeploy a SQL Server container in Kubernetes with Azure Kubernetes Services (AKS)
適用対象:Applies to: SQL ServerSQL Server (サポートされているすべてのバージョン)
SQL ServerSQL Server (all supported versions)
SQL ServerSQL Server (サポートされているすべてのバージョン)
SQL ServerSQL Server (all supported versions)
高可用性 (HA) のための永続ストレージを使用して、Azure Kubernetes Service (AKS) の Kubernetes で SQL Server インスタンスを構成する方法について説明します。Learn how to configure a SQL Server instance on Kubernetes in Azure Kubernetes Service (AKS), with persistent storage for high availability (HA). このソリューションでは回復性が提供されます。The solution provides resiliency. SQL Server インスタンスで障害が発生した場合、Kubernetes によって新しいポッドに自動的に再作成されます。If the SQL Server instance fails, Kubernetes automatically re-creates it in a new pod. Kubernetes では、ノード障害に対する回復性も提供されます。Kubernetes also provides resiliency against a node failure.
このチュートリアルでは、AKS 上のコンテナーに高可用性 SQL Server インスタンスを構成する方法について説明します。This tutorial demonstrates how to configure a highly available SQL Server instance in a container on AKS.
- SA パスワードを作成するCreate an SA password
- ストレージを作成するCreate storage
- 配置を作成するCreate the deployment
- SQL Server Management Studio (SSMS) と接続するConnect with SQL Server Management Studio (SSMS)
- 障害と復旧を検証するVerify failure and recovery
Azure Kubernetes Service で実行されている Kubernetes 上の HA ソリューションHA solution on Kubernetes running in Azure Kubernetes Service
Kubernetes 1.6 以降では、ストレージ クラス、永続ボリューム要求、および Azure ディスク ボリューム タイプがサポートされています。Kubernetes 1.6 and later has support for storage classes, persistent volume claims, and the Azure disk volume type. Kubernetes で ネイティブに SQL Server インスタンスを作成して管理できます。You can create and manage your SQL Server instances natively in Kubernetes. この記事の例では、共有ディスクのフェールオーバー クラスター インスタンスと同様の高可用性構成を実現するために、配置を作成する方法を示します。The example in this article shows how to create a deployment to achieve a high availability configuration similar to a shared disk failover cluster instance. この構成では、Kubernetes はクラスター オーケストレーターの役割を果たします。In this configuration, Kubernetes plays the role of the cluster orchestrator. コンテナー内の SQL Server インスタンスで障害が発生すると、オーケストレーターにより、同じ永続ストレージに接続されるコンテナーの別のインスタンスがブートストラップされます。When a SQL Server instance in a container fails, the orchestrator bootstraps another instance of the container that attaches to the same persistent storage.
上の図で、mssql-server
はポッド内のコンテナーです。In the preceding diagram, mssql-server
is a container in a pod. Kubernetes により、クラスター内のリソースが調整されます。Kubernetes orchestrates the resources in the cluster. レプリカ セットによって、ノード障害が発生した後でポッドが自動的に復旧されます。A replica set ensures that the pod is automatically recovered after a node failure. アプリケーションがサービスに接続します。Applications connect to the service. このケースでは、サービスは、mssql-server
の障害後も変化しない IP アドレスがホストされているロード バランサーを表します。In this case, the service represents a load balancer that hosts an IP address that stays the same after failure of the mssql-server
.
次の図では、mssql-server
コンテナーで障害が発生しています。In the following diagram, the mssql-server
container has failed. オーケストレーターとしての Kubernetes により、レプリカ セット内に適切な数の正常なインスタンスが存在することが保証され、構成に従って新しいコンテナーが開始されます。As the orchestrator, Kubernetes guarantees the correct count of healthy instances in the replica set, and starts a new container according to the configuration. オーケストレーターによって同じノード上で新しいポッドを開始され、mssql-server
によって同じ永続ストレージに再接続されます。The orchestrator starts a new pod on the same node, and mssql-server
reconnects to the same persistent storage. サービスは、再作成された mssql-server
に接続されます。The service connects to the re-created mssql-server
.
次の図では、mssql-server
コンテナーがホストされているノードで障害が発生しています。In the following diagram, the node hosting the mssql-server
container has failed. オーケストレーターによって異なるノード上で新しいポッドを開始され、mssql-server
によって同じ永続ストレージに再接続されます。The orchestrator starts the new pod on a different node, and mssql-server
reconnects to the same persistent storage. サービスは、再作成された mssql-server
に接続されます。The service connects to the re-created mssql-server
.
前提条件Prerequisites
Kubernetes クラスターKubernetes cluster
このチュートリアルでは、Kubernetes クラスターが必要です。The tutorial requires a Kubernetes cluster. この手順では、kubectl を使用してクラスターを管理します。The steps use kubectl to manage the cluster.
kubectl
を使って AKS に単一ノード Kubernetes クラスターを作成して接続する方法については、Azure Kubernetes Service (AKS) クラスターのデプロイに関する記事をご覧ください。See Deploy an Azure Kubernetes Service (AKS) cluster to create and connect to a single-node Kubernetes cluster in AKS withkubectl
.
注意
ノード障害から保護するため、Kubernetes クラスターには複数のノードが必要です。To protect against node failure, a Kubernetes cluster requires more than one node.
Azure CLI 2.0.23Azure CLI 2.0.23
- このチュートリアルの手順は、Azure CLI 2.0.23 に対して検証されています。The instructions in this tutorial have been validated against Azure CLI 2.0.23.
SA パスワードを作成するCreate an SA password
Kubernetes クラスターで SA パスワードを作成します。Create an SA password in the Kubernetes cluster. Kubernetes では、パスワードなどの機密構成情報をシークレットとして管理できます。Kubernetes can manage sensitive configuration information, like passwords as secrets.
次のコマンドでは、SA アカウントのパスワードが作成されます。The following command creates a password for the SA account:
kubectl create secret generic mssql --from-literal=SA_PASSWORD="MyC0m9l&xP@ssw0rd"
MyC0m9l&xP@ssw0rd
は複雑なパスワードに置き換えます。Replace MyC0m9l&xP@ssw0rd
with a complex password.
そのコマンドを実行すると、SA_PASSWORD
に対する値 MyC0m9l&xP@ssw0rd
を保持する mssql
という名前のシークレットが Kubernetes に作成されます。To create a secret in Kubernetes named mssql
that holds the value MyC0m9l&xP@ssw0rd
for the SA_PASSWORD
, run the command.
ストレージを作成するCreate storage
Kubernetes クラスターで、永続ボリュームと永続ボリューム要求を構成します。Configure a persistent volume and persistent volume claim in the Kubernetes cluster. 次の手順を実行します。Complete the following steps:
マニフェストを作成して、ストレージ クラスと永続ボリューム要求を定義します。Create a manifest to define the storage class and the persistent volume claim. マニフェストでは、ストレージ プロビジョナー、パラメーター、再要求ポリシーを指定します。The manifest specifies the storage provisioner, parameters, and reclaim policy. Kubernetes クラスターでは、このマニフェストを使って、永続ストレージが作成されます。The Kubernetes cluster uses this manifest to create the persistent storage.
次の yaml の例では、ストレージ クラスと永続ボリューム要求が定義されています。The following yaml example defines a storage class and persistent volume claim. この Kubernetes クラスターは Azure 内にあるため、ストレージ クラス プロビジョナーは
azure-disk
です。The storage class provisioner isazure-disk
, because this Kubernetes cluster is in Azure. ストレージ アカウントの種類はStandard_LRS
です。The storage account type isStandard_LRS
. 永続ボリューム要求はmssql-data
という名前です。The persistent volume claim is namedmssql-data
. 永続ボリューム要求のメタデータには、それをストレージ クラスに接続するための注釈が含まれています。The persistent volume claim metadata includes an annotation connecting it back to the storage class.kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: azure-disk provisioner: kubernetes.io/azure-disk parameters: storageaccounttype: Standard_LRS kind: Managed --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: mssql-data annotations: volume.beta.kubernetes.io/storage-class: azure-disk spec: accessModes: - ReadWriteOnce resources: requests: storage: 8Gi
ファイルを保存します (例: pvc.yaml)。Save the file (for example, pvc.yaml).
Kubernetes で永続ボリューム要求を作成します。Create the persistent volume claim in Kubernetes.
kubectl apply -f <Path to pvc.yaml file>
<Path to pvc.yaml file>
は、ファイルを保存した場所です。<Path to pvc.yaml file>
is the location where you saved the file.永続ボリュームが Azure ストレージ アカウントとして自動的に作成され、永続ボリューム要求にバインドされます。The persistent volume is automatically created as an Azure storage account, and bound to the persistent volume claim.
永続ボリューム要求を確認します。Verify the persistent volume claim.
kubectl describe pvc <PersistentVolumeClaim>
<PersistentVolumeClaim>
は、永続ボリューム要求の名前です。<PersistentVolumeClaim>
is the name of the persistent volume claim.前のステップでは、永続ボリューム要求に
mssql-data
という名前が指定されています。In the preceding step, the persistent volume claim is namedmssql-data
. 永続ボリューム要求に関するメタデータを表示するには、次のコマンドを実行します。To see the metadata about the persistent volume claim, run the following command:kubectl describe pvc mssql-data
返されるメタデータには、
Volume
という名前の値が含まれます。The returned metadata includes a value calledVolume
. この値は、BLOB の名前にマップされます。This value maps to the name of the blob.Volume の値は、Azure portal の次の図における BLOB の名前の一部と一致します。The value for volume matches part of the name of the blob in the following image from the Azure portal:
永続ボリュームを確認します。Verify the persistent volume.
kubectl describe pv
kubectl
では、自動的に作成されて永続ボリューム要求にバインドされた永続ボリュームに関するメタデータが返されます。kubectl
returns metadata about the persistent volume that was automatically created and bound to the persistent volume claim.
配置を作成するCreate the deployment
この例では、SQL Server インスタンスをホストしているコンテナーが、Kubernetes 配置オブジェクトとして記述されています。In this example, the container hosting the SQL Server instance is described as a Kubernetes deployment object. 配置ではレプリカ セットが作成されます。The deployment creates a replica set. レプリカ セットによってポッドが作成されます。The replica set creates the pod.
このステップでは、SQL Server mssql-server-linux の Docker イメージに基づいてコンテナーを記述するマニフェストを作成します。In this step, create a manifest to describe the container based on the SQL Server mssql-server-linux Docker image. マニフェストでは、mssql-server
永続ボリューム要求と、Kubernetes クラスターに既に適用されている mssql
シークレットが参照されます。The manifest references the mssql-server
persistent volume claim, and the mssql
secret that you already applied to the Kubernetes cluster. また、マニフェストではサービスについても記述されています。The manifest also describes a service. このサービスはロード バランサーです。This service is a load balancer. ロード バランサーにより、SQL Server インスタンスの復旧後も IP アドレスが維持されることが保証されます。The load balancer guarantees that the IP address persists after SQL Server instance is recovered.
配置を記述するマニフェスト (YAML ファイル) を作成します。Create a manifest (a YAML file) to describe the deployment. 次の例では、SQL Server コンテナー イメージに基づくコンテナーを含む配置が記述されています。The following example describes a deployment, including a container based on the SQL Server container image.
apiVersion: apps/v1 kind: Deployment metadata: name: mssql-deployment spec: replicas: 1 selector: matchLabels: app: mssql template: metadata: labels: app: mssql spec: terminationGracePeriodSeconds: 30 hostname: mssqlinst securityContext: fsGroup: 10001 containers: - name: mssql image: mcr.microsoft.com/mssql/server:2019-latest ports: - containerPort: 1433 env: - name: MSSQL_PID value: "Developer" - name: ACCEPT_EULA value: "Y" - name: SA_PASSWORD valueFrom: secretKeyRef: name: mssql key: SA_PASSWORD volumeMounts: - name: mssqldb mountPath: /var/opt/mssql volumes: - name: mssqldb persistentVolumeClaim: claimName: mssql-data --- apiVersion: v1 kind: Service metadata: name: mssql-deployment spec: selector: app: mssql ports: - protocol: TCP port: 1433 targetPort: 1433 type: LoadBalancer
前のコードを、
sqldeployment.yaml
という名前の新しいファイルにコピーします。Copy the preceding code into a new file, namedsqldeployment.yaml
. 次の値を更新します。Update the following values:MSSQL_PID
value: "Developer"
: SQL Server Developer Edition を実行するようにコンテナーを設定します。MSSQL_PIDvalue: "Developer"
: Sets the container to run SQL Server Developer edition. Developer Edition には、運用データ用のライセンスは付与されません。Developer edition is not licensed for production data. 配置を運用環境で使用する場合は、適切なエディション (Enterprise
、Standard
、またはExpress
) を設定します。If the deployment is for production use, set the appropriate edition (Enterprise
,Standard
, orExpress
).注意
詳細については、「SQL Server のライセンス方法」を参照してください。For more information, see How to license SQL Server.
persistentVolumeClaim
:この値には、永続ボリューム要求に使用される名前にマップされるclaimName:
のエントリが必要です。persistentVolumeClaim
: This value requires an entry forclaimName:
that maps to the name used for the persistent volume claim. このチュートリアルではmssql-data
を使用します。This tutorial usesmssql-data
.name: SA_PASSWORD
:このセクションで定義されているように、コンテナー イメージを構成して SA パスワードを設定します。name: SA_PASSWORD
: Configures the container image to set the SA password, as defined in this section.valueFrom: secretKeyRef: name: mssql key: SA_PASSWORD
Kubernetes では、コンテナーを配置するときに、
mssql
という名前のシークレットを参照してパスワードの値が取得されます。When Kubernetes deploys the container, it refers to the secret namedmssql
to get the value for the password.securityContext
:securityContext によって、Pod または Container の特権とアクセス制御の設定が定義されます。この場合、それはポッド レベルで指定されるため、すべてのコンテナー (この場合は 1 つだけ) はそのセキュリティ コンテキストに準拠します。securityContext
: A securityContext defines privilege and access control settings for a Pod or Container, in this case it is specified at the pod level, so all containers ( in this case only one) adhere to that security context. このセキュリティ コンテキストでは、値 10001 (mssql グループの GID) の fsGroup を定義します。つまり、コンテナーのすべてのプロセスも補足グループ ID 10001 (mssql) に属します。In the security context we define the fsGroup with the value 10001 ( which is the GID for mssql group) means, all processes of the container are also part of the supplementary group ID 10001(mssql). ボリューム /var/opt/mssql とそのボリュームで作成されたあらゆるファイルはグループ ID 10001 (mssql グループ) になります。The owner for volume /var/opt/mssql and any files created in that volume will be Group ID 10001(mssql group).
注意
LoadBalancer
サービスの種類を使うことにより、SQL Server インスタンスにポート 1433 で (インターネットを経由して) リモート アクセスできるようになります。By using theLoadBalancer
service type, the SQL Server instance is accessible remotely (via the internet) at port 1433.ファイルを保存します (例: sqldeployment.yaml)。Save the file (for example, sqldeployment.yaml).
配置を作成します。Create the deployment.
kubectl apply -f <Path to sqldeployment.yaml file>
<Path to sqldeployment.yaml file>
は、ファイルを保存した場所です。<Path to sqldeployment.yaml file>
is the location where you saved the file.配置とサービスが作成されます。The deployment and service are created. SQL Server インスタンスはコンテナー内にあり、永続ストレージに接続されています。The SQL Server instance is in a container, connected to persistent storage.
ポッドの状態を表示するには、「
kubectl get pod
」と入力します。To view the status of the pod, typekubectl get pod
.上の図では、ポッドの状態は
Running
です。In the preceding image, the pod has a status ofRunning
. この状態は、コンテナーの準備ができていることを示します。This status indicates that the container is ready. この処理には数分かかることがあります。This may take several minutes.注意
配置が作成された後、ポッドが表示されるまでに数分かかることがあります。After the deployment is created, it can take a few minutes before the pod is visible. 遅延は、クラスターによって Docker Hub から mssql-server-linux イメージがプルされるためです。The delay is because the cluster pulls the mssql-server-linux image from the Docker hub. イメージが初めてプルされた後の配置は、既にイメージがキャッシュされているノードに対するものの場合は、高速になる可能性があります。After the image is pulled the first time, subsequent deployments might be faster if the deployment is to a node that already has the image cached on it.
サービスが実行されていることを確認します。Verify the services are running. 次のコマンドを実行します。Run the following command:
kubectl get services
このコマンドでは、実行されているサービスと共に、サービスの内部および外部の IP アドレスも返されます。This command returns services that are running, as well as the internal and external IP addresses for the services.
mssql-deployment
サービスの外部 IP アドレスを記録しておきます。Note the external IP address for themssql-deployment
service. この IP アドレスを使って SQL Server に接続します。Use this IP address to connect to SQL Server.Kubernetes クラスター内のオブジェクトの状態に関する詳細情報を取得するには、以下を実行します。For more information about the status of the objects in the Kubernetes cluster, run:
az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>
次のコマンドを実行する方法でも、コンテナーが非ルートとして実行されていることを確認できます。You can also verify the container is running as non-root by running the following command:
kubectl.exe exec <name of SQL POD> -it -- /bin/bash
次に 'whoami' を実行します。mssql としてユーザー名が表示されるはずです。and then run 'whoami' you should see the username as mssql. これは非ルート ユーザーです。Which is a non-root user.
whoami
SQL Server インスタンスに接続するConnect to the SQL Server instance
説明に従ってコンテナーを構成した場合は、Azure 仮想ネットワークの外部からアプリケーションに接続できます。If you configured the container as described, you can connect with an application from outside the Azure virtual network. sa
アカウントと、サービスの外部 IP アドレスを使います。Use the sa
account and the external IP address for the service. Kubernetes シークレットとして構成したパスワードを使います。Use the password that you configured as the Kubernetes secret.
次のアプリケーションを使って、SQL Server インスタンスに接続できます。You can use the following applications to connect to the SQL Server instance.
sqlcmdsqlcmd
sqlcmd
を使って接続するには、次のコマンドを実行します。To connect withsqlcmd
, run the following command:sqlcmd -S <External IP Address> -U sa -P "MyC0m9l&xP@ssw0rd"
次の値を置き換えます。Replace the following values:
<External IP Address>
は、mssql-deployment
サービスの IP アドレスに<External IP Address>
with the IP address for themssql-deployment
serviceMyC0m9l&xP@ssw0rd
は、自分のパスワードにMyC0m9l&xP@ssw0rd
with your password
障害と復旧を検証するVerify failure and recovery
障害と復旧を確認するには、ポッドを削除します。To verify failure and recovery, you can delete the pod. 手順は次のとおりです。Do the following steps:
SQL Server が実行されているポッドの一覧を表示します。List the pod running SQL Server.
kubectl get pods
SQL Server が実行されているポッドの名前を記録します。Note the name of the pod running SQL Server.
ポッドを削除します。Delete the pod.
kubectl delete pod mssql-deployment-0
mssql-deployment-0
は、前のステップでポッド名に対して返された値です。mssql-deployment-0
is the value returned from the previous step for pod name.
Kubernetes では、ポッドが自動的に再作成されて SQL Server インスタンスが復旧され、永続ストレージに接続されます。Kubernetes automatically re-creates the pod to recover a SQL Server instance, and connect to the persistent storage. 新しいポッドが配置されたことを確認するには、kubectl get pods
を使います。Use kubectl get pods
to verify that a new pod is deployed. 新しいコンテナーの IP アドレスが同じであることを確認するには、kubectl get services
を使います。Use kubectl get services
to verify that the IP address for the new container is the same.
まとめSummary
このチュートリアルでは、高可用性を実現するために SQL Server コンテナーを Kubernetes クラスターに配置する方法を学習しました。In this tutorial, you learned how to deploy SQL Server containers to a Kubernetes cluster for high availability.
- SA パスワードを作成するCreate an SA password
- ストレージを作成するCreate storage
- 配置を作成するCreate the deployment
- SQL Server Management Studio (SSMS) と接続するConnect with SQL Server Management Studios (SSMS)
- 障害と復旧を検証するVerify failure and recovery