Activer la prise en charge de plusieurs espaces de noms dans un cluster AKS en utilisant AGIC
Les espaces de noms Kubernetes permettent de partitionner un cluster Kubernetes et de l’allouer à des sous-groupes d’une équipe plus grande. Ces sous-groupes peuvent ensuite déployer et gérer l’infrastructure avec des contrôles plus précis des ressources, de la sécurité et de la configuration. Kubernetes permet de définir indépendamment une ou plusieurs ressources d’entrée au sein de chaque espace de noms.
À partir de la version 0.7, le Contrôleur d’entrée Azure Application Gateway Kubernetes (AGIC, Application Gateway Ingress Controller) peut observer plusieurs espaces de noms et en ingérer les événements. Si un administrateur AKS (Azure Kubernetes Service) décide d’utiliser Azure Application Gateway comme entrée, tous les espaces de noms utilisent le même déploiement d’Application Gateway. Une seule installation d’AGIC surveille les espaces de noms accessibles et configure le déploiement Application Gateway associé.
La version 0.7 d’AGIC continue d’observer exclusivement l’espace de noms default
, sauf si vous le remplacez explicitement par un ou plusieurs espaces de noms différents dans la configuration Helm.
Conseil
Envisagez une Passerelle d’application pour conteneurs pour votre solution d’entrée Kubernetes.
Activer la prise en charge de plusieurs espaces de noms
Modifiez le fichier helm-config.yaml de l’une des manières suivantes :
- Supprimez entièrement la clé
watchNamespace
du fichier helm-config.yaml. AGIC observe tous les espaces de noms. - Définissez
watchNamespace
sur une chaîne vide. AGIC observe tous les espaces de noms. - Ajoutez plusieurs espaces de noms, séparés par une virgule (par exemple,
watchNamespace: default,secondNamespace
). AGIC observe exclusivement ces espaces de noms.
- Supprimez entièrement la clé
Appliquez les modifications du modèle Helm en exécutant
helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure
.
Une fois que vous avez déployé AGIC avec la capacité d’observer plusieurs espaces de noms, celui-ci effectue les actions suivantes :
- Répertorie les ressources d’entrée de tous les espaces de noms accessibles
- Filtre les ressources d’entrée annotées avec
kubernetes.io/ingress.class: azure/application-gateway
- Compose une configuration Application Gateway combinée
- Applique la configuration au déploiement Application Gateway associé via Azure Resource Manager
Gérer les configurations conflictuelles
Des ressources d’entrée à plusieurs espaces de noms peuvent demander à AGIC de créer des configurations conflictuelles pour un seul déploiement Application Gateway. Autrement dit, deux entrées pourraient revendiquer le même domaine.
En haut de la hiérarchie, AGIC pourrait créer des écouteurs (adresse IP, port et hôte) et des règles d’acheminement (écouteur de liaison, pool de back-ends et paramètres HTTP). Plusieurs espaces de noms et entrées pourraient les partager.
À l’inverse, AGIC pourrait créer des chemins d’accès, des pools de back-ends, des paramètres HTTP et des certificats TLS pour un seul espace de noms et supprimer les doublons.
Par exemple, envisagez les ressources d’entrée en double suivantes qui sont définies dans les espaces de noms staging
et production
pour www.contoso.com
:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: websocket-ingress
namespace: staging
annotations:
kubernetes.io/ingress.class: azure/application-gateway
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
serviceName: web-service
servicePort: 80
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: websocket-ingress
namespace: production
annotations:
kubernetes.io/ingress.class: azure/application-gateway
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
serviceName: web-service
servicePort: 80
Bien que les deux ressources d’entrée exigent que le trafic pour www.contoso.com
soit acheminé vers les espaces de noms Kubernetes respectifs, un seul serveur principal peut fournir le trafic. AGIC crée une configuration sur la base de la « première entrée, première sortie » pour l’une des ressources. Si deux ressources d’entrée sont créées en même temps, la priorité va à la première selon l’ordre alphabétique. En fonction de cette propriété, AGIC crée les paramètres pour l’entrée production
. Application Gateway est configuré avec les ressources suivantes :
- Écouteur :
fl-www.contoso.com-80
- Règle d’acheminement :
rr-www.contoso.com-80
- Pool de back-ends :
pool-production-contoso-web-service-80-bp-80
- Paramètres HTTP :
bp-production-contoso-web-service-80-80-websocket-ingress
- Sonde d’intégrité :
pb-production-contoso-web-service-80-websocket-ingress
Remarque
À l’exception de l’écouteur et de la règle d’acheminement, les ressources Application Gateway créées incluent le nom de l’espace de noms (production
) pour lequel AGIC les a créées.
Si les deux ressources d’entrée sont introduites dans le cluster AKS à des moments différents, il est probable qu’AGIC se retrouve dans un scénario où il reconfigure Application Gateway et réachemine le trafic de namespace-B
vers namespace-A
.
Par exemple, si vous ajoutez staging
en premier, AGIC configure Application Gateway pour acheminer le trafic vers le pool de back-ends intermédiaire. À un stade ultérieur, l’introduction de production
entrée entraîne la réprogrammation d’Application Gateway par AGIC, qui commence à router le trafic vers le pool principal production
.
Limiter l’accès aux espaces de noms
Par défaut, AGIC configure Application Gateway en fonction des entrées annotées dans n’importe quel espace de noms. Si vous souhaitez limiter ce comportement, vous disposez des options suivantes :
- Limitez les espaces de noms en définissant explicitement ceux qu’AGIC doit observer via la clé YAML
watchNamespace
dans helm-config.yaml. - Utilisez les objets Role et RoleBinding pour limiter AGIC à des espaces de noms spécifiques.
Exemple de fichier de configuration Helm
# This file contains the essential configs for the ingress controller helm chart
# Verbosity level of the App Gateway Ingress Controller
verbosityLevel: 3
################################################################################
# Specify which application gateway the ingress controller manages
#
appgw:
subscriptionId: <subscriptionId>
resourceGroup: <resourceGroupName>
name: <applicationGatewayName>
# Setting appgw.shared to "true" creates an AzureIngressProhibitedTarget CRD.
# This prohibits AGIC from applying config for any host/path.
# Use "kubectl get AzureIngressProhibitedTargets" to view and change this.
shared: false
################################################################################
# Specify which kubernetes namespace the ingress controller watches
# Default value is "default"
# Leaving this variable out or setting it to blank or empty string would
# result in Ingress Controller observing all accessible namespaces.
#
# kubernetes:
# watchNamespace: <namespace>
################################################################################
# Specify the authentication with Azure Resource Manager
#
# Two authentication methods are available:
# - Option 1: AAD-Pod-Identity (https://github.com/Azure/aad-pod-identity)
armAuth:
type: aadPodIdentity
identityResourceID: <identityResourceId>
identityClientID: <identityClientId>
## Alternatively you can use Service Principal credentials
# armAuth:
# type: servicePrincipal
# secretJSON: <<Generate this value with: "az ad sp create-for-rbac --subscription <subscription-uuid> --role Contributor --sdk-auth | base64 -w0" >>
################################################################################
# Specify if the cluster is Kubernetes RBAC enabled or not
rbac:
enabled: false # true/false
# Specify aks cluster related information. THIS IS BEING DEPRECATED.
aksClusterConfiguration:
apiServerAddress: <aks-api-server-address>