[pl] sync with PRs 47674, 47677, 46260, 44963, 41584

Author: dkarczmarski

content/pl/docs/concepts/overview/components.md

@@ -2,117 +2,87 @@
 title: Składniki Kubernetesa
 content_type: concept
 description: >
-  Klaster Kubernetesa tworzą: komponenty warstwy sterowania
-  oraz zbiór maszyn nazywanych węzłami.
-weight: 30
-card: 
+  Omówienie głównych elementów tworzących klaster Kubernetesa.
+weight: 10
+card:
+  title: Komponenty klastra
   name: concepts
   weight: 20
 ---
 
-<!-- overview -->
-W wyniku instalacji Kubernetesa otrzymujesz klaster.
-
-{{< glossary_definition term_id="cluster" length="all" prepend="Klaster Kubernetes to">}}
-
-W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, poprawnie działającego klastra Kubernetesa.
-
-{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Składniki Kubernetesa" caption="Części składowe klastra Kubernetes" class="diagram-large" >}}
-
-<!-- body -->
-## Części składowe warstwy sterowania
-
-Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik).
-
-Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie, a jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) znajdziesz opis konfiguracji warstwy sterowania działającej na wielu maszynach.
-
-### kube-apiserver
-
-{{< glossary_definition term_id="kube-apiserver" length="all" >}}
 
-### etcd
 
-{{< glossary_definition term_id="etcd" length="all" >}}
-
-### kube-scheduler
-
-{{< glossary_definition term_id="kube-scheduler" length="all" >}}
-
-### kube-controller-manager
-
-{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
-
-Przykładowe kontrolery:
-
-* Node controller: Odpowiada za rozpoznawanie i reagowanie na sytuacje, kiedy węzeł staje się z jakiegoś powodu niedostępny.
-* Job controller: Czeka na obiekty typu *Job*, które definiują zadania uruchamiane jednorazowo
-  i startuje Pody, odpowiadające za ich wykonanie tych zadań.
-* EndpointSlice controller: Dostarcza informacji do obiektów typu *EndpointSlice* (aby zapewnić połaczenie pomiędzy Serwisami i Podami).
-* ServiceAccount controllers: Tworzy domyślne konta dla nowych przestrzeni nazw (*namespaces*).
-
-### cloud-controller-manager
+<!-- overview -->
 
-{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
+Ta strona zawiera wysokopoziomy przegląd niezbędnych komponentów, które tworzą klaster Kubernetesa.
 
-cloud-controller-manager uruchamia jedynie kontrolery właściwe dla konkretnego dostawcy usług chmurowych.
-Jeśli uruchamiasz Kubernetesa we własnym centrum komputerowym lub w środowisku szkoleniowym na swoim
-komputerze, klaster nie będzie miał cloud controller managera.
+{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Komponenty Kubernetesa" caption="Komponenty klastra Kubernetesa" class="diagram-large" clicktozoom="true" >}}
 
-Podobnie jak w przypadku kube-controller-manager, cloud-controller-manager łączy w jednym pliku binarnym
-kilka niezależnych pętli sterowania. Można go skalować horyzontalnie
-(uruchomić więcej niż jedną instancję), aby poprawić wydajność lub zwiększyć odporność na awarie.
+<!-- body -->
 
-Następujące kontrolery mogą zależeć od dostawców usług chmurowych:
+## Składniki Kubernetesa {#core-components}
 
-* Node controller: Aby sprawdzić u dostawcy usługi chmurowej, czy węzeł został skasowany po tym, jak przestał odpowiadać
-* Route controller: Aby ustawić trasy *(routes)* w niższych warstwach infrastruktury chmurowej
-* Service controller: Aby tworzyć, aktualizować i kasować *cloud load balancers*
+Klaster Kubernetesa składa się z warstwy sterowania oraz jednego
+lub więcej węzłów roboczych. Oto krótki przegląd głównych komponentów:
 
-## Składniki węzłów
+### Części składowe warstwy sterowania {#control-plane-components}
 
-Składniki węzłów uruchomiane są na każdym węźle. Utrzymują pody w działaniu i ustawiają środowisko uruchomieniowe Kubernetes.
+Zarządzanie ogólnym stanem klastra:
 
-### kubelet
+[kube-apiserver](/docs/concepts/architecture/#kube-apiserver)
+: Podstawowy komponent udostępniający interfejs API Kubernetesa przez HTTP
 
-{{< glossary_definition term_id="kubelet" length="all" >}}
+[etcd](/docs/concepts/architecture/#etcd)
+: Stabilna i wysoko dostępna baza danych typu klucz-wartość, wykorzystywana do przechowywania stanu całego klastra Kubernetesa.
 
-### kube-proxy
+[kube-scheduler](/docs/concepts/architecture/#kube-scheduler)
+: Wyszukuje Pody, które nie zostały jeszcze przypisane do węzła, i przydziela każdy Pod do odpowiedniego węzła.
 
-{{< glossary_definition term_id="kube-proxy" length="all" >}}
+[kube-controller-manager](/docs/concepts/architecture/#kube-controller-manager)
+: Uruchamia {{< glossary_tooltip text="kontrolery" term_id="controller" >}} realizujące logikę działania API Kubernetesa.
 
-### Container runtime
+[cloud-controller-manager](/docs/concepts/architecture/#cloud-controller-manager) (opcjonalne)
+: Zapewnia integrację klastra Kubernetesa z infrastrukturą dostarczaną przez zewnętrznych dostawców chmurowych.
 
-{{< glossary_definition term_id="container-runtime" length="all" >}}
+### Składniki węzłów {#node-components}
 
-## Dodatki (*Addons*) {#dodatki}
+Działa na każdym węźle klastra, odpowiada za utrzymanie aktywnych podów oraz zapewnienie środowiska uruchomieniowego Kubernetesa:
 
-Dodatki korzystają z podstawowych obiektów Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, itp.), aby rozszerzyć funkcjonalności klastra. Ponieważ są to funkcjonalności obejmujące cały klaster, zasoby te należą do przestrzeni nazw *(namespace)* `kube-system`.
+[kubelet](/docs/concepts/architecture/#kubelet)
+: Odpowiada za nadzorowanie, czy pody oraz ich kontenery są uruchomione i działają zgodnie z oczekiwaniami.
 
-Wybrane dodatki opisano poniżej. Rozszerzona lista dostępnych dodatków jest w części [Dodatki](/docs/concepts/cluster-administration/addons/).
+[kube-proxy](/docs/concepts/architecture/#kube-proxy) (opcjonalne)
+: Utrzymuje reguły sieciowe na węzłach w celu obsługi komunikacji z {{< glossary_tooltip text="usługami (ang. Service)" term_id="service" >}}.
 
-### DNS
+[Środowisko uruchomieniowe kontenerów](/docs/concepts/architecture/#container-runtime)
+: Oprogramowanie odpowiedzialne za uruchamianie kontenerów. Przeczytaj [Środowiska uruchomieniowe kontenerów](/docs/setup/production-environment/container-runtimes/), aby dowiedzieć się więcej.
 
-Mimo, że inne dodatki nie są bezwzględnie wymagane, wszystkie klastry Kubernetes powinny mieć [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), ponieważ wiele przykładów z niego korzysta.
+{{% thirdparty-content single="true" %}}
 
-*Cluster DNS* to serwer DNS, który uzupełnienia inne serwery DNS z twojego środowiska, dostarczając informacje o rekordach DNS dla usług Kubernetes.
+Klaster może wymagać dodatkowego oprogramowania na każdym węźle; możesz na przykład uruchomić
+[systemd](https://systemd.io/) na węzłach z systemem Linux do monitorowania i zarządzania lokalnymi usługami.
 
-Kontenery uruchomione przez Kubernetes automatycznie przeszukują ten serwer DNS.
+## Dodatki (Addons) {#addons}
 
-### Interfejs użytkownika (Dashboard)
+Dodatki rozszerzają funkcjonalność Kubernetesa. Oto kilka ważnych przykładów:
 
-[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) to webowy interfejs ogólnego zastosowania przeznaczony dla użytkowników klastra Kubernetes. Umożliwia zarządzanie i rozwiązywanie problemów związanych z aplikacjami uruchamianymi na klastrze, a także z samym klastrem.
+[DNS](/docs/concepts/architecture/#dns)
+: Umożliwia rozpoznawanie nazw DNS dla usług i komponentów działających w całym klastrze
 
-### Monitorowanie zasobów w kontenerach
+[Web UI](/docs/concepts/architecture/#web-ui-dashboard) (Dashboard)
+: Umożliwia zarządzanie klastrem Kubernetesa poprzez webowy interfejs.
 
-[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) zapisuje serie czasowe podstawowych metryk kontenerów w centralnej bazie danych i oferuje interfejs użytkownika do przeglądania tych danych.
+[Monitorowanie zasobów kontenera](/docs/concepts/architecture/#container-resource-monitoring)
+: Służy do monitorowania zasobów kontenerów poprzez gromadzenie i zapisywanie danych o ich wydajności.
 
-### Logowanie na poziomie klastra
+[Logowanie na poziomie klastra](/docs/concepts/architecture/#cluster-level-logging)
+: Umożliwia zbieranie i przechowywanie logów z kontenerów w centralnym systemie logowania dostępnym na poziomie całego klastra.
 
-Mechanizm [logowania na poziomie klastra](/docs/concepts/cluster-administration/logging/) odpowiada za zapisywanie logów pochodzących z poszczególnych kontenerów do wspólnego magazynu, który posiada interfejs do przeglądania i przeszukiwania.
+## Elastyczność architektury {#flexibility-in-architecture}
 
-## {{% heading "whatsnext" %}}
+Dzięki elastycznej architekturze Kubernetesa można dostosować sposób
+wdrażania i zarządzania poszczególnymi komponentami do konkretnych wymagań - od prostych
+klastrów deweloperskich po złożone systemy produkcyjne na dużą skalę.
 
-* Więcej o [Węzłach](/docs/concepts/architecture/nodes/)
-* Więcej o [Kontrolerach](/docs/concepts/architecture/controller/)
-* Więcej o [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
-* Oficjalna [dokumentacja](https://etcd.io/docs/) etcd
+Szczegółowe informacje o każdym komponencie oraz różnych sposobach konfiguracji
+architektury klastra znajdziesz na stronie [Architektura klastra](/docs/concepts/architecture/).