Azure Kubernetes Services (AKS) を使用して Kubernetes に SQL Server コンテナーを配置するDeploy a SQL Server container in Kubernetes with Azure Kubernetes Services (AKS)

適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) - Linux適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) - Linux

高可用性 (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.

Kubernetes クラスターの SQL Server コンテナー

上の図で、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.

Kubernetes クラスターの SQL 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.

Kubernetes クラスターで SQL Server ポッドが回復


  • Kubernetes クラスターKubernetes cluster


    ノード障害から保護するため、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:

  1. マニフェストを作成して、ストレージ クラスと永続ボリューム要求を定義します。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 is azure-disk, because this Kubernetes cluster is in Azure. ストレージ アカウントの種類は Standard_LRS です。The storage account type is Standard_LRS. 永続ボリューム要求は mssql-data という名前です。The persistent volume claim is named mssql-data. 永続ボリューム要求のメタデータには、それをストレージ クラスに接続するための注釈が含まれています。The persistent volume claim metadata includes an annotation connecting it back to the storage class.

    kind: StorageClass
         name: azure-disk
      storageaccounttype: Standard_LRS
      kind: Managed
    kind: PersistentVolumeClaim
    apiVersion: v1
      name: mssql-data
      annotations: azure-disk
      - ReadWriteOnce
          storage: 8Gi

    ファイルを保存します (例: pvc.yaml)。Save the file (for example, pvc.yaml).

  2. 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.


  3. 永続ボリューム要求を確認します。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 named mssql-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 called Volume. この値は、BLOB の名前にマップされます。This value maps to the name of the blob.

    Volume を含む、返されたメタデータのスクリーンショット

    Volume の値は、Azure portal の次の図における BLOB の名前の一部と一致します。The value for volume matches part of the name of the blob in the following image from the Azure portal:

    Azure portal での BLOB 名のスクリーンショット

  4. 永続ボリュームを確認します。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.

  1. 配置を記述するマニフェスト (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
      name: mssql-deployment
      replicas: 1
           app: mssql
            app: mssql
          terminationGracePeriodSeconds: 30
          hostname: mssqlinst
            fsGroup: 10001
          - name: mssql
            - containerPort: 1433
            - name: MSSQL_PID
              value: "Developer"
            - name: ACCEPT_EULA
              value: "Y"
            - name: SA_PASSWORD
                  name: mssql
                  key: SA_PASSWORD 
            - name: mssqldb
              mountPath: /var/opt/mssql
          - name: mssqldb
              claimName: mssql-data
    apiVersion: v1
    kind: Service
      name: mssql-deployment
        app: mssql
        - protocol: TCP
          port: 1433
          targetPort: 1433
      type: LoadBalancer

    前のコードを、sqldeployment.yaml という名前の新しいファイルにコピーします。Copy the preceding code into a new file, named sqldeployment.yaml. 次の値を更新します。Update the following values:

    • MSSQL_PID value: "Developer": SQL Server Developer Edition を実行するようにコンテナーを設定します。MSSQL_PID value: "Developer": Sets the container to run SQL Server Developer edition. Developer Edition には、運用データ用のライセンスは付与されません。Developer edition is not licensed for production data. 配置を運用環境で使用する場合は、適切なエディション (EnterpriseStandard、または Express) を設定します。If the deployment is for production use, set the appropriate edition (Enterprise, Standard, or Express).


      詳細については、「SQL Server のライセンス方法」を参照してください。For more information, see How to license SQL Server.

    • persistentVolumeClaim:この値には、永続ボリューム要求に使用される名前にマップされる claimName: のエントリが必要です。persistentVolumeClaim: This value requires an entry for claimName: that maps to the name used for the persistent volume claim. このチュートリアルでは mssql-data を使用します。This tutorial uses mssql-data.

    • name: SA_PASSWORD:このセクションで定義されているように、コンテナー イメージを構成して SA パスワードを設定します。name: SA_PASSWORD: Configures the container image to set the SA password, as defined in this section.

          name: mssql
          key: SA_PASSWORD

    Kubernetes では、コンテナーを配置するときに、mssql という名前のシークレットを参照してパスワードの値が取得されます。When Kubernetes deploys the container, it refers to the secret named mssql 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 the LoadBalancer service type, the SQL Server instance is accessible remotely (via the internet) at port 1433.

    ファイルを保存します (例: sqldeployment.yaml)。Save the file (for example, sqldeployment.yaml).

  2. 配置を作成します。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, type kubectl get pod.

    get pod コマンドのスクリーンショット

    上の図では、ポッドの状態は Running です。In the preceding image, the pod has a status of Running. この状態は、コンテナーの準備ができていることを示します。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.

  3. サービスが実行されていることを確認します。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 the mssql-deployment service. この IP アドレスを使って SQL Server に接続します。Use this IP address to connect to SQL Server.

    get service コマンドのスクリーンショット

    Kubernetes クラスター内のオブジェクトの状態に関する詳細情報を取得するには、以下を実行します。For more information about the status of the objects in the Kubernetes cluster, run:

    az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>
  4. 次のコマンドを実行する方法でも、コンテナーが非ルートとして実行されていることを確認できます。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.


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 with sqlcmd, 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 the mssql-deployment service
    • MyC0m9l&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:

  1. SQL Server が実行されているポッドの一覧を表示します。List the pod running SQL Server.

    kubectl get pods

    SQL Server が実行されているポッドの名前を記録します。Note the name of the pod running SQL Server.

  2. ポッドを削除します。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.


このチュートリアルでは、高可用性を実現するために 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

次のステップNext steps