Chapitre 2. Comprendre la mise en réseau
Les administrateurs de clusters disposent de plusieurs options pour exposer au trafic externe les applications qui s'exécutent au sein d'un cluster et pour sécuriser les connexions réseau :
- Types de services, tels que les ports de nœuds ou les équilibreurs de charge
-
Les ressources de l'API, telles que
IngressetRoute
Par défaut, Kubernetes attribue à chaque pod une adresse IP interne pour les applications qui s'exécutent dans le pod. Les pods et leurs conteneurs peuvent fonctionner en réseau, mais les clients extérieurs au cluster n'ont pas accès au réseau. Lorsque vous exposez votre application au trafic externe, le fait de donner à chaque module sa propre adresse IP signifie que les modules peuvent être traités comme des hôtes physiques ou des machines virtuelles en termes d'allocation de ports, de mise en réseau, de nommage, de découverte de services, d'équilibrage de charge, de configuration d'applications et de migration.
Certaines plateformes en nuage proposent des API de métadonnées qui écoutent l'adresse IP 169.254.169.254, une adresse IP locale dans le bloc CIDR d'IPv4 169.254.0.0/16.
Ce bloc CIDR n'est pas accessible depuis le réseau de pods. Les pods qui ont besoin d'accéder à ces adresses IP doivent recevoir un accès au réseau hôte en définissant le champ spec.hostNetwork dans la spécification du pod sur true.
Si vous autorisez un hôte pod à accéder au réseau, vous lui accordez un accès privilégié à l'infrastructure réseau sous-jacente.
2.1. OpenShift Container Platform DNS
Si vous exécutez plusieurs services, tels que des services front-end et back-end à utiliser avec plusieurs pods, des variables d'environnement sont créées pour les noms d'utilisateur, les IP de service, etc. afin que les pods front-end puissent communiquer avec les services back-end. Si le service est supprimé et recréé, une nouvelle adresse IP peut lui être attribuée, ce qui oblige à recréer les pods frontaux pour récupérer les valeurs mises à jour de la variable d'environnement IP du service. En outre, le service back-end doit être créé avant tous les pods front-end pour garantir que l'IP du service est générée correctement et qu'elle peut être fournie aux pods front-end en tant que variable d'environnement.
Pour cette raison, OpenShift Container Platform dispose d'un DNS intégré de sorte que les services peuvent être atteints par le DNS du service ainsi que par l'IP/port du service.
