Kubernetes - komunikacja kontenera w kapsule z użyciem nazw zamiast "localhost"?

Question

Z kubernetes docs:

Wnioski w pod wszystkie używać tej samej przestrzeni nazw sieci (tego samego IP i przestrzeń portu) i może w ten sposób „znaleźć” siebie i komunikowania się za pomocą localhost.

Czy można używać nazw konkretnych kontenerów zamiast locahost?

Na przykład z docker-compose up używa się nazwy usługido komunikacji. [docs]

Tak więc, jeśli mój doker-compose.yml plik jest

version: '2' 
services: 
    web: 
    build: . 
    ports: 
     - "8000:8000" 
    srv: 
    build: . 
    ports: 
     - "3000:3000" 

Potem dostęp srv od wewnątrz web wywołując http://srv:3000/, niehttp://localhost:3000

jaki sposób można osiągnąć ten sam zachowanie w kubernetes? Jakikolwiek sposób określić nazwę używaną w konfiguracji yaml pods?

Answer 1

localhost to nazwa urządzenia zwrotnego sieci (zwykle 127.0.0.1 dla IPv4 i ::1 dla IPv6). Zazwyczaj jest to określone w pliku /etc/hosts.

Strąk ma swój własny adres IP, więc każdy kontener wewnątrz ma ten sam adres IP. Jeśli te pojemniki powinny być niezależne (tj. Nie muszą być kolokowane), powinny one znajdować się we własnej kapsule. Następnie możesz zdefiniować service dla każdego, który umożliwia wyszukiwanie DNS jako "$ SERVICENAME" z pods w tej samej przestrzeni nazw, lub "$ SERVICENAME. $ NAMESPACE" z pods w różnych przestrzeniach nazw.

Answer 2

rozmieszcza poszczególne kontenery, łącząc je ze sobą, aby znały swoje nazwy i adresy IP.

a w Kubernetes jest podobny, ale nie jest to celem kapsuły do ​​obsługi wielu usług zewnętrznych i łączenia ich ze sobą.

Kapsuła jest przeznaczona dla kontenerów, które muszą być uruchomione na tym samym hoście i współpracować tylko między sobą. Kontenery komunikują się wewnętrznie przez localhost.

Większość Pods jest w rzeczywistości jednym pojemnikiem.

A Pod komunikuje się z otoczeniem za pomocą Services. W istocie kapsuła wygląda tak, jakby była tylko jednym pojemnikiem.

pod maską, Pod jest co najmniej 2 pojemniki: pojemnik pause zarządza IP Pod, a następnie dołączonym kontenerem. Pozwala to na zawieszenie się kontenera, ponowne uruchomienie i ponowne połączenie w podsadce bez zmiany adresu IP, co pozwala zarządzać awarią kontenerów bez angażowania programu planującego i upewniać się, że pods pozostaje w pojedynczym węźle podczas jego trwania, więc restart jest szybki.

Jeśli pojemniki my przełożone każdym razem, gdy awarię, będą one potencjalnie skończyć na innego hosta, routing musiałby być aktualizowany itp ...