Kubernetes Basics · Lekcja

DNS i wykrywanie usług

Dowiedz się, jak Pody odnajdują się za pomocą wbudowanego DNS Kubernetes oraz jak działa wykrywanie usług od podstaw.

DNS i wykrywanie usług to bezpłatna lekcja Kubernetes Basics na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Kubernetes Basics, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Kubernetes Basics zawiera 4 lekcji w sumie.

Problem wykrywania usług

Pody są tworzone i usuwane, a ich adresy IP stale się zmieniają. Wpisanie adresów IP na stałe przestałoby działać niemal natychmiast. Kubernetes rozwiązuje ten problem dzięki wykrywaniu usług za pomocą DNS.

Zamiast adresu IP używa się stabilnej nazwy.

DNS klastra

W każdym klastrze działa usługa DNS (zwykle CoreDNS). Automatycznie tworzy rekordy DNS dla obiektów Service i Podów, dzięki czemu nazwy są rozwiązywane do właściwego adresu ClusterIP.

Nazwy DNS obiektów Service

Obiekt Service otrzymuje nazwę DNS zgodną z przewidywalnym schematem:

service-name.namespace.svc.cluster.local

W tej samej przestrzeni nazw można użyć tylko krótkiej nazwy service-name.

# from a Pod in the same namespace
curl http://payment-service:8080

# fully qualified, from any namespace
curl http://payment-service.shop.svc.cluster.local:8080

Przestrzenie nazw i nazewnictwo

Przestrzeń nazw jest częścią nazwy. Aby dotrzeć do obiektu Service w innej przestrzeni nazw, należy ją uwzględnić: service.namespace.

# Pod in 'frontend' namespace calling 'backend' namespace
curl http://api.backend.svc.cluster.local

Testowanie DNS z poziomu Poda

Można uruchomić tymczasowy Pod, aby przetestować rozwiązywanie nazw.

kubectl run dnstest --image=busybox:1.36 --rm -it --restart=Never -- nslookup payment-service

Jak CoreDNS rozwiązuje nazwy

Gdy Pod wysyła zapytanie o nazwę, żądanie trafia do CoreDNS. CoreDNS wyszukuje pasujący obiekt Service i zwraca jego adres ClusterIP. W przypadku obiektów Service typu headless zwraca bezpośrednio adresy IP Podów.

Obiekty Service typu headless

Obiekt Service typu headless (clusterIP: None) pomija pojedynczy wirtualny adres IP. Zamiast tego DNS zwraca adresy IP poszczególnych Podów, co jest niezbędne w przypadku aplikacji stanowych, które adresują Pody bezpośrednio.

apiVersion: v1
kind: Service
metadata:
  name: db
spec:
  clusterIP: None
  selector:
    app: db
  ports:
  - port: 5432

Rekordy DNS Podów

W przypadku obiektu Service typu headless każdy obsługiwany Pod może również otrzymać własny rekord DNS. Jest to przydatne w przypadku StatefulSets, w których Pody mają stabilne tożsamości, takie jak db-0 i db-1.

# stable per-Pod name in a StatefulSet
curl http://db-0.db.default.svc.cluster.local:5432

Sprawdzanie pliku resolv.conf w Podzie

Kubernetes wstrzykuje konfigurację DNS do każdego Poda. Domeny wyszukiwania pozwalają poprawnie rozwiązywać krótkie nazwy.

kubectl exec -it mypod -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.local

Zmienne środowiskowe a DNS

Kubernetes wstrzykuje również informacje o połączeniu z obiektami Service jako zmienne środowiskowe, ale tylko dla obiektów Service, które istniały w chwili uruchomienia Poda. DNS jest preferowany, ponieważ zawsze odzwierciedla bieżący stan.

Typowe problemy z DNS

Pomijanie przestrzeni nazw przy wywoływaniu usług w innych przestrzeniach nazw
Oczekiwanie rekordu DNS dla obiektu Service bez pasujących Podów (bez endpointów)
Buforowanie nieaktualnych adresów IP w aplikacji zamiast ponownego rozwiązywania nazwy

Szybki test

Należy wybrać prawidłowy format nazwy DNS.

Podsumowanie

Dowiedział się Pan, że Kubernetes używa CoreDNS do nadawania obiektom Service stabilnych nazw DNS zgodnych ze schematem service.namespace.svc.cluster.local. Krótkie nazwy działają w obrębie jednej przestrzeni nazw, obiekty Service typu headless udostępniają adresy IP poszczególnych Podów, a DNS zawsze odzwierciedla bieżący stan klastra.

Często zadawane pytania

Czy lekcja „DNS i wykrywanie usług” jest bezpłatna?

Tak — pełny tekst „DNS i wykrywanie usług” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Kubernetes Basics, przejdź na CoddyKit PRO. Kurs Kubernetes Basics zawiera 4 lekcji w sumie.

Co nauczysz się w „DNS i wykrywanie usług”?

Dowiedz się, jak Pody odnajdują się za pomocą wbudowanego DNS Kubernetes oraz jak działa wykrywanie usług od podstaw. Ćwiczysz Kubernetes Basics z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Kubernetes Basics?

Nie wymagamy żadnego doświadczenia. Kubernetes Basics w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „DNS i wykrywanie usług”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Kubernetes Basics?

Tak. Każda lekcja Kubernetes Basics zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Udostępnianie aplikacji za pomocą Services
Typy Service: ClusterIP, NodePort, LoadBalancer
Ingress zapewniający dostęp zewnętrzny
DNS i wykrywanie usług

← Powrót do Kubernetes Basics