Exposer des applications Kubernetes avec ingress-gce dans GKE

Vue d'ensemble

Lorsque nous travaillons avec Google Kubernetes Engine (GKE), nous n'avons pas nécessairement besoin de déployer un « contrôleur d'ingress » personnalisé pour exposer nos applications. Il en existe déjà un appelé ingress-gce qui s'exécute sur les nœuds maîtres du cluster.

Comme nous n’avons aucun contrôle sur les nœuds maîtres d’un cluster GKE, nous ne pouvons pas voir ce qu'ils exécutent et ne verrons donc pas les pods ingress-gce.

Lorsque nous créons des objets ingress sans configurations spécifiques indiquant pour quel « contrôleur d'ingress » ils sont créés, l'ingress-gce les inspectera et appliquera les règles qu'ils définissent.

Sachez qu'à chaque fois que vous créez un objet ingress traité avec succès par ingress-gce, un équilibreur de charge HTTP(S) Google Cloud (externe au cluster) est également créé.

Le trafic HTTP(S) arrivant à cet équilibreur de charge sera ensuite automatiquement transmis aux pods ingress-gce exécutés à l'intérieur du cluster.

Lorsqu'une valeur d'en-tête d'hôte de requête HTTP(S) (par exemple « www.hackerstack.org ») correspond à une règle ingress traitée par les pods ingress-gce, cette requête HTTP(S) est transmise à l'un des services internes du cluster tels que définis par la règle ingress.

Étant donné que nos pods d’applications sont accessibles via ces services internes du cluster, ils seront ensuite accessibles depuis l’extérieur du cluster via l’équilibreur de charge HTTP(S) externe.

Création de l'objet ingress

Voici le manifeste pour la création d'un objet « ingress » qui est censé être traité par le « contrôleur d'ingress » ingress-gce dans GKE :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  namespace: myapp
  annotations:
    # Use an already existing global static IP as the IP address of the HTTP/HTTPS
    # loadbalancer that will be created for this ingress object
    kubernetes.io/ingress.global-static-ip-name: "my-static-public-ip"
    # Use an already existing managed certificate for rules that use TLS
    networking.gke.io/managed-certificates: "my-managed-certificate"
    # Use the frontendconfig called 'redirect-http-to-https' to redirect http to https
    networking.gke.io/v1beta1.FrontendConfig: "redirect-http-to-https" 
spec:
  rules:
  - host: myapp.example.local
    http:
      paths:
      - backend:
          service:
            name: myapp
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
    secretName: "my-managed-certificate"

• Nous verrons ensuite comment créer le certificat TLS managé (renouvelé automatiquement) et le frontendconfig utilisés dans le manifeste de l'objet « ingress » et expliquerons quelques éléments à leur sujet.
• Concernant l'adresse IP statique globale, voici la documentation pour la créer : réservation d'adresse IP externe statique gcp
• Voici une liste des annotations liées à l'objet « ingress » que nous pouvons utiliser dans le manifeste pour des fonctionnalités supplémentaires annotations d'objets gce-ingress
• Pour plus d'informations sur tous les champs disponibles que nous pouvons utiliser dans le manifeste de l'objet « ingress », consultez Référence API Kubernetes Ingress v1
• Comme vous pouvez le voir dans le manifeste de l'objet « ingress », nous avons défini une règle pour les requêtes HTTP(S) avec un en-tête Host correspondant à « myapp.example.local ». La section « backend » définit un nom de service interne de cluster et un port sur lequel les requêtes correspondant à la règle seront transmises.
• Pour que cela fonctionne correctement, le service backend doit être de type « LoadBalancer ». Nous allons maintenant montrer le manifeste pour la création de ce service backend.

Création du service backend

• Le service backend sur lequel l'ingress-gce acheminera le trafic HTTP(S) éligible doit être de type « LoadBalancer » lors de l'utilisation de GKE (il ne peut pas être de type « ClusterIP » par exemple, qui est pris en charge par d'autres « contrôleurs d'ingress ».

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: myapp
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
spec:
  selector:
    app: myapp
  ports:
    - name: http
      port: 80           # port on which the service will be reachable
      targetPort: 8080   # backend pods port on which the associated service will forward resquests 
  type: LoadBalancer

• Voici une liste d'annotations liées à GKE gce-ingress que nous pouvons utiliser dans le manifeste du service backend pour des fonctionnalités supplémentaires : annotation-service-backend-gke-ingress-gce

Création du certificat managé

Voici le manifeste que nous utilisons pour créer le certificat TLS managé (renouvelé automatiquement) pour le nom de domaine public à partir duquel nos applications Kubernetes seront accessibles :

apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: "my-managed-certificate"
  namespace: myapp
spec:
  domains:
    - mydomain.example.local

Avant de créer l'objet de certificat géré, nous devons nous assurer que le nom de domaine pour lequel nous générons le certificat TLS pointe vers l'adresse IP publique (l'IP statique globale) de l'équilibreur de charge HTTP(S) externe du cluster que nous avons mentionné précédemment.

Une fois les prérequis remplis, le certificat TLS sera généré et disponible pour être utilisé par l'équilibreur de charge HTTP(S). Il sera automatiquement renouvelé avant expiration.

Frontendconfig et backendconfig

Frontendconfig et backendconfig sont des ressources personnalisées disponibles uniquement dans GKE. Elles peuvent être utilisées pour activer des fonctionnalités supplémentaires lors de l'utilisation d' ingress-gce (le « contrôleur d'ingress » par défaut dans GKE).

Frontendconfig

Lorsque nous activons certaines fonctionnalités de frontendconfig, elles sont disponibles pour tous les services backend définis dans les objets « ingress » et donc pour toutes les applications accessibles via ces services backend.

Voici un exemple de manifeste que nous utilisons pour créer des ressources frontendconfig :

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: redirect-http-to-https
  namespace: myapp
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: "302"

Cette ressource frontendconfig, une fois indiquée (nous verrons comment par la suite) dans le manifeste d'un objet 'ingress' dédié à être utilisé par le 'contrôleur d'ingress' ingress-gce, activera la redirection HTTP vers HTTPS pour tous les hôtes spécifiés dans les règles de cet objet ingress. Cela créera automatiquement une règle pour l'équilibreur de charge HTTP(S) externe du cluster associé au 'contrôleur d'ingress' ingress-gce afin d'effectuer la redirection.

En plus de la redirection HTTP vers HTTPS, il existe d'autres fonctionnalités « ingress » qui peuvent être activées via les ressources frontendconfig. Pour une liste complète, consultez la section « FrontendConfig » dans fonctionnalités de gke-gce-ingress.

Pour utiliser une ressource frontendconfig existante pour activer des fonctionnalités spécifiques, nous spécifions le nom de cette frontendconfig à l'intérieur du champ metadata.annotations du manifeste « ingress » comme suit :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  (...)
  annotations:
    (...)
    # Redirect HTTP to HTTPS
    networking.gke.io/v1beta1.FrontendConfig: "redirect-http-to-https" 
    (...)
spec:
  rules:
  - host: myapp.example.local
    (...)
  tls:
    secretName: "my-managed-certificate"

Backendconfig

Lorsque nous activons certaines fonctionnalités de backendconfig, elles sont disponibles pour les services backend spécifiques que nous choisissons et donc disponibles uniquement pour les applications accessibles via les services backend choisis.

Voici un exemple de manifeste que nous utilisons pour créer des ressources backendconfig :

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: myapp
  name: my-cloud-armor-rules
spec:
  securityPolicy:
    name: "cloud-armor-default" # an already existing cloud armor security policy

Cette configuration backend, une fois utilisée par un ou plusieurs des services backend des ressources « ingress », activera une politique de sécurité Google Cloud Armor sur ces services backend, par exemple pour restreindre l'accès uniquement à des adresses IP spécifiques ou bloquer certaines attaques d'applications Web bien connues.

En plus de l'activation des fonctionnalités Google Cloud Armor pour des backends « ingress » spécifiques, il existe d'autres fonctionnalités « ingress » qui peuvent être activées via les ressources backenconfig. Pour une liste complète, consultez la section « BackendConfig » dans fonctionnalités de gke-gce-ingress.

Pour utiliser une ressource backendconfig existante afin d'activer des fonctionnalités spécifiques pour les services backend d'ingress choisis, nous spécifions le nom de cette backendconfig à l'intérieur du champ metadata.annotations Le domaine des services backend choisis se manifeste comme suit :

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-cloud-armor-rules"}'
  (...)

C'est tout. Nous savons maintenant comment exposer publiquement nos applications Kubernetes dans GKE à l'aide du « contrôleur d'ingress » par défaut et utiliser les ressources personnalisées frontendconfig et backendconfig pour activer des fonctionnalités supplémentaires.