Chemin de mises à niveau pour AppScan 360° : Accès à l'API de passerelle

Présentation

La migration d'une configuration d'accès Kubernetes héritée vers un modèle basé sur une passerelle (par exemple, API de passerelle Istio) offre une flexibilité de routage améliorée, une prise en charge native du trafic multicluster/multiprotocole et une intégration supérieure avec les fonctions de maillage de service.

Ce document décrit les stratégies recommandées pour la migration en fonction du type de cluster, de la disponibilité de l'équilibreur de charge et des exigences opérationnelles.

1. Stratégies de mise à niveau

Approche A : Mise à niveau propre

Scénario : L'accès n'est plus nécessaire pour les charges de travail.

Processus : 1. Déposez le contrôleur d'accès existant.

2. Déployez le contrôleur de passerelle sur les ports par défaut (80/443) à l'aide d'un équilibreur de charge (MetalLB ou SLVLB).

3. Vérifiez que le service est configuré avec les adresses IP externes correctes.

Approche B : Approche secondaire/de coexistence

Scénario : Les charges de travail existantes dépendent toujours du contrôleur d'accès hérité.
Processus :
1. Conservez le contrôleur d'accès.
2. Déployez le contrôleur de passerelle sur des ports personnalisés pour éviter les conflits.
3. Planifiez la suppression éventuelle de l'accès une fois la migration validée.

2. Scénarios de déploiement (approche de coexistence)

Scénario 1 : Passerelle avec accès comme déploiement

Contexte : Le cluster exécute actuellement un contrôleur d'accès en tant que déploiement standard.
Approche : Déployez le contrôleur de passerelle (API de passerelle Istio) en tant que déploiement séparé à l'aide de MetalLB pour fournir des pools IP externes.
Avantages : Permet la coexistence ; routage simplifié via MetalLB.
Inconvénients : Nécessite une gestion minutieuse des ports (en évitant les conflits 80/443).

Scénario 2 : Passerelle sur K3s avec SLVLB (Klipper)

Contexte : Environnement K3S avec équilibreur de charge de service (Klipper) activé.
Approche : Installez le contrôleur de passerelle et définissez le type de service sur LoadBalancer. SLVLB attribuera automatiquement des adresses IP de nœud.
Avantages : Configuration minimale ; fonctionne immédiatement pour K3s.
Inconvénients : L'attribution d'adresses IP est dynamique ; nécessite des règles de pare-feu pour les ports de nœud.

3. Configuration de port personnalisée (mode de coexistence)

Lorsqu'un contrôleur d'accès existant occupe les ports 80 et 443, la passerelle créée par ASCP doit être configurée avec des ports d'écoute personnalisés.

Configuration via singular-singular.clusterkit.yaml

Les dispositifs d'écoute Gateway peuvent être définis avec des ports personnalisés dans la configuration YAML.

Configuration via singular-singular.clusterkit.properties

Les propriétés suivantes définissent les ports d'écoute personnalisés :

CK_GATEWAY_TLS_PASSTHROUGH_LISTENER_PORT_NUMBER : Port passe-système TLS K8s désigné par le client.

CK_GATEWAY_HTTPS_LISTENER_PORT_NUMBER : Port HTTPS K8s désigné par le client.

CK_GATEWAY_HTTP_LISTENER_PORT_NUMBER : Port HTTP K8s désigné par le client.

4. Matrice de comparaison des stratégies


Approche	Type de cluster	Equilibreur de charge	Avantages	Inconvénients
K3s avec SLVLB	K3s	SLVLB	Configuration minimale ; attribution d'adresses IP automatique	Adresses IP dynamiques ; accès au nœud requis
Coexistence	N'importe lequel	N'importe lequel	Aucune perturbation ; migration progressive	Nécessite des ports personnalisés
Approche propre	N'importe lequel	Recommandé	Architecture la plus simple ; ports par défaut	Nécessite la suppression de l'accès
Passerelle + MetalLB	N'importe lequel	MetalLB	Attribution d'adresses IP contrôlée	Nécessite une configuration MetalLB

5. Propriétés de passerelle requises

Assurez-vous que les variables suivantes sont définies dans votre fichier de propriétés :


CK_GATEWAY_CLASS_NAME='<GATEWAY_CLASS_NAME>'
CK_GATEWAY_PRIVATE_HOST_DOMAIN='<AS360_DOMAIN>'
CK_GATEWAY_PRIVATE_HOST_SUBDOMAIN='<AS360_SUBDOMAIN>'

6. Procédure d'installation (passerelle Istio)

Remarque : Ces étapes ont été validées spécifiquement pour la version de passerelle Istio.

Etape 1 : Installer les CRD d'API de passerelle

Les CRD doivent être installées avant l'installation de la mise en œuvre du contrôleur de passerelle. https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.4.0


GATEWAY_API_VERSION="v1.4.0"

kubectl apply -f 
https://github.com/kubernetes-sigs/gateway-api/releases/download/${G
ATEWAY_API_VERSION}/standard-install.yaml
kubectl apply -f 
https://github.com/kubernetes-sigs/gateway-api/releases/download/${G
ATEWAY_API_VERSION}/experimental-install.yaml

Vérifiez l'installation :


kubectl get crds | grep gateway.networking.k8s.io

Etape 2 : Ajouter le référentiel Helm Istio


helm repo add istio 
https://istio-release.storage.googleapis.com/charts || true
helm repo update

Etape 3 : Installer la base Istio (CRD)


kubectl create namespace istio-system --dry-run=client -o yaml | 
kubectl apply -f -
helm install istio-base istio/base -n istio-system

Vérifiez l'installation :


helm status istio-base -n istio-system

Etape 4 : Installer Istiod (plan de contrôle)

Créez un fichier nommé istiod-values.yaml :


global:
 proxy:
   autoInject: disabled

resources:
 requests:
   cpu: 10m
   memory: 64Mi
 limits:
   cpu: 100m
   memory: 256Mi

autoscaleEnabled: false

env:
 PILOT_ENABLE_ALPHA_GATEWAY_API: "true"

telemetry:
 enabled: false

Installez à l'aide de Helm :



helm install istiod istio/istiod \
 -n istio-system \
 -f istiod-values.yaml

Attendez que le système soit prêt :


kubectl rollout status deployment/istiod -n istio-system 
--timeout=120s

Etape 5 : Vérification finale


# Check Istio pods
kubectl get pods -n istio-system

# Verify GatewayClass resource
kubectl get gatewayclass

Lorsque l'installation a réussi, Istio GatewayClass est répertorié comme disponible.