Condividi tramite


Distribuire l’Istanza gestita di SQL abilitata da Azure Arc usando gli strumenti kubernetes

Questo articolo illustra come distribuire Istanza gestita di SQL di Azure per Azure Arc con gli strumenti Kubernetes.

Prerequisiti

È necessario aver già creato un controller dei dati.

Per creare un'istanza gestita di SQL usando gli strumenti Kubernetes, è necessario che gli strumenti Kubernetes siano installati. Gli esempi riportati in questo articolo useranno kubectl, tuttavia è possibile usare approcci simili con altri strumenti Kubernetes, ad esempio il dashboard di Kubernetes, oc o helm, se si ha familiarità con questi strumenti e con i file yaml/json di Kubernetes.

Installare lo strumento kubectl

Panoramica

Per creare un'istanza gestita di SQL, è necessario:

  1. Creare un segreto Kubernetes per archiviare in modo sicuro l'account di accesso e la password dell'amministratore di sistema
  2. Creare una risorsa personalizzata di Istanza gestita di SQL in base alla definizione di risorsa personalizzata SqlManagedInstance

Definire entrambi questi elementi in un file yaml.

Creare un file yaml

Usare il file yaml modello come punto di partenza per creare il proprio file yaml dell'istanza gestita di SQL personalizzata. Scaricare questo file nel computer locale e aprirlo in un editor di testo. Usare un editor di testo come VS Code che supporta l'evidenziazione della sintassi e il linting per i file yaml.

Nota

A partire dalla versione di febbraio 2022, è necessario specificare ReadWriteMany (RWX) per i backup. Altre informazioni sulle modalità di accesso. Se non viene specificata alcuna classe di archiviazione per i backup, viene usata la classe di archiviazione predefinita in Kubernetes. Se il valore predefinito non è in grado di supportare RWX, l'installazione di Istanza gestita di SQL potrebbe non riuscire.

File yaml di esempio

Vedere l'esempio seguente di un file 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

Personalizzazione di ID accesso e password

Un segreto Kubernetes viene archiviato come stringa con codifica in Base 64, una per il nome utente e una per la password. Sarà necessario codificare in Base 64 un ID accesso e una password amministratore di sistema e inserirli nel percorso segnaposto in data.password e data.username. Non includere i simboli < e > indicati nel modello.

Nota

Per una sicurezza ottimale, l'utilizzo del valore sa non è consentito per l'account di accesso. Seguire i criteri di complessità delle password.

È possibile avvalersi di uno strumento online per la codifica in Base 64 del nome utente e della password desiderati, oppure degli strumenti dell'interfaccia della riga di comando, in base alla piattaforma.

PowerShell

[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('<your string to encode here>'))

#Example
#[Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('example'))

Linux/macOS

echo -n '<your string to encode here>' | base64

#Example
# echo -n 'example' | base64

Personalizzazione del nome

Il modello ha un valore di sql1 per l'attributo name. È possibile modificare questo valore, ma deve includere caratteri che seguono gli standard di denominazione DNS. È anche necessario modificare il nome del segreto affinché corrisponda. Ad esempio, se si modifica il nome dell'istanza gestita di SQL in sql2, è necessario modificare il nome del segreto da sql1-login-secret a sql2-login-secret

Personalizzazione dei requisiti delle risorse

È possibile modificare i requisiti delle risorse, ovvero i limiti e le richieste RAM e core in base alle esigenze.

Nota

Sono disponibili altre informazioni sulla governance delle risorse Kubernetes.

Requisiti per i limiti e le richieste di risorse:

  • Il valore limite di core è obbligatorio per motivi di fatturazione.
  • La parte restante delle richieste e dei limiti delle risorse è facoltativa.
  • Il limite di core e richieste deve essere un valore intero positivo, se specificato.
  • È richiesto un minimo di 1 core per la richiesta di core, se specificato.
  • Il formato del valore di memoria segue la notazione Kubernetes.
  • Per la richiesta di memoria è necessario almeno 2 GB, se specificato.
  • Come linea guida generale, è necessario avere 4 GB di RAM per ogni 1 core per i casi d'uso di produzione.

Personalizzazione del tipo di servizio

Se si desidera, il tipo di servizio può essere modificato in NodePort. Verrà assegnato un numero di porta casuale.

Personalizzazione dell'archiviazione

È possibile personalizzare le classi di archiviazione affinché l'archiviazione corrisponda all'ambiente. Se si hanno dubbi sulle classi di archiviazione disponibili, eseguire il comando kubectl get storageclass per visualizzarle.

Il modello ha un valore predefinito di default.

Ad esempio:

storage:
    data:
      volumes:
      - className: default 

Questo esempio indica che è presente una classe di archiviazione denominata default, non che sia presente una classe di archiviazione predefinita. Facoltativamente, è anche possibile modificare le dimensioni dello spazio di archiviazione. Per altre informazioni, vedere Configurazione dell'archiviazione.

Creazione dell'istanza gestita di SQL.

Dopo aver personalizzato il file yaml dell'istanza gestita di SQL, è possibile creare l'istanza gestita di SQL eseguendo il comando seguente:

kubectl create -n <your target namespace> -f <path to your yaml file>

#Example
#kubectl create -n arc -f C:\arc-data-services\sqlmi.yaml

Monitoraggio dello stato della creazione

Il completamento della creazione dell'istanza gestita di SQL richiederà alcuni minuti. Lo stato di avanzamento può essere monitorato in un'altra finestra del terminale con i comandi seguenti:

Nota

I comandi di esempio seguenti presuppongono che sia stata creata un'istanza gestita di SQL denominata sql1 e uno spazio dei nomi Kubernetes con il nome arc. Se è stato usato un nome di spazio dei nomi/istanza gestita di SQL diverso, è possibile sostituire arc e sqlmi con i nomi.

kubectl get sqlmi/sql1 --namespace arc
kubectl get pods --namespace arc

È anche possibile controllare lo stato della creazione di qualsiasi pod specifico. Eseguire kubectl describe pod .... Usare questo comando per risolvere eventuali problemi. Ad esempio:

kubectl describe pod/<pod name> --namespace arc

#Example:
#kubectl describe pod/sql1-0 --namespace arc

Risorse che consentono di risolvere i problemi di distribuzione

Se si verificano problemi con la distribuzione, vedere la guida alla risoluzione dei problemi.

Connettersi all'Istanza gestita di SQL abilitata da Azure Arc