Hello,
Dans cet article, je vous présenter comment déployer un cluster AKS privé. Au moment ou j’écris cet article cette fonctionnalité est encore en « public preview ».
Au sein d’un cluster AKS traditionnel le « control plane » (API Master) est exposé publiquement. Il possible de restreindre l’accès, comme expliqué dans cet article: AKS | Restreindre l’accès a API Server
Désormais il est possible d’avoir une connexion privé direct vers l’API Master avec un « Private Link« . Plus concrètement il est désormais plus nécessaire d’avoir une adresse ip publique entre votre node pool et l’API Master.
Pour le moment cette fonctionnalité est disponible uniquement dans les régions suivantes:
- West US
- West US 2
- East US 2
- Canada Central
- North Europe
- West Europe
- Australia East
## Requirements
az extension update --name aks-preview
az extension list
az feature register --name AKSPrivateLinkPreview --namespace Microsoft.ContainerService
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AKSPrivateLinkPreview')].{Name:name,State:properties.state}"
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.Network
az feature register --name PodSecurityPolicyPreview --namespace Microsoft.ContainerService
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSecurityPolicyPreview')].{Name:name,State:properties.state}"
az feature register --name MultiAgentpoolPreview --namespace Microsoft.ContainerService
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/MultiAgentpoolPreview')].{Name:name,State:properties.state}"
az feature register --name VMSSPreview --namespace Microsoft.ContainerService
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/VMSSPreview')].{Name:name,State:properties.state}"
az feature register --name PodSecurityPolicyPreview --namespace Microsoft.ContainerService
az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSecurityPolicyPreview')].{Name:name,State:properties.state}"
## Create a resource group
RG_NAME=aksprivate
az group create --name $RG_NAME --location canadacentral
## Last Kubernetes version for a specific region
VERSION=$(az aks get-versions -l eastus --query 'orchestrators[-1].orchestratorVersion' -o tsv)
## Create a virtual network and subnet
az network vnet create \
--resource-group $RG_NAME \
--name myVnet \
--address-prefixes 10.0.0.0/8 \
--subnet-name myAKSSubnet \
--subnet-prefix 10.240.0.0/16
## Create a service principal and read in the application ID
SP_ID_PASSWORD=$(az ad sp create-for-rbac --skip-assignment --query [appId,password] -o tsv)
SP_ID=$(echo ${SP_ID_PASSWORD} | sed -e 's/ .*//g')
SP_PASSWORD=$(echo ${SP_ID_PASSWORD} | sed -e 's/.* //g')
unset SP_ID_PASSWORD
## Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15
## Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RG_NAME --name myVnet --query id -o tsv)
## Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee 458e9c24-b6c2-4c32-88df-28bacb890a22 --scope $VNET_ID --role Contributor
## Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RG_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)
## Create AKS Private Cluster
CLUSTER_NAME=aksmaxpriv
az aks create \
--resource-group $RG_NAME \
--name $CLUSTER_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 \
--kubernetes-version $VERSION \
--generate-ssh-keys \
--enable-vmss \
--enable-cluster-autoscaler \
--min-count 1 \
--max-count 3 \
--service-principal $SP_ID \
--client-secret $SP_PASSWORD
- Aucune prise en charge des nœuds virtuels dans un cluster privé pour faire tourner des instances ACI privées dans un Azure VNET privé
- Aucune prise en charge de l’intégration Azure DevOps prête à l’emploi avec des clusters privés
- Si les clients doivent activer ACR pour fonctionner avec des AKS privés, le VNET de l’ACR devra être comparé avec le cluster d’agents VNET
- Pas de prise en charge actuelle pour Azure Dev Spaces
- Pas de prise en charge pour convertir les clusters AKS existants en clusters privés
- La suppression ou la modification du point de terminaison privé dans le sous-réseau client entraînera l’arrêt du fonctionnement du cluster
- Azure Monitor pour les conteneurs « Live Data » n’est pas actuellement pris en charge.
Maxime.
