Distribuire un cluster Big Data nel cluster privato del servizio Azure Kubernetes (AKS)

  • Articolo

Importante

Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.

Questo articolo illustra come distribuire cluster Big Data di SQL Server nel cluster privato del servizio Azure Kubernetes (AKS). Questa configurazione supporta l'uso limitato di indirizzi IP pubblici nell'ambiente di rete aziendale.

Una distribuzione privata offre i vantaggi seguenti:

  • Uso limitato degli indirizzi IP pubblici
  • Il traffico di rete tra i server applicazioni e i pool di nodi del cluster rimane solo sulla rete privata
  • Con la configurazione personalizzata, il traffico in uscita deve soddisfare requisiti specifici

Questo articolo illustra come usare un cluster privato AKS per limitare l'uso di un indirizzo IP pubblico quando sono applicate le stringhe di sicurezza corrispondenti.

Distribuire un cluster Big Data privato con un cluster privato del servizio Azure Kubernetes

Per iniziare, creare un cluster privato AKS per assicurarsi che il traffico di rete tra il server API e i pool di nodi risieda solo sulla rete privata. In un cluster privato AKS il piano di controllo o il server API dispone di indirizzi IP interni.

Questa sezione mostra come distribuire un cluster Big Data nel cluster privato del servizio Azure Kubernetes con gestione di rete avanzata (CNI).

Creare un cluster privato AKS con gestione di rete avanzata


export REGION_NAME=<your Azure region >
export RESOURCE_GROUP=< your resource group name >
export SUBNET_NAME=aks-subnet
export VNET_NAME=bdc-vnet
export AKS_NAME=< your aks private cluster name >
 
az group create -n $RESOURCE_GROUP -l $REGION_NAME
 
az network vnet create \
    --resource-group $RESOURCE_GROUP \
    --location $REGION_NAME \
    --name $VNET_NAME \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name $SUBNET_NAME \
    --subnet-prefix 10.1.0.0/16
 

SUBNET_ID=$(az network vnet subnet show \
    --resource-group $RESOURCE_GROUP \
    --vnet-name $VNET_NAME \
    --name $SUBNET_NAME \
    --query id -o tsv)
 
echo $SUBNET_ID
## will be displayed something similar as the following: 
/subscriptions/xxxx-xxxx-xxx-xxxx-xxxxxxxx/resourceGroups/your-bdc-rg/providers/Microsoft.Network/virtualNetworks/your-aks-vnet/subnets/your-aks-subnet

Creare un cluster privato AKS con gestione di rete avanzata (CNI)

Per eseguire il passaggio successivo, è necessario effettuare il provisioning di un cluster AKS con Load Balancer Standard, con la funzionalità cluster privato abilitata. Il comando è simile al seguente:

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $AKS_NAME \
    --load-balancer-sku standard \
    --enable-private-cluster \
    --network-plugin azure \
    --vnet-subnet-id $SUBNET_ID \
    --docker-bridge-address 172.17.0.1/16 \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --node-vm-size Standard_D13_v2 \
    --node-count 2 \
    --generate-ssh-keys

Al termine di una distribuzione corretta, passando al gruppo di risorse <MC_yourakscluster> si noterà che kube-apiserver è un endpoint privato. Vedere ad esempio la sezione seguente.

Connettersi a un cluster AKS

az aks get-credentials -n $AKS_NAME -g $RESOURCE_GROUP

Creare il profilo di distribuzione del cluster Big Data

Dopo la connessione a un cluster AKS è possibile iniziare a distribuire il cluster Big Data, preparare la variabile di ambiente e avviare una distribuzione:

azdata bdc config init --source aks-dev-test --target private-bdc-aks --force

Generare e configurare il profilo di distribuzione personalizzato del cluster Big Data:

azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.docker.imageTag=2019-CU6-ubuntu-16.04"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.storage.data.className=default"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.storage.logs.className=default"

azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.endpoints[1].serviceType=NodePort"

azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.master.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].serviceType=NodePort"

Distribuire un cluster Big Data SQL Server privato con disponibilità elevata

Se si distribuisce un cluster Big Data di SQL Server con disponibilità elevata, si userà il profilo di distribuzione aks-dev-test-ha. Al termine di una distribuzione corretta, è possibile usare lo stesso comando kubectl get svc per creare un servizio master-secondary-svc aggiuntivo. È necessario configurare ServiceType come NodePort. Gli altri passaggi sono simili a quelli indicati nella sezione precedente.

Nell'esempio seguente ServiceType viene impostato su NodePort.

azdata bdc config replace -c private-bdc-aks /bdc.json -j "$.spec.resources.master.spec.endpoints[1].serviceType=NodePort"

Distribuire un cluster Big Data in un cluster privato AKS

export AZDATA_USERNAME=<your bdcadmin username>
export AZDATA_PASSWORD=< your bdcadmin password>

azdata bdc create --config-profile private-bdc-aks --accept-eula yes

Controllare lo stato della distribuzione

La distribuzione può richiedere alcuni minuti ed è possibile usare il comando seguente per verificarne lo stato:

kubectl get pods -n mssql-cluster -w

Verificare lo stato del servizio

Usare il comando seguente per verificare lo stato dei servizi. Verificare che siano tutti integri e senza IP esterni:

kubectl get services -n mssql-cluster

Vedere come gestire il cluster Big Data nel cluster privato del servizio Azure Kubernetes. Il passaggio successivo consiste nel connettersi a un cluster Big Data di SQL Server.

Per questo scenario, vedere gli script di automazione nel repository di esempi SQL Server su GitHub.

Contenuto correlato