Kf s'intègre étroitement à Kubernetes et Istio pour garantir une application fiable des règles de réseau.
Par défaut, les charges de travail Kf sont exécutées dans le cluster Kubernetes et résolvent les adresses à l'aide du DNS Kubernetes. Ce résolveur DNS tente d'abord de résoudre les adresses du cluster, et seulement si aucune d'entre elles n'est résolue en externe.
Chaque application Kf est exécutée avec un side-car Envoy injecté par Istio ou Anthos Service Mesh (ASM). Ce side-car fait office de proxy pour l'ensemble du trafic réseau entrant et sortant du pod Kubernetes.
Chaque pod Kubernetes est exécuté sur un nœud, une machine physique ou virtuelle chargée de gérer les images de conteneur qui constituent un pod. Les nœuds existent sur un réseau physique ou virtuel.
Ensemble, ils constituent une hiérarchie de systèmes que vous pouvez appliquer aux règles de réseau. Celles-ci sont répertoriées ci-dessous, de la moins précise à la plus précise.
Règles au niveau du réseau
La protection des charges de travail commence par le réseau sur lequel votre cluster GKE est installé.
Si vous exécutez Kf sur un cluster GKE sur GCP, Kf formule les recommandations suivantes :
- Placer le cluster GKE sur un réseau de cloud privé virtuel (VPC)
- Activer l'accès privé à Google
- Utiliser Cloud NAT pour contrôler la sortie
Règles au niveau du nœud
Vous pouvez configurer des règles pour les conteneurs exécutés sur le nœud à l'aide des objets NetworkPolicy de Kubernetes. Il s'agit du mappage le plus proche des règles de réseau Cloud Foundry appliquées dans Kubernetes.
Les objets NetworkPolicy sont sauvegardés par un module complémentaire de Kubernetes. Si vous configurez votre propre cluster GKE, vous devez activer l'application des objets NetworkPolicy.
Kf ajoute des libellés aux applications avec kf.dev/networkpolicy=app et les compile avec kf.dev/networkpolicy=build.
Cela vous permet de cibler les objets NetworkPolicy directement sur les pods exécutant des applications ou des compilations.
Chaque espace Kf crée d'abord deux objets NetworkPolicy, un ciblant les applications et l'autre les compilations. Vous pouvez modifier la configuration dans les champs spec.networkConfig.(app|build)NetworkPolicy.(in|e)gress de l'espace.
Ces champs peuvent être définis sur l'une des valeurs suivantes :
| Valeur d'énumération | Description |
|---|---|
PermitAll |
Autorise tout le trafic. |
DenyAll |
Refuse tout le trafic. |
Par défaut, Kf utilise une règle de réseau permissive. Cela permet à KF d'utiliser les fonctionnalités suivantes :
- Routage du trafic Nord/Sud vers la passerelle d'entrée du cluster
- Sortie vers Internet, par exemple pour récupérer des packs de création
- Routage du trafic Est/Ouest entre les applications
- Accès au serveur DNS Kubernetes
- Accès aux registres de conteneurs
- Accès direct au réseau VPC
- Accès aux services Google, tels que Cloud Logging
- Accès au serveur Workload Identity pour les identifiants à rotation automatique
Règles de maillage de services
Si vous avez besoin de contrôler avec précision le réseau, l'authentification, les autorisations et l'observabilité, vous pouvez appliquer des règles à l'aide de Anthos Service Mesh.
Un maillage de services est une couche d'infrastructure qui permet une communication gérée, observable et sécurisée sur vos services. Vous pouvez ainsi créer des applications d'entreprise fiables dotées de nombreux microservices sur l'infrastructure de votre choix.
Consultez la liste des fonctionnalités compatibles ici.