instruction: Explain Usługi, równoważenie obciążenia i sieci w Kubernetesie
output: Usługi, równoważenie obciążenia i sieci w Kubernetesie
  Pojęcia i zasoby związane z siecią w Kubernetesie.
  Model sieciowy Kubernetesa
  Model sieci Kubernetesa składa się z kilku części:
  Każdy
  otrzymuje swój własny unikalny adres IP w całym klastrze.
  Pod ma swoją własną, prywatną przestrzeń nazw sieci, która jest
  współdzielona przez wszystkie kontenery w ramach tego
  poda. Procesy działające w różnych kontenerach w tym samym
  podzie mogą komunikować się ze sobą za pośrednictwem
  localhost
  Sieć podów
  (znana również jako sieć klastra) obsługuje komunikację
  między podami. Zapewnia, że (z zastrzeżeniem celowego segmentowania sieci):
  Wszystkie pody mogą komunikować się ze wszystkimi innymi podami,
  niezależnie od tego, czy znajdują się na tym samym
  węźle
  , czy na różnych węzłach. Pody mogą
  komunikować się ze sobą bezpośrednio, bez użycia proxy ani translacji adresów (NAT).
  W systemie Windows ta reguła nie dotyczy podów z siecią hosta.
  Agenci na węźle (takie jak demony systemowe czy
  kubelet) mogą komunikować się ze wszystkimi podami na tym węźle.
  Obiekt API
  Service
  pozwala na udostępnienie stabilnego (długoterminowego) adresu IP lub nazwy
  hosta dla usługi zrealizowanej przez jeden lub więcej backendowych podów, gdzie
  poszczególne pody składające się na usługę mogą zmieniać się w czasie.
  Kubernetes automatycznie zarządza obiektami
  EndpointSlice
  dostarczać informacje o Podach obsługujących daną usługę.
  Implementacja proxy serwisu monitoruje zestaw obiektów Service i EndpointSlice,
  a także konfiguruje warstwę danych w celu
  kierowania ruchu serwisowego do jego backendów, używając API systemu
  operacyjnego lub dostawcy chmury do przechwytywania lub przepisania pakietów.
  Obiekt API
  Gateway
  (lub jego poprzednik,
  Ingress
  ) umożliwia udostępnienie usług klientom znajdującym się poza klastrem.
  Prostszy, ale mniej konfigurowalny mechanizm dostępu do klastra (Ingress) jest
  dostępny za pośrednictwem API usług (Service) z wykorzystaniem opcji
  type: LoadBalancer
  , pod warunkiem
  korzystania z obsługiwanego dostawcy chmury (
  Cloud Provider
  NetworkPolicy
  to wbudowane API Kubernetesa, które pozwala na
  kontrolowanie ruchu pomiędzy podami, lub pomiędzy podami a światem zewnętrznym.
  W starszych systemach kontenerowych nie było automatycznej łączności pomiędzy
  kontenerami na różnych hostach, więc często konieczne było jawne
  tworzenie połączeń między kontenerami lub mapowanie portów
  kontenerów na porty hostów, aby były osiągalne przez kontenery na
  innych hostach. W Kubernetesie nie jest to potrzebne; model Kubernetesa
  polega na tym, że pody mogą być traktowane podobnie jak maszyny
  wirtualne lub fizyczne hosty z perspektyw alokacji portów, nazewnictwa,
  wykrywania usług, równoważenia obciążenia, konfiguracji aplikacji i migracji.
  Tylko kilka części tego modelu jest implementowanych
  przez Kubernetesa samodzielnie. Dla pozostałych części
  Kubernetes definiuje API, ale odpowiadającą funkcjonalność
  zapewniają zewnętrzne komponenty, z których niektóre są opcjonalne:
  Konfiguracja przestrzeni nazw sieci poda jest obsługiwana przez oprogramowanie systemowe implementujące
  Interfejs Uruchomieniowy Kontenera (ang. Container Runtime Interface)
  Sama sieć podów jest zarządzana przez
  implementację sieci podów
  W systemie Linux, większość środowisk
  uruchomieniowych kontenerów używa
  Container Networking Interface (CNI)
  do interakcji z implementacją sieci
  podów, dlatego te implementacje często nazywane są
  wtyczkami CNI
  Kubernetes dostarcza domyślną implementację proxy usług,
  nazywaną
  kube-proxy
  , ale
  niektóre implementacje sieciowe poda używają zamiast tego własnego
  proxy usług, które jest ściślej zintegrowane z resztą implementacji.
  NetworkPolicy jest zazwyczaj również implementowane przez
  implementację sieci poda. (Niektóre prostsze implementacje sieci poda nie
  implementują NetworkPolicy, lub administrator może zdecydować się na
  skonfigurowanie sieci poda bez wsparcia dla NetworkPolicy. W takich
  przypadkach API będzie nadal obecne, ale nie będzie miało żadnego efektu.)
  Istnieje wiele
  implementacji Gateway API
  z których niektóre są specyficzne dla określonych środowisk
  chmurowych, inne bardziej skupione na środowiskach "bare metal", a jeszcze inne bardziej ogólne.
  Co dalej?
  Samouczek
  Łączenie aplikacji z usługami
  pozwala na naukę o Usługach i sieciach Kubernetesa poprzez praktyczne przykłady.
  Dokumentacja
  Sieci Klastra
  wyjaśnia, jak
  skonfigurować sieć dla twojego klastra, a także dostarcza przegląd użytych technologii.
  Twoja opinia
  Czy ta strona była przydatna?
  Dziękujemy za informację zwrotną. Jeśli masz konkretne pytanie dotyczące użycia Kubernetesa, odwiedź
  Stack Overflow
  Zgłoś problem w
  repozytorium GitHuba
  , jeśli chcesz
  zgłosić problem
  Zaproponuj ulepszenie
  Ostatnia modyfikacja February 16, 2025 at 4:17 PM PST:
  [pl] docs/concepts/services-networking/_index.md (0984eb3369)