Impossible de résoudre le nom d'hôte d'un autre service dans mon installation Kubernetes Windows

Question

J'ai récemment suivi le didacticiel sur l'utilisation des modules Kubernetes avec Windows (https://docs.microsoft.com/en-us/azure/container-service/kubernetes/container-service-kubernetes-windows-walkthrough). J'ai décidé d'étendre l'exemple à deux services, un front appelant celui à l'arrière. Simplifié:

https://gist.github.com/sebug/f478f1cfd0a793e8d556c6001bbbe142

Mais maintenant, quand je me connecte à l'un des noeuds avant:

kubectl exec -it samplefront-2836659004-4m824 -- powershell 

Je ne peux pas ping l'autre service:

PS C:\> ping sample-back 
Ping request could not find host sample-back. Please check the name and try again. 

J'ai entendu qu'il peut-être à cause des deux interfaces réseau et le mauvais serveur DNS étant choisi, mais je n'ai pas trouvé un moyen de spécifier quoi que ce soit dans le déploiement.

Windows IP Configuration 


Ethernet adapter vEthernet (Container NIC 7baf5cc0): 

Connection-specific DNS Suffix . : 
Link-local IPv6 Address . . . . . : fe80::f182:e2e7:7bce:ed60%33 
IPv4 Address. . . . . . . . . . . : 10.244.0.211 
Subnet Mask . . . . . . . . . . . : 255.255.255.0 
Default Gateway . . . . . . . . . : 10.244.0.1 

Ethernet adapter vEthernet (Container NIC ae765bad): 

Connection-specific DNS Suffix . : 10jheu23yh0ujpey5vzw0q45qg.ax.internal.cloudapp.net 
Link-local IPv6 Address . . . . . : fe80::c4dc:b785:9cd:2a7b%37 
IPv4 Address. . . . . . . . . . . : 172.31.245.122 
Subnet Mask . . . . . . . . . . . : 255.255.240.0 
Default Gateway . . . . . . . . . : 172.31.240.1 

Answer 1

Donc après avoir essayé différents scénarios que je pensais que je voudrais supprimer le programme d'installation et essayez à nouveau, en spécifiant une version spécifique de Microsoft/iis - et cela a fonctionné:

https://gist.github.com/sebug/0f7776668fff4e0e6b3f3d313846afa6

kripke:Documents/Projets/ScaledSample% kubectl exec -it samplefront-1226573881-21bbh -- ping sample-back 


Pinging sample-back [10.0.216.120] with 32 bytes of data: 
Reply from 10.0.216.120: bytes=32 time<1ms TTL=128 
Reply from 10.0.216.120: bytes=32 time<1ms TTL=128 
Reply from 10.0.216.120: bytes=32 time<1ms TTL=128 
Reply from 10.0.216.120: bytes=32 time<1ms TTL=128 

Ping statistics for 10.0.216.120: 
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 
Approximate round trip times in milli-seconds: 
Minimum = 0ms, Maximum = 0ms, Average = 0ms 

Mon hypothèse est soit que je suis tombé sur une instance plus sage après avoir recréé le groupe de ressources et le cluster ou que cette spécification de la version exacte de l'image du conteneur a fait l'affaire.

Answer 2

ne peut pas résoudre le nom d'hôte d'un autre service à l'intérieur de mes Kubernetes.

Ceci est un comportement de conception. Parce que l'IP de cluster n'existe pas.

Dans Kubernetes, tous les services d'un cluster sont gérés par kube-proxy. kube-proxy s'exécute sur tous les nœuds du cluster, et ce qu'il écrit iptables règles pour chaque service (nœud Linux, identique à Windows). Ces règles iptables gèrent le trafic vers les adresses IP de service. Ils n'ont pas de règles pour ICMP, parce que ce n'est pas nécessaire. Mais nous pouvons faire un ping sur le pod IP ou le DNS du pod.

Par exemple, nous pouvons utiliser cette commande pour répertorier les adresses IP PODS:

root@k8s-master-9F42C511-0:~# kubectl get pods -o wide 
NAME        READY  STATUS RESTARTS AGE  IP   NODE 
azure-vote-back-3048739398-8zx8b 1/1  Running 0   18m  10.244.1.2 k8s-agent-9f42c511-0 
azure-vote-front-837696400-tglpn 1/1  Running 0   18m  10.244.1.3 k8s-agent-9f42c511-0 

Ensuite, nous utilisons un pod ping les adresses IP:

root@k8s-master-9F42C511-0:~# kubectl exec -it azure-vote-front-837696400-tglpn -- /bin/bash 
root@azure-vote-front-837696400-tglpn:/app# ping 10.244.1.3 
PING 10.244.1.3 (10.244.1.3): 56 data bytes 
64 bytes from 10.244.1.3: icmp_seq=0 ttl=64 time=0.063 ms 
64 bytes from 10.244.1.3: icmp_seq=1 ttl=64 time=0.052 ms 
^C--- 10.244.1.3 ping statistics --- 
2 packets transmitted, 2 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 0.052/0.057/0.063/0.000 ms 
root@azure-vote-front-837696400-tglpn:/app# ping 10.244.1.4 
PING 10.244.1.4 (10.244.1.4): 56 data bytes 
64 bytes from 10.244.1.4: icmp_seq=0 ttl=64 time=0.102 ms 
64 bytes from 10.244.1.4: icmp_seq=1 ttl=64 time=0.098 ms 
^C--- 10.244.1.4 ping statistics --- 
2 packets transmitted, 2 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 0.098/0.100/0.102/0.000 ms 

De plus, nous pouvons ping 'A pod record. Dans les kubernetes, un enregistrement de pod sous la forme de pod-ip-address.my-namespace.pod.cluster.local.

Par exemple, une nacelle avec IP 1.2.3.4 dans l'espace de noms default avec un nom DNS de cluster.local aurait une entrée: 1-2-3-4.default.pod.cluster.local

Dans mon laboratoire, mon pod est un disque comme celui-ci:

root@k8s-master-9F42C511-0:~# kubectl exec -it azure-vote-front-837696400-tglpn -- /bin/bash 
root@azure-vote-front-837696400-tglpn:/app# ping 10-244-1-2.default.pod.cluster.local                            
PING 10-244-1-2.default.pod.cluster.local (10.244.1.2): 56 data bytes 
64 bytes from 10.244.1.2: icmp_seq=0 ttl=64 time=0.103 ms 
64 bytes from 10.244.1.2: icmp_seq=1 ttl=64 time=0.087 ms 
64 bytes from 10.244.1.2: icmp_seq=2 ttl=64 time=0.096 ms 
^C--- 10-244-1-2.default.pod.cluster.local ping statistics --- 
3 packets transmitted, 3 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 0.087/0.095/0.103/0.000 ms 

Donc, nous ne pouvons pas adresse IP de cluster de ping, mais nous pouvons utiliser l'URL pour le tester. Nous pouvons interroger l'adresse IP de pod, et un enregistrement.

---

Mise à jour:
Désolé pour mon erreur, les règles K8S Un record pour Linux Agent travaillent, mais ne fonctionne pas pour l'agent Windows.

Pour plus d'informations sur les conteneurs du serveur Windows, veuillez vous reporter à ce article.