Mise en réseau

GKE On-Prem utilise des concepts de mise en réseau Kubernetes tels que les objets Service etIngress. Ce document décrit la configuration initiale des réseaux GKE On-Prem.

Opérations des services de cluster et mode île

GKE On-Prem utilise une configuration en Mode île dans laquelle les pods peuvent communiquer directement entre eux au sein d'un cluster, mais ne peuvent pas être contactés depuis l'extérieur du cluster. Cette configuration forme au sein du réseau une "île" qui n'est pas connectée au réseau externe. Les clusters utilisent BGP (via le plug-in CNI Calico) pour former un maillage de nœud à nœud complet entre les nœuds de cluster, ce qui permet à un pod d'atteindre directement les autres pods du cluster.

Tout le trafic sortant du pod vers des cibles extérieures au cluster est fait l'objet d'une traduction NAT suivant l'adresse IP du nœud. GKE On-Prem inclut un équilibreur de charge L7 avec un contrôleur d'entrée basé sur Envoy qui gère les règles d'objet Ingress pour les services ClusterIP déployés dans le cluster. Le contrôleur d'entrée est lui-même exposé en tant que service NodePort dans le cluster.

Vous pouvez contacter le service NodePort d'entrée via un équilibreur de charge L3/L4 F5. L'installation configure une adresse IP virtuelle (VIP) (avec les ports 80 et 443) sur l'équilibreur de charge. L'adresse IP virtuelle renvoie vers les ports du service NodePort pour le contrôleur d'entrée. Voici comment les clients externes peuvent accéder aux services du cluster.

Les clusters d'utilisateur peuvent exécuter des services de type LoadBalancer tant qu'un champ loadBalancerIP est configuré dans les spécifications du service. Dans le champ loadBalancerIP, vous devez indiquer l'adresse IP virtuelle que vous souhaitez utiliser. Celle-ci sera configurée sur F5, en renvoyant vers les NodePorts du service.

Au lieu d'utiliser l'équilibreur de charge F5, vous pouvez activer le mode d'équilibrage de charge manuel. Si vous choisissez d'utiliser l'équilibrage de charge manuel, vous ne pouvez pas exécuter les services de type LoadBalancer. À la place, vous pouvez créer des services de type NodePort et configurer manuellement votre équilibreur de charge pour les utiliser en tant que backends. Vous pouvez également exposer des services à des clients externes en utilisant un objet Ingress.

Architecture réseau

Schéma de présentation de l'architecture de GKE On-Prem Figure : Réseau GKE On-Prem.

Adresses IP des nœuds
Adresses IP attribuées de manière statique ou par DHCP pour les nœuds (également appelés machines virtuelles ou VM). Doivent être routables dans le centre de données. Vous pouvez attribuer manuellement des adresses IP statiques.
Bloc CIDR des pods
Bloc CIDR non routable pour tous les pods du cluster. À partir de cette plage, des plages plus petites /24 sont attribuées par nœud. Si vous avez besoin d'un cluster à N nœuds, assurez-vous que ce bloc est suffisamment grand pour accepter N/24 blocs.
Bloc CIDR des services
En Mode île, semblable au bloc CIDR du pod et donc utilisé uniquement dans le cluster. Tout bloc CIDR privé qui ne chevauche pas les nœuds, les adresses IP virtuelles ou le bloc CIDR du pod. Vous pouvez partager le même bloc entre les clusters. La taille du bloc détermine le nombre de services. Une adresse IP de service est nécessaire pour le service d'entrée proprement dit, et dix adresses IP ou plus pour les services Kubernetes tels que le DNS du cluster, etc.
Adresses IP virtuelles de service
Nombre N d'adresses IP routables à configurer sur F5 pour l'entrée L4 lorsque vous exposez un service. Ces adresses IP virtuelles sont identiques aux valeurs loadBalancerIP que vous définissez lorsque vous créez des services de type LoadBalancer.
Adresse IP virtuelle de plan de contrôle
Adresse IP routable à configurer sur l'équilibreur de charge F5 pour le serveur d'API Kubernetes.
Adresse IP virtuelle d'entrée
Adresse IP routable à configurer sur l'équilibreur de charge F5 pour l'entrée L7 en association avec les proxys Envoy s'exécutant sur chaque nœud.

Options de configuration de la mise en réseau

Vous disposez de plusieurs options pour configurer la mise en réseau de vos clusters :

  • Vous pouvez choisir un réseau vCenter global ou utiliser un autre réseau vCenter pour les clusters d'administrateur et d'utilisateur.
  • Vous pouvez utiliser un proxy HTTP et choisir quelles adresses vous souhaitez exclure du proxy.
  • Vous pouvez choisir l'allocation d'adresses IP statique ou DHCP.
  • Vous pouvez choisir le mode d'équilibrage de charge intégré ou manuel.

Lors de l'installation, vous spécifiez vos préférences dans le fichier de configuration de GKE On-Prem.

Configurations de mise en réseau vCenter

Le champ network de la configuration détermine le réseau vCenter à utiliser pour les clusters :

  • Le champ vcenter.network global spécifie un réseau spécifique.
  • admincluster.vcenter.network remplace le champ global et spécifie le réseau à utiliser pour le cluster d'administrateur.
  • usercluster.vcenter.network remplace le champ global et spécifie le réseau à utiliser pour le cluster d'utilisateur.

Exemple : Accéder à une application Web via une URL

Supposons qu'une application Web de livre d'or est en cours d'exécution dans votre cluster en tant que déploiement nommé frontend. Vous souhaitez vous connecter à l'application à l'aide d'une URL, www.guestbook.com. Vous devez pouvoir mapper l'URL sur le déploiement en cours d'exécution dans votre cluster. Pour ce faire, vous pouvez utiliser un objet Kubernetes Ingress.

Pour commencer, vous devez créer une entrée DNS générique pour *.guestbook.com qui renvoie vers l'adresse IP virtuelle d'entrée existante du cluster :

*.guestbook.com    A   [INGRESS_VIP]

Ensuite, vous devez créer un service pour le déploiement de l'interface. L'exécution de kubectl expose crée un service qui regroupe logiquement les pods du déploiement et leur fournit une adresse IP commune dans le cluster :

kubectl expose deployment frontend

Cela crée un service de type ClusterIP, comme suit :

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: ClusterIP

Vous devez mapper l'URL, www.guestbook.com, sur le service d'interface que vous venez de créer. L'application de l'objet Ingress ci-dessous crée ce mappage :

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend
  labels:
    app: guestbook
spec:
  rules:
    - host: www.guestbook.com
      http:
        paths:
          - backend:
              serviceName: frontend   # name of the frontend Service
              servicePort: 80

Accédez maintenant à www.guestbook.com pour ouvrir l'application Web dans votre navigateur.

Découvrez comment cela fonctionne :

  • Étant donné que vous avez créé cette entrée DNS générique, lorsque vous utilisez l'URL, vous accédez à l'adresse IP virtuelle d'entrée du cluster.
  • Le cluster recherche le bon objet Ingress en fonction du nom d'hôte, qui dans le cas présent est www.guestbook.com.
  • Le trafic est transféré vers un pod d'interface via un port.

Exemple : Accéder à une application Web via une adresse IP

Si votre application n'est pas une application Web ou si vous avez des contraintes de mise en réseau, vous préférerez peut-être créer une adresse IP virtuelle spécifiquement pour votre service. Pour ce faire, vous pouvez utiliser un service Kubernetes de type LoadBalancer.

Le service ci-dessous crée une adresse IP virtuelle spécifique à l'application guestbook :

apiVersion: v1
kind: Service
metadata:
  labels:
    app: guestbook
  name: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: guestbook
  type: LoadBalancer
  loadBalancerIP: [IP_ADDRESS]
  

Une fois que vous avez appliqué ce service, l'adresse IP virtuelle apparaît dans votre console F5 et vous pouvez voir les adresses IP des nœuds dans le menu Pools de la console. Si vous accédez à l'adresse IP, l'application est chargée.