Chaîne de connexion qu'un pod doit utiliser pour se connecter à un pod postgresql dans le même cluster?

tl; dr: postgres-service.default.svc

voir l'explication dans la documentation : default est le nom de votre espace de noms et la partie du domaine du cluster peut être omise.

Le fichier /etc/resolv.conf à l'intérieur du pod a-t-il l'IP du pod coredns? Cela devrait ressembler à ceci:

nslookup kubernetes.default.svc

Vérifiez également si vous pouvez rechercher un autre service

u@pod$ cat /etc/resolv.conf
nameserver 10.0.0.10 # IP of core dns pod
search default.svc.cluster.local svc.cluster.local cluster.local example.com
options ndots:5

Vérifiez ceci guide sur la façon de déboguer les problèmes avec les services dans kubernetes.

J'ai lu toutes les réponses et tous les commentaires, recommençons pour avoir un nouveau point de vue.

Je travaille actuellement sur une application qui fonctionnera dans un pod kubernetes. Il est censé se connecter à un pod PostgreSql, qui est exécuté dans le même cluster.

Afin de vous aider, nous devons tester chaque étape de votre environnement séparément.

Tout d'abord, une clarification:

• Les services n'acceptent pas le ping , pour tester le service, vous devez tester le port de l'application qui est exposée. Il est conçu de cette façon.

Étape 1 - Nous devons nous assurer que le service PostgreSQL fonctionne correctement.

Voici mon PostgreSQL déployé:

root@test-shell-845c969686-vh9zh:/# psql --host=postgresql --port=5432 --username=postgres --dbname=postgres  
Password for user postgres: 
psql (10.10 (Ubuntu 10.10-0ubuntu0.18.04.1), server 11.6)
Type "help" for help.

postgres=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of 
-----------+------------------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

• Section A - Exécutez un module shell interactif postgresql-client :

root@test-shell-845c969686-h9gz2:/# export my_conn='postgresql://postgres:postgres@postgresql/postgres'
root@test-shell-845c969686-h9gz2:/# pg_isready -d $my_conn
kneeling-scorpion-postgresql:5432 - accepting connections

Si les informations d'identification sont correctes, vous verrez postgres = # . Essayez d'exécuter une commande comme \du:

root@test-shell-845c969686-h9gz2:/# pg_isready --host=postgresql --port=5432 --username=postgres --dbname=postgresql
postgresql:5432 - accepting connections

SI: ça marche! Passez à l ' Étape 2 .

SI NON:

• Section B - Tester manuellement avec postgresql-client .

Démarrez un seul pod d'exécution d'un shell Ubuntu:

kubectl run -i --tty --rm --image ubuntu test-shell - / bin / bash

Ensuite, installez le client postgresql et nslookup:

apt update && apt install postgresql-client -y && apt install dnsutils -y

Exécutez un nslookup sur le service:

root@test-shell-845c969686-h9gz2:/# nslookup postgresql
Server:         10.0.0.10
Address:        10.0.0.10#53

Name:   postgresql.default.svc.cluster.local
Address: 10.0.8.179

Comme vous pouvez le voir, comme nous travaillons dans le même cluster et namespace , tous les appels effectués à genoux-scorpion-postgresql sont correctement attribués sans spécifier le nom de domaine complet.

Exécutez le pg_isready (rappelez-vous que host est le service, pas le pod) :

postgres=# \du
                                   List of roles
 Role name |                         Attributes                         | Member of 
-----------+------------------------------------------------------------+-----------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Vous pouvez testez également en tant que chaîne de connexion:

La structure est export my_conn = 'postgresql: // user: password @ FQDN / DATABASE'

$ kubectl run postgresql-client --rm --tty -i --restart='Never' \
--namespace default \
--image docker.io/bitnami/postgresql:11.6.0-debian-10-r0 \
--env="PGPASSWORD=postgres" \
--command -- psql --host postgres \
-U postgres -d postgres -p 5432

• Il peut y avoir un problème avec votre PostgreSQL.
• À ce stade, je vous suggère de réessayer ces tests, mais avec une base de données propre comme celle de Helm Chart: stable / postgresql . Documentation ici . Il est vraiment facile à installer et à supprimer en cas de besoin.

Étape 2 - Se restreindre au client:

À ce stade, je suppose que votre connexion à la base de données fonctionne correctement. Nous devons donc revoir quelques points:

• Si vous pouvez vous connecter à la base de données à partir d'autres pods, je vous suggère d'essayer de déployer et d'exécuter une instance de votre APP à partir de l'Ubuntu POD que nous avons utilisé dans la section B.

Si cela ne fonctionne toujours pas, vous vous êtes maintenant limité à un problème dans votre application.

Si vous rencontrez des difficultés à reproduire cette solution, laissez je sais dans les commentaires.

Je ne suis pas sûr de comprendre pourquoi .. Mais tout mon asp. L'application conteneurisée Net Core n'a pas pu résoudre le nom du service.

Ceux-ci ont dû être résolus dans une étape distincte en utilisant https: // docs. microsoft.com/en-us/dotnet/api/system.net.dns.gethostname?view=netframework-4.8 , puis transmis en tant qu'adresse IP, résolue à partir de l'étape précédente ..

Je me suis basé sur la façon dont nslookup a répondu, il échoue initialement car l'enregistrement DNS n'est pas mis en cache, puis résout le nom d'hôte car il peut être trouvé via la diffusion.

Je suppose que puisque la recherche initiale de DNS échoue, elle se déclenche et une exception à laquelle la mienne a échoué ...