Migrer les flux entrants vers l’API de passerelle

ThingPark Enterprise 8.1.2 introduit la prise en charge de l’API de passerelle pour les flux entrants. La prise en charge de l’ingress est dépréciée en même temps et sera supprimée avec la version 9.0.

Comme pour l’architecture Ingress héritée, les flux entrants de l’API et des passerelles sont tous deux routés par un équilibrageur de charge unique

La migration est effectuée en déployant d’abord la passerelle et l’équilibreur de charge correspondant, puis en mettant en place le répartiteur de charge. Le basculement vers ce nouveau répartiteur de charge se fait en mettant à jour l’entrée DNS pour qu’elle pointe vers la (les) nouvelle(s) adresse(s) IP.

Prérequis pour activer l’API de passerelle

Le déploiement ThingPark Enterprise nécessite le déploiement du plan de contrôle Istio et de la définition de ressource personnalisée Custom Resource Definition de l’API de passerelle

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm upgrade -i istio-base istio/base -n istio-system --version 1.30.2 --set defaultRevision=default --create-namespace
helm upgrade -i istiod istio/istiod -n istio-system --version 1.30.2 --wait -f values-istiod.yaml
kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.0/experimental-install.yaml

information

Le fichier de configuration values-istiod.yaml se trouve dans le dépôt de configuration avec les fichiers de personnalisation (dossier examples/customization)

Activer l’installation de la passerelle d’ingress pour le déploiement dans le fichier values-thingpark-stack-all.yaml

global:
  gatewayApi:
    enabled: true
# If the letsencrypt issuer is used, the thingpark-application-controller chart must be updated to configure cert-manager
cert-manager:
  config:
    enableGatewayAPI: true

Configurer la passerelle pour activer l’intégration avec l’équilibreur de charge dans l’infrastructure ciblée (exemple pour Azure)

global:
  gatewayApi:
    annotations:
        service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path: /healthz/ready
        service.beta.kubernetes.io/port_80_health-probe_port: "15021"
        service.beta.kubernetes.io/port_443_health-probe_port: "15021"
        service.beta.kubernetes.io/port_443_health-probe_protocol: HTTP
        service.beta.kubernetes.io/port_4443_health-probe_port: "15021"
        service.beta.kubernetes.io/port_3001_health-probe_port: "15021"
        service.beta.kubernetes.io/port_3101_health-probe_port: "15021"
        service.beta.kubernetes.io/port_3002_health-probe_port: "15021"
        service.beta.kubernetes.io/port_2022_health-probe_port: "15021"
        sidecar.istio.io/logLevel: info

Déploiement du point de terminaison de l’API de passerelle

L’étape suivante déploiera la passerelle en parallèle du contrôleur nginx-ingress. L’installation déploiera un nouvel équilibreur de charge exposant à la fois l’API et les passerelles.

• Mettre à jour le chart thingpark-application-controllers avec la nouvelle configuration

helm upgrade -i tpe-controllers -n $NAMESPACE \
  actility/thingpark-application-controllers --version $THINGPARK_APPLICATION_CONTROLLERS_VERSION \
  -f  values-thingpark-stack-all.yaml

• Mettre à jour le chart thingpark-enterprise en utilisant votre personnalisation

helm upgrade -i tpe --debug --timeout 20m -n $NAMESPACE \
  actility/thingpark-enterprise --version $THINGPARK_ENTERPRISE_VERSION \
  -f  values-thingpark-stack-all.yaml

Basculement de l’API et des passerelles

Reconfigurer l’entrée DNS utilisée dans .Values.global.dnsHostname pour qu’elle pointe vers le nouvel équilibreur de charge.

Désactiver le contrôleur ingress-nginx

ingress-nginx:
  enabled: false

helm upgrade -i tpe-controllers -n $NAMESPACE \
  actility/thingpark-application-controllers --version $THINGPARK_APPLICATION_CONTROLLERS_VERSION \
  -f  values-thingpark-stack-all.yaml

Les passerelles ne se reconnecteront pas automatiquement tant que le contrôleur d’ingress n’est pas désactivé