J'ai créé un cluster GKE privé avec Istio via l'interface utilisateur de Cloud Console. Le cluster est configuré avec l'appairage de VPC pour pouvoir atteindre un autre cluster GKE privé dans un autre projet Google Cloud.
J'ai créé un déploiement (appelé site Web ) avec un service dans Kubernetes dans l'espace de noms staging . Mon objectif est d'exposer ce service au monde extérieur avec Istio, en utilisant le proxy Envoy. J'ai créé le VirtualService et la Gateway nécessaires pour ce faire, en suivant ce guide .
Lors de l'exécution de "kubectl exec ..." pour accéder à un pod dans le cluster privé, je peux me connecter avec succès à l'adresse IP interne du service site Web et voir le résultat de ce service avec "curl".
J'ai configuré une passerelle NAT pour que les pods du cluster privé puissent se connecter à Internet. J'ai confirmé cela en curl - en utilisant diverses pages Web non Google à partir du module website .
Cependant, je ne peux pas me connecter au service site Web depuis l'extérieur, en utilisant l ' IP externe du service istio-ingressgateway , comme le guide ci-dessus le mentionne. Au lieu de cela, curl -ing que IP externe conduit à un timeout.
J'ai mis la configuration YAML complète pour toutes les ressources associées dans un Gist privé, ici: https: //gist.github.com/marceldegraaf/0f36ca817a8dba45ac97bf6b310ca282
Je me demande si je manque quelque chose dans ma configuration ici, ou si mon cas d'utilisation est réellement impossible?
3 Réponses :
En regardant votre Gist, je soupçonne que le problème réside dans la connexion de la Gateway à la istio-ingressgateway.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: website-gateway
namespace: staging
labels:
version: v1
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
En particulier, je ne suis pas convaincu que la partie selector est correcte.
Vous devriez pouvoir faire quelque chose comme
kubectl describe po -n istio-system istio-ingressgateway-rrrrrr-pppp
pour découvrir ce que le sélecteur tente de faire correspondre dans le module Istio Ingress Gateway.
Merci! Il semble que istio-ingressgateway ait cette étiquette, voir la sortie de kubectl describe pod ici: gist.github.com/marceldegraaf/... . Cela devrait relier correctement la Gateway au pod istio-ingressgateway , n'est-ce pas?
Avez-vous vérifié les journaux de l'équilibreur de charge GCP et également que la vérification de l'état de la LB est dans un état sain?
La vérification de l'état LB est verte et il n'y a aucune erreur dans les journaux de l'équilibreur de charge.
Ok, donc le LB parle à quelque chose - vous devriez être capable de trouver les entrées de journal des pings LB dans le pod istio-ingressgateway s'il est correctement câblé.
Après avoir vérifié toutes les options, la seule façon d'exposer le cluster GKE privé avec Istio à l'extérieur est d'utiliser Cloud NAT .
Étant donné que le nœud maître dans GKE est un service géré, il existe actuellement des limites lors de l'utilisation d'Istio avec un cluster privé. La seule solution de contournement qui permettrait de réaliser votre cas d'utilisation est d'utiliser Cloud NAT. J'ai également joint un article sur la façon de commencer à utiliser Cloud NAT ici .
Merci! J'ai configuré Cloud NAT, mais comme mentionné dans ma question initiale, cela ne résout pas le problème pour moi.
Comme j'ai testé le passé, en utilisant spécifiquement Cloud NAT, cela fonctionne; cependant, en utilisant une passerelle NAT séparée, cela ne fonctionnera pas. Comme vous l'avez mentionné dans votre message d'origine, vous avez uniquement mentionné l'utilisation d'une passerelle NAT. Assurez-vous que vous utilisez spécifiquement Google Cloud NAT pour permettre au cluster de communiquer en externe.
J'ai eu le même problème. Dans mon cas, le service virtuel istio ne trouve pas mon service.
Essayez ceci sur votre VirtualService:
route:
- destination:
host: website
port:
number: 80
Si vous utilisez simplement l'adresse IP externe d'un nœud, plutôt qu'un LoadBalancer ou une entrée, vous devez vous assurer que vos règles de pare-feu GCE autorisent le trafic.
@PaulAnnetts merci pour votre réponse. L '
IP externede laistio-ingressgatewayest liée à une règle de transfert dans Cloud Load Balancer, avec les nœuds GKE comme pool cible. J'ai ajouté une règle de pare-feu pour autoriser explicitement tout le trafic entrant sur TCP: 80 pour l'ensemble du réseau, mais même dans ce cas, macurlsur l 'IP externeentraîne un délai d'expiration. Une idée de ce qui me manque?Avez-vous vérifié les journaux pour istio-ingressgateway? Si votre service est touché et si le service a une erreur, cela apparaîtra dans ce journal.
Merci pour votre réponse @mjkool. Lors de la vérification des journaux pour
istio-ingressgateway, je ne vois aucune requête entrant lorsque j'essaie d'accéder à l 'IP externede l'extérieur. Je vois des demandes dans les journaux deistio-ingressgatewaylorsque j'essaye de lecurldepuis l'intérieur du cluster.@MarceldeGraaf, une solution au problème?