Kubernetes で Azure SQL Edge コンテナーをデプロイする
重要
Azure SQL Edge では ARM64 プラットフォームがサポートされなくなりました。
Azure SQL Edge は、Kubernetes で実行される Azure IoT Edge の IoT Edge モジュールまたはスタンドアロン コンテナー ポッドの両方として、Kubernetes クラスターにデプロイできます。 この記事の残りの部分では、Kubernetes クラスター上のスタンドアロン コンテナーのデプロイに焦点を当てます。 Kubernetes での Azure IoT Edge のデプロイの詳細については、「Azure IoT Edge on Kubernetes (プレビュー)」を参照してください。
このチュートリアルでは、Kubernetes クラスター上のコンテナーに高可用性 Azure SQL Edge インスタンスを構成する方法について説明します。
- SA パスワードを作成する
- ストレージを作成する
- 配置を作成する
- SQL Server Management Studio (SSMS) と接続する
- 障害と復旧を検証する
Kubernetes 1.6 以降では、ストレージ クラス、永続ボリューム要求、および Azure ディスク ボリューム タイプがサポートされています。 Kubernetes でネイティブに Azure SQL Edge インスタンスを作成して管理できます。 この記事の例では、共有ディスクのフェールオーバー クラスター インスタンスと同様の高可用性構成を実現するために、配置を作成する方法を示します。 この構成では、Kubernetes はクラスター オーケストレーターの役割を果たします。 コンテナー内の Azure SQL Edge インスタンスで障害が発生すると、オーケストレーターにより、同じ永続ストレージに接続されるコンテナーの別のインスタンスがブートストラップされます。
上の図で、azure-sql-edge はポッド内のコンテナーです。 Kubernetes により、クラスター内のリソースが調整されます。 レプリカ セットによって、ノード障害が発生した後でポッドが自動的に復旧されます。 アプリケーションがサービスに接続します。 このケースでは、サービスは、azure-sql-edge の障害後も変化しない IP アドレスがホストされているロード バランサーを表します。
次の図では、azure-sql-edge コンテナーで障害が発生しています。 オーケストレーターとしての Kubernetes により、レプリカ セット内に適切な数の正常なインスタンスが存在することが保証され、構成に従って新しいコンテナーが開始されます。 オーケストレーターによって同じノード上で新しいポッドを開始され、azure-sql-edge によって同じ永続ストレージに再接続されます。 サービスは、再作成された azure-sql-edge に接続されます。
次の図では、azure-sql-edge コンテナーがホストされているノードで障害が発生しています。 オーケストレーターによって異なるノード上で新しいポッドを開始され、azure-sql-edge によって同じ永続ストレージに再接続されます。 サービスは、再作成された azure-sql-edge に接続されます。
前提条件
Kubernetes クラスター
このチュートリアルでは、Kubernetes クラスターが必要です。 この手順では、kubectl を使用してクラスターを管理します。
このチュートリアルでは、Azure Kubernetes Service を使用して Azure SQL Edge をデプロイします。
kubectlを使って AKS に単一ノード Kubernetes クラスターを作成して接続する方法については、Azure Kubernetes Service (AKS) クラスターのデプロイに関する記事をご覧ください。
Note
ノード障害から保護するため、Kubernetes クラスターには複数のノードが必要です。
Azure CLI
- このチュートリアルの手順は、Azure CLI 2.10.1 に対して検証されています。
SQL Edge をデプロイするための Kubernetes 名前空間を作成する
Kubernetes クラスターに新しい名前空間を作成します。 この名前空間を使用して、SQL Edge と、必要なすべての成果物がデプロイされます。 Kubernetes 名前空間の詳細については、名前空間 を参照してください。
kubectl create namespace <namespace name>
SA パスワードを作成する
Kubernetes クラスターで SA パスワードを作成します。 Kubernetes では、パスワードなどの機密構成情報をシークレットとして管理できます。
次のコマンドでは、SA アカウントのパスワードが作成されます。
kubectl create secret generic mssql --from-literal=SA_PASSWORD="MyC0m9l&xP@ssw0rd" -n <namespace name>
MyC0m9l&xP@ssw0rd は複雑なパスワードに置き換えます。
ストレージを作成する
Kubernetes クラスターで、永続ボリュームと永続ボリューム要求を構成します。 次の手順を実行します。
マニフェストを作成して、ストレージ クラスと永続ボリューム要求を定義します。 マニフェストでは、ストレージ プロビジョナー、パラメーター、再要求ポリシーを指定します。 Kubernetes クラスターでは、このマニフェストを使って、永続ストレージが作成されます。
次の yaml の例では、ストレージ クラスと永続ボリューム要求が定義されています。 この Kubernetes クラスターは Azure 内にあるため、ストレージ クラス プロビジョナーは
azure-diskです。 ストレージ アカウントの種類はStandard_LRSです。 永続ボリューム要求はmssql-dataという名前です。 永続ボリューム要求のメタデータには、それをストレージ クラスに接続するための注釈が含まれています。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)。
Kubernetes で永続ボリューム要求を作成します。
kubectl apply -f <Path to pvc.yaml file> -n <namespace name><Path to pvc.yaml file>は、ファイルを保存した場所です。永続ボリュームが Azure ストレージ アカウントとして自動的に作成され、永続ボリューム要求にバインドされます。
永続ボリューム要求を確認します。
kubectl describe pvc <PersistentVolumeClaim> -n <name of the namespace><PersistentVolumeClaim>は、永続ボリューム要求の名前です。前のステップでは、永続ボリューム要求に
mssql-dataという名前が指定されています。 永続ボリューム要求に関するメタデータを表示するには、次のコマンドを実行します。kubectl describe pvc mssql-data -n <namespace name>返されるメタデータには、
Volumeという名前の値が含まれます。 この値は、BLOB の名前にマップされます。
永続ボリュームを確認します。
kubectl describe pv -n <namespace name>kubectlでは、自動的に作成されて永続ボリューム要求にバインドされた永続ボリュームに関するメタデータが返されます。
配置を作成する
この例では、Azure SQL Edge インスタンスをホストするコンテナーを、Kubernetes デプロイ オブジェクトとして記述しています。 配置ではレプリカ セットが作成されます。 レプリカ セットによってポッドが作成されます。
この手順では、Azure SQL Edge Docker イメージに基づいてコンテナーを記述するマニフェストを作成します。 マニフェストでは、mssql-data 永続ボリューム要求と、Kubernetes クラスターに既に適用されている mssql シークレットが参照されます。 また、マニフェストではサービスについても記述されています。 このサービスはロード バランサーです。 ロード バランサーにより、Azure SQL Edge インスタンスの復旧後も IP アドレスが維持されることが保証されます。
配置を記述するマニフェスト (YAML ファイル) を作成します。 次の例では、Azure SQL Edge コンテナー イメージに基づくコンテナーを含むデプロイが記述されています。
apiVersion: apps/v1 kind: Deployment metadata: name: sqledge-deployment spec: replicas: 1 selector: matchLabels: app: sqledge template: metadata: labels: app: sqledge spec: volumes: - name: sqldata persistentVolumeClaim: claimName: mssql-data containers: - name: azuresqledge image: mcr.microsoft.com/azure-sql-edge:latest ports: - containerPort: 1433 volumeMounts: - name: sqldata mountPath: /var/opt/mssql env: - name: MSSQL_PID value: "Developer" - name: ACCEPT_EULA value: "Y" - name: SA_PASSWORD valueFrom: secretKeyRef: name: mssql key: SA_PASSWORD - name: MSSQL_AGENT_ENABLED value: "TRUE" - name: MSSQL_COLLATION value: "SQL_Latin1_General_CP1_CI_AS" - name: MSSQL_LCID value: "1033" terminationGracePeriodSeconds: 30 securityContext: fsGroup: 10001 --- apiVersion: v1 kind: Service metadata: name: sqledge-deployment spec: selector: app: sqledge ports: - protocol: TCP port: 1433 targetPort: 1433 name: sql type: LoadBalancer前のコードを、
sqldeployment.yamlという名前の新しいファイルにコピーします。 次の値を更新します。MSSQL_PID
value: "Developer": Azure SQL Edge Developer Edition を実行するようにコンテナーを設定します。 Developer Edition には、運用データ用のライセンスは付与されません。 デプロイを運用環境で使用する場合は、エディションをPremiumに設定します。Note
詳細については、Azure SQL Edge のライセンス方法に関する記事を参照してください。
persistentVolumeClaim:この値には、永続ボリューム要求に使用される名前にマップされるclaimName:のエントリが必要です。 このチュートリアルではmssql-dataを使用します。name: SA_PASSWORD:このセクションで定義されているように、コンテナー イメージを構成して SA パスワードを設定します。valueFrom: secretKeyRef: name: mssql key: SA_PASSWORDKubernetes では、コンテナーを配置するときに、
mssqlという名前のシークレットを参照してパスワードの値が取得されます。
Note
LoadBalancerサービスの種類を使うことにより、Azure SQL Edge インスタンスにポート 1433 で (インターネットを経由して) リモート アクセスできるようになります。ファイルを保存します (例:
sqledgedeploy.yaml)。配置を作成します。
kubectl apply -f <Path to sqledgedeploy.yaml file> -n <namespace name><Path to sqldeployment.yaml file>は、ファイルを保存した場所です。
配置とサービスが作成されます。 Azure SQL Edge インスタンスはコンテナー内にあり、永続ストレージに接続されています。
ポッドの状態を表示するには、「
kubectl get pod -n <namespace name>」と入力します。
上の図では、ポッドの状態は
Runningです。 この状態は、コンテナーの準備ができていることを示します。 この処理には数分かかることがあります。Note
配置が作成された後、ポッドが表示されるまでに数分かかることがあります。 遅延は、クラスターで Docker ハブから Azure SQL Edge コンテナー イメージがプルされるためです。 イメージが初めてプルされた後の配置は、既にイメージがキャッシュされているノードに対するものの場合は、高速になる可能性があります。
サービスが実行されていることを確認します。 次のコマンドを実行します。
kubectl get services -n <namespace name>このコマンドでは、実行されているサービスと共に、サービスの内部および外部の IP アドレスも返されます。
mssql-deploymentサービスの外部 IP アドレスを記録しておきます。 この IP アドレスを使って Azure SQL Edge に接続します。
Kubernetes クラスター内のオブジェクトの状態に関する詳細情報を取得するには、以下を実行します。
az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>
Azure SQL Edge インスタンスに接続する
説明に従ってコンテナーを構成した場合は、Azure 仮想ネットワークの外部からアプリケーションに接続できます。 sa アカウントと、サービスの外部 IP アドレスを使います。 Kubernetes シークレットとして構成したパスワードを使います。 Azure SQL Edge インスタンスへの接続の詳細については、Azure SQL Edge への接続 に関する記事を参照してください。
障害と復旧を検証する
障害と復旧を確認するには、ポッドを削除します。 手順は次のとおりです。
Azure SQL Edge を実行しているポッドを一覧表示します。
kubectl get pods -n <namespace name>Azure SQL Edge が実行されているポッドの名前をメモします。
ポッドを削除します。
kubectl delete pod sqledge-deployment-7df66c9999-rc9xlsqledge-deployment-7df66c9999-rc9xlは、前のステップでポッド名に対して返された値です。
Kubernetes によって、Azure SQL Edge インスタンスを復旧するためのポッドが自動的に再作成され、永続ストレージに接続されます。 新しいポッドが配置されたことを確認するには、kubectl get pods を使います。 新しいコンテナーの IP アドレスが同じであることを確認するには、kubectl get services を使います。
まとめ
このチュートリアルでは、高可用性を実現するために Azure SQL Edge コンテナーを Kubernetes クラスターに配置する方法について説明しました。
- SA パスワードを作成する
- ストレージを作成する
- 配置を作成する
- Azure SQL Edge Management Studio (SSMS) と接続する
- 障害と復旧を検証する