Déployer SQL Managed Instance activé par Azure Arc à l’aide d’outils Kubernetes
Cet article explique la procédure de déploiement d’Azure SQL Managed Instance pour Azure Arc avec des outils Kubernetes.
Prérequis
Vous devez avoir déjà créé un contrôleur de données.
Pour créer une instance gérée SQL à l’aide des outils Kubernetes, vous devez avoir installé ceux-ci. Les exemples de cet article utilisent kubectl, mais des approches similaires peuvent être utilisées avec d’autres outils Kubernetes tels que le tableau de bord Kubernetes, ocou helm si vous êtes familiarisé avec ces outils et Kubernetes yaml/json.
Vue d’ensemble
Pour créer une instance SQL Managed Instance, vous devez :
- créer un secret Kubernetes pour stocker votre identifiant d’administrateur système et votre mot de passe en toute sécurité ;
- créer une ressource SQL Managed Instance personnalisée en fonction de la définition de ressource personnalisée
SqlManagedInstance;
définir ces deux éléments dans un fichier YAML.
Créer un fichier YAML
Utilisez le modèle de fichier YAML comme point de départ pour créer votre propre fichier YAML d’instance gérée SQL personnalisée. Téléchargez ce fichier sur votre ordinateur local et ouvrez-le dans un éditeur de texte. Utilisez un éditeur de texte, tel que VS Code, qui prend en charge la mise en surbrillance de la syntaxe et le linting pour les fichiers YAML.
Remarque
À partir de la version de février 2022, vous devez spécifier une classe de stockage compatible ReadWriteMany (RWX) pour les sauvegardes. En savoir plus sur le modes d'accès.
Si aucune classe de stockage n’est spécifiée pour les sauvegardes, la classe de stockage par défaut de Kubernetes est utilisée. Si la valeur par défaut n’est pas compatible RWX, l’installation de SQL Managed Instance peut échouer.
Example de fichier YAML
Voici un exemple d’une réponse YAML :
apiVersion: v1
data:
password: <your base64 encoded password>
username: <your base64 encoded username>
kind: Secret
metadata:
name: sql1-login-secret
type: Opaque
---
apiVersion: sql.arcdata.microsoft.com/v12
kind: SqlManagedInstance
metadata:
name: sql1
annotations:
exampleannotation1: exampleannotationvalue1
exampleannotation2: exampleannotationvalue2
labels:
examplelabel1: examplelabelvalue1
examplelabel2: examplelabelvalue2
spec:
dev: true #options: [true, false]
licenseType: LicenseIncluded #options: [LicenseIncluded, BasePrice]. BasePrice is used for Azure Hybrid Benefits.
tier: GeneralPurpose #options: [GeneralPurpose, BusinessCritical]
security:
adminLoginSecret: sql1-login-secret
scheduling:
default:
resources:
limits:
cpu: "2"
memory: 4Gi
requests:
cpu: "1"
memory: 2Gi
services:
primary:
type: LoadBalancer
storage:
#backups:
# volumes:
# - className: azurefile # Backup volumes require a ReadWriteMany (RWX) capable storage class
# size: 5Gi
data:
volumes:
- className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
size: 5Gi
datalogs:
volumes:
- className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
size: 5Gi
logs:
volumes:
- className: default # Use default configured storage class or modify storage class based on your Kubernetes environment
size: 5Gi
Personnalisation de l’identifiant et du mot de passe
Une clé secrète Kubernetes est stockée sous la forme d’une chaîne encodée en base64, une pour le nom d’utilisateur et l’autre pour le mot de passe. Vous devez coder en base64 un identifiant et un mot de passe d’administrateur système et les placer à l’emplacement de l’espace réservé à data.password et data.username. N’incluez pas les symboles < et > fournis dans le modèle.
Remarque
Pour une sécurité optimale, l’utilisation de la valeur sa n’est pas autorisée pour l’identifiant.
Respectez la stratégie de complexité de mot de passe.
Vous pouvez utiliser un outil en ligne pour encoder en base64 votre nom d’utilisateur et votre mot de passe souhaités, ou vous pouvez utiliser des outils CLI en fonction de votre plateforme.
PowerShell
[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('<your string to encode here>'))
#Example
#[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('example'))
Linux/mac OS
echo -n '<your string to encode here>' | base64
#Example
# echo -n 'example' | base64
Personnalisation du nom
Le modèle a la valeur sql1 pour l’attribut de nom. Vous pouvez le modifier, mais il doit contenir des caractères qui respectent les normes DNS en matière d’attribution de noms. Vous devez également modifier le nom du secret pour qu’il corresponde. Par exemple, si vous remplacez le nom de l’instance gérée SQL par sql2, vous devez remplacer le nom du secret sql1-login-secret par sql2-login-secret
Personnalisation des besoins en ressources
Vous pouvez modifier les besoins en ressources (la RAM, les limites principales et les requêtes) le cas échéant.
Remarque
Vous pouvez en apprendre plus sur la gouvernance des ressources Kubernetes.
Conditions requises pour les requêtes et les limites de ressources :
- La valeur limite des cœurs est obligatoire à des fins de facturation.
- Les autres requêtes et limites de ressources sont facultatives.
- La limite et la requête de cœurs doivent être une valeur entière positive, le cas échéant.
- Un cœur au minimum est obligatoire pour la requête de cœurs, le cas échéant.
- Le format de la valeur de mémoire respecte la notation Kubernetes.
- Un minimum de 2 Go est requis pour la demande de mémoire, si elle est spécifiée.
- En règle générale, vous devez disposer de 4 Go de RAM pour chaque cœur pour les cas d’usage de production.
Personnalisation du type de service
Le type de service peut être modifié en NodePort si vous le souhaitez. Un numéro de port aléatoire sera attribué.
Personnalisation du stockage
Vous pouvez personnaliser les classes de stockage en fonction de votre environnement. Si vous n’êtes pas sûr des classes de stockage disponibles, vous pouvez exécuter la commande kubectl get storageclass pour les afficher.
Le modèle a une valeur par défaut de default.
Par exemple
storage:
data:
volumes:
- className: default
Cet exemple signifie qu’il existe une classe de stockage nommée default, et non pas qu’une classe de stockage est utilisée par défaut. Vous pouvez également modifier la taille de votre stockage. Pour plus d'informations, consultez Configuration du stockage.
Création de l’instance gérée SQL
Maintenant que vous avez personnalisé le fichier YAML de l’instance gérée SQL, vous pouvez créer cette dernière en exécutant la commande suivante :
kubectl create -n <your target namespace> -f <path to your yaml file>
#Example
#kubectl create -n arc -f C:\arc-data-services\sqlmi.yaml
Surveillance de l’état de la création
La création de l’instance gérée SQL prendra quelques minutes. Vous pouvez superviser la progression dans une autre fenêtre de terminal avec les commandes suivantes :
Remarque
Les exemples de commandes ci-dessous supposent que vous avez créé une instance gérée SQL nommée sql1 et un espace de noms Kubernetes avec le nom arc. Si vous avez utilisé un autre nom pour l’espace de noms/l’instance gérée SQL, vous pouvez remplacer arc et sqlmi par ces noms.
kubectl get sqlmi/sql1 --namespace arc
kubectl get pods --namespace arc
Vous pouvez également vérifier l’état de la création de pods spécifiques. Exécutez kubectl describe pod .... Cette commande permet de résoudre tous les problèmes. Par exemple :
kubectl describe pod/<pod name> --namespace arc
#Example:
#kubectl describe pod/sql1-0 --namespace arc
Résoudre les problèmes de déploiement
Si vous rencontrez des problèmes avec le déploiement, consultez le Guide de résolution des problèmes.