Partager via

Déployer SQL Managed Instance activée par Azure Arc à l’aide des outils Kubernetes

  • Article

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.

Installer l’outil kubectl

Vue d’ensemble

Pour créer une instance SQL Managed Instance, vous devez :

  1. créer un secret Kubernetes pour stocker votre identifiant d’administrateur système et votre mot de passe en toute sécurité ;
  2. 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 coder en base64 votre nom d’utilisateur et mot de passe souhaités, ou vous pouvez utiliser des outils de 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.
  • Au moins 2 Go sont requis pour la requête de mémoire, le cas échéant.
  • 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.

Contenu connexe

Se connecter à SQL Managed Instance doté d’Azure Arc