Distribuire Istanza gestita di SQL abilitato da Azure Arc usando gli strumenti kubernetes

  • Articolo

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

Prerequisiti

È necessario aver già creato un titolare del trattamento dei dati.

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

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 un Istanza gestita di SQL risorsa personalizzata in base alla definizione della SqlManagedInstance risorsa personalizzata

Definire entrambi questi elementi in un file yaml.

Creare un file yaml

Usare il file yaml del 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 l'linting per i file yaml.

Nota

A partire dalla versione di febbraio 2022, ReadWriteMany è necessario specificare la classe di archiviazione con supporto per 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 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 dell'account di accesso e della password

Un segreto Kubernetes viene archiviato come stringa con codifica Base64, uno per il nome utente e uno per la password. Sarà necessario codificare base64 come account di accesso e password dell'amministratore di sistema e inserirli nel percorso segnaposto in data.password e data.username. Non includere i < simboli e > forniti nel modello.

Nota

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

È possibile usare uno strumento online per codificare base64 il nome utente e la password desiderati oppure usare gli strumenti dell'interfaccia della riga di comando a seconda della 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 per sql1 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 in modo che 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 di RAM e core e le richieste, in base alle esigenze.

Nota

Altre informazioni sulla governance delle risorse kubernetes sono disponibili.

Requisiti per i limiti e le richieste delle risorse:

  • Il valore limite di core è necessario a scopo di fatturazione.
  • Il resto delle richieste e dei limiti delle risorse è facoltativo.
  • Il limite di core e la richiesta devono essere un valore intero positivo, se specificato.
  • Per la richiesta di core è necessario almeno 1 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

Il tipo di servizio può essere modificato in NodePort, se necessario. Verrà assegnato un numero di porta casuale.

Personalizzazione dell'archiviazione

È possibile personalizzare le classi di archiviazione per l'archiviazione in modo che corrispondano all'ambiente. Se non si è certi delle classi di archiviazione disponibili, eseguire il comando kubectl get storageclass per visualizzarle.

Il modello ha un valore predefinito .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 di creazione

Il completamento della creazione dell'istanza gestita di SQL richiederà alcuni minuti. È possibile monitorare lo stato di avanzamento 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 diverso di spazio dei nomi/istanza gestita di SQL, è possibile sostituire arc e sqlmi con i nomi.

kubectl get sqlmi/sql1 --namespace arc

kubectl get pods --namespace arc

È anche possibile controllare lo stato di 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

Risolvere i problemi di distribuzione

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

Contenuto correlato

Connessione a Istanza gestita di SQL abilitato da Azure Arc