Dokumentacja

• 1: Kubernetes — Dokumentacja
• 1.1: Dostępne wersje dokumentacji
• 2: Od czego zacząć
• 3: Pojęcia
• 3.1: Przegląd
• 3.1.1: Składniki Kubernetesa
• 3.1.2: API Kubernetesa
• 3.2: Windows w Kubernetesie
• 4: Zadania
• 5: Samouczki
• 5.1: Hello Minikube
• 5.2: Naucz się podstaw
• 5.2.1: Tworzenie klastra
• 5.2.1.1: Jak użyć Minikube do stworzenia klastra
• 5.2.2: Instalowanie aplikacji
• 5.2.2.1: Jak użyć kubectl do tworzenia Deploymentu
• 5.2.3: Poznawanie aplikacji
• 5.2.3.1: Pody i Węzły
• 5.2.4: Udostępnianie aplikacji
• 5.2.4.1: Jak używać Service do udostępniania aplikacji
• 5.2.5: Skalowanie aplikacji
• 5.2.5.1: Uruchamianie wielu instancji aplikacji
• 5.2.6: Aktualizowanie aplikacji
• 5.2.6.1: Aktualizacje Rolling Update
• 6: Materiały źródłowe
• 6.1: Słownik
• 7: Współtwórz dokumentację K8s
• 7.1: Zgłaszanie propozycji poprawy treści
• 7.2: Dokumentowanie funkcji nowego wydania
• 7.3: Przeglądanie zmian
• 7.4: Aktualizacja materiałów źródłowych
• 7.5: Styl dokumentacji
• 7.5.1: Typy treści
• 7.6: Tłumaczenie dokumentacji na język polski
• 8:

1 - Kubernetes — Dokumentacja

1.1 - Dostępne wersje dokumentacji

Ten serwis zawiera dokumentację do bieżącej i czterech poprzednich wersji Kubernetesa.

Dostępność dokumentacji obejmującej konkretną wersję Kubernetesa nie oznacza automatycznie, że dana wersja Kubernetesa jest ciągle aktywnie wspierana. Zajrzyj do dokumentu Support period, aby dowiedzieć się, do kiedy objęte wsparciem są poszczególne wersje Kubernetesa.

2 - Od czego zacząć

Ten rozdział poświęcony jest różnym metodom konfiguracji i uruchomienia Kubernetesa. Instalując Kubernetesa, przy wyborze platformy kieruj się: łatwością w utrzymaniu, spełnianymi wymogami bezpieczeństwa, poziomem sterowania, dostępnością zasobów oraz doświadczeniem wymaganym do zarządzania klastrem.

Możesz pobrać Kubernetesa, aby zainstalować klaster na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym.

Niektóre komponenty Kubernetesa, na przykład `kube-apiserver czy kube-proxy mogą być uruchamiane jako kontenery wewnątrz samego klastra.

Zalecamy uruchamianie komponentów Kubernetesa jako kontenery zawsze, kiedy jest to możliwe i na zarządzanie nimi przez samego Kubernetesa. Do tej kategorii nie należą komponenty odpowiedzialne za uruchamianie kontenerów, w szczególności - kubelet.

Jeśli nie chcesz zarządzać klastrem Kubernetesa samodzielnie, możesz wybrać serwis zarządzany przez zewnętrznego dostawcę, wybierając na przykład spośród certyfikowanych platform. Dostępne są także inne standardowe i specjalizowane rozwiązania dla różnych środowisk chmurowych bądź bazujące bezpośrednio na sprzęcie fizycznym.

Środowisko do nauki

Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym. Zapoznaj się z narzędziami instalacyjnymi.

Środowisko produkcyjne

Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (abstrakcjami) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora.

Do instalacji klastra Kubernetesa zarządzanego samodzielnie oficjalnym narzędziem jest kubeadm.

Co dalej?

• Pobierz Kubernetesa
• Pobierz i zainstaluj narzędzia, w tym kubectl
• Wybierz środowisko uruchomieniowe dla kontenerów w nowym klastrze
• Naucz się najlepszych praktyk przy konfigurowaniu klastra

Kubernetes zaprojektowano w ten sposób, że warstwa sterowania wymaga do działania systemu Linux. W ramach klastra aplikacje mogą być uruchamiane na systemie Linux i innych, w tym Windows.

• Naucz się, jak zbudować klaster z węzłami Windows

3 - Pojęcia

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 klastra, a także posłużyć do lepszego poznania działania całego systemu.

3.1 - Przegląd

Na tej stronie znajdziesz ogólne informacje o Kubernetesie.

Kubernetes to przenośna, rozszerzalna platforma oprogramowania open-source służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach, która umożliwia deklaratywną konfigurację i automatyzację. Ekosystem Kubernetesa jest duży i dynamicznie się rozwija. Usługi dla Kubernetesa, wsparcie i narzędzia są szeroko dostępne.

Nazwa Kubernetes pochodzi z języka greckiego i oznacza sternika albo pilota. Skrót K8s powstał poprzez zastąpienie ośmiu liter pomiędzy "K" i "s". Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność.

Trochę historii

Aby zrozumieć, dlaczego Kubernetes stał się taki przydatny, cofnijmy sie trochę w czasie.

Era wdrożeń tradycyjnych: Na początku aplikacje uruchamiane były na fizycznych serwerach. Nie było możliwości separowania zasobów poszczególnych aplikacji, co prowadziło do problemów z alokacją zasobów. Przykładowo, kiedy wiele aplikacji jest uruchomionych na jednym fizycznym serwerze, część tych aplikacji może zużyć większość dostępnych zasobów, powodując spowolnienie działania innych. Rozwiązaniem tego problemu mogło być uruchamianie każdej aplikacji na osobnej maszynie. Niestety, takie podejście ograniczało skalowanie, ponieważ większość zasobów nie była w pełni wykorzystywana, a utrzymanie wielu fizycznych maszyn było kosztowne.

Era wdrożeń w środowiskach wirtualnych: Jako rozwiązanie zaproponowano wirtualizację, która umożliwia uruchamianie wielu maszyn wirtualnych (VM) na jednym procesorze fizycznego serwera. Wirtualizacja pozwala izolować aplikacje pomiędzy maszynami wirtualnymi, zwiększając w ten sposób bezpieczeństwo, jako że informacje związane z jedną aplikacją nie są w łatwy sposób dostępne dla pozostałych.

Wirtualizacja pozwala lepiej wykorzystywać zasoby fizycznego serwera i lepiej skalować, ponieważ aplikacje mogą być łatwo dodawane oraz aktualizowane, pozwala ograniczyć koszty sprzętu oraz ma wiele innych zalet. Za pomocą wirtualizacji można udostępnić wybrane zasoby fizyczne jako klaster maszyn wirtualnych "wielokrotnego użytku".

Każda maszyna wirtualna jest pełną maszyną zawierającą własny system operacyjny pracujący na zwirtualizowanej warstwie sprzętowej.

Era wdrożeń w kontenerach: Kontenery działają w sposób zbliżony do maszyn wirtualnych, ale mają mniejszy stopnień wzajemnej izolacji, współdzieląc ten sam system operacyjny. Kontenery określane są mianem "lekkich". Podobnie, jak maszyna wirtualna, kontener posiada własny system plików, udział w zasobach procesora, pamięć, przestrzeń procesów itd. Ponieważ kontenery są definiowane rozłącznie od leżących poniżej warstw infrastruktury, mogą być łatwiej przenoszone pomiędzy chmurami i różnymi dystrybucjami systemu operacyjnego.

Kontenery zyskały popularność ze względu na swoje zalety, takie jak:

• Szybkość i elastyczność w tworzeniu i instalacji aplikacji: obraz kontenera buduje się łatwiej niż obraz VM.
• Ułatwienie ciągłego rozwoju, integracji oraz wdrażania aplikacji (Continuous development, integration, and deployment): obrazy kontenerów mogą być budowane w sposób wiarygodny i częsty. W razie potrzeby, przywrócenie poprzedniej wersji aplikacji jest stosunkowo łatwie (ponieważ obrazy są niezmienne).
• Rozdzielenie zadań Dev i Ops: obrazy kontenerów powstają w fazie build/release, a nie w trakcie procesu instalacji, oddzielając w ten sposób aplikacje od infrastruktury.
• Obserwowalność obejmuje nie tylko informacje i metryki z poziomu systemu operacyjnego, ale także poprawność działania samej aplikacji i inne sygnały.
• Spójność środowiska na etapach rozwoju oprogramowania, testowania i działania w trybie produkcyjnym: działa w ten sam sposób na laptopie i w chmurze.
• Możliwość przenoszenia pomiędzy systemami operacyjnymi i platformami chmurowymi: Ubuntu, RHEL, CoreOS, prywatnymi centrami danych, największymi dostawcami usług chmurowych czy gdziekolwiek indziej.
• Zarządzanie, które w centrum uwagi ma aplikacje: Poziom abstrakcji przeniesiony jest z warstwy systemu operacyjnego działającego na maszynie wirtualnej na poziom działania aplikacji, która działa na systemie operacyjnym używając zasobów logicznych.
• Luźno powiązane, rozproszone i elastyczne "swobodne" mikro serwisy: Aplikacje podzielone są na mniejsze, niezależne komponenty, które mogą być dynamicznie uruchamiane i zarządzane - nie jest to monolityczny system działający na jednej, dużej maszynie dedykowanej na wyłączność.
• Izolacja zasobów: wydajność aplikacji możliwa do przewidzenia
• Wykorzystanie zasobów: wysoka wydajność i upakowanie.

Do czego potrzebujesz Kubernetesa i jakie są jego możliwości

Kontenery są dobrą metodą na opakowywanie i uruchamianie aplikacji. W środowisku produkcyjnym musisz zarządzać kontenerami, w których działają aplikacje i pilnować, aby nie było żadnych przerw w ich dostępności. Przykładowo, kiedy jeden z kontenerów przestaje działać, musi zostać wymieniony. Nie byłoby prościej, aby takimi działaniami zajmował się jakiś system?

I tu właśnie przychodzi z pomocą Kubernetes! Kubernetes zapewnia środowisko do uruchamiania systemów rozproszonych o wysokiej niezawodności. Kubernetes obsługuje skalowanie aplikacji, przełączanie w sytuacjach awaryjnych, różne scenariusze wdrożeń itp. Przykładowo, Kubernetes w łatwy sposób może zarządzać wdrożeniem nowej wersji oprogramowania zgodnie z metodyką canary deployments.

Kubernetes zapewnia:

• Detekcję nowych serwisów i balansowanie ruchu Kubernetes może udostępnić kontener używając nazwy DNS lub swojego własnego adresu IP. Jeśli ruch przychodzący do kontenera jest duży, Kubernetes może balansować obciążenie i przekierować ruch sieciowy, aby zapewnić stabilność całej instalacji.
• Zarządzanie obsługą składowania danych Kubernetes umożliwia automatyczne montowanie systemów składowania danych dowolnego typu — lokalnych, od dostawców chmurowych i innych.
• Automatyczne wdrożenia i wycofywanie zmian Możesz opisać oczekiwany stan instalacji za pomocą Kubernetesa, który zajmie się doprowadzeniem w sposób kontrolowany stanu faktycznego do stanu oczekiwanego. Przykładowo, przy pomocy Kubernetesa możesz zautomatyzować proces tworzenia nowych kontenerów na potrzeby swojego wdrożenia, usuwania istniejących i przejęcia zasobów przez nowe kontenery.
• Automatyczne zarządzanie dostępnymi zasobami Twoim zadaniem jest dostarczenie klastra maszyn, które Kubernetes może wykorzystać do uruchamiania zadań w kontenerach. Określasz zapotrzebowanie na moc procesora i pamięć RAM dla każdego z kontenerów. Kubernetes rozmieszcza kontenery na maszynach w taki sposób, aby jak najlepiej wykorzystać dostarczone zasoby.
• Samoczynne naprawianie Kubernetes restartuje kontenery, które przestały działać, wymienia je na nowe, wymusza wyłączenie kontenerów, które nie odpowiadają na określone zapytania o stan i nie rozgłasza powiadomień o ich dostępności tak długo, dopóki nie są gotowe do działania.
• Zarządzanie informacjami poufnymi i konfiguracją Kubernetes pozwala składować i zarządzać informacjami poufnymi, takimi jak hasła, tokeny OAuth czy klucze SSH. Informacje poufne i zawierające konfigurację aplikacji mogą być dostarczane i zmieniane bez konieczności ponownego budowania obrazu kontenerów i bez ujawniania poufnych danych w ogólnej konfiguracji oprogramowania.

Czym Kubernetes nie jest

Kubernetes nie jest tradycyjnym, zawierającym wszystko systemem PaaS (Platform as a Service). Ponieważ Kubernetes działa w warstwie kontenerów, a nie sprzętu, posiada różne funkcjonalności ogólnego zastosowania, wspólne dla innych rozwiązań PaaS, takie jak: instalacje (deployments), skalowanie i balansowanie ruchu, umożliwiając użytkownikom integrację rozwiązań służących do logowania, monitoringu i ostrzegania. Co ważne, Kubernetes nie jest monolitem i domyślnie dostępne rozwiązania są opcjonalne i działają jako wtyczki. Kubernetes dostarcza elementy, z których może być zbudowana platforma deweloperska, ale pozostawia użytkownikowi wybór i elastyczność tam, gdzie jest to ważne.

Kubernetes:

• Nie ogranicza typów aplikacji, które są obsługiwane. Celem Kubernetesa jest możliwość obsługi bardzo różnorodnego typu zadań, włączając w to aplikacje bezstanowe (stateless), aplikacje ze stanem (stateful) i ogólne przetwarzanie danych. Jeśli jakaś aplikacja może działać w kontenerze, będzie doskonale sobie radzić w środowisku Kubernetesa.
• Nie oferuje wdrażania aplikacji wprost z kodu źródłowego i nie buduje aplikacji. Procesy Continuous Integration, Delivery, and Deployment (CI/CD) są zależne od kultury pracy organizacji, jej preferencji oraz wymagań technicznych.
• Nie dostarcza serwisów z warstwy aplikacyjnej, takich jak warstwy pośrednie middleware (np. broker wiadomości), środowiska analizy danych (np. Spark), bazy danych (np. MySQL), cache ani klastrowych systemów składowania danych (np. Ceph) jako usług wbudowanych. Te składniki mogą być uruchamiane na klastrze Kubernetes i udostępniane innym aplikacjom przez przenośne rozwiązania, takie jak Open Service Broker.
• Nie wymusza użycia konkretnych systemów zbierania logów, monitorowania ani ostrzegania. Niektóre z tych rozwiązań są udostępnione jako przykłady. Dostępne są też mechanizmy do gromadzenia i eksportowania różnych metryk.
• Nie dostarcza, ani nie wymusza języka/systemu używanego do konfiguracji (np. Jsonnet). Udostępnia API typu deklaratywnego, z którego można korzystać za pomocą różnych metod wykorzystujących deklaratywne specyfikacje.
• Nie zapewnia, ani nie wykorzystuje żadnego ogólnego systemu do zarządzania konfiguracją, utrzymaniem i samo-naprawianiem maszyn.
• Co więcej, nie jest zwykłym systemem planowania (orchestration). W rzeczywistości, eliminuje konieczność orkiestracji. Zgodnie z definicją techniczną, orkiestracja to wykonywanie określonego ciągu zadań: najpierw A, potem B i następnie C. Dla kontrastu, Kubernetes składa się z wielu niezależnych, możliwych do złożenia procesów sterujących, których zadaniem jest doprowadzenie stanu faktycznego do stanu oczekiwanego. Nie ma znaczenia, w jaki sposób przechodzi się od A do C. Nie ma konieczności scentralizowanego zarządzania. Dzięki temu otrzymujemy system, który jest potężniejszy, bardziej odporny i niezawodny i dający więcej możliwości rozbudowy.

Co dalej?

• Poczytaj o komponentach Kubernetesa
• Poczytaj o API Kubernetesa
• Poczytaj o architekturze klastra
• Jesteś gotowy zacząć pracę?

3.1.1 - Składniki Kubernetesa

W wyniku instalacji Kubernetesa otrzymujesz klaster.

Klaster Kubernetes to zestaw maszyn roboczych, nazywanych węzłami, na których uruchamiane są aplikacje w kontenerach. Każdy klaster musi posiadać przynajmniej jeden węzeł.

Na węźle (lub węzłach) roboczych rozmieszczane są pody, które są częściami składowymi aplikacji. Warstwa sterowania zarządza węzłami roboczymi i podami należącymi do klastra. W środowisku produkcyjnym warstwa sterowania rozłożona jest zazwyczaj na kilka maszyn, a klaster uruchomiony jest na wielu węzłach zapewniając większą niezawodność i odporność na awarie.

W tym dokumencie opisujemy składniki niezbędne do zbudowania kompletnego, poprawnie działającego klastra Kubernetesa.

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 poda, 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 znajdziesz opis konfiguracji warstwy sterowania działającej na wielu maszynach.

kube-apiserver

Serwer API jest składnikiem warstwy sterowania Kubernetesa, który udostępnia API. Server API służy jako front-end warstwy sterowania Kubernetesa.

Podstawową implementacją serwera API Kubernetesa jest kube-apiserver. kube-apiserver został zaprojektowany w taki sposób, aby móc skalować się horyzontalnie — to oznacza, że zwiększa swoją wydajność poprzez dodawanie kolejnych instancji. Można uruchomić kilka instancji kube-apiserver i rozkładać między nimi ruch od klientów.

etcd

Magazyn typu klucz-wartość (key/value store), zapewniający spójność i wysoką dostępność, używany do przechowywania wszystkich danych o klastrze Kubernetesa.

Jeśli Twój klaster Kubernetesa używa etcd do przechowywania swoich danych, upewnij się, że masz opracowany plan tworzenia kopii zapasowych tych danych.

Szczegółowe informacje na temat etcd można znaleźć w oficjalnej dokumentacji.

kube-scheduler

Składnik warstwy sterowania, który śledzi tworzenie nowych podów i przypisuje im węzły, na których powinny zostać uruchomione.

Przy podejmowaniu decyzji o wyborze węzła brane pod uwagę są wymagania indywidualne i zbiorcze odnośnie zasobów, ograniczenia wynikające z polityk sprzętu i oprogramowania, wymagania affinity i anty-affinity, lokalizacja danych, zależności między zadaniami i wymagania czasowe.

kube-controller-manager

Składnik warstwy sterowania odpowiedzialny za uruchamianie kontrolerów.

Z poziomu podziału logicznego, każdy kontroler jest oddzielnym procesem, ale w celu zmniejszenia złożoności, wszystkie kontrolery są skompilowane do jednego programu binarnego i uruchamiane jako jeden proces.

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

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.

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.

Następujące kontrolery mogą zależeć od dostawców usług chmurowych:

• 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

Składniki węzłów

Składniki węzłów uruchomiane są na każdym węźle. Utrzymują pody w działaniu i ustawiają środowisko uruchomieniowe Kubernetes.

kubelet

Agent, który działa na każdym węźle klastra. Odpowiada za uruchamianie kontenerów w ramach poda.

kubelet korzysta z dostarczanych (różnymi metodami) PodSpecs i gwarantuje, że kontenery opisane przez te PodSpecs są uruchomione i działają poprawnie. Kubelet nie zarządza kontenerami, które nie zostały utworzone przez Kubernetesa.

kube-proxy

kube-proxy to proxy sieciowe, które uruchomione jest na każdym węźle klastra i uczestniczy w tworzeniu serwisu.

kube-proxy utrzymuje reguły sieciowe na węźle. Dzięki tym regułom sieci na zewnątrz i wewnątrz klastra mogą komunikować się z podami.

kube-proxy używa warstwy filtrowania pakietów dostarczanych przez system operacyjny, o ile taka jest dostępna. W przeciwnym przypadku, kube-proxy samo zajmuje sie przekazywaniem ruchu sieciowego.

Container runtime

Podstawowy komponent umożliwiający efektywne uruchamianie kontenerów w Kubernetesie. Odpowiada za zarządzanie uruchamianiem i cyklem życia kontenerów w środowisku Kubernetes.

Kubernetes obsługuje różne container runtimes: containerd, CRI-O oraz każdą implementację zgodną z Kubernetes CRI (Container Runtime Interface).

Dodatki (Addons)

Dodatki korzystają z podstawowych obiektów Kubernetes (DaemonSet, 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.

Wybrane dodatki opisano poniżej. Rozszerzona lista dostępnych dodatków jest w części Dodatki.

DNS

Mimo, że inne dodatki nie są bezwzględnie wymagane, wszystkie klastry Kubernetes powinny mieć cluster DNS, ponieważ wiele przykładów z niego korzysta.

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.

Kontenery uruchomione przez Kubernetes automatycznie przeszukują ten serwer DNS.

Interfejs użytkownika (Dashboard)

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.

Monitorowanie zasobów w kontenerach

Container Resource Monitoring zapisuje serie czasowe podstawowych metryk kontenerów w centralnej bazie danych i oferuje interfejs użytkownika do przeglądania tych danych.

Logowanie na poziomie klastra

Mechanizm logowania na poziomie klastra 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.

Co dalej?

• Więcej o Węzłach
• Więcej o Kontrolerach
• Więcej o kube-scheduler
• Oficjalna dokumentacja etcd

3.1.2 - API Kubernetesa

Sercem warstwy sterowania Kubernetes jest serwer API. Serwer udostępnia API poprzez HTTP, umożliwiając wzajemną komunikację pomiędzy użytkownikami, częściami składowymi klastra i komponentami zewnętrznymi.

API Kubernetesa pozwala na sprawdzanie i zmianę stanu obiektów (przykładowo: pody, Namespaces, ConfigMaps, Events).

Większość operacji może zostać wykonana poprzez interfejs linii komend (CLI) kubectl lub inne programy, takie jak kubeadm, które używają API. Możesz też korzystać z API bezpośrednio przez wywołania typu REST.

Jeśli piszesz aplikację używającą API Kubernetesa, warto rozważyć użycie jednej z bibliotek klienckich.

Specyfikacja OpenAPI

Pełną specyfikację API udokumentowano za pomocą OpenAPI.

Serwer API Kubernetesa udostępnia specyfikację OpenAPI poprzez ścieżkę /openapi/v2. Aby wybrać format odpowiedzi, użyj nagłówków żądania zgodnie z tabelą:

W Kubernetesie zaimplementowany jest alternatywny format serializacji na potrzeby API oparty o Protobuf, który jest przede wszystkim przeznaczony na potrzeby wewnętrznej komunikacji w klastrze. Więcej szczegółów znajduje się w dokumencie Kubernetes Protobuf serialization. oraz w plikach Interface Definition Language (IDL) dla każdego ze schematów zamieszczonych w pakietach Go, które definiują obiekty API.

OpenAPI V3

Kubernetes v1.32 publikuje (na razie w wersji roboczej) własne API zgodnie ze specyfikacją OpenAPI v3. Ta funkcjonalność jest w wersji beta i jest domyślnie włączona. Funkcjonalności w wersji beta można wyłączać poprzez feature gate o nazwie OpenAPIV3 składnika kube-apiserver.

Pod adresem /openapi/v3 można znaleźć listę wszystkich dostępnych grup/wersji. Zwracane wartości są dostępne tylko w formacie JSON. Grupy/wersje opisane są następującym schematem:

{
    "paths": {
        ...,
        "api/v1": {
            "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"
        },
        "apis/admissionregistration.k8s.io/v1": {
            "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"
        },
        ....
    }
}

Względne adresy URL wskazują na niezmieniające się opisy OpenAPI, aby umożliwić trzymanie cache po stronie klienta. Serwer API zwraca również odpowiednie nagłówki HTTP dla cache (Expires ustawione na 1 rok wprzód, Cache-Control jako immutable). Wysłanie zapytania do nieaktualnego URL spowoduje przekierowanie przez serwer API do wersji najnowszej.

Serwer API Kubernetesa udostępnia specyfikację OpenAPI v3 pod adresem /openapi/v3/apis/<group>/<version>?hash=<hash>, zgodnie z podziałem na grupy i wersje.

Tabela poniżej podaje dopuszczalne wartości nagłówków żądania.

Przechowywanie stanu

Kubernetes przechowuje serializowany stan swoich obiektów w etcd.

Grupy i wersje API

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/rbac.authorization.k8s.io/v1alpha1.

Rozdział wersji wprowadzony jest na poziomie całego API, a nie na poziomach 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 oraz pozwala na kontrolowany dostęp do tych API, które są w fazie wycofywania lub fazie eksperymentalnej.

Aby ułatwić rozbudowę API Kubernetes, wprowadziliśmy grupy API, które mogą być włączane i wyłączane.

Zasoby API są rozróżniane poprzez przynależność do grupy API, typ zasobu, przestrzeń nazw (namespace,
o ile ma zastosowanie) oraz nazwę. Serwer API może przeprowadzać konwersję między różnymi wersjami API w sposób niewidoczny dla użytkownika: wszystkie te różne wersje reprezentują w rzeczywistości ten sam zasób. Serwer API może udostępniać te same dane poprzez kilka różnych wersji API.

Załóżmy przykładowo, że istnieją dwie wersje v1 i v1beta1 tego samego zasobu. Obiekt utworzony przez wersję v1beta1 może być odczytany, zaktualizowany i skasowany zarówno przez wersję v1beta1, jak i v1, do czasu aż wersja v1beta1 będzie przestarzała i usunięta. Wtedy możesz dalej korzystać i modyfikować obiekt poprzez wersję v1.

Trwałość API

Z naszego doświadczenia wynika, że każdy system, który odniósł sukces, musi się nieustająco rozwijać w miarę zmieniających się potrzeb. Dlatego Kubernetes został tak zaprojektowany, aby API mogło się zmieniać i rozrastać. Projekt Kubernetes dąży do tego, aby nie wprowadzać zmian niezgodnych z istniejącymi aplikacjami klienckimi i utrzymywać zgodność przez wystarczająco długi czas, aby inne projekty zdążyły się dostosować do zmian.

W ogólności, nowe zasoby i pola definiujące zasoby API są dodawane stosunkowo często. Usuwanie zasobów lub pól jest regulowane przez API deprecation policy.

Po osiągnięciu przez API statusu ogólnej dostępności (general availability - GA), oznaczanej zazwyczaj jako wersja API v1, bardzo zależy nam na utrzymaniu jej zgodności w kolejnych wydaniach. Kubernetes utrzymuje także zgodność dla wersji beta API tam, gdzie jest to możliwe: jeśli zdecydowałeś się używać API w wersji beta, możesz z niego korzystać także później, kiedy dana funkcjonalność osiągnie status stabilnej.

Zajrzyj do API versions reference po szczegółowe definicje różnych poziomów wersji API.

Rozbudowa API

API Kubernetesa można rozszerzać na dwa sposoby:

1. Definicje zasobów własnych (custom resources) pozwalają deklaratywnie określać, jak serwer API powinien dostarczać wybrane przez Ciebie zasoby API.
2. Można także rozszerzać API Kubernetesa implementując warstwę agregacji.

Co dalej?

• Naucz się, jak rozbudowywać API Kubernetesa poprzez dodawanie własnych CustomResourceDefinition.
• Controlling Access To The Kubernetes API opisuje sposoby, jakimi klaster zarządza dostępem do API.
• Punkty dostępowe API (endpoints), typy zasobów i przykłady zamieszczono w API Reference.
• Aby dowiedzieć się, jaki rodzaj zmian można określić jako zgodne i jak zmieniać API, zajrzyj do API changes.

3.2 - Windows w Kubernetesie

Kubernetes obsługuje węzły robocze działające zarówno na systemie Linux, jak i Microsoft Windows.

CNCF i jej macierzysta organizacja Linux Foundation przyjmują neutralne podejście do kompatybilności w kontekście dostawców. Możliwe jest dołączenie swojego serwera Windows jako węzeł roboczy do klastra Kubernetes.

Możesz zainstalować i skonfigurować kubectl na Windows niezależnie od tego, jakiego systemu operacyjnego używasz w ramach swojego klastra.

Jeśli używasz węzłów Windows, możesz przeczytać:

• Sieci w Windows
• Windows storage w Kubernetesie
• Zarządzanie zasobami dla węzłów Windows
• Konfiguracja RunAsUserName dla Podów Windows i kontenerów
• Utwórz Windows HostProcess Pod
• Konfigurowanie grupowych zarządzanych kont Usług dla Podów i kontenerów Windows
• Bezpieczeństwo dla węzłów Windows
• Wskazówki dotyczące debugowania w systemie Windows
• Przewodnik dotyczący harmonogramowania kontenerów Windows w Kubernetesie

lub, aby uzyskać przegląd, przeczytaj:

4 - Zadania

W tej części dokumentacji Kubernetesa znajdują się opisy sposobu realizacji różnych zadań. Przedstawione są one zazwyczaj jako krótka sekwencja kilku kroków związanych z pojedynczym zadaniem.

Jeśli chciałbyś stworzyć nową stronę poświęconą jakiemuś zadaniu, przeczytaj Jak przygotować propozycję zmian (PR).

5 - Samouczki

W tym rozdziale dokumentacji Kubernetes znajdziesz różne samouczki. Dzięki nim dowiesz się, jak osiągnąć złożone cele, które przekraczają wielkość pojedynczego zadania. Typowy samouczek podzielony jest na kilka części, z których każda zawiera sekwencję odpowiednich kroków. Przed zapoznaniem się z samouczkami warto stworzyć zakładkę do słownika, aby móc się później do niego na bieżąco odwoływać.

Podstawy

• Podstawy Kubernetesa (PL) to interaktywny samouczek, który pomoże zrozumieć system Kubernetes i wypróbować jego podstawowe możliwości.

• Introduction to Kubernetes (edX)

• Hello Minikube (PL)

Konfiguracja

• Configuring Redis Using a ConfigMap

Aplikacje bezstanowe (Stateless Applications)

• Exposing an External IP Address to Access an Application in a Cluster

• Example: Deploying PHP Guestbook application with Redis

Aplikacje stanowe (Stateful Applications)

• StatefulSet Basics

• Example: WordPress and MySQL with Persistent Volumes

• Example: Deploying Cassandra with Stateful Sets

• Running ZooKeeper, A CP Distributed System

Serwisy

• Using Source IP

Bezpieczeństwo

• Apply Pod Security Standards at Cluster level
• Apply Pod Security Standards at Namespace level
• AppArmor
• Seccomp

Co dalej?

Jeśli chciałbyś napisać nowy samouczek, odwiedź Content Page Types, gdzie znajdziesz dodatkowe informacje o tym typie strony.

5.1 - Hello Minikube

Ten samouczek pokaże, jak uruchomić przykładową aplikację na Kubernetesie przy użyciu minikube oraz Katacoda. Katacoda to darmowe środowisko Kubernetes dostępne bezpośrednio z przeglądarki web.

Cele

• Skonfiguruj przykładową aplikację do uruchomienia w minikube.
• Uruchom aplikację.
• Przejrzyj jej logi.

Zanim zaczniesz

W tym samouczku wykorzystamy obraz kontenera, który korzysta z NGINX, aby wyświetlić z powrotem wszystkie przychodzące zapytania.

Stwórz klaster minikube

1. Kliknij w Launch Terminal

   Informacja:

   Jeśli masz minikube zainstalowane lokalnie, uruchom `minikube start`. Przed uruchomieniem `minikube dashboard`, otwórz okno nowego terminala, uruchom w nim `minikube dashboard` i przełącz się z powrotem do okna głównego terminala.
   

2. Otwórz panel Kubernetesa w przeglądarce:

   minikube dashboard
   

3. Tylko w Katacoda: Na górze okienka z terminalem kliknij na znak plus, a następnie wybierz Select port to view on Host 1.

4. Tylko w Katacoda: Wpisz 30000i kliknij Display Port.

Otwieranie panelu poprzez URL

Jeśli nie chcesz otwierać przeglądarki, uruchom panel z opcją --url, aby wyświetlić URL:

minikube dashboard --url

Stwórz Deployment

Pod w Kubernetesie to grupa jednego lub wielu kontenerów połączonych ze sobą na potrzeby administrowania i dostępu sieci. W tym samouczku Pod zawiera tylko jeden kontener. Deployment w Kubernetesie monitoruje stan twojego Poda i restartuje należące do niego kontenery, jeśli z jakichś powodów przestaną działać. Użycie Deploymentu to rekomendowana metoda zarządzania tworzeniem i skalowaniem Podów.

1. Użyj polecenia kubectl create do stworzenia Deploymentu, który będzie zarządzał Podem. Pod uruchamia kontener wykorzystując podany obraz Dockera.

   kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080
   

2. Sprawdź stan Deploymentu:

   kubectl get deployments
   

   Wynik powinien wyglądać podobnie do:

   NAME         READY   UP-TO-DATE   AVAILABLE   AGE
   hello-node   1/1     1            1           1m
   

3. Sprawdź stan Poda:

   kubectl get pods
   

   Wynik powinien wyglądać podobnie do:

   NAME                          READY     STATUS    RESTARTS   AGE
   hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
   

4. Obejrzyj zdarzenia na klastrze:

   kubectl get events
   

5. Sprawdź konfigurację kubectl:

   kubectl config view
   

   Informacja:

   Więcej informacji na temat polecenia `kubectl` znajdziesz w [przeglądzie kubectl](/docs/reference/kubectl/).
   

Stwórz Serwis

Domyślnie Pod jest dostępny tylko poprzez swój wewnętrzny adres IP wewnątrz klastra Kubernetes. Aby kontener hello-node był osiągalny spoza wirtualnej sieci Kubernetesa, musisz najpierw udostępnić Pod jako Serwis Kubernetes.

1. Udostępnij Pod w Internecie przy pomocy polecenia kubectl expose:

   kubectl expose deployment hello-node --type=LoadBalancer --port=8080
   

   Opcja --type=LoadBalancer wskazuje, że chcesz udostępnić swój Serwis na zewnątrz klastra.

   Aplikacja, która jest umieszczona w obrazie kontenera registry.k8s.io/echoserver, nasłuchuje jedynie na porcie TCP 8080. Jeśli użyłeś kubectl expose do wystawienia innego portu, aplikacje klienckie mogą nie móc się podłączyć do tamtego innego portu.

2. Sprawdź Serwis, który właśnie utworzyłeś:

   kubectl get services
   

   Wynik powinien wyglądać podobnie do:

   NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
   hello-node   LoadBalancer   10.108.144.78   <pending>     8080:30369/TCP   21s
   kubernetes   ClusterIP      10.96.0.1       <none>        443/TCP          23m
   

   U dostawców usług chmurowych, którzy obsługują load balancers, zostanie przydzielony zewnętrzny adres IP na potrzeby serwisu. W minikube, serwis typu LoadBalancer można udostępnić poprzez polecenie minikube service.

3. Uruchom poniższe polecenie:

   minikube service hello-node
   

4. Tylko w Katacoda: Kliknij znak plus, a następnie Select port to view on Host 1.

5. Tylko w Katacoda: Wpisz 30369 (sprawdź numer portu obok 8080 w opisie Serwisu) i kliknij Display Port

   Otworzy sie okno przeglądarki obsługującej twoją aplikację i wyświetli odpowiedź tej aplikacji.

Włącz dodatki

Narzędzie minikube dysponuje zestawem wbudowanych dodatków, które mogą być włączane, wyłączane i otwierane w lokalnym środowisku Kubernetes.

1. Lista aktualnie obsługiwanych dodatków:

   minikube addons list
   

   Wynik powinien wyglądać podobnie do:

   addon-manager: enabled
   dashboard: enabled
   default-storageclass: enabled
   efk: disabled
   freshpod: disabled
   gvisor: disabled
   helm-tiller: disabled
   ingress: disabled
   ingress-dns: disabled
   logviewer: disabled
   metrics-server: disabled
   nvidia-driver-installer: disabled
   nvidia-gpu-device-plugin: disabled
   registry: disabled
   registry-creds: disabled
   storage-provisioner: enabled
   storage-provisioner-gluster: disabled
   

2. Włącz dodatek, na przykład metrics-server:

   minikube addons enable metrics-server
   

   Wynik powinien wyglądać podobnie do:

   The 'metrics-server' addon is enabled
   

3. Sprawdź Pody i Serwisy, który właśnie stworzyłeś:

   kubectl get pod,svc -n kube-system
   

   Wynik powinien wyglądać podobnie do:

   NAME                                        READY     STATUS    RESTARTS   AGE
   pod/coredns-5644d7b6d9-mh9ll                1/1       Running   0          34m
   pod/coredns-5644d7b6d9-pqd2t                1/1       Running   0          34m
   pod/metrics-server-67fb648c5                1/1       Running   0          26s
   pod/etcd-minikube                           1/1       Running   0          34m
   pod/influxdb-grafana-b29w8                  2/2       Running   0          26s
   pod/kube-addon-manager-minikube             1/1       Running   0          34m
   pod/kube-apiserver-minikube                 1/1       Running   0          34m
   pod/kube-controller-manager-minikube        1/1       Running   0          34m
   pod/kube-proxy-rnlps                        1/1       Running   0          34m
   pod/kube-scheduler-minikube                 1/1       Running   0          34m
   pod/storage-provisioner                     1/1       Running   0          34m
   
   NAME                           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
   service/metrics-server         ClusterIP   10.96.241.45    <none>        80/TCP              26s
   service/kube-dns               ClusterIP   10.96.0.10      <none>        53/UDP,53/TCP       34m
   service/monitoring-grafana     NodePort    10.99.24.54     <none>        80:30002/TCP        26s
   service/monitoring-influxdb    ClusterIP   10.111.169.94   <none>        8083/TCP,8086/TCP   26s
   

4. Wyłącz dodatek metrics-server:

   minikube addons disable metrics-server
   

   Wynik powinien wyglądać podobnie do:

   metrics-server was successfully disabled
   

Porządkujemy po sobie

Teraz jest czas na wyczyszczenie zasobów, które utworzyłeś w klastrze:

kubectl delete service hello-node
kubectl delete deployment hello-node

(Opcjonalnie) Zatrzymaj wirtualną maszynę Minikube (VM):

minikube stop

(Opcjonalnie) Skasuj Minikube VM:

minikube delete

Co dalej?

• Dowiedz się więcej o obiektach typu Deployment.
• Dowiedz się więcej o instalowaniu aplikacji.
• Dowiedz się więcej o obiektach typu Serwis.

5.2 - Naucz się podstaw

Podstawy Kubernetesa

Ten samouczek poprowadzi Cię przez podstawy systemu zarządzania zadaniami na klastrze Kubernetes. W każdym module znajdziesz najważniejsze informacje o głównych pojęciach i funkcjonalnościach Kubernetes. Dzięki samouczkom nauczysz się zarządzać prostym klasterem i skonteneryzowanymi aplikacjami uruchamianymi na tym klastrze.

Nauczysz się, jak:

• Zainstalować skonteneryzowaną aplikację na klastrze.
• Wyskalować tę instalację.
• Zaktualizować aplikację do nowej wersji.
• Rozwiązywać problemy z aplikacją.

Co Kubernetes może dla Ciebie zrobić?

Użytkownicy oczekują od współczesnych serwisów internetowych dostępności non-stop, a deweloperzy chcą móc instalować nowe wersje swoich serwisów kilka razy dziennie. Używając kontenerów można przygotowywać oprogramowanie w taki sposób, aby mogło być instalowane i aktualizowane nie powodując żadnych przestojów. Kubernetes pomaga uruchamiać te aplikacje w kontenerach tam, gdzie chcesz i kiedy chcesz i znajdować niezbędne zasoby i narzędzia wymagane do ich pracy. Kubernetes może działać w środowiskach produkcyjnych, jest otwartym oprogramowaniem zaprojektowanym z wykorzystaniem nagromadzonego przez Google doświadczenia w zarządzaniu kontenerami, w połączeniu z najcenniejszymi ideami społeczności.

Podstawy Kubernetes — Moduły

1. Zbuduj klaster Kubernetes

2. Zainstaluj aplikację

3. Zapoznaj się z aplikacją

4. Udostępnij aplikację publicznie

5. Skaluj aplikację

6. Zaktualizuj aplikację

5.2.1 - Tworzenie klastra

Poznaj klaster Kubernetesa i naucz się, jak stworzyć jego prostą wersję przy pomocy Minikube.

5.2.1.1 - Jak użyć Minikube do stworzenia klastra

5.2.2 - Instalowanie aplikacji

5.2.2.1 - Jak użyć kubectl do tworzenia Deploymentu

5.2.3 - Poznawanie aplikacji

5.2.3.1 - Pody i Węzły

5.2.4 - Udostępnianie aplikacji

5.2.4.1 - Jak używać Service do udostępniania aplikacji

5.2.5 - Skalowanie aplikacji

5.2.5.1 - Uruchamianie wielu instancji aplikacji

Cele

• Wyskaluj aplikację przy użyciu kubectl.

Skalowanie aplikacji

W poprzednim module stworzyliśmy Deployment i udostępniliśmy go publicznie korzystając z Serwisu. Deployment utworzył tylko jeden Pod, w którym uruchomiona jest nasza aplikacja. Wraz ze wzrostem ruchu, będziemy musieli wyskalować aplikację, aby była w stanie obsłużyć zwiększone zapotrzebowanie użytkowników.

Skalowanie polega na zmianie liczby replik w Deploymencie.

Podsumowanie:

• Skalowanie Deploymentu

Od samego początku w ramach Deploymentu można uruchomić wiele instancji — skorzystaj z parametru --replicas polecenia kubectl create deployment

Ogólnie o skalowaniu

Wstecz Dalej

Kiedy zwiększamy skalę Deploymentu, uruchomienie nowych Podów jest zlecane na Węzłach, które posiadają odpowiednio dużo zasobów. Operacja skalowania zwiększy liczbę Podów do oczekiwanej wartości. W Kubernetes możliwe jest również autoskalowanie Podów, ale jest ono poza zakresem niniejszego samouczka. Istnieje także możliwość skalowania do zera — w ten sposób zatrzymane zostaną wszystkie Pody należące do konkretnego Deploymentu.

Kiedy działa jednocześnie wiele instancji jednej aplikacji, należy odpowiednio rozłożyć ruch pomiędzy każdą z nich. Serwisy posiadają zintegrowany load-balancer, który dystrybuuje ruch na wszystkie Pody w Deployment wystawionym na zewnątrz. Serwis prowadzi ciągły monitoring Podów poprzez ich punkty dostępowe (endpoints), aby zapewnić, że ruch kierowany jest tylko do tych Podów, które są faktycznie dostępne.

Skalowanie polega na zmianie liczby replik w ramach Deploymentu.

Kiedy aplikacja ma uruchomioną więcej niż jedną instancję, można prowadzić ciągłe aktualizacje (Rolling updates) bez przerw w działaniu aplikacji. O tym będzie mowa w następnym module.

5.2.6 - Aktualizowanie aplikacji

5.2.6.1 - Aktualizacje Rolling Update

Cele

• Przeprowadzić płynną aktualizację przy użyciu kubectl.

Aktualizowanie aplikacji

Użytkownicy oczekują, że aplikacje są dostępne non-stop, a deweloperzy chcieliby móc wprowadzać nowe wersje nawet kilka razy dziennie. W Kubernetes jest to możliwe dzięki mechanizmowi płynnych aktualizacji (rolling updates). Rolling updates pozwala prowadzić aktualizację w ramach Deploymentu bez przerw w jego działaniu dzięki krokowemu aktualizowaniu kolejnych Podów. Nowe Pody uruchamiane są na Węzłach, które posiadają wystarczające zasoby.

W poprzednim module wyskalowaliśmy aplikację aby była uruchomiona na wielu instancjach. To niezbędny wymóg, aby móc prowadzić aktualizacje bez wpływu na dostępność aplikacji. Domyślnie, maksymalna liczba Podów, które mogą być niedostępne w trakcie aktualizacji oraz Podów, które mogą być tworzone, wynosi jeden. Obydwie opcje mogą być zdefiniowane w wartościach bezwzględnych lub procentowych (ogólnej liczby Podów). W Kubernetes, każdy aktualizacja ma nadany numer wersji i każdy Deployment może być wycofany do wersji poprzedniej (stabilnej).

Podsumowanie:

• Aktualizacja aplikacji

Rolling updates to metoda na aktualizację Deploymentów bez przerwy w ich dostępności poprzez stopniową zamianę kolejnych Podów na ich nowe wersje.

Ogólnie o Rolling updates

Wstecz Dalej

Podobnie, jak w przypadku skalowania aplikacji, jeśli Deployment jest udostępniony publicznie, Serwis będzie kierował ruch tylko do Podów, które są dostępne w trakcie aktualizacji. Dostępny Pod to taki, którego instancja jest dostępna dla użytkowników aplikacji.

Płynne aktualizacje pozwalają na:

• Promocję aplikacji z jednego środowiska do innego (poprzez aktualizację obrazu kontenera)
• Wycofywanie się do poprzedniej wersji
• Continuous Integration oraz Continuous Delivery aplikacji bez przerw w jej działaniu

Jeśli Deployment jest udostępniony publicznie, Serwis będzie kierował ruch w trakcie aktualizacji tylko do Podów, które są aktualnie dostępne.

6 - Materiały źródłowe

Tutaj znajdziesz dokumentację źródłową Kubernetesa.

Dokumentacja API

• Glossary - Pełna, zestandaryzowana lista terminologii Kubernetesa

• Kubernetes API Reference

• One-page API Reference for Kubernetes v1.32

• Using The Kubernetes API - ogólne informacje na temat API Kubernetesa

• API access control - szczegóły dotyczące kontroli dostępu do API Kubernetesa

• Well-Known Labels, Annotations and Taints

Oficjalnie wspierane biblioteki klienckie

Aby wywołać Kubernetes API z wybranego języka programowania, możesz skorzystać z bibliotek klienckich. Oficjalnie wspierane biblioteki to:

• Kubernetes Go client library
• Kubernetes Python client library
• Kubernetes Java client library
• Kubernetes JavaScript client library
• Kubernetes C# client library
• Kubernetes Haskell client library

Polecenia tekstowe (CLI)

• kubectl - Główne narzędzie tekstowe (linii poleceń) do zarządzania klastrem Kubernetes.
  • JSONPath - Podręcznik składni wyrażeń JSONPath dla kubectl.
• kubeadm - Narzędzie tekstowe do łatwego budowania klastra Kubernetes spełniającego niezbędne wymogi bezpieczeństwa.

Komponenty

• kubelet - Główny agent działający na każdym węźle. Kubelet pobiera zestaw definicji PodSpecs i gwarantuje, że opisane przez nie kontenery poprawnie działają.

• kube-apiserver - REST API, które sprawdza poprawność i konfiguruje obiekty API, takie jak pody, serwisy czy kontrolery replikacji.

• kube-controller-manager - Proces wykonujący główne pętle sterowania Kubernetes.

• kube-proxy - Przekazuje bezpośrednio dane przepływające w transmisji TCP/UDP lub dystrybuuje ruch TCP/UDP zgodnie ze schematem round-robin pomiędzy usługi back-endu.

• kube-scheduler - Scheduler odpowiada za dostępność, wydajność i zasoby.

• Scheduler Policies

• Scheduler Profiles

• Spis portów i protokołów, które muszą być otwarte dla warstwy sterowania i na węzłach roboczych.

API konfiguracji

W tej części zebrano "niepublikowane" API, które służą do konfiguracji komponentów Kubernetesa lub innych narzędzi. Choć większość tych API nie jest udostępniane przez serwer API w trybie RESTful, są one niezbędne dla użytkowników i administratorów w korzystaniu i zarządzaniu klastrem.

• kubeconfig (v1)
• kube-apiserver admission (v1)
• kube-apiserver configuration (v1alpha1) i
• kube-apiserver configuration (v1beta1) i kube-apiserver configuration (v1)
• kube-apiserver encryption (v1)
• kube-apiserver event rate limit (v1alpha1)
• kubelet configuration (v1alpha1), kubelet configuration (v1beta1) i kubelet configuration (v1)
• kubelet credential providers (v1alpha1), kubelet credential providers (v1beta1) i kubelet credential providers (v1)
• kube-scheduler configuration (v1beta3) i kube-scheduler configuration (v1)
• kube-controller-manager configuration (v1alpha1)
• kube-proxy configuration (v1alpha1)
• audit.k8s.io/v1 API
• Client authentication API (v1beta1) i Client authentication API (v1)
• WebhookAdmission configuration (v1)
• ImagePolicy API (v1alpha1)

API konfiguracji dla kubeadm

• v1beta3
• v1beta4

Zewnętrzne API

Istnieją API, które zostały zdefiniowane w ramach projektu Kubernetes, ale nie zostały zaimplementowane przez główny projekt:

• Metrics API (v1beta1)
• Custom Metrics API (v1beta2)
• External Metrics API (v1beta1)

Dokumentacja projektowa

Archiwum dokumentacji projektowej różnych funkcjonalności Kubernetes. Warto zacząć od Kubernetes Architecture oraz Kubernetes Design Overview.

6.1 - Słownik

7 - Współtwórz dokumentację K8s

Istnieje wiele sposobów, aby wnieść wkład do Kubernetes. Możesz pracować nad projektami nowych funkcji, możesz dokumentować kod, który już mamy, możesz pisać do naszego bloga. Jest więcej: możesz implementować te nowe funkcje lub naprawiać błędy. Możesz pomóc ludziom dołączyć do naszej społeczności współtwórców lub wspierać istniejących współtwórców.

We wszystkich tych sposobach, aby mieć wpływ na projekt, my - Kubernetes - stworzyliśmy dedykowaną stronę internetową: https://k8s.dev/. Możesz tam przejść, aby dowiedzieć się więcej o wnoszeniu wkładu do Kubernetes.

Jeśli chcesz dowiedzieć się, jak wnosić wkład do tej dokumentacji, przeczytaj Wnoszenie wkładu do dokumentacji Kubernetes.

Możesz również przeczytać CNCF stronę o wnoszeniu wkładu do Kubernetes.

7.1 - Zgłaszanie propozycji poprawy treści

Jeśli zauważysz problem z dokumentacją Kubernetesa lub masz pomysł na nową treść, otwórz zgłoszenie. Wszystko, czego potrzebujesz, to konto GitHub i przeglądarka internetowa.

W większości przypadków nowa praca nad dokumentacją Kubernetesa rozpoczyna się od zgłoszenia na GitHubie. Współtwórcy Kubernetesa następnie przeglądają, kategoryzują i tagują zgłoszenia. Następnie Ty lub inny członek społeczności Kubernetesa otwiera pull requesta z poprawkami rozwiązującymi problem.

Otwarcie zgłoszenia

Jeśli chcesz zasugerować ulepszenia do istniejącej treści lub zauważysz błąd, otwórz zgłoszenie.

1. Kliknij link Create an issue na prawym pasku bocznym. Przekieruje Cię to na stronę z problemem w GitHub wstępnie wypełnioną kilkoma nagłówkami.
2. Opisz problem lub sugestię poprawy. Podaj jak najwięcej szczegółów.
3. Kliknij Submit new issue.

Po przesłaniu, od czasu do czasu sprawdzaj swoje zgłoszenie lub włącz powiadomienia GitHub. Recenzenci i inni członkowie społeczności mogą zadawać pytania, zanim będą mogli podjąć działania w sprawie Twojego zgłoszenia.

Sugestia nowej treści

Jeśli masz pomysł na nowe treści, ale nie jesteś pewien, gdzie powinny się one znaleźć, możesz nadal utworzyć zgłoszenie. Wykonaj jeden z kroków:

• Wybierz istniejącą stronę w sekcji, do której Twoim zdaniem należy treść, i kliknij Create an issue.
• Przejdź do GitHub i utwórz zgłoszenie bezpośrednio.

Jak tworzyć świetne zgłoszenia

Pamiętaj o następujących rzeczach przy zgłaszaniu problemu:

• Podaj jasny opis problemu. Opisz, co konkretnie jest brakujące, nieaktualne, błędne lub wymaga poprawy.
• Wyjaśnij, jaki konkretny wpływ ma ten problem na użytkowników.
• W przypadku problemów o dużym zakresie, podziel je na mniejsze zagadnienia, aby łatwiej było nad nimi pracować. Na przykład, "Napraw dokumentację dotyczącą bezpieczeństwa" jest zbyt ogólne, ale "Dodaj szczegóły do tematu 'Ograniczanie dostępu do sieci'" jest na tyle precyzyjne, by można było podjąć działanie.
• Przeszukaj istniejące zgłoszenia, aby sprawdzić, czy jest coś związanego lub podobnego do nowego zgłoszenia.
• Jeśli nowe zgłoszenie dotyczy innego zgłoszenia lub pull requesta, odwołaj się do niego poprzez podanie pełnego adresu URL lub numeru zgłoszenia lub pull requesta poprzedzonego znakiem #. Na przykład: Introduced by #987654.
• Przestrzegaj Kodeksu postępowania. Szanuj innych współtwórców. Na przykład, "Dokumentacja jest okropna" nie jest ani pomocną ani uprzejmą opinią.

7.2 - Dokumentowanie funkcji nowego wydania

Każda główna wersja Kubernetesa wprowadza nowe funkcje, które wymagają dokumentacji. Nowe wersje przynoszą również aktualizacje do istniejących funkcji i dokumentacji (na przykład awansowanie funkcji z wersji alpha do beta).

Zazwyczaj SIG odpowiedzialny za funkcję przesyła szkic dokumentacji funkcji jako pull request do odpowiedniego gałęzi rozwojowej w repozytorium kubernetes/website, a ktoś z zespołu SIG Docs dostarcza uwagi redakcyjne lub edytuje szkic bezpośrednio. Ta sekcja opisuje konwencje dotyczące rozgałęzień (ang. branching) oraz proces stosowany podczas wydania przez obie grupy.

Dla współtwórców dokumentacji

Ogólnie rzecz biorąc, współtwórcy dokumentacji nie piszą treści od podstaw na potrzeby wydania. Zamiast tego współpracują z SIG tworzącym nową funkcję, aby dopracować szkic dokumentacji i przygotować go do wydania.

Po wybraniu fukncji do udokumentowania lub wsparcia, zapytaj o nią na kanale Slack #sig-docs, podczas cotygodniowego spotkania SIG Docs lub bezpośrednio w zgłoszeniu PR wystawionym przez SIG odpowiedzialny za funkcje. Jeśli otrzymasz zgodę, możesz edytować PR za pomocą jednej z technik opisanych w Wprowadź zmiany do PR innej osoby.

Dowiedz się o nadchodzących funkcjach

Aby dowiedzieć się o nadchodzących funkcjach, weź udział w cotygodniowym spotkaniu SIG Release (zobacz stronę społeczności w celu uzyskania informacji o nadchodzących spotkaniach) i monitoruj dokumentację dotyczącą wydania w repozytorium kubernetes/sig-release. Każde wydanie ma podkatalog w katalogu /sig-release/tree/master/releases/. Podkatalog zawiera harmonogram wydania, szkic notatek do wydania oraz dokument z listą każdej osoby w zespole wydania.

Harmonogram wersji zawiera linki do wszystkich innych dokumentów, spotkań, protokołów spotkań i kamieni milowych związanych z wydaniem. Zawiera również informacje o celach i harmonogramie wydania oraz wszelkich specjalnych procesach wdrożonych dla tego wydania. Pod koniec dokumentu zdefiniowano kilka terminów związanych z wydaniem.

Ten dokument zawiera również link do Arkusza śledzenia funkcji, który jest oficjalnym sposobem na poznanie wszystkich nowych funkcji planowanych do wprowadzenia w wydaniu.

Dokumentacja zespołu odpowiadającego za kolejne wydanie zawiera listę osób do przypisanych do różnych ról. Jeśli nie jest jasne, do kogo się zwrócić w sprawie konkretnej funkcji lub pytania, które masz, możesz skorzystać z jednego z dwóch rozwiązań: weź udział w spotkaniu zespołu, aby zadać swoje pytanie, lub skontaktuj się z liderem wydania, aby mógł Cię odpowiednio skierować.

Szkic notatek z wydania to dobre miejsce, aby dowiedzieć się o specyficznych funkcjach, zmianach, przestarzałych elementach i innych kwestiach dotyczących wydania. Ponieważ treść nie jest ostateczna aż do późnego etapu, warto zachować ostrożność.

Arkusz śledzenia funkcji

Arkusz śledzenia funkcji dla danej wersji Kubernetesa wymienia każdą funkcję, która jest planowana do wydania. Każdy element zawiera nazwę funkcji, link do głównego problemu na GitHubie, poziom stabilności (Alpha, Beta lub Stable), SIG i osobę odpowiedzialną za jej wdrożenie, czy wymaga dokumentacji, projekt notatki o wydaniu dla funkcji oraz czy została zintegrowana. Pamiętaj o następujących zasadach:

• Funkcje w wersji Beta i Stable są zazwyczaj priorytetowane wyżej w dokumentacji niż funkcje w wersji Alfa.
• Trudno jest przetestować (a tym samym udokumentować) funkcję, która nie została zmergowana, lub przynajmniej jest uważana za kompletną w swoim PR.
• Określenie, czy funkcja wymaga dokumentacji, jest procesem manualnym. Nawet jeśli funkcja nie jest oznaczona jako wymagająca dokumentacji, może być konieczne jej udokumentowanie.

Dla developerów lub innych członków SIG

Ta sekcja zawiera informacje dla członków innych SIG Kubernetesów dokumentujących nowe funkcje na potrzeby wydania.

Jeśli jesteś członkiem SIG, który rozwija nową funkcję dla Kubernetesa, musisz współpracować z SIG Docs, aby mieć pewność, że Twoja funkcja zostanie udokumentowana na czas przed wydaniem. Sprawdź arkusz śledzenia funkcji lub sprawdź kanał Slack Kubernetes #sig-release, aby zweryfikować szczegóły harmonogramu i terminy.

Otwórz tymczasowy PR

1. Otwórz szkic pull requestu do gałęzi dev-1.33 w repozytorium kubernetes/website, z małym commitem, który później zmienisz. Aby utworzyć szkic pull requestu, użyj rozwijanego menu Create Pull Request i wybierz Create Draft Pull Request, następnie kliknij Draft Pull Request.
2. Edytuj opis pull requesta, aby zawierał linki do PR-ów w kubernetes/kubernetes oraz zgłoszeń w kubernetes/enhancements.
3. Zostaw komentarz w powiązanym zgłoszeniu w tym repozytorium kubernetes/enhancements z linkiem do PR, aby powiadomić osobę zajmującą się dokumentacją tej wersji, że dokumentacja dotycząca funkcji jest w przygotowaniu i powinna być śledzona w tym wydaniu.

Jeśli Twoja funkcjonalność nie wymaga żadnych zmian w dokumentacji, upewnij się, że zespół sig-release o tym wie, wspominając o tym na kanale Slack #sig-release. Jeśli funkcjonalność wymaga dokumentacji, ale PR nie został utworzony, funkcjonalność może zostać usunięta z kamienia milowego.

PR gotowy do przeglądu

Kiedy będziesz gotowy, wypełnij swój tymczasowy PR dokumentacją funkcji i zmień stan PR z roboczego na ready for review. Aby oznaczyć pull request jako gotowy do przeglądu, przejdź do pola scalania (ang. merge box) i kliknij Ready for review.

Najlepiej jak potrafisz opisz swoją funkcję i sposób jej użycia. Jeśli potrzebujesz pomocy w strukturyzacji swojej dokumentacji, zapytaj na kanale Slack #sig-docs.

Gdy ukończysz swój materiał, osoba odpowiedzialna za dokumentację przypisana do Twojej funkcji go przegląda. Aby zapewnić dokładność techniczną, treść może również wymagać przeglądu technicznego przez odpowiednie SIG-i. Skorzystaj z ich sugestii, aby dopracować treść do stanu gotowego do wydania.

Jeśli twoja funkcja wymaga dokumentacji, a pierwsza wersja treści nie zostanie dostarczona, funkcja może zostać usunięta z kamienia milowego.

Bramki funkcji (ang. feature gates)

Jeśli Twoja funkcja jest funkcją Alfa lub Beta i jest włączana warunkowo bramką funkcji (ang. feature gate), potrzebujesz dla niej pliku bramki funkcji wewnątrz content/en/docs/reference/command-line-tools-reference/feature-gates/. Nazwa pliku powinna być nazwą bramki funkcji z sufiksem .md. Możesz spojrzeć na inne pliki już znajdujące się w tym samym katalogu, aby uzyskać wskazówkę, jak powinien wyglądać Twój plik. Zwykle wystarczy jeden akapit; dla dłuższych wyjaśnień dodaj dokumentację w innym miejscu i dodaj do niej link.

Aby upewnić się, że twój feature gate pojawi się w tabeli Alpha/Beta Feature gates, dodaj następujące informacje do sekcji front matter w pliku Markdown z opisem:

stages:
  - stage: <alpha/beta/stable/deprecated>  # Specify the development stage of the feature gate
    defaultValue: <true or false>     # Set to true if enabled by default, false otherwise
    fromVersion: <Version>            # Version from which the feature gate is available
    toVersion: <Version>              # (Optional) The version until which the feature gate is available

W przypadku nowych bramek funkcji wymagany jest również osobny opis bramki funkcji; utwórz nowy plik Markdown w content/en/docs/reference/command-line-tools-reference/feature-gates/ (użyj innych plików jako szablonu).

Gdy zmieniasz bramkę funkcji z domyślnie wyłączonej na domyślnie włączoną, może być konieczne zmienienie również innej dokumentacji (nie tylko listy bramek funkcji). Uważaj na zwroty takie jak „Pole exampleSetting jest polem beta i jest domyślnie wyłączone. Możesz je włączyć, włączając bramkę funkcji ProcessExampleThings.”

Jeśli Twoja funkcja osiągnęła status GA lub została oznaczona jako przestarzała, dodaj dodatkowy wpis stage w ramach bloku stages w pliku opisu. Upewnij się, że etapy Alpha i Beta pozostają nienaruszone. Ten krok przenosi bramkę funkcji z Feature gates for Alpha/Beta do Feature gates for graduated or deprecated features. Na przykład:

stages:
  - stage: alpha 
    defaultValue: false
    fromVersion: "1.12"
    toVersion: "1.12"
  - stage: beta 
    defaultValue: true
    fromVersion: "1.13"
  # Added a `toVersion` to the previous stage.
    toVersion: "1.18"
  # Added 'stable' stage block to existing stages.
  - stage: stable
    defaultValue: true
    fromVersion: "1.19"
    toVersion: "1.27"

Ostatecznie Kubernetes przestanie w ogóle uwzględniać bramę funkcji. Aby zasygnalizować usunięcie bramy funkcji, uwzględnij removed: true w przedniej części odpowiedniego pliku opisu. Wprowadzenie tej zmiany oznacza, że informacje o bramie funkcji przenoszą się z Skróty funkcji dla ukończonych lub przestarzałych funkcji do dedykowanej strony zatytułowanej Skróty funkcji (usunięte), łącznie z jej opisem.

Wszystkie PR-y zostały zrecenzowane i są gotowe do scalenia

Jeśli Twój PR nie został jeszcze scalony z gałęzią dev-1.33 przed terminem wydania, współpracuj z osobą odpowiedzialną za dokumentację i zarządzającą wydaniem, aby dodać go przed terminem. Jeśli Twoja funkcja potrzebuje dokumentacji, a dokumentacja nie jest gotowa, funkcja może zostać usunięta z bieżącego planu (milestone).

7.3 - Przeglądanie zmian

W tej sekcji opisano, jak dokonać przeglądu treści.

7.4 - Aktualizacja materiałów źródłowych

Tematy w tej sekcji opisują, jak aktualizować (czyli ponownie wygenerować) materiały źródłowe (ang. reference documentation) Kubernetesa.

Aby zbudować materiały źródłowe, zapoznaj się z następującym przewodnikiem:

• Szybki start generowania materiałów źródłowych

7.5 - Styl dokumentacji

Tematy w tej sekcji zawierają wskazówki dotyczące stylu pisania, formatowania treści i organizacji, a także korzystania ze specyficznych dostosowań Hugo dla dokumentacji Kubernetesa.

7.5.1 - Typy treści

Dokumentacja Kubernetesa obejmuje kilka typów treści stron:

• Pojęcia i koncepcje (ang. Concept)
• Zadanie (ang. Task)
• Samouczek (ang. Tutorial)
• Materiały źródłowe (ang. Reference)

Sekcje treści

Każdy typ strony zawiera szereg sekcji zdefiniowanych przez komentarze Markdown i nagłówki HTML. Możesz dodać nagłówki do swojej strony za pomocą kodu heading. Komentarze i nagłówki pomagają utrzymać odpowiednią strukturę strony dla danego typu.

Przykłady komentarzy w Markdown definiujących sekcje strony:

<!-- overview -->

<!-- body -->

Aby utworzyć typowe nagłówki na swoich stronach, użyj kodu heading z nazwą nagłówka.

Przykłady nazw nagłówków:

• whatsnext - co dalej
• prerequisites - wymagania wstępne
• objectives - cele
• cleanup - sprzątanie
• synopsis - streszczenie
• seealso - zobacz także
• options - opcje

Na przykład, aby utworzyć nagłówek whatsnext, dodaj kod nagłówka z nazwą "whatsnext":

## {{% heading "whatsnext" %}}

Możesz zadeklarować nagłówek prerequisites w następujący sposób:

## {{% heading "prerequisites" %}}

Kod heading oczekuje jednego parametru typu string. Ten parametr nagłówka odpowiada prefiksowi zmiennej w plikach i18n/<lang>/<lang>.toml. Na przykład:

i18n/en/en.toml:

[whatsnext_heading]
other = "What's next"

i18n/ko/ko.toml:

[whatsnext_heading]
other = "다음 내용"

Typy zawartości

Każdy typ zawartości nieformalnie definiuje swoją oczekiwaną strukturę strony. Twórz zawartość strony, korzystając z sugerowanych sekcji strony.

Pojęcie (ang. Concept)

Strona z pojęciami wyjaśnia określony aspekt Kubernetesa. Na przykład, strona koncepcyjna może opisywać obiekt Deployment w Kubernetesie i wyjaśniać jego rolę jako aplikacji po wdrożeniu, skalowaniu i aktualizacji. Zazwyczaj strony koncepcyjne nie zawierają instrukcji krok po kroku, lecz odsyłają do zadań lub samouczków.

Aby napisać nową stronę z pojęciem, utwórz plik Markdown w podkatalogu katalogu /content/en/docs/concepts, z następującymi sekcjami:

Strony koncepcyjne są podzielone na trzy sekcje:

Sekcje overview i body pojawiają się jako komentarze na stronie z koncepcjami. Możesz dodać sekcję whatsnext do swojej strony za pomocą kodu heading.

Wypełnij każdą sekcję treścią. Postępuj zgodnie z tymi wytycznymi:

• Organizuj treści za pomocą nagłówków H2 i H3.
• Dla overview, ustaw kontekst tematu za pomocą pojedynczego akapitu.
• Dla body wyjaśnij koncepcję.
• Dla whatsnext, podaj wypunktowaną listę tematów (maksymalnie 5), aby dowiedzieć się więcej o koncepcji.

Strona adnotacje jest opublikowanym przykładem strony koncepcyjnej.

Zadanie (ang. Task)

Strony opisujące wykonywanie zadań zawierają minimum wyjaśnień, ale zwykle podają odnośniki do dokumentacji objaśniającej pojęcia i szerszy kontekst danego tematu.

Aby napisać nową stronę zadania, utwórz plik Markdown w podkatalogu katalogu /content/en/docs/tasks, z następującymi sekcjami:

Sekcje overview, steps i discussion pojawiają się jako komentarze na stronie zadania. Możesz dodać sekcje prerequisites i whatsnext do swojej strony za pomocą kodu heading.

Każdą sekcję uzupełnij treścią. Użyj następujących wytycznych:

• Użyj nagłówków poziomu H2 lub niższego (z dwoma wiodącymi znakami #). Sekcje są automatycznie tytułowane przez szablon.
• Dla overview użyj akapitu, aby ustawić kontekst dla całego tematu.
• Dla prerequisites używaj list punktowanych, kiedy to możliwe. Zaczynaj dodawać dodatkowe wymagania wstępne poniżej include. Domyślne wymagania wstępne obejmują działający klaster Kubernetesa.
• Dla steps używaj numerowanych list.
• Do omówienia użyj standardowej treści, aby rozwinąć informacje zawarte w sekcji steps.
• Dla whatsnext, podaj listę punktowaną z maksymalnie 5 tematami, które mogą zainteresować czytelnika jako kolejne tematy do przeczytania.

Przykład opublikowanego tematu zadania to Korzystanie z proxy HTTP do uzyskania dostępu do API Kubernetesa.

Samouczek (ang. Tutorial)

Strona samouczka pokazuje, jak osiągnąć cel, który jest bardziej złożony niż pojedyncze zadanie. Zazwyczaj strona samouczka składa się z kilku sekcji, z których każda zawiera sekwencję kroków. Na przykład samouczek może przeprowadzać użytkownika przez przykładowy kod ilustrujący określoną funkcję Kubernetesa. Samouczki mogą zawierać ogólne wyjaśnienia, ale powinny odsyłać do powiązanych tematów koncepcyjnych w celu dogłębnego omówienia zagadnienia.

Aby napisać nową stronę samouczka, utwórz plik Markdown w podkatalogu katalogu /content/en/docs/tutorials, z następującymi sekcjami:

Sekcje overview, objectives i lessoncontent pojawiają się jako komentarze na stronie samouczka. Możesz dodać sekcje prerequisites, cleanup i whatsnext do swojej strony za pomocą kodu heading.

Każdą sekcję uzupełnij treścią. Użyj następujących wytycznych:

• Użyj nagłówków poziomu H2 lub niższego (z dwoma wiodącymi znakami #). Sekcje są automatycznie tytułowane przez szablon.
• Dla overview użyj akapitu, aby ustawić kontekst dla całego tematu.
• W przypadku prerequisites używaj, jeśli to możliwe, list punktowanych. Dodaj dodatkowe wymagania wstępne poniżej tych domyślnie uwzględnionych.
• Dla objectives, używaj list wypunktowanych.
• Dla lessoncontent, użyj mieszanki list numerowanych i treści narracyjnej w zależności od potrzeb.
• W przypadku cleanup, użyj numerowanych list, aby opisać kroki niezbędne do posprzątania stanu klastra po zakończeniu zadania.
• Dla whatsnext, podaj listę punktowaną z maksymalnie 5 tematami, które mogą zainteresować czytelnika jako kolejne tematy do przeczytania.

Przykładem opublikowanego tematu samouczka jest Uruchamianie aplikacji bezstanowej przy użyciu Deployment.

Materiały źródłowe (ang. Reference)

Każde narzędzie Kubernetesa ma swoją stronę materiałów źródłowych (ang. reference page), gdzie można znaleźć jego opis i listę dostępnych opcji. Dokumentacja ta jest generowana przez skrypty, które automatycznie pobierają informacje z poleceń narzędzia.

Strona z odniesieniem do narzędzia ma kilka możliwych sekcji:

Przykłady opublikowanych stron referencyjnych narzędzi to:

• kubeadm init
• kube-apiserver
• kubectl

Co dalej?

• Dowiedz się więcej o Przewodniku stylu
• Dowiedz się więcej o Przewodniku treści
• Dowiedz się więcej o organizacji treści

7.6 - Tłumaczenie dokumentacji na język polski

Na tej stronie znajdziesz wskazówki i wytyczne przydatne przy tłumaczeniu dokumentacji Kubernetesa na język polski.

Dokumentem nadrzędnym jest angielski opis stylu dokumentacji.

Wskazówki ogólne

Staramy się, aby styl tłumaczenia był jak najbardziej naturalny. W przypadku dokumentacji technicznej może być to trudne zadanie, szczególnie gdy chcemy utrzymać precyzję tłumaczenia. Zależy nam na unikaniu sytuacji, kiedy tekst zaczyna sprawiać wrażenie przetłumaczonego maszynowo.

Pamiętajmy też, że oficjalna wykładnia zawsze znajduje się w tekście angielskim. Polskie tłumaczenie ma ułatwić pierwsze kroki osobom, które zaczynają swoją przygodę z Kubernetesem.

Wytyczne szczegółowe

Odmiana terminu Kubernetes

Kubernetes jest nazwą własną, liczba pojedyncza, rodzaj męski. Odmieniamy: Kubernetesa, Kubernetesem itp. W uzasadnionych przypadkach można stosować też "system Kubernetes".

Odmiana terminów Pod, Deployment

Odmieniamy zgodnie z ogólnymi zasadami - poda, deploymentu itp.

Ujednolicony słownik

W sieci dostępne są słowniki terminów informatycznych. Poniższa tabela zawiera słowa specyficzne dla Kubernetesa i inne często używane wyrażenia.

8 -

Aby zastosować odpowiedni filtr, kliknij w etykietę lub użyj rozwijanej listy. Aby posortować rosnąco lub malejąco, kliknij w wybrany nagłówek tabeli.

Filtruj według pojęć:
Filtruj według obiektów:
Filtruj według poleceń: