|
| 1 | +--- |
| 2 | +title: Składniki Kubernetes |
| 3 | +content_template: templates/concept |
| 4 | +weight: 20 |
| 5 | +card: |
| 6 | +name: concepts |
| 7 | +weight: 20 |
| 8 | +--- |
| 9 | + |
| 10 | +{{% capture overview %}} |
| 11 | +W wyniku instalacji Kubernetes otrzymujesz klaster. |
| 12 | + |
| 13 | +{{< glossary_definition term_id="cluster" length="all" prepend="Klaster to">}} |
| 14 | + |
| 15 | +W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, poprawnie działającego klastra Kubernetes. |
| 16 | + |
| 17 | +Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego różnymi częściami składowymi. |
| 18 | + |
| 19 | + |
| 20 | +{{% /capture %}} |
| 21 | + |
| 22 | +{{% capture body %}} |
| 23 | +## Master — częsci składowe |
| 24 | + |
| 25 | +Komponenty *master* odpowiadają za warstwę sterowania klastra. Podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), 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). |
| 26 | + |
| 27 | +Komponenty *master* mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*. |
| 28 | + |
| 29 | +### kube-apiserver |
| 30 | + |
| 31 | +{{< glossary_definition term_id="kube-apiserver" length="all" >}} |
| 32 | + |
| 33 | +### etcd |
| 34 | + |
| 35 | +{{< glossary_definition term_id="etcd" length="all" >}} |
| 36 | + |
| 37 | +### kube-scheduler |
| 38 | + |
| 39 | +{{< glossary_definition term_id="kube-scheduler" length="all" >}} |
| 40 | + |
| 41 | +### kube-controller-manager |
| 42 | + |
| 43 | +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} |
| 44 | + |
| 45 | +Kontrolerami są: |
| 46 | + |
| 47 | +* Node Controller: Odpowiada za rozpoznawanie i reagowanie na sytuacje, kiedy węzeł staje się z jakiegoś powodu niedostępny. |
| 48 | +* Replication Controller: Odpowiada za utrzymanie prawidłowej liczby podów dla każdego obiektu typu *ReplicationController* w systemie. |
| 49 | +* Endpoints Controller: Dostarcza informacji do obiektów typu *Endpoints* (tzn. łączy ze sobą Serwisy i Pody). |
| 50 | +* Service Account & Token Controllers: Tworzy domyślne konta i tokeny dostępu API dla nowych przestrzeni nazw (*namespaces*). |
| 51 | + |
| 52 | +### cloud-controller-manager |
| 53 | + |
| 54 | +[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) uruchamia kontroler, który komunikuje się z usługami dostawcy chmury, na których zbudowany jest klaster. Oprogramowanie cloud-controller-manager, wprowadzone w Kubernetes 1.6 ma status rozwojowy beta. |
| 55 | + |
| 56 | +cloud-controller-manager wykonuje tylko pętle sterowania konkretnych dostawców usług chmurowych. Wykonywanie tych pętli sterowania musi być wyłączone w kube-controller-manager. Wyłączenie następuje poprzez ustawienie opcji `--cloud-provider` jako `external` przy starcie kube-controller-manager. |
| 57 | + |
| 58 | +cloud-controller-manager umożliwia rozwój oprogramowania dostawców usług chmurowych niezależnie od samego oprogramowania Kubernetes. W poprzednich wersjach, główny kod Kubernetes był zależny od kodu dostarczonego przez zewnętrznych dostawców różnych usług chmurowych. W przyszłych wydaniach, oprogramowanie związane z dostawcami chmurowymi będzie utrzymywane przez nich samych i podłączane do cloud-controller-managera w trakcie uruchamiana Kubernetes. |
| 59 | + |
| 60 | +Następujące kontrolery zależą od dostawców usług chmurowych: |
| 61 | + |
| 62 | +* Node Controller: Aby sprawdzić u dostawcy usługi chmurowej, czy węzeł został skasowany po tym, jak przestał odpowiadać |
| 63 | +* Route Controller: Aby ustawić trasy *(routes)* w niższych warstwach infrastruktury chmurowej |
| 64 | +* Service Controller: Aby tworzyć, aktualizować i kasować *cloud load balancers* |
| 65 | +* Volume Controller: Aby tworzyć, podłączać i montować woluminy oraz zarządzać nimi przez dostawcę usług chmurowych |
| 66 | + |
| 67 | +## Składniki węzłów |
| 68 | + |
| 69 | +Składniki węzłów uruchomiane są na każdym węźle. Utrzymują pody w działaniu i ustawiają środowisko uruchomieniowe Kubernetes. |
| 70 | + |
| 71 | +### kubelet |
| 72 | + |
| 73 | +{{< glossary_definition term_id="kubelet" length="all" >}} |
| 74 | + |
| 75 | +### kube-proxy |
| 76 | + |
| 77 | +{{< glossary_definition term_id="kube-proxy" length="all" >}} |
| 78 | + |
| 79 | +### Container Runtime |
| 80 | + |
| 81 | +{{< glossary_definition term_id="container-runtime" length="all" >}} |
| 82 | + |
| 83 | +## Dodatki (*Addons*) {#dodatki} |
| 84 | + |
| 85 | +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`. |
| 86 | + |
| 87 | +Wybrane dodatki opisano poniżej. Rozszerzona lista dostępnych dodatków jest w części [Dodatki](/docs/concepts/cluster-administration/addons/). |
| 88 | + |
| 89 | +### DNS |
| 90 | + |
| 91 | +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. |
| 92 | + |
| 93 | +*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. |
| 94 | + |
| 95 | +Kontenery uruchomione przez Kubernetes automatycznie przeszukują ten serwer DNS. |
| 96 | + |
| 97 | +### Interfejs użytkownika (Dasard) |
| 98 | + |
| 99 | +[Dasard](/docs/tasks/access-application-cluster/web-ui-dasard/) 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. |
| 100 | + |
| 101 | +### Monitorowanie zasobów w kontenerach |
| 102 | + |
| 103 | +[Container Resource Monitoring](/docs/tasks/debug-application-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. |
| 104 | + |
| 105 | +### Logowanie na poziomie klastra |
| 106 | + |
| 107 | +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. |
| 108 | + |
| 109 | +{{% /capture %}} |
| 110 | +{{% capture whatsnext %}} |
| 111 | +* Więcej o [Węzłach](/docs/concepts/architecture/nodes/) |
| 112 | +* Więcej o [Kontrolerach](/docs/concepts/architecture/controller/) |
| 113 | +* Więcej o [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) |
| 114 | +* Oficjalna [dokumentacja](https://etcd.io/docs/) etcd |
| 115 | +{{% /capture %}} |
0 commit comments