DNS i CoreDNS w Kubernetes

data

2026-07-07

kategoria

Containers

także w

Networking

czytanie

1 min / 285 słów

Sieć w Kubernetes daje możliwość komunikacji po adresach IP.

Problem w tym, że adresy nie są dobrym interfejsem dla aplikacji.

Pody są dynamiczne:

mogą zostać usunięte,
mogą powstać ponownie,
mogą dostać inny adres IP,
mogą zostać przeniesione na inny node.

Dlatego aplikacje potrzebują stabilnego sposobu odnajdywania usług.

Tę rolę pełni DNS.

CoreDNS

Standardowym serwerem DNS używanym w Kubernetes jest CoreDNS.

Jego zadaniem jest obsługa nazw związanych z zasobami klastra.

Przykład:

text

backend.default.svc.cluster.local

Taka nazwa może wskazywać na Service o nazwie backend w namespace default.

Aplikacja nie musi znać konkretnego IP.

Dlaczego DNS jest ważny

Wyobraź sobie dwie aplikacje:

text

frontend
backend

Frontend chce połączyć się z backendem.

Bez DNS musiałby znać konkretny adres:

text

10.96.32.15

Z DNS może użyć:

text

backend

To znacznie bardziej odporne na zmiany infrastruktury.

Jak wygląda przepływ

W uproszczeniu:

text

frontend Pod
   |
   v
DNS query
   |
   v
CoreDNS
   |
   v
Service IP

Potem dopiero zaczyna się właściwa komunikacja sieciowa:

text

Service IP
   |
   v
kube-proxy / eBPF
   |
   v
backend Pod

To ważne rozróżnienie.

DNS nie przenosi ruchu aplikacyjnego.

DNS jedynie odpowiada:

pod jakim adresem znajduje się to, czego szukasz?

CoreDNS a Service

CoreDNS i Service są ze sobą powiązane, ale odpowiadają za inne rzeczy.

Service daje stabilny adres logiczny.

CoreDNS daje stabilną nazwę.

Można to zapisać tak:

text

nazwa
  |
  v
CoreDNS
  |
  v
Service IP
  |
  v
network datapath
  |
  v
Pod

CoreDNS a kube-proxy

Najprostsze rozróżnienie:

text

CoreDNS
-> zamienia nazwę na adres

kube-proxy / eBPF
-> kieruje ruch do endpointu

Jeżeli DNS działa, ale datapath jest uszkodzony, aplikacja może poprawnie rozwiązać nazwę, ale połączenie nadal nie zadziała.

Jeżeli datapath działa, ale DNS nie działa, komunikacja po IP może działać, ale komunikacja po nazwach już nie.

Czy CoreDNS jest częścią control plane?

Nie w takim sensie jak:

kube-apiserver,
scheduler,
controller-manager,
etcd.

CoreDNS jest zwykle uruchamiany jako workload w klastrze.

Mimo to jest tak podstawowym elementem większości instalacji Kubernetes, że praktycznie zawsze pojawia się przy omawianiu architektury.

Co zapamiętać

CoreDNS odpowiada za service discovery po nazwach.

Nie odpowiada za routing pakietów ani za uruchamianie aplikacji.

Najkrócej:

text

CoreDNS
-> "gdzie?"

network datapath
-> "jak tam dotrzeć?"