Polish translation update 2020-08-12
Synchronize Polish translation with upstream changes up to fcd8af988c.
Co-authored-by: Karol Pucyński
Co-authored-by: Michał Sochoń
This commit is contained in:
Maciej Filocha
@@ -8,64 +8,3 @@ weight: 40
|
||||
<!-- overview -->
|
||||
|
||||
Rozdział dotyczący pojęć ma za zadanie pomóc w zrozumieniu poszczególnych składowych systemu oraz obiektów abstrakcyjnych, których Kubernetes używa do reprezentacji {{< glossary_tooltip text="klastra" term_id="cluster" length="all" >}}, a także posłużyć do lepszego poznania działania całego systemu.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Przegląd
|
||||
|
||||
Pracując w środowisku Kubernetes, używasz *obiektów API Kubernetes* aby opisać *zamierzony stan* klastra: jakie aplikacje lub inne zadania chcesz uruchomić, jakich obrazów kontenerów chcesz użyć, ilu replik potrzebujesz, które zasoby dyskowe i sieciowe chcesz udostępnić itp. Zamierzony stan uzyskuje się definiując obiekty API Kubernetes, zazwyczaj przy pomocy polecenia `kubectl`. Możesz także używać API bezpośrednio, aby konfigurować i modyfikować stan klastra.
|
||||
|
||||
Gdy tylko zdefiniujesz zamierzony stan, warstwa sterowania Kubernetes (*Kubernetes Control Plane*) podejmuje działania, aby aktualny stan klastra był zgodny ze stanem zamierzonym, wykorzystując do tego Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). W tym celu Kubernetes wykonuje szereg automatycznych zadań, takich jak start lub restart kontenerów, skalowanie liczby replik dla danej aplikacji itp. Warstwa sterowania Kubernetes to zbiór różnych procesów działających na klastrze:
|
||||
|
||||
* **Kubernetes Master** to zbiór trzech procesów uruchamianych na pojedynczym węźle klastra, który pełni rolę węzła _master_. Te procesy to: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) oraz [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
* Na każdym węźle klastra, nie będącym węzłem typu _Master_, działają dwa procesy:
|
||||
* **[kubelet](/docs/admin/kubelet/)**, który komunikuje się z Kubernetes Master.
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, proxy sieciowe pośredniczące w usługach sieciowych Kubernetes.
|
||||
|
||||
## Obiekty Kubernetes
|
||||
|
||||
Kubernetes składa się z różnych abstrakcyjnych obiektów, które reprezentują stan systemu: wdrożone aplikacje i zadania w kontenerach, powiązane zasoby sieciowe i dyskowe oraz inne informacje o tym, co się dzieje na klasterze. Te abstrakcyjne obiekty są reprezentowane przez API Kubernetes. [Opis obiektów w Kubernetesie](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) zawiera więcej szczegółów na ten temat.
|
||||
|
||||
Do podstawowych obiektów Kubernetes należą:
|
||||
|
||||
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Service *(Serwis)*](/docs/concepts/services-networking/service/)
|
||||
* [Volume *(Wolumin)*](/docs/concepts/storage/volumes/)
|
||||
* [Namespace *(Przestrzeń nazw)*](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
Kubernetes zawiera także obiekty abstrakcyjne wyższego poziomu, zbudowane z obiektów podstawowych przy wykorzystaniu [kontrolerów](/docs/concepts/architecture/controller/), które dostarczają dodatkowe funkcjonalności i udogodnienia. Należą do nich:
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Job](/docs/concepts/workloads/controllers/job/)
|
||||
|
||||
## Warstwa sterowania (*Kubernetes Control Plane*) {#warstwa-sterowania}
|
||||
|
||||
Różne komponenty warstwy sterowania, takie jak: *Kubernetes Master* czy *kubelet*, odpowiadają za to, jak Kubernetes komunikuje się z klastrem. Warstwa sterowania przechowuje informacje o wszystkich obiektach Kubernetes w systemie i w sposób ciągły steruje ich stanem. Pętle sterowania reagują na zmiany zachodzące w klastrze w sposób ciągły, starając się doprowadzić, aby stan faktyczny wszystkich obiektów odpowiadał stanowi zamierzonemu przez użytkownika.
|
||||
|
||||
Przykładowo, kiedy używasz Kubernetes API do stworzenia Deploymentu, podajesz oczekiwany stan systemu. Warstwa sterowania Kubernetes zapisuje stworzenie tego obiektu, a następnie realizuje Twoje polecenie startując wymagane aplikacje i zlecając ich uruchomienie na węzłach klastra - w ten sposób starając się zapewnić, że faktyczny stan klastra jest zgodny ze stanem zamierzonym.
|
||||
|
||||
### Kubernetes Master
|
||||
|
||||
*Kubernetes Master* odpowiada za utrzymanie klastra w zamierzonym stanie. Za każdym razem, kiedy korzystasz z `kubectl`, łączysz się z węzłem typu *master* danego klastra.
|
||||
|
||||
> "*Master*" odnosi się do zbioru procesów zarządzających stanem klastra. Zazwyczaj procesy te są uruchomione na pojedynczym węźle klastra, który jest określany jako "master". Master może być też zreplikowany w celu zagwarantowania wyższej dostępności i niezawodności.
|
||||
|
||||
### Węzły (*Kubernetes Nodes*) {#wezly}
|
||||
|
||||
Węzły klastra to maszyny (wirtualne, fizyczne i in.), na których uruchamiane są aplikacje i inne zadania. Kubernetes master steruje każdym z węzłów — rzadko kiedy zachodzi konieczność bezpośredniej interakcji z węzłami.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Jeśli chcesz dodać stronę z nowym pojęciem, odwiedź
|
||||
[Page Content Types](/docs/contribute/style/page-content-types/#concept),
|
||||
aby dowiedzieć się o tworzeniu stron opisujących pojęcia.
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
title: "Przegląd"
|
||||
weight: 20
|
||||
---
|
||||
description: Ogólny zarys Kubernetesa i komponentów, z których jest zbudowany.
|
||||
---
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
title: Składniki Kubernetes
|
||||
title: Składniki Kubernetesa
|
||||
content_type: concept
|
||||
description: >
|
||||
Klaster Kubernetesa tworzą: komponenty warstwy sterowania
|
||||
oraz zbiór maszyn nazywanych węzłami.
|
||||
weight: 20
|
||||
card:
|
||||
name: concepts
|
||||
|
||||
@@ -2,6 +2,9 @@
|
||||
title: API Kubernetes
|
||||
content_type: concept
|
||||
weight: 30
|
||||
description: >
|
||||
API Kubernetesa służy do odpytywania i zmiany stanu obiektów Kubernetesa.
|
||||
Sercem warstwy sterowania Kubernetesa jest serwer API i udostępniane przez niego HTTP API. Przez ten serwer odbywa się komunikacja pomiędzy użytkownikami, różnymi częściami składowymi klastra oraz komponentami zewnętrznymi.
|
||||
card:
|
||||
name: concepts
|
||||
weight: 30
|
||||
@@ -17,9 +20,6 @@ API Kubernetes pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: p
|
||||
|
||||
Punkt dostępowe _(endpoints)_ API, typy zasobów i przykłady opisane są w [API Reference](/docs/reference/kubernetes-api/).
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Zmiany w API
|
||||
@@ -80,7 +80,7 @@ W Kubernetes zaimplementowany jest alternatywny format serializacji na potrzeby
|
||||
|
||||
Aby ułatwić usuwanie poszczególnych pól lub restrukturyzację reprezentacji zasobów, Kubernetes obsługuje
|
||||
równocześnie wiele wersji API, każde poprzez osobną ścieżkę API, na przykład: `/api/v1` lub
|
||||
`/apis/extensions/v1beta1`.
|
||||
`/apis/rbac.authorization.k8s.io/v1alpha1`.
|
||||
|
||||
Zdecydowaliśmy się na rozdział wersji na poziomie całego API, a nie na poziomie poszczególnych zasobów lub pól, aby być pewnym,
|
||||
że API odzwierciedla w sposób przejrzysty i spójny zasoby systemowe i ich zachowania i pozwala
|
||||
@@ -127,7 +127,7 @@ Obecne w użyciu jest kilka grup API:
|
||||
1. Nazwane grupy udostępnione są przez ścieżkę REST `/apis/$GROUP_NAME/$VERSION` i używają `apiVersion: $GROUP_NAME/$VERSION`
|
||||
(np. `apiVersion: batch/v1`). Pełna lista wpieranych grup API jest dostępna w [Kubernetes API reference](/pl/docs/reference/).
|
||||
|
||||
API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/concepts/api-extension/custom-resources/):
|
||||
API może być rozbudowane na dwa sposoby przy użyciu [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/):
|
||||
|
||||
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
|
||||
jest przewidziana dla użytkowników z minimalnymi wymaganiami CRUD.
|
||||
@@ -147,20 +147,11 @@ Ta opcja przyjmuje rozdzielony przecinkami zbiór par klucz=wartość, który op
|
||||
{{< note >}}Włączenie lub wyłączenie grup lub zasobów wymaga restartu kube-apiserver i kube-controller-manager,
|
||||
aby zmiany w `--runtime-config` zostały wprowadzone.{{< /note >}}
|
||||
|
||||
## Dostęp do grup zasobów _extensions/v1beta1_
|
||||
|
||||
DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs i ReplicaSets znajdują się w grupie API `extensions/v1beta1` i są domyślnie wyłączone.
|
||||
Przykładowo: aby włączyć deployments i daemonsets, ustaw
|
||||
`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
|
||||
|
||||
{{< note >}}Włączanie i wyłączanie pojedynczych zasobów możliwe jest jedynie w ramach grupy API `extensions/v1beta1` z przyczyn historycznych{{< /note >}}
|
||||
|
||||
## Trwałość
|
||||
|
||||
Kubernetes przechowuje swój stan w postaci serializowanej jako zasoby API zapisywane w
|
||||
{{< glossary_tooltip term_id="etcd" >}}.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) opisuje
|
||||
|
||||
Reference in New Issue
Block a user