Traefik Ingress dans IBM Cloud

Ingress rend les services de votre cluster accessibles depuis un réseau public ou privé. Il transmet les requêtes à vos applications et gère les accès externes en fonction des règles de routage que vous configurez.

Lorsque vous provisionnez un cluster IBM Cloud Kubernetes Service, vous pouvez activer un ou plusieurs contrôleurs Ingress basés sur Traefik. IBM fournit les composants nécessaires à l'utilisation du contrôleur Ingress. Pour définir la manière dont les composants interagissent, créez des ressources Ingress.

Pour plus d'informations sur Ingress d' Kubernetes, consultez la documentation disponible à l'adresse Kubernetes.

IBM- composants Ingress fournis

Lorsque vous créez un cluster, IBM met à votre disposition les composants nécessaires à l'utilisation d'Ingress. Dans votre ressource Ingress, vous précisez comment ces composants sont utilisés.

Ingress domain
Classe d'Ingress
Des équilibreurs de charge d'application (ALB)
Certificat TLS

Ingress domain

Le domaine Ingress par défaut génère une adresse URL unique pour chaque application de votre cluster. Ce domaine est référencé par les adresses IP de tous les ALB de votre cluster.

Lorsque vous créez un cluster, un sous-domaine Ingress unique est automatiquement créé et enregistré comme domaine par défaut. Vous pouvez remplacer le domaine par défaut par n'importe quel domaine existant dans votre cluster.

Les ALB privés ne font pas référence au sous-domaine Ingress fourni par IBM; ils nécessitent en revanche un domaine personnalisé.

Vous pouvez également créer ou ajouter votre propre nom de domaine enregistré auprès du fournisseur de noms de domaine interne d' IBM Cloud ou auprès d'un fournisseur externe IBM Cloud Internet Services.

Le sous-domaine est enregistré au format suivant.

<cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud

Le tableau suivant décrit chaque partie du sous-domaine.

Description du format de sous-domaine Ingress
Composant de sous-domaine	Description
`<cluster_name>`	Le nom de votre cluster. Si le nom du cluster comporte 26 caractères ou moins et qu'il est unique dans cette région, le nom complet du cluster est utilisé : `myclustername`. Si le nom du cluster comporte 26 caractères ou moins et qu'un autre cluster portant le même nom existe dans cette région, le nom complet du cluster est utilisé et un tiret suivi de six caractères aléatoires est ajouté : `myclustername-ABC123`. Si le nom du cluster comporte 26 caractères ou plus et qu’il est unique dans cette région, seuls les 24 premiers caractères sont utilisés : `myveryverylongclusternam`. Si le nom du cluster comporte 26 caractères ou plus et qu’un autre cluster portant le même nom existe dans cette région, seuls les 17 premiers caractères sont utilisés et un tiret suivi de six caractères aléatoires est ajouté : `myveryverylongclu-ABC123`.
`<globally_unique_account_HASH>`	Une valeur de hachage unique globale est créée pour votre compte IBM Cloud. Tous les sous-domaines que vous créez pour les NLB dans les clusters de votre compte utilisent ce hachage.
`0000`	Sert de compteur pour chaque sous-domaine créé dans votre cluster.
`<region>`	La région dans laquelle le cluster est créé.
`containers.appdomain.cloud`	Sous-domaine des sous-domaines IBM Cloud Kubernetes Service.

Pour générer une adresse URL unique pour chaque application, les chemins d'accès aux services de votre application sont ajoutés à la route publique. Par exemple, consultez l'application suivante : URL.

mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1

Classe d'Ingress

La classe Ingress détermine le type de contrôleur Ingress utilisé. IBM propose deux classes Ingress : une publique (public-iks-traefik) et une privée (private-iks-traefik). Ces deux classes implémentent le contrôleur Ingress de Traefik. Lorsque vous créez votre ressource Ingress, la classe Ingress que vous spécifiez détermine si vos applications sont accessibles au public ou en accès privé.

Vous pouvez utiliser une classe Ingress personnalisée en configurant ingressClass dans la configuration de déploiement personnalisable.

Des équilibreurs de charge d'application (ALB)

Les ALB surveillent les requêtes entrantes destinées aux services HTTP, HTTPS ou TCP, puis les transfèrent vers le pod d'application approprié, conformément aux règles que vous définissez dans la ressource Ingress.

Lorsque vous créez un cluster standard avec une infrastructure classique ou VPC, un ALB public et un ALB privé sont automatiquement créés pour vous dans chaque zone.

ALB dans les clusters classiques

Lorsque vous créez un cluster classique, un ALB public et un ALB privé sont automatiquement créés pour vous dans chaque zone. Les ALB publics et privés des clusters classiques se voient attribuer une adresse IP statique qui ne change pas pendant toute la durée de vie du cluster.

Les ALB publics partagent le même sous-domaine Ingress fourni par IBM, qui est enregistré pour vous lors de la création d'un cluster, et l'adresse IP individuelle de chaque ALB public est associée à ce sous-domaine. Pour trouver l'adresse IP d'un ALB public, exécutez la commande « ibmcloud ks ingress alb ls » et consultez le champ « ALB IP » dans le résultat.

Les ALB privés dans les clusters classiques n'utilisent pas le sous-domaine Ingress fourni par IBM et ne sont pas activés automatiquement. Vous devez d'abord activer les ALB privées dans l'interface de ligne de commande (CLI), puis spécifier la classe « private-iks-traefik » dans votre ressource Ingress. Une fois les ALB privés activés, vous pouvez trouver les adresses IP privées en exécutant la commande « ibmcloud ks ingress alb ls » et en consultant le champ « ALB IP » dans le résultat affiché.

Si un pod ALB public ou privé est réaffecté, il conserve la même adresse IP. Cependant, la suppression d'une zone comportant un ALB, ou la suppression de tous les nœuds de travail d'un VLAN appartenant à cette zone, entraîne la suppression de l'adresse IP de cet ALB.

ALB dans VPC

Lorsque vous créez un cluster VPC, un ALB public et un ALB privé sont automatiquement créés pour vous dans chaque zone. De plus, un équilibreur de charge VPC public est automatiquement créé en dehors de votre cluster, au sein de votre VPC. Lorsque vous activez les ALB privés dans votre cluster VPC, un équilibreur de charge VPC privé est également créé.

Les adresses IP des ALB dans les clusters VPC ne sont pas statiques et peuvent changer au fil du temps. Par conséquent, les équilibreurs de charge VPC associent l'adresse IP publique ou privée de vos ALB à un nom d'hôte statique. Des noms d'hôte distincts sont utilisés pour les ALB publics et privés. Le nom d'hôte de l'ALB est distinct du sous-domaine Ingress du cluster.

Pour connaître le nom d'hôte d'un ALB dans un cluster VPC, exécutez la commande suivante : ibmcloud ks ingress alb ls``. Les noms d'hôte privés ne sont répertoriés que si les ALB privés sont activés.

Configuration requise pour les nœuds de travail des ALB

Au moins deux nœuds de travail sont nécessaires par zone dans votre cluster pour que les ALB fonctionnent en haute disponibilité et reçoivent des mises à jour périodiques.

Les règles d'anti-affinité applicables aux pods ALB garantissent qu'un seul pod est planifié par nœud de travail. Lorsque des mises à jour automatiques sont appliquées aux pods ALB, le pod est rechargé.

Si vous ne disposez que d'un seul nœud de travail, et donc d'un seul pod ALB, celui-ci ne se met pas automatiquement à jour pour éviter les interruptions de trafic. Dans ce cas, les mises à jour ne sont appliquées que lorsque vous supprimez manuellement le pod et que vous en planifiez un nouveau. Le fait de disposer d'au moins deux nœuds de travail par zone permet d'éviter ce scénario.

Notez que si une zone tombe en panne, vous risquez de rencontrer des défaillances intermittentes dans les requêtes adressées à l'ALB Ingress de cette zone.

Certificat « TLS » par défaut

Lorsque vous créez un cluster, un certificat « TLS » par défaut est généré; vous pouvez l'utiliser avec le sous-domaine Ingress fourni par IBM. Vous pouvez spécifier soit le certificat par défaut d' TLS, soit un certificat personnalisé que vous fournissez dans la ressource Ingress.

Pensez à utiliser Secrets Manager pour gérer de manière centralisée et mettre à jour automatiquement vos certificats de sous-domaines Ingress et autres secrets.

La configuration d'Ingress avec des certificats « TLS » implique la création ou l'importation de secrets. Si vous souhaitez utiliser l'API Ingress d' IBM Cloud pour effectuer ces étapes, vous devez disposer d'une instance par défaut d' Secrets Manager. Sinon, vous pouvez utiliser les commandes « kubectl » pour copier vos certificats.

Premiers pas avec Ingress

Lorsque vous êtes prêt à utiliser Ingress dans votre cluster, créez une ressource Ingress pour configurer vos composants Ingress, définir des règles de routage des requêtes et spécifier le chemin d'accès aux services d'application. Une ressource Ingress distincte est requise pour chaque espace de noms contenant une application ou un service que vous souhaitez rendre accessible.