Kubernetes - szybki przewodnik

Kubernetes w narzędziu do zarządzania kontenerami typu open source obsługiwanym przez Cloud Native Computing Foundation (CNCF). Jest to również znane jako ulepszona wersja Borg, która została opracowana w Google do zarządzania zarówno długotrwałymi procesami, jak i zadaniami wsadowymi, które wcześniej były obsługiwane przez oddzielne systemy.

Kubernetes oferuje możliwość automatyzacji wdrażania, skalowania aplikacji i operacji na kontenerach aplikacji w klastrach. Jest w stanie stworzyć infrastrukturę zorientowaną na kontener.

Funkcje Kubernetes

Oto niektóre z ważnych funkcji Kubernetes.

• Kontynuuje rozwój, integrację i wdrażanie

• Infrastruktura kontenerowa

• Zarządzanie ukierunkowane na aplikacje

• Infrastruktura skalowalna automatycznie

• Spójność środowiska w testowaniu i produkcji

• Infrastruktura luźno powiązana, w której każdy komponent może działać jako oddzielna jednostka

• Większa gęstość wykorzystania zasobów

• Przewidywalna infrastruktura, która zostanie stworzona

Jednym z kluczowych elementów Kubernetes jest to, że może uruchamiać aplikacje na klastrach infrastruktury maszyn fizycznych i wirtualnych. Ma również możliwość uruchamiania aplikacji w chmurze.It helps in moving from host-centric infrastructure to container-centric infrastructure.

W tym rozdziale omówimy podstawową architekturę Kubernetes.

Kubernetes - architektura klastra

Jak widać na poniższym diagramie, Kubernetes jest zgodny z architekturą klient-serwer. W tym przypadku mamy master zainstalowany na jednej maszynie, a węzeł na osobnych maszynach Linux.

Kluczowe komponenty master i node są zdefiniowane w następnej sekcji.

Kubernetes - główne komponenty maszyn

Poniżej znajdują się komponenty Kubernetes Master Machine.

etcd

Przechowuje informacje o konfiguracji, które mogą być używane przez każdy z węzłów w klastrze. Jest to magazyn wartości kluczy o wysokiej dostępności, który można rozdzielić na wiele węzłów. Jest dostępny tylko dla serwera Kubernetes API, ponieważ może zawierać poufne informacje. Jest to rozproszony magazyn wartości kluczy, dostępny dla wszystkich.

Serwer API

Kubernetes to serwer API, który zapewnia całą operację na klastrze za pomocą API. Serwer API implementuje interfejs, co oznacza, że ​​różne narzędzia i biblioteki mogą się z nim łatwo komunikować.Kubeconfigto pakiet wraz z narzędziami po stronie serwera, których można używać do komunikacji. Udostępnia Kubernetes API.

Kierownik Kontrolera

Ten komponent jest odpowiedzialny za większość kolektorów, które regulują stan klastra i wykonują zadanie. Ogólnie można go uznać za demona działającego w pętli nie kończącej się i odpowiedzialnego za zbieranie i wysyłanie informacji do serwera API. Działa w kierunku uzyskania udostępnionego stanu klastra, a następnie wprowadzenia zmian w celu przywrócenia bieżącego stanu serwera do pożądanego stanu. Kluczowymi kontrolerami są kontroler replikacji, kontroler punktu końcowego, kontroler przestrzeni nazw i kontroler konta usługi. Menedżer kontrolera obsługuje różnego rodzaju kontrolery do obsługi węzłów, punktów końcowych itp.

Planista

Jest to jeden z kluczowych elementów mastera Kubernetes. Jest to usługa master odpowiedzialna za dystrybucję obciążenia. Odpowiada za śledzenie wykorzystania obciążenia roboczego w węzłach klastra, a następnie umieszczanie obciążenia, na którym zasoby są dostępne, i akceptowanie obciążenia. Innymi słowy, jest to mechanizm odpowiedzialny za przydzielanie zasobników do dostępnych węzłów. Harmonogram jest odpowiedzialny za wykorzystanie obciążenia i przydzielanie pod do nowego węzła.

Kubernetes - składniki węzłów

Poniżej znajdują się kluczowe komponenty serwera Node, które są niezbędne do komunikacji z masterem Kubernetes.

Doker

Pierwszym wymaganiem każdego węzła jest Docker, który pomaga w uruchamianiu hermetyzowanych kontenerów aplikacji w stosunkowo izolowanym, ale lekkim środowisku operacyjnym.

Usługa Kubelet

Jest to niewielka usługa w każdym węźle odpowiedzialna za przekazywanie informacji do i z usługi płaszczyzny kontroli. Współdziała zetcdstore, aby odczytać szczegóły konfiguracji i wartości wright. To komunikuje się z głównym komponentem w celu otrzymywania poleceń i pracy. Plikkubeletproces przejmuje wtedy odpowiedzialność za utrzymanie stanu pracy i serwera węzła. Zarządza regułami sieciowymi, przekierowaniem portów itp.

Usługa proxy Kubernetes

Jest to usługa proxy, która działa na każdym węźle i pomaga w udostępnianiu usług hostowi zewnętrznemu. Pomaga w przekazywaniu żądania do poprawnych kontenerów i jest w stanie wykonać podstawowe równoważenie obciążenia. Daje pewność, że środowisko sieciowe jest przewidywalne i dostępne, a jednocześnie jest izolowane. Zarządza podami w węźle, woluminach, sekretach, tworzy kontrolę stanu nowych kontenerów itp.

Kubernetes - struktura główna i węzłowa

Poniższe ilustracje przedstawiają strukturę Kubernetes Master i Node.

Ważne jest, aby skonfigurować wirtualne centrum danych (vDC) przed skonfigurowaniem Kubernetes. Można to uznać za zestaw maszyn, na których mogą komunikować się ze sobą za pośrednictwem sieci. Aby uzyskać praktyczne podejście, możesz ustawić vDC naPROFITBRICKS jeśli nie masz skonfigurowanej infrastruktury fizycznej lub chmury.

Po zakończeniu konfiguracji IaaS w dowolnej chmurze należy skonfigurować Master i Node.

Note- Konfiguracja jest pokazana dla maszyn Ubuntu. To samo można skonfigurować również na innych komputerach z systemem Linux.

Wymagania wstępne

Installing Docker- Docker jest wymagany we wszystkich wystąpieniach Kubernetes. Poniżej przedstawiono kroki, aby zainstalować Docker.

Step 1 - Zaloguj się do komputera za pomocą konta użytkownika root.

Step 2- Zaktualizuj informacje o pakiecie. Upewnij się, że pakiet apt działa.

Step 3 - Uruchom następujące polecenia.

$ sudo apt-get update $ sudo apt-get install apt-transport-https ca-certificates

Step 4 - Dodaj nowy klucz GPG.

$ sudo apt-key adv \ --keyserver hkp://ha.pool.sks-keyservers.net:80 \ --recv-keys 58118E89F3A912897C070ADBF76221572C52609D $ echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" | sudo tee
/etc/apt/sources.list.d/docker.list

Step 5 - Zaktualizuj obraz pakietu interfejsu API.

$ sudo apt-get update

Po wykonaniu wszystkich powyższych zadań można rozpocząć właściwą instalację silnika Docker. Jednak zanim to nastąpi, musisz sprawdzić, czy wersja jądra, której używasz, jest poprawna.

Zainstaluj silnik platformy Docker

Uruchom następujące polecenia, aby zainstalować aparat Docker.

Step 1 - Zaloguj się do komputera.

Step 2 - Zaktualizuj indeks pakietu.

$ sudo apt-get update

Step 3 - Zainstaluj aparat Docker za pomocą następującego polecenia.

$ sudo apt-get install docker-engine

Step 4 - Uruchom demona Dockera.

$ sudo apt-get install docker-engine

Step 5 - Aby bardzo, jeśli Docker jest zainstalowany, użyj następującego polecenia.

$ sudo docker run hello-world

Zainstaluj etcd 2.0

Należy to zainstalować na Kubernetes Master Machine. Aby go zainstalować, uruchom następujące polecenia.

$ curl -L https://github.com/coreos/etcd/releases/download/v2.0.0/etcd
-v2.0.0-linux-amd64.tar.gz -o etcd-v2.0.0-linux-amd64.tar.gz ->1
$ tar xzvf etcd-v2.0.0-linux-amd64.tar.gz ------>2 $ cd etcd-v2.0.0-linux-amd64 ------------>3
$ mkdir /opt/bin ------------->4 $ cp etcd* /opt/bin ----------->5

W powyższym zestawie poleceń -

• Najpierw pobieramy plik etcd. Zapisz to pod określoną nazwą.
• Następnie musimy odtarować pakiet tar.
• Robimy reż. wewnątrz / opt o nazwie bin.
• Skopiuj wyodrębniony plik do lokalizacji docelowej.

Teraz jesteśmy gotowi do budowy Kubernetes. Musimy zainstalować Kubernetes na wszystkich komputerach w klastrze.

$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git $ cd kubernetes
$ make release

Powyższe polecenie utworzy plik _outputdir w katalogu głównym folderu kubernetes. Następnie możemy wyodrębnić katalog do dowolnego wybranego przez nas katalogu / opt / bin itp.

Następnie przychodzi część dotycząca sieci, w której musimy zacząć od konfiguracji mastera i węzła Kubernetes. W tym celu dokonamy wpisu w pliku hosta, który można wykonać na komputerze węzła.

$ echo "<IP address of master machine> kube-master
< IP address of Node Machine>" >> /etc/hosts

Poniżej będzie wynik powyższego polecenia.

Teraz zaczniemy od rzeczywistej konfiguracji w Kubernetes Master.

Najpierw zaczniemy kopiować wszystkie pliki konfiguracyjne do ich właściwej lokalizacji.

$ cp <Current dir. location>/kube-apiserver /opt/bin/ $ cp <Current dir. location>/kube-controller-manager /opt/bin/
$ cp <Current dir. location>/kube-kube-scheduler /opt/bin/ $ cp <Current dir. location>/kubecfg /opt/bin/
$ cp <Current dir. location>/kubectl /opt/bin/ $ cp <Current dir. location>/kubernetes /opt/bin/

Powyższe polecenie skopiuje wszystkie pliki konfiguracyjne do wymaganej lokalizacji. Teraz wrócimy do tego samego katalogu, w którym zbudowaliśmy folder Kubernetes.

$ cp kubernetes/cluster/ubuntu/init_conf/kube-apiserver.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/init_conf/kube-controller-manager.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-kube-scheduler.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-apiserver /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-controller-manager /etc/init.d/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kube-kube-scheduler /etc/init.d/

$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/ $ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/

Następnym krokiem jest aktualizacja skopiowanego pliku konfiguracyjnego w / etc. reż.

Skonfiguruj etcd na urządzeniu głównym za pomocą następującego polecenia.

$ ETCD_OPTS = "-listen-client-urls = http://kube-master:4001"

Skonfiguruj kube-apiserver

W tym celu na wzorcu musimy edytować plik /etc/default/kube-apiserver plik, który skopiowaliśmy wcześniej.

$ KUBE_APISERVER_OPTS = "--address = 0.0.0.0 \
--port = 8080 \
--etcd_servers = <The path that is configured in ETCD_OPTS> \
--portal_net = 11.1.1.0/24 \
--allow_privileged = false \
--kubelet_port = < Port you want to configure> \
--v = 0"

Skonfiguruj menedżera kontrolera kube

Musimy dodać następującą zawartość w /etc/default/kube-controller-manager.

$ KUBE_CONTROLLER_MANAGER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--machines = kube-minion \ -----> #this is the kubernatics node
--v = 0

Następnie skonfiguruj harmonogram Kube w odpowiednim pliku.

$ KUBE_SCHEDULER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--v = 0"

Gdy wszystkie powyższe zadania zostaną ukończone, możemy przejść dalej i przywołać Kubernetes Master. Aby to zrobić, zrestartujemy Dockera.

$ service docker restart

Konfiguracja węzła Kubernetes

Węzeł Kubernetes będzie uruchamiał dwie usługi kubelet and the kube-proxy. Zanim przejdziemy dalej, musimy skopiować pliki binarne, które pobraliśmy do ich wymaganych folderów, w których chcemy skonfigurować węzeł kubernetes.

Użyj tej samej metody kopiowania plików, którą zrobiliśmy dla wzorca kubernetes. Ponieważ będzie uruchamiać tylko kubelet i kube-proxy, skonfigurujemy je.

$ cp <Path of the extracted file>/kubelet /opt/bin/ $ cp <Path of the extracted file>/kube-proxy /opt/bin/
$ cp <Path of the extracted file>/kubecfg /opt/bin/ $ cp <Path of the extracted file>/kubectl /opt/bin/
$ cp <Path of the extracted file>/kubernetes /opt/bin/

Teraz skopiujemy treść do odpowiedniego katalogu.

$ cp kubernetes/cluster/ubuntu/init_conf/kubelet.conf /etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-proxy.conf /etc/init/ $ cp kubernetes/cluster/ubuntu/initd_scripts/kubelet /etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-proxy /etc/init.d/ $ cp kubernetes/cluster/ubuntu/default_scripts/kubelet /etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy /etc/default/

Skonfigurujemy kubelet i kube-proxy conf akta.

Skonfigurujemy /etc/init/kubelet.conf.

$ KUBELET_OPTS = "--address = 0.0.0.0 \
--port = 10250 \
--hostname_override = kube-minion \
--etcd_servers = http://kube-master:4001 \
--enable_server = true
--v = 0"
/

W przypadku kube-proxy skonfigurujemy za pomocą następującego polecenia.

$ KUBE_PROXY_OPTS = "--etcd_servers = http://kube-master:4001 \
--v = 0"
/etc/init/kube-proxy.conf

Na koniec zrestartujemy usługę Docker.

$ service docker restart

Teraz skończyliśmy konfigurację. Możesz to sprawdzić, uruchamiając następujące polecenia.

$ /opt/bin/kubectl get minions

Obrazy Kubernetes (Docker) są kluczowymi elementami składowymi infrastruktury kontenerowej. Na razie obsługujemy Kubernetes tylko do obsługi obrazów Dockera. Każdy kontener w kapsule ma w sobie uruchomiony obraz Dockera.

Kiedy konfigurujemy pod, właściwość obrazu w pliku konfiguracyjnym ma taką samą składnię jak polecenie Docker. Plik konfiguracyjny zawiera pole do zdefiniowania nazwy obrazu, który planujemy pobrać z rejestru.

Poniżej znajduje się wspólna struktura konfiguracji, która pobierze obraz z rejestru Docker i wdroży go do kontenera Kubernetes.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
      containers:
         - name: neo4j-server ------------------------> 2
         image: <Name of the Docker image>----------> 3
         imagePullPolicy: Always ------------->4
         command: ["echo", "SUCCESS"] ------------------->

W powyższym kodzie zdefiniowaliśmy -

• name: Tesing_for_Image_pull - Ta nazwa ma na celu zidentyfikowanie i sprawdzenie nazwy kontenera, który zostałby utworzony po ściągnięciu obrazów z rejestru Docker.

• name: neo4j-server- To jest nazwa nadana kontenerowi, który próbujemy utworzyć. Tak jak daliśmy neo4j-server.

• image: <Name of the Docker image>- To jest nazwa obrazu, który próbujemy pobrać z Dockera lub wewnętrznego rejestru obrazów. Musimy zdefiniować pełną ścieżkę rejestru wraz z nazwą obrazu, który próbujemy pobrać.

• imagePullPolicy - Zawsze - ta zasada pobierania obrazu określa, że ​​za każdym razem, gdy uruchomimy ten plik w celu utworzenia kontenera, ponownie pobierze on tę samą nazwę.

• command: [“echo”, “SUCCESS”] - Dzięki temu, gdy utworzymy kontener i jeśli wszystko pójdzie dobrze, wyświetli się komunikat, gdy uzyskamy dostęp do kontenera.

Aby pobrać obraz i utworzyć kontener, uruchomimy następujące polecenie.

$ kubectl create –f Tesing_for_Image_pull

Po pobraniu dziennika otrzymamy wynik jako pomyślny.

$ kubectl log Tesing_for_Image_pull

Powyższe polecenie zakończy się sukcesem lub otrzymamy wynik jako niepowodzenie.

Note - Zaleca się samodzielne wypróbowanie wszystkich poleceń.

Główną funkcją zadania jest stworzenie jednej lub więcej kapsuły i śledzenie sukcesu strąków. Zapewniają pomyślne ukończenie określonej liczby zasobników. Po zakończeniu określonej liczby pomyślnych uruchomień zasobników zadanie jest uznawane za zakończone.

Tworzenie pracy

Użyj następującego polecenia, aby utworzyć zadanie -

apiVersion: v1
kind: Job ------------------------> 1
metadata:
   name: py
   spec:
   template:
      metadata
      name: py -------> 2
      spec:
         containers:
            - name: py ------------------------> 3
            image: python----------> 4
            command: ["python", "SUCCESS"]
            restartPocliy: Never --------> 5

W powyższym kodzie zdefiniowaliśmy -

• kind: Job → Zdefiniowaliśmy ten rodzaj jako Hiob, który powie kubectl że yaml używany plik służy do tworzenia pod typu zadania.

• Name:py → To jest nazwa szablonu, którego używamy, a specyfikacja definiuje szablon.

• name: py → nadaliśmy nazwę jako py pod specyfikacją kontenera, która pomaga zidentyfikować Pod, który zostanie z niego utworzony.

• Image: python → obraz, który będziemy ciągnąć, aby stworzyć pojemnik, który będzie działał wewnątrz kapsuły.

• restartPolicy: Never →Ten warunek ponownego uruchomienia obrazu jest podawany jako nigdy, co oznacza, że ​​jeśli kontener zostanie zabity lub jeśli jest fałszywy, nie uruchomi się ponownie.

Utworzymy zadanie za pomocą następującego polecenia z yaml, który jest zapisywany pod nazwą py.yaml.

$ kubectl create –f py.yaml

Powyższe polecenie utworzy zadanie. Jeśli chcesz sprawdzić stan zadania, użyj następującego polecenia.

$ kubectl describe jobs/py

Powyższe polecenie utworzy zadanie. Jeśli chcesz sprawdzić stan zadania, użyj następującego polecenia.

Zaplanowana praca

Zaplanowane zadanie w Kubernetes używa Cronetes, który przyjmuje zadanie Kubernetes i uruchamia je w klastrze Kubernetes.

• Planowanie zadania spowoduje uruchomienie zasobnika w określonym momencie.
• Tworzy się dla niego parodystyczną pracę, która wywołuje się automatycznie.

Note - Funkcja zaplanowanego zadania jest obsługiwana przez wersję 1.4, a API betch / v2alpha 1 jest włączane po przejściu –runtime-config=batch/v2alpha1 podczas uruchamiania serwera API.

Użyjemy tego samego yamla, którego użyliśmy do utworzenia zadania i ustawimy je jako zaplanowane.

apiVersion: v1
kind: Job
metadata:
   name: py
spec:
   schedule: h/30 * * * * ? -------------------> 1
   template:
      metadata
         name: py
      spec:
         containers:
         - name: py
         image: python
         args:
/bin/sh -------> 2
-c
ps –eaf ------------> 3
restartPocliy: OnFailure

W powyższym kodzie zdefiniowaliśmy -

• schedule: h/30 * * * * ? → Aby zaplanować uruchamianie zadania co 30 minut.

• /bin/sh: To wejdzie do kontenera z / bin / sh

• ps –eaf → Uruchomi polecenie ps -eaf na komputerze i wyświetli listę wszystkich uruchomionych procesów wewnątrz kontenera.

Ta koncepcja zaplanowanego zadania jest przydatna, gdy próbujemy zbudować i uruchomić zestaw zadań w określonym momencie, a następnie zakończyć proces.

Etykiety

Etykiety to pary klucz-wartość, które są dołączone do podów, kontrolera replikacji i usług. Są używane jako atrybuty identyfikujące obiekty, takie jak pody i kontroler replikacji. Można je dodawać do obiektu w czasie tworzenia i można je dodawać lub modyfikować w czasie wykonywania.

Selektory

Etykiety nie zapewniają wyjątkowości. Ogólnie można powiedzieć, że wiele obiektów może mieć takie same etykiety. Selektor etykiet to podstawowy element grupujący w Kubernetes. Są używane przez użytkowników do wybierania zbioru obiektów.

Kubernetes API obsługuje obecnie dwa typy selektorów -

• Selektory oparte na równości
• Selektory oparte na zestawie

Selektory oparte na równości

Umożliwiają filtrowanie według klucza i wartości. Pasujące obiekty powinny spełniać wszystkie określone etykiety.

Selektory oparte na zestawie

Selektory oparte na zbiorach umożliwiają filtrowanie kluczy według zestawu wartości.

apiVersion: v1
kind: Service
metadata:
   name: sp-neo4j-standalone
spec:
   ports:
      - port: 7474
      name: neo4j
   type: NodePort
   selector:
      app: salesplatform ---------> 1
      component: neo4j -----------> 2

W powyższym kodzie używamy selektora etykiet jako app: salesplatform i komponent jak component: neo4j.

Po uruchomieniu pliku przy użyciu rozszerzenia kubectl polecenie, utworzy usługę o nazwie sp-neo4j-standalone który będzie komunikował się na porcie 7474. Ype to NodePort z nowym selektorem etykiet jako app: salesplatform i component: neo4j.

Przestrzeń nazw zapewnia dodatkową kwalifikację do nazwy zasobu. Jest to pomocne, gdy wiele zespołów korzysta z tego samego klastra i istnieje możliwość kolizji nazw. Może to być wirtualna ściana między wieloma klastrami.

Funkcjonalność przestrzeni nazw

Oto niektóre z ważnych funkcji przestrzeni nazw w Kubernetes -

• Przestrzenie nazw ułatwiają komunikację między podami przy użyciu tej samej przestrzeni nazw.

• Przestrzenie nazw to wirtualne klastry, które mogą znajdować się na szczycie tego samego klastra fizycznego.

• Zapewniają logiczne oddzielenie zespołów i ich środowisk.

Utwórz przestrzeń nazw

Następujące polecenie służy do tworzenia przestrzeni nazw.

apiVersion: v1
kind: Namespce
metadata
   name: elk

Kontroluj przestrzeń nazw

Następujące polecenie służy do sterowania przestrzenią nazw.

$ kubectl create –f namespace.yml ---------> 1
$ kubectl get namespace -----------------> 2 $ kubectl get namespace <Namespace name> ------->3
$ kubectl describe namespace <Namespace name> ---->4 $ kubectl delete namespace <Namespace name>

W powyższym kodzie

• Używamy polecenia, aby utworzyć przestrzeń nazw.
• Spowoduje to wyświetlenie wszystkich dostępnych przestrzeni nazw.
• Spowoduje to uzyskanie określonej przestrzeni nazw, której nazwa jest określona w poleceniu.
• W tym miejscu zostaną opisane wszystkie szczegóły dotyczące usługi.
• Spowoduje to usunięcie określonej przestrzeni nazw obecnej w klastrze.

Korzystanie z przestrzeni nazw w usłudze - przykład

Poniżej znajduje się przykładowy plik dotyczący używania przestrzeni nazw w usłudze.

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

W powyższym kodzie używamy tej samej przestrzeni nazw w metadanych usługi o nazwie elk.

Węzeł to działająca maszyna w klastrze Kubernetes, znana również jako stronnik. Są to jednostki robocze, które mogą być instancjami fizycznymi, wirtualnymi lub chmurowymi.

Każdy węzeł ma całą wymaganą konfigurację wymaganą do uruchomienia na nim platformy, takiej jak usługa proxy i usługa kubelet wraz z platformą Docker, która jest używana do uruchamiania kontenerów platformy Docker w pod utworzonym w węźle.

Nie są tworzone przez Kubernetes, ale są tworzone zewnętrznie przez dostawcę usług w chmurze lub menedżera klastra Kubernetes na maszynach fizycznych lub maszynach wirtualnych.

Kluczowym elementem Kubernetes do obsługi wielu węzłów jest menedżer kontrolerów, który obsługuje wiele rodzajów kontrolerów do zarządzania węzłami. Aby zarządzać węzłami, Kubernetes tworzy obiekt typu węzeł, który potwierdzi, że utworzony obiekt jest prawidłowym węzłem.

Serwis z Selektorem

apiVersion: v1
kind: node
metadata:
   name: < ip address of the node>
   labels:
      name: <lable name>

W formacie JSON tworzony jest rzeczywisty obiekt, który wygląda następująco -

{
   Kind: node
   apiVersion: v1
   "metadata": 
   {
      "name": "10.01.1.10",
      "labels"
      {
         "name": "cluster 1 node"
      }
   }
}

Kontroler węzła

Są zbiorem usług, które działają w Kubernetes master i na bieżąco monitorują węzeł w klastrze na podstawie metadata.name. Jeśli wszystkie wymagane usługi są uruchomione, węzeł jest sprawdzany, a nowo utworzony pod zostanie przypisany do tego węzła przez kontroler. Jeśli nie jest ważny, master nie przypisze do niego żadnego strąka i będzie czekał, aż stanie się ważny.

Mistrz Kubernetes automatycznie rejestruje węzeł, jeśli –register-node flaga jest prawdziwa.

–register-node = true

Jeśli jednak administrator klastra chce zarządzać nim ręcznie, można to zrobić, obracając mieszkanie o -

–register-node = false

Usługę można zdefiniować jako logiczny zestaw zasobników. Można go zdefiniować jako abstrakcję w górnej części kapsuły, która zapewnia pojedynczy adres IP i nazwę DNS, za pomocą której można uzyskać dostęp do zasobników. Dzięki usłudze bardzo łatwo jest zarządzać konfiguracją równoważenia obciążenia. Pomaga strąkom w bardzo łatwym skalowaniu.

Usługa to obiekt REST w Kubernetes, którego definicję można przesłać do Kubernetes apiServer na serwerze głównym Kubernetes w celu utworzenia nowej instancji.

Usługa bez selektora

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
   targetPort: 31999

Powyższa konfiguracja utworzy usługę o nazwie Tutorial_point_service.

Plik konfiguracji usługi z selektorem

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: "My Application" -------------------> (Selector)
   ports:
   - port: 8080
   targetPort: 31999

W tym przykładzie mamy selektor; więc aby przenieść ruch, musimy ręcznie utworzyć punkt końcowy.

apiVersion: v1
kind: Endpoints
metadata:
   name: Tutorial_point_service
subnets:
   address:
      "ip": "192.168.168.40" -------------------> (Selector)
   ports:
      - port: 8080

W powyższym kodzie utworzyliśmy punkt końcowy, który będzie kierował ruch do punktu końcowego zdefiniowanego jako „192.168.168.40:8080”.

Tworzenie usług wieloportowych

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: “My Application” -------------------> (Selector)
   ClusterIP: 10.3.0.12
   ports:
      -name: http
      protocol: TCP
      port: 80
      targetPort: 31999
   -name:https
      Protocol: TCP
      Port: 443
      targetPort: 31998

Rodzaje usług

ClusterIP- Pomaga to w ograniczaniu usługi w klastrze. Ujawnia usługę w ramach zdefiniowanego klastra Kubernetes.

spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService

NodePort- Ujawni usługę na statycznym porcie we wdrożonym węźle. ZAClusterIP usługa, do której NodePortusługa będzie kierować, jest tworzony automatycznie. Dostęp do usługi można uzyskać spoza klastra za pomocąNodeIP:nodePort.

spec:
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService
      clusterIP: 10.20.30.40

Load Balancer - Wykorzystuje system równoważenia obciążenia dostawców usług w chmurze. NodePort i ClusterIP usługi są tworzone automatycznie, do których będzie kierować zewnętrzny moduł równoważenia obciążenia.

Pełna obsługa yamlplik z typem usługi jako Port węzła. Spróbuj sam go stworzyć.

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: env_name

Pod to zbiór kontenerów i ich miejsca przechowywania w węźle klastra Kubernetes. Możliwe jest utworzenie kapsuły z wieloma kontenerami w środku. Na przykład przechowywanie kontenera bazy danych i kontenera danych w tym samym pod.

Rodzaje strąków

Istnieją dwa rodzaje strąków -

• Jeden pojemnik na pojemnik
• Pojemnik na wiele pojemników

Pojedyncza kapsuła kontenerowa

Można je po prostu utworzyć za pomocą polecenia kubctl run, w którym masz zdefiniowany obraz w rejestrze Dockera, który pobierzemy podczas tworzenia poda.

$ kubectl run <name of pod> --image=<name of the image from registry>

Example - Stworzymy kapsułę z obrazem kocura, który jest dostępny w hubie Docker.

$ kubectl run tomcat --image = tomcat:8.0

Można to również zrobić, tworząc plik yaml plik, a następnie uruchom plik kubectl create Komenda.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always

Kiedyś powyżej yaml plik zostanie utworzony, zapiszemy plik pod nazwą tomcat.yml i uruchom polecenie create, aby uruchomić dokument.

$ kubectl create –f tomcat.yml

Stworzy kapsułę z imieniem kocur. Możemy użyć polecenia opisz razem zkubectl opisać kapsułę.

Pojemnik na wiele pojemników

Wiele kontenerów jest tworzonych przy użyciu yaml mail z definicją pojemników.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
containerPort: 7501
   imagePullPolicy: Always

W powyższym kodzie utworzyliśmy jeden kapsułę z dwoma kontenerami wewnątrz, jeden dla tomcat, a drugi dla MongoDB.

Kontroler replikacji to jedna z kluczowych funkcji Kubernetes, która jest odpowiedzialna za zarządzanie cyklem życia poda. Jest odpowiedzialny za upewnienie się, że określona liczba replik pod jest uruchomiona w dowolnym momencie. Jest używany w czasie, gdy chce się upewnić, że określona liczba kapsułek lub co najmniej jeden jest uruchomiony. Ma możliwość podniesienia lub zmniejszenia określonej liczby strąków.

Najlepszą praktyką jest używanie kontrolera replikacji do zarządzania cyklem życia kapsuły zamiast wielokrotnego tworzenia kapsuły.

apiVersion: v1
kind: ReplicationController --------------------------> 1
metadata:
   name: Tomcat-ReplicationController --------------------------> 2
spec:
   replicas: 3 ------------------------> 3
   template:
      metadata:
         name: Tomcat-ReplicationController
      labels:
         app: App
         component: neo4j
      spec:
         containers:
         - name: Tomcat- -----------------------> 4
         image: tomcat: 8.0
         ports:
            - containerPort: 7474 ------------------------> 5

Szczegóły konfiguracji

• Kind: ReplicationController → W powyższym kodzie zdefiniowaliśmy rodzaj jako kontroler replikacji, który informuje plik kubectl że yaml plik zostanie użyty do utworzenia kontrolera replikacji.

• name: Tomcat-ReplicationController→ Pomaga to w identyfikacji nazwy, pod którą zostanie utworzony kontroler replikacji. Jeśli uruchomimy kubctl, pobierzrc < Tomcat-ReplicationController > pokaże szczegóły kontrolera replikacji.

• replicas: 3 → Pomaga to kontrolerowi replikacji zrozumieć, że musi utrzymywać trzy repliki kapsuły w dowolnym momencie cyklu życia kapsuły.

• name: Tomcat → W sekcji specyfikacji zdefiniowaliśmy nazwę jako tomcat, która powie kontrolerowi replikacji, że kontener znajdujący się w zasobnikach to tomcat.

• containerPort: 7474 → Pomaga to w upewnieniu się, że wszystkie węzły w klastrze, w których jest uruchomiony kontener wewnątrz kapsuły, będą widoczne na tym samym porcie 7474.

Tutaj usługa Kubernetes działa jako moduł równoważenia obciążenia dla trzech replik tomcat.

Zestaw replik zapewnia, ile replik zasobnika powinno być uruchomionych. Można to uznać za zamiennik kontrolera replikacji. Kluczowa różnica między zestawem replik a kontrolerem replikacji polega na tym, że kontroler replikacji obsługuje tylko selektor oparty na równości, podczas gdy zestaw replik obsługuje selektor oparty na zestawie.

apiVersion: extensions/v1beta1 --------------------->1
kind: ReplicaSet --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
         tier: Backend ------------------> 3
      matchExpression:
{ key: tier, operation: In, values: [Backend]} --------------> 4
template:
   metadata:
      lables:
         app: Tomcat-ReplicaSet
         tier: Backend
      labels:
         app: App
         component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Szczegóły konfiguracji

• apiVersion: extensions/v1beta1 → W powyższym kodzie wersja API to zaawansowana wersja beta Kubernetes, która obsługuje koncepcję zestawu replik.

• kind: ReplicaSet → Zdefiniowaliśmy rodzaj jako zestaw replik, który pomaga kubectl zrozumieć, że plik jest używany do tworzenia zestawu replik.

• tier: Backend → Zdefiniowaliśmy warstwę etykiet jako zaplecze, które tworzy pasujący selektor.

• {key: tier, operation: In, values: [Backend]} → To pomoże matchExpression aby zrozumieć warunek dopasowania, który zdefiniowaliśmy, oraz w operacji używanej przez matchlabel aby znaleźć szczegóły.

Uruchom powyższy plik za pomocą kubectl i utwórz zestaw replik zaplecza z podaną definicją w yaml plik.

Wdrożenia są uaktualnione i nowsza wersja kontrolera replikacji. Zarządzają wdrażaniem zestawów replik, które są również ulepszoną wersją kontrolera replikacji. Mają możliwość aktualizacji zestawu replik, a także przywracania poprzedniej wersji.

Zapewniają wiele zaktualizowanych funkcji matchLabels i selectors. Mamy nowy kontroler w master Kubernetes zwany kontrolerem wdrażania, który to umożliwia. Ma możliwość zmiany rozmieszczenia w połowie.

Zmiana stanowiska

Updating- Użytkownik może zaktualizować trwające wdrożenie przed jego zakończeniem. W tym przypadku istniejące wdrożenie zostanie rozliczone i zostanie utworzone nowe wdrożenie.

Deleting- Użytkownik może wstrzymać / anulować wdrożenie, usuwając je przed jego zakończeniem. Ponowne odtworzenie tego samego wdrożenia spowoduje jego wznowienie.

Rollback- Możemy cofnąć wdrażanie lub wdrażanie w toku. Użytkownik może utworzyć lub zaktualizować wdrożenie przy użyciuDeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec.

Strategie wdrażania

Strategie wdrażania pomagają zdefiniować, w jaki sposób nowy RC powinien zastąpić istniejący RC.

Recreate- Ta funkcja zabije wszystkie istniejące RC, a następnie uruchomi nowe. Powoduje to szybkie rozmieszczenie, jednak spowoduje to przestój, gdy stare zasobniki nie działają, a nowe nie pojawiły się.

Rolling Update- Ta funkcja stopniowo obniża stary RC i wyświetla nowy. Powoduje to powolne wdrażanie, jednak nie ma wdrażania. Przez cały czas dostępnych jest kilka starych i kilka nowych.

Plik konfiguracyjny Deployment wygląda następująco.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
         lables:
            app: Tomcat-ReplicaSet
            tier: Backend
   spec:
      containers:
         - name: Tomcatimage:
            tomcat: 8.0
            ports:
               - containerPort: 7474

W powyższym kodzie jedyną rzeczą, która różni się od zestawu replik, jest to, że zdefiniowaliśmy ten rodzaj jako wdrożenie.

Utwórz stanowisko

$ kubectl create –f Deployment.yaml -–record
deployment "Deployment" created Successfully.

Pobierz wdrożenie

$ kubectl get deployments
NAME           DESIRED     CURRENT     UP-TO-DATE     AVILABLE    AGE
Deployment        3           3           3              3        20s

Sprawdź stan wdrożenia

$ kubectl rollout status deployment/Deployment

Aktualizowanie wdrożenia

$ kubectl set image deployment/Deployment tomcat=tomcat:6.0

Cofam się do poprzedniego wdrożenia

$ kubectl rollout undo deployment/Deployment –to-revision=2

W Kubernetes wolumin można traktować jako katalog, który jest dostępny dla kontenerów w pod. W Kubernetes mamy różne typy wolumenów, a typ określa sposób tworzenia wolumenu i jego zawartość.

Koncepcja głośności była obecna w Dockerze, jednak jedynym problemem było to, że głośność była bardzo ograniczona do określonej kapsuły. Gdy tylko życie kapsuły dobiegło końca, objętość również została utracona.

Z drugiej strony woluminy tworzone za pośrednictwem Kubernetes nie są ograniczone do żadnego kontenera. Obsługuje dowolny lub wszystkie kontenery wdrożone wewnątrz platformy Kubernetes. Kluczową zaletą wolumenu Kubernetes jest to, że obsługuje on różne rodzaje pamięci, w których kapsuła może korzystać z wielu z nich w tym samym czasie.

Typy woluminów Kubernetes

Oto lista niektórych popularnych tomów Kubernetes -

• emptyDir- Jest to rodzaj wolumenu, który jest tworzony, gdy pod jest po raz pierwszy przypisany do węzła. Pozostaje aktywny tak długo, jak długo Pod działa w tym węźle. Wolumin jest początkowo pusty, a kontenery w kapsule mogą odczytywać i zapisywać pliki w woluminie emptyDir. Po usunięciu Poda z węzła dane w emptyDir zostaną usunięte.

• hostPath - Ten typ woluminu montuje plik lub katalog z systemu plików węzła hosta do twojego poda.

• gcePersistentDisk- Ten typ wolumenu montuje dysk stały Google Compute Engine (GCE) w Twoim Pod. Dane wgcePersistentDisk pozostaje nienaruszony, gdy Pod zostanie usunięty z węzła.

• awsElasticBlockStore- Ten typ wolumenu montuje Amazon Web Services (AWS) Elastic Block Store w Twoim Pod. Tak jakgcePersistentDisk, dane w pliku awsElasticBlockStore pozostaje nienaruszony, gdy Pod zostanie usunięty z węzła.

• nfs - An nfsvolume pozwala na zamontowanie istniejącego NFS (Network File System) w twoim pod. Dane w plikunfswolumin nie jest kasowany po usunięciu Poda z węzła. Wolumen jest tylko odmontowany.

• iscsi - An iscsi wolumin pozwala na zamontowanie istniejącego wolumenu iSCSI (SCSI przez IP) w kapsule.

• flocker- Jest to klastrowy menedżer ilości danych kontenera typu open source. Służy do zarządzania wolumenami danych. ZAflockervolume pozwala na zamontowanie zbioru danych Flocker w pod. Jeśli zbiór danych nie istnieje we Flockerze, najpierw musisz go utworzyć za pomocą interfejsu API Flockera.

• glusterfs- Glusterfs to sieciowy system plików typu open source. Głośność glusterfs umożliwia zamontowanie woluminu glusterfs w kapsuły.

• rbd- RBD oznacza Rados Block Device. Narbdvolume pozwala na zamontowanie woluminu Rados Block Device w twoim kapsuły. Dane pozostają zachowane po usunięciu Poda z węzła.

• cephfs - A cephfsvolume pozwala na zamontowanie istniejącego woluminu CephFS w twoim pod. Dane pozostają nienaruszone po usunięciu Poda z węzła.

• gitRepo - A gitRepo wolumin montuje pusty katalog i klonuje plik git repozytorium do niego, aby twój kapsuła mogła użyć.

• secret - A secret volume służy do przekazywania poufnych informacji, takich jak hasła, do podów.

• persistentVolumeClaim - A persistentVolumeClaimvolume służy do zamontowania PersistentVolume w pod. PersistentVolumes to sposób, w jaki użytkownicy mogą „ubiegać się” o trwałą pamięć masową (taką jak GCE PersistentDisk lub wolumin iSCSI) bez znajomości szczegółów konkretnego środowiska chmurowego.

• downwardAPI - A downwardAPIwolumen jest używany do udostępniania aplikacji w dół danych API. Montuje katalog i zapisuje żądane dane w zwykłych plikach tekstowych.

• azureDiskVolume - An AzureDiskVolume służy do montowania dysku danych Microsoft Azure w pod.

Trwały wolumen i trwałe oświadczenie dotyczące wolumenu

Persistent Volume (PV)- To część sieciowej pamięci masowej, która została udostępniona przez administratora. Jest to zasób w klastrze, który jest niezależny od dowolnego zasobnika korzystającego z PV.

Persistent Volume Claim (PVC)- Magazyn żądany przez Kubernetes dla jego podów jest znany jako PVC. Użytkownik nie musi znać podstawowej obsługi administracyjnej. Oświadczenia muszą zostać utworzone w tej samej przestrzeni nazw, w której jest tworzony pod.

Tworzenie trwałego woluminu

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv0001 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

W powyższym kodzie zdefiniowaliśmy -

• kind: PersistentVolume → Zdefiniowaliśmy rodzaj jako PersistentVolume, który informuje kubernetes, że używany plik yaml służy do tworzenia trwałego woluminu.

• name: pv0001 → Nazwa PersistentVolume, którą tworzymy.

• capacity: → Ta specyfikacja określi pojemność PV, którą próbujemy stworzyć.

• storage: 10Gi → To mówi podstawowej infrastrukturze, że próbujemy zająć miejsce 10Gi na zdefiniowanej ścieżce.

• ReadWriteOnce → Informuje o prawach dostępu do wolumenu, który tworzymy.

• path: "/tmp/data01" → Ta definicja mówi maszynie, że próbujemy utworzyć wolumen pod tą ścieżką w podstawowej infrastrukturze.

Tworzenie PV

$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created

Sprawdzanie PV

$ kubectl get pv
NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE
pv0001        10Gi            RWO         Available                            14s

Opisywanie PV

$ kubectl describe pv pv0001

Tworzenie trwałego oświadczenia woluminu

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

W powyższym kodzie zdefiniowaliśmy -

• kind: PersistentVolumeClaim → Instruuje bazową infrastrukturę, że próbujemy zająć określoną ilość miejsca.

• name: myclaim-1 → Nazwa roszczenia, które próbujemy utworzyć.

• ReadWriteOnce → To określa tryb roszczenia, które próbujemy utworzyć.

• storage: 3Gi → To powie kubernetes o ilości miejsca, które staramy się zająć.

Tworzenie PVC

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

Pobieranie szczegółowych informacji na temat PVC

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv0001     10Gi         RWO       7s

Opisz PCV

$ kubectl describe pv pv0001

Używanie PV i PVC z POD

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

W powyższym kodzie zdefiniowaliśmy -

• volumeMounts: → To jest ścieżka w kontenerze, na której nastąpi montaż.

• Volume: → Ta definicja definiuje definicję objętości, o którą będziemy się ubiegać.

• persistentVolumeClaim: → Pod tym określamy nazwę wolumenu, którego będziemy używać w zdefiniowanej kapsule.

Sekrety można zdefiniować jako obiekty Kubernetes używane do przechowywania poufnych danych, takich jak nazwa użytkownika i hasła z szyfrowaniem.

Istnieje wiele sposobów tworzenia sekretów w Kubernetes.

• Tworzenie z plików txt.
• Tworzenie z pliku yaml.

Tworzenie z pliku tekstowego

Aby utworzyć sekrety z pliku tekstowego, takie jak nazwa użytkownika i hasło, najpierw musimy zapisać je w pliku txt i użyć następującego polecenia.

$ kubectl create secret generic tomcat-passwd –-from-file = ./username.txt –fromfile = ./.
password.txt

Tworzenie z pliku Yaml

apiVersion: v1
kind: Secret
metadata:
name: tomcat-pass
type: Opaque
data:
   password: <User Password>
   username: <User Name>

Tworzenie sekretu

$ kubectl create –f Secret.yaml
secrets/tomcat-pass

Korzystanie z Secrets

Po utworzeniu sekretów można je wykorzystać w kapsule lub kontrolerze replikacji jako -

• Zmienna środowiskowa
• Volume

Zmienna środowiskowa

Aby użyć sekretu jako zmiennej środowiskowej, użyjemy env w sekcji specyfikacji pliku pod yaml.

env:
- name: SECRET_USERNAME
   valueFrom:
      secretKeyRef:
         name: mysecret
         key: tomcat-pass

Jak Tom

spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat:7.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Tajna konfiguracja jako zmienna środowiskowa

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
replicas: replica_count
template:
   metadata:
      name: appname
   spec:
      nodeSelector:
         resource-group:
      containers:
         - name: appname
            image:
            imagePullPolicy: Always
            ports:
            - containerPort: 3000
            env: -----------------------------> 1
               - name: ENV
                  valueFrom:
                     configMapKeyRef:
                        name: appname
                        key: tomcat-secrets

W powyższym kodzie, pod env definicji używamy sekretów jako zmiennej środowiskowej w kontrolerze replikacji.

Sekrety jako mocowanie wolumenu

apiVersion: v1
kind: pod
metadata:
   name: appname
spec:
   metadata:
      name: appname
   spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat: 8.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Zasady sieciowe definiują sposób, w jaki zasobniki w tej samej przestrzeni nazw będą komunikować się ze sobą i z punktem końcowym sieci. To wymagaextensions/v1beta1/networkpoliciesdo włączenia w konfiguracji środowiska wykonawczego na serwerze API. Jego zasoby używają etykiet do wybierania zasobników i definiowania reguł zezwalających na ruch do określonego zasobnika, oprócz tego, który jest zdefiniowany w przestrzeni nazw.

Najpierw musimy skonfigurować zasady izolacji przestrzeni nazw. Zasadniczo tego rodzaju zasady sieciowe są wymagane w modułach równoważenia obciążenia.

kind: Namespace
apiVersion: v1
metadata:
   annotations:
      net.beta.kubernetes.io/network-policy: |
      {
         "ingress": 
         {
            "isolation": "DefaultDeny"
         }
      }

$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy = 
{\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

Po utworzeniu przestrzeni nazw musimy utworzyć zasady sieciowe.

Polityka sieciowa Yaml

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
   name: allow-frontend
   namespace: myns
spec:
   podSelector:
      matchLabels:
         role: backend
   ingress:
   - from:
      - podSelector:
         matchLabels:
            role: frontend
   ports:
      - protocol: TCP
         port: 6379

Kubernetes API służy jako podstawa dla deklaratywnego schematu konfiguracji systemu. KubectlNarzędzie wiersza poleceń może służyć do tworzenia, aktualizowania, usuwania i pobierania obiektu API. Kubernetes API działa jako komunikator między różnymi komponentami Kubernetes.

Dodawanie API do Kubernetes

Dodanie nowego API do Kubernetes doda nowe funkcje do Kubernetes, co zwiększy funkcjonalność Kubernetes. Jednak oprócz tego zwiększy również koszt i łatwość konserwacji systemu. Aby uzyskać równowagę między kosztem a złożonością, zdefiniowano kilka zestawów.

Dodawane API powinno być przydatne dla ponad 50% użytkowników. Nie ma innego sposobu na zaimplementowanie tej funkcjonalności w Kubernetes. Wyjątkowe okoliczności są omawiane na spotkaniu społeczności Kubernetes, a następnie dodawane jest API.

Zmiany API

Aby zwiększyć możliwości Kubernetes, system na bieżąco wprowadza zmiany. Robi to zespół Kubernetes, aby dodać funkcjonalność do Kubernetes bez usuwania lub wpływu na istniejącą funkcjonalność systemu.

Aby zademonstrować ogólny proces, oto (hipotetyczny) przykład -

• Użytkownik POST wysyła obiekt Poda do /api/v7beta1/...

• JSON nie jest przekształcany w plik v7beta1.Pod Struktura

• Wartości domyślne są stosowane do v7beta1.Pod

• Plik v7beta1.Pod jest konwertowany na api.Pod Struktura

• Plik api.Pod jest sprawdzany, a wszelkie błędy są zwracane do użytkownika

• Plik api.Pod jest konwertowany na v6.Pod (ponieważ v6 jest najnowszą stabilną wersją)

• Plik v6.Pod jest kierowany do JSON i zapisywany do etcd

Teraz, gdy mamy już przechowywany obiekt Pod, użytkownik może pobrać ten obiekt w dowolnej obsługiwanej wersji interfejsu API. Na przykład -

• Użytkownik pobiera kapsułę /api/v5/...

• JSON jest odczytywany z etcd i unmarshalled do v6.Pod Struktura

• Wartości domyślne są stosowane do v6.Pod

• Plik v6.Pod jest konwertowany na strukturę api.Pod

• Plik api.Pod jest konwertowany na v5.Pod Struktura

• Plik v5.Pod jest kierowany do formatu JSON i wysyłany do użytkownika

Konsekwencją tego procesu jest to, że zmiany API muszą być dokonywane ostrożnie i wstecz.

Wersjonowanie API

Aby ułatwić obsługę wielu struktur, Kubernetes obsługuje wiele wersji API, z których każda znajduje się w innej ścieżce API, takiej jak /api/v1 lub /apsi/extensions/v1beta1

Standardy wersjonowania w Kubernetes są zdefiniowane w wielu standardach.

Poziom alfa

• Ta wersja zawiera alfa (np. V1alpha1)

• Ta wersja może zawierać błędy; włączona wersja może zawierać błędy

• Wsparcie dla błędów można zrezygnować w dowolnym momencie.

• Zalecane do użytku tylko w krótkoterminowych testach, ponieważ wsparcie może nie być obecne przez cały czas.

Poziom Beta

• Nazwa wersji zawiera wersję beta (np. V2beta3)

• Kod jest w pełni przetestowany, a włączona wersja ma być stabilna.

• Wsparcie tej funkcji nie zostanie porzucone; mogą wystąpić drobne zmiany.

• Zalecane tylko do zastosowań, które nie mają krytycznego znaczenia biznesowego ze względu na możliwość niekompatybilnych zmian w kolejnych wersjach.

Stabilny poziom

• Nazwa wersji to vX gdzie X jest liczbą całkowitą.

• Stabilne wersje funkcji pojawią się w wydanym oprogramowaniu dla wielu kolejnych wersji.

Kubectl to narzędzie wiersza poleceń do interakcji z Kubernetes API. Jest to interfejs używany do komunikacji i zarządzania podami w klastrze Kubernetes.

Aby współdziałać z klastrem Kubernetes, należy ustawić kubectl na lokalny.

Ustawianie Kubectl

Pobierz plik wykonywalny na lokalną stację roboczą za pomocą polecenia curl.

W systemie Linux

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/linux/amd64/kubectl

Na stacji roboczej OS X.

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/darwin/amd64/kubectl

Po zakończeniu pobierania przenieś pliki binarne w ścieżce systemu.

$ chmod +x kubectl
$ mv kubectl /usr/local/bin/kubectl

Konfiguracja Kubectl

Poniżej przedstawiono kroki, aby wykonać operację konfiguracji.

$ kubectl config set-cluster default-cluster --server = https://${MASTER_HOST} -- certificate-authority = ${CA_CERT}

$ kubectl config set-credentials default-admin --certificateauthority = ${
CA_CERT} --client-key = ${ADMIN_KEY} --clientcertificate = ${
ADMIN_CERT}

$ kubectl config set-context default-system --cluster = default-cluster -- user = default-admin $ kubectl config use-context default-system

• Zastąpić ${MASTER_HOST} z adresem węzła głównego lub nazwą używaną w poprzednich krokach.

• Zastąpić ${CA_CERT} z absolutną ścieżką do ca.pem utworzone w poprzednich krokach.

• Zastąpić ${ADMIN_KEY} z absolutną ścieżką do admin-key.pem utworzone w poprzednich krokach.

• Zastąpić ${ADMIN_CERT} z absolutną ścieżką do admin.pem utworzone w poprzednich krokach.

Weryfikacja konfiguracji

Aby sprawdzić, czy kubectl działa dobrze, czy nie, sprawdź, czy klient Kubernetes jest poprawnie skonfigurowany.

$ kubectl get nodes

NAME       LABELS                                     STATUS
Vipin.com  Kubernetes.io/hostname = vipin.mishra.com    Ready

Kubectlkontroluje klaster Kubernetes. Jest to jeden z kluczowych komponentów Kubernetes, który działa na stacji roboczej na dowolnej maszynie po zakończeniu konfiguracji. Ma możliwość zarządzania węzłami w klastrze.

Kubectlpolecenia są używane do interakcji i zarządzania obiektami Kubernetes i klastrem. W tym rozdziale omówimy kilka poleceń używanych w Kubernetes za pośrednictwem kubectl.

kubectl annotate - Aktualizuje adnotację w zasobie.

$kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ...
KEY_N = VAL_N [--resource-version = version]

Na przykład,

kubectl annotate pods tomcat description = 'my frontend'

kubectl api-versions - Wyświetla obsługiwane wersje interfejsu API w klastrze.

$ kubectl api-version;

kubectl apply - Ma możliwość konfigurowania zasobu według pliku lub standardowego wejścia.

$ kubectl apply –f <filename>

kubectl attach - To przywiązuje rzeczy do działającego kontenera.

$ kubectl attach <pod> –c <container> $ kubectl attach 123456-7890 -c tomcat-conatiner

kubectl autoscale - Służy do automatycznego skalowania zasobników, które są zdefiniowane, takie jak wdrożenie, zestaw replik, kontroler replikacji.

$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min = MINPODS] -- max = MAXPODS [--cpu-percent = CPU] [flags] $ kubectl autoscale deployment foo --min = 2 --max = 10

kubectl cluster-info - Wyświetla informacje o klastrze.

$ kubectl cluster-info

kubectl cluster-info dump - Zrzuca istotne informacje dotyczące klastra w celu debugowania i diagnostyki.

$ kubectl cluster-info dump
$ kubectl cluster-info dump --output-directory = /path/to/cluster-state

kubectl config - Modyfikuje plik kubeconfig.

$ kubectl config <SUBCOMMAD>
$ kubectl config –-kubeconfig <String of File name>

kubectl config current-context - Wyświetla aktualny kontekst.

$ kubectl config current-context
#deploys the current context

kubectl config delete-cluster - usuwa określony klaster z kubeconfig.

$ kubectl config delete-cluster <Cluster Name>

kubectl config delete-context - usuwa określony kontekst z kubeconfig.

$ kubectl config delete-context <Context Name>

kubectl config get-clusters - Wyświetla klaster zdefiniowany w pliku kubeconfig.

$ kubectl config get-cluster $ kubectl config get-cluster <Cluser Name>

kubectl config get-contexts - Opisuje jeden lub wiele kontekstów.

$ kubectl config get-context <Context Name>

kubectl config set-cluster - Ustawia wpis klastra w Kubernetes.

$ kubectl config set-cluster NAME [--server = server] [--certificateauthority =
path/to/certificate/authority] [--insecure-skip-tls-verify = true]

kubectl config set-context - Ustawia wpis kontekstu w punkcie wejścia kubernetes.

$ kubectl config set-context NAME [--cluster = cluster_nickname] [-- user = user_nickname] [--namespace = namespace] $ kubectl config set-context prod –user = vipin-mishra

kubectl config set-credentials - Ustawia wpis użytkownika w kubeconfig.

$ kubectl config set-credentials cluster-admin --username = vipin --
password = uXFGweU9l35qcif

kubectl config set - Ustawia indywidualną wartość w pliku kubeconfig.

$ kubectl config set PROPERTY_NAME PROPERTY_VALUE

kubectl config unset - Cofa określony komponent w kubectl.

$ kubectl config unset PROPERTY_NAME PROPERTY_VALUE

kubectl config use-context - Ustawia bieżący kontekst w pliku kubectl.

$ kubectl config use-context <Context Name>

kubectl config view

$ kubectl config view $ kubectl config view –o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl cp - Kopiuj pliki i katalogi do iz kontenerów.

$ kubectl cp <Files from source> <Files to Destinatiion> $ kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

kubectl create- Aby utworzyć zasób według nazwy pliku lub stdin. Aby to zrobić, akceptowane są formaty JSON lub YAML.

$ kubectl create –f <File Name> $ cat <file name> | kubectl create –f -

W ten sam sposób możemy utworzyć wiele rzeczy wymienionych przy użyciu rozszerzenia create polecenie wraz z kubectl.

• deployment
• namespace
• quota
• tajny rejestr docker
• secret
• tajny rodzajowy
• tajne tls
• serviceaccount
• service clusterip
• usługa loadbalancer
• usługa nodeport

kubectl delete - Usuwa zasoby według nazwy pliku, standardowego wejścia, zasobu i nazw.

$ kubectl delete –f ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

kubectl describe- Opisuje dowolny zasób w Kubernetes. Wyświetla szczegóły zasobu lub grupy zasobów.

$ kubectl describe <type> <type name>
$ kubectl describe pod tomcat

kubectl drain- Służy do opróżniania węzła w celach konserwacyjnych. Przygotowuje węzeł do konserwacji. Spowoduje to oznaczenie węzła jako niedostępnego, aby nie był przypisywany nowy kontener, który zostanie utworzony.

$ kubectl drain tomcat –force

kubectl edit- Służy do zakończenia zasobów na serwerze. Pozwala to na bezpośrednią edycję zasobu, który można otrzymać za pomocą narzędzia wiersza poleceń.

$ kubectl edit <Resource/Name | File Name) Ex. $ kubectl edit rc/tomcat

kubectl exec - Pomaga to wykonać polecenie w kontenerze.

$ kubectl exec POD <-c CONTAINER > -- COMMAND < args...> $ kubectl exec tomcat 123-5-456 date

kubectl expose- Służy do ujawniania obiektów Kubernetes, takich jak pod, kontroler replikacji i usługa, jako nowej usługi Kubernetes. Ma to możliwość ujawnienia go za pośrednictwem działającego kontenera lub z plikuyaml plik.

$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol = TCP|UDP] [--target-port = number-or-name] [--name = name] [--external-ip = external-ip-ofservice] [--type = type] $ kubectl expose rc tomcat –-port=80 –target-port = 30000
$ kubectl expose –f tomcat.yaml –port = 80 –target-port =

kubectl get - To polecenie może pobierać dane z klastra dotyczące zasobów Kubernetes.

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columnsfile=...|
go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]
(TYPE [NAME | -l label] | TYPE/NAME ...) [flags]

Na przykład,

$ kubectl get pod <pod name> $ kubectl get service <Service name>

kubectl logs- Służą do umieszczania kłód kontenera w kapsule. Drukowanie dzienników może oznaczać zdefiniowanie nazwy kontenera w kapsule. Jeśli POD ma tylko jeden pojemnik, nie ma potrzeby definiowania jego nazwy.

$ kubectl logs [-f] [-p] POD [-c CONTAINER] Example $ kubectl logs tomcat.
$ kubectl logs –p –c tomcat.8

kubectl port-forward - Są używane do przekazywania jednego lub więcej portów lokalnych do strąków.

$ kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT
[...[LOCAL_PORT_N:]REMOTE_PORT_N]
$ kubectl port-forward tomcat 3000 4000 $ kubectl port-forward tomcat 3000:5000

kubectl replace - Możliwość zastępowania zasobu według nazwy pliku lub stdin.

$ kubectl replace -f FILENAME $ kubectl replace –f tomcat.yml
$ cat tomcat.yml | kubectl replace –f -

kubectl rolling-update- Wykonuje aktualizację kroczącą na kontrolerze replikacji. Zastępuje określony kontroler replikacji nowym kontrolerem replikacji, aktualizując jednocześnie POD.

$ kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --
image = NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC)
$ kubectl rolling-update frontend-v1 –f freontend-v2.yaml

kubectl rollout - Jest w stanie zarządzać wdrażaniem wdrożenia.

$ Kubectl rollout <Sub Command>
$ kubectl rollout undo deployment/tomcat

Oprócz powyższego możemy wykonać wiele zadań za pomocą rolloutu, takich jak -

• historia wdrażania
• wstrzymanie wdrażania
• wznowienie wdrażania
• stan wdrożenia
• wdrożenie cofnij

kubectl run - Polecenie Uruchom ma możliwość uruchomienia obrazu w klastrze Kubernetes.

$ kubectl run NAME --image = image [--env = "key = value"] [--port = port] [--
replicas = replicas] [--dry-run = bool] [--overrides = inline-json] [--command] --
[COMMAND] [args...]
$ kubectl run tomcat --image = tomcat:7.0 $ kubectl run tomcat –-image = tomcat:7.0 –port = 5000

kubectl scale - Skaluje rozmiar wdrożeń Kubernetes, zestawu replik, kontrolera replikacji lub zadania.

$ kubectl scale [--resource-version = version] [--current-replicas = count] -- replicas = COUNT (-f FILENAME | TYPE NAME ) $ kubectl scale –-replica = 3 rs/tomcat
$ kubectl scale –replica = 3 tomcat.yaml

kubectl set image - Aktualizuje obraz szablonu pod.

$ kubectl set image (-f FILENAME | TYPE NAME)
CONTAINER_NAME_1 = CONTAINER_IMAGE_1 ... CONTAINER_NAME_N = CONTAINER_IMAGE_N
$ kubectl set image deployment/tomcat busybox = busybox ngnix = ngnix:1.9.1 $ kubectl set image deployments, rc tomcat = tomcat6.0 --all

kubectl set resources- Służy do ustawiania zawartości zasobu. Aktualizuje zasoby / limity obiektu za pomocą szablonu pod.

$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits = LIMITS & -- requests = REQUESTS] $ kubectl set resources deployment tomcat -c = tomcat --
limits = cpu = 200m,memory = 512Mi

kubectl top node- Wyświetla użycie procesora / pamięci / pamięci. Górne polecenie pozwala zobaczyć zużycie zasobów dla węzłów.

$ kubectl top node [node Name]

Tego samego polecenia można również użyć w przypadku kapsuły.

Aby stworzyć aplikację do wdrożenia Kubernetes, musimy najpierw stworzyć aplikację na Dockerze. Można to zrobić na dwa sposoby -

• Pobierając
• Z pliku Docker

Pobierając

Istniejący obraz można pobrać z centrum Docker i przechowywać w lokalnym rejestrze platformy Docker.

Aby to zrobić, uruchom Docker pull Komenda.

$ docker pull --help
Usage: docker pull [OPTIONS] NAME[:TAG|@DIGEST]
Pull an image or a repository from the registry
   -a, --all-tags = false     Download all tagged images in the repository
   --help = false             Print usage

Poniżej zostanie wyświetlony wynik powyższego kodu.

Powyższy zrzut ekranu przedstawia zestaw obrazów, które są przechowywane w naszym lokalnym rejestrze Docker.

Jeśli z obrazu chcemy zbudować kontener składający się z aplikacji do przetestowania, możemy to zrobić za pomocą polecenia Docker run.

$ docker run –i –t unbunt /bin/bash

Z pliku Docker

Aby stworzyć aplikację z pliku Docker, musimy najpierw stworzyć plik Docker.

Poniżej znajduje się przykład pliku Jenkins Docker.

FROM ubuntu:14.04
MAINTAINER [email protected]
ENV REFRESHED_AT 2017-01-15
RUN apt-get update -qq && apt-get install -qqy curl
RUN curl https://get.docker.io/gpg | apt-key add -
RUN echo deb http://get.docker.io/ubuntu docker main > /etc/apt/↩
sources.list.d/docker.list
RUN apt-get update -qq && apt-get install -qqy iptables ca-↩
certificates lxc openjdk-6-jdk git-core lxc-docker
ENV JENKINS_HOME /opt/jenkins/data
ENV JENKINS_MIRROR http://mirrors.jenkins-ci.org
RUN mkdir -p $JENKINS_HOME/plugins
RUN curl -sf -o /opt/jenkins/jenkins.war -L $JENKINS_MIRROR/war-↩ stable/latest/jenkins.war RUN for plugin in chucknorris greenballs scm-api git-client git ↩ ws-cleanup ;\ do curl -sf -o $JENKINS_HOME/plugins/${plugin}.hpi \ -L $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ↩
; done
ADD ./dockerjenkins.sh /usr/local/bin/dockerjenkins.sh
RUN chmod +x /usr/local/bin/dockerjenkins.sh
VOLUME /var/lib/docker
EXPOSE 8080
ENTRYPOINT [ "/usr/local/bin/dockerjenkins.sh" ]

Po utworzeniu powyższego pliku zapisz go pod nazwą Dockerfile i cd do ścieżki pliku. Następnie uruchom następujące polecenie.

$ sudo docker build -t jamtur01/Jenkins .

Po utworzeniu obrazu możemy sprawdzić, czy obraz działa dobrze i czy można go przekonwertować na kontener.

$ docker run –i –t jamtur01/Jenkins /bin/bash

Wdrożenie to metoda konwertowania obrazów na kontenery, a następnie przydzielania tych obrazów do podów w klastrze Kubernetes. Pomaga to również w skonfigurowaniu klastra aplikacji, który obejmuje wdrożenie usługi, pod, kontrolera replikacji i zestawu replik. Klaster można skonfigurować w taki sposób, aby aplikacje wdrożone na kapsuły mogły się ze sobą komunikować.

W tej konfiguracji możemy mieć ustawienie modułu równoważenia obciążenia na górze jednej aplikacji kierującej ruch do zestawu podów, a później komunikują się z podami zaplecza. Komunikacja między podami odbywa się za pośrednictwem obiektu usługi zbudowanego w Kubernetes.

Ngnix Load Balancer Yaml File

apiVersion: v1
kind: Service
metadata:
   name: oppv-dev-nginx
      labels:
         k8s-app: omni-ppv-api
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: dev

Kontroler replikacji Ngnix Yaml

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
   replicas: replica_count
   template:
      metadata:
         name: appname
         labels:
            k8s-app: appname
            component: nginx
               env: env_name
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
      image: IMAGE_TEMPLATE
      imagePullPolicy: Always
      ports:
         - containerPort: 8080
         resources:
            requests:
               memory: "request_mem"
               cpu: "request_cpu"
            limits:
               memory: "limit_mem"
               cpu: "limit_cpu"
            env:
            - name: BACKEND_HOST
               value: oppv-env_name-node:3000

Frontend Service Yaml File

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - name: http
      port: 3000
      protocol: TCP
      targetPort: 3000
   selector:
      k8s-app: appname
      component: nodejs
      env: dev

Kontroler replikacji frontendu Yaml File

apiVersion: v1
kind: ReplicationController
metadata:
   name: Frontend
spec:
   replicas: 3
   template:
      metadata:
         name: frontend
         labels:
            k8s-app: Frontend
            component: nodejs
            env: Dev
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
         image: IMAGE_TEMPLATE
         imagePullPolicy: Always
         ports:
            - containerPort: 3000
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "limit_cpu"
                  limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            env:
               - name: ENV
               valueFrom:
               configMapKeyRef:
               name: appname
               key: config-env

Plik Yaml usługi zaplecza

apiVersion: v1
kind: Service
metadata:
   name: backend
   labels:
      k8s-app: backend
spec:
   type: NodePort
   ports:
   - name: http
      port: 9010
      protocol: TCP
      targetPort: 9000
   selector:
      k8s-app: appname
      component: play
      env: dev

Wspierany kontroler replikacji Yaml File

apiVersion: v1
kind: ReplicationController
metadata:
   name: backend
spec:
   replicas: 3
   template:
      metadata:
         name: backend
      labels:
         k8s-app: beckend
         component: play
         env: dev
spec:
   nodeSelector:
      resource-group: oppv
      containers:
         - name: appname
            image: IMAGE_TEMPLATE
            imagePullPolicy: Always
            ports:
            - containerPort: 9000
            command: [ "./docker-entrypoint.sh" ]
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "request_cpu"
               limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            volumeMounts:
               - name: config-volume
               mountPath: /app/vipin/play/conf
         volumes:
            - name: config-volume
            configMap:
            name: appname

Autoscalingjest jedną z kluczowych funkcji klastra Kubernetes. Jest to funkcja, w której klaster jest w stanie zwiększać liczbę węzłów, gdy zapotrzebowanie na odpowiedź usługi rośnie i zmniejsza liczbę węzłów, gdy zapotrzebowanie maleje. Ta funkcja automatycznego skalowania jest obecnie obsługiwana w Google Cloud Engine (GCE) i Google Container Engine (GKE) i wkrótce zostanie uruchomiona w AWS.

Aby skonfigurować skalowalną infrastrukturę w GCE, musimy najpierw mieć aktywny projekt GCE z włączonymi funkcjami monitorowania w chmurze Google, rejestrowania w chmurze Google i sterowaniem stosem.

Najpierw skonfigurujemy klaster z kilkoma działającymi w nim węzłami. Po zakończeniu musimy ustawić następującą zmienną środowiskową.

Zmienna środowiskowa

export NUM_NODES = 2
export KUBE_AUTOSCALER_MIN_NODES = 2
export KUBE_AUTOSCALER_MAX_NODES = 5
export KUBE_ENABLE_CLUSTER_AUTOSCALER = true

Po zakończeniu uruchomimy klaster, uruchamiając kube-up.sh. Spowoduje to utworzenie klastra wraz z dodatkiem auto-skalarnym klastra.

./cluster/kube-up.sh

Podczas tworzenia klastra możemy sprawdzić nasz klaster za pomocą następującego polecenia kubectl.

$ kubectl get nodes
NAME                             STATUS                       AGE
kubernetes-master                Ready,SchedulingDisabled     10m
kubernetes-minion-group-de5q     Ready                        10m
kubernetes-minion-group-yhdx     Ready                        8m

Teraz możemy wdrożyć aplikację w klastrze, a następnie włączyć poziomy autoskaler podów. Można to zrobić za pomocą następującego polecenia.

$ kubectl autoscale deployment <Application Name> --cpu-percent = 50 --min = 1 --
max = 10

Powyższe polecenie pokazuje, że będziemy utrzymywać co najmniej jedną i maksymalnie 10 replik POD w miarę wzrostu obciążenia aplikacji.

Stan autoskalera możemy sprawdzić, uruchamiając plik $kubclt get hpaKomenda. Zwiększymy obciążenie strąków za pomocą następującego polecenia.

$ kubectl run -i --tty load-generator --image = busybox /bin/sh
$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

Możemy sprawdzić hpa biegiem $ kubectl get hpa Komenda.

$ kubectl get hpa NAME REFERENCE TARGET CURRENT php-apache Deployment/php-apache/scale 50% 310% MINPODS MAXPODS AGE 1 20 2m $ kubectl get deployment php-apache
NAME         DESIRED    CURRENT    UP-TO-DATE    AVAILABLE   AGE
php-apache      7          7           7            3        4m

Możemy sprawdzić liczbę działających podów za pomocą następującego polecenia.

jsz@jsz-desk2:~/k8s-src$ kubectl get pods
php-apache-2046965998-3ewo6 0/1        Pending 0         1m
php-apache-2046965998-8m03k 1/1        Running 0         1m
php-apache-2046965998-ddpgp 1/1        Running 0         5m
php-apache-2046965998-lrik6 1/1        Running 0         1m
php-apache-2046965998-nj465 0/1        Pending 0         1m
php-apache-2046965998-tmwg1 1/1        Running 0         1m
php-apache-2046965998-xkbw1 0/1        Pending 0         1m

I wreszcie możemy uzyskać status węzła.

$ kubectl get nodes
NAME                             STATUS                        AGE
kubernetes-master                Ready,SchedulingDisabled      9m
kubernetes-minion-group-6z5i     Ready                         43s
kubernetes-minion-group-de5q     Ready                         9m
kubernetes-minion-group-yhdx     Ready                         9m

Konfigurowanie pulpitu Kubernetes obejmuje kilka kroków z zestawem narzędzi wymaganych jako warunki wstępne do skonfigurowania.

• Docker (1.3+)
• idź (1.5+)
• nodejs (4.2.2+)
• npm (1.3+)
• java (7+)
• łyk (3.9+)
• Kubernetes (1.1.2+)

Konfigurowanie pulpitu nawigacyjnego

$ sudo apt-get update && sudo apt-get upgrade Installing Python $ sudo apt-get install python
$ sudo apt-get install python3 Installing GCC $ sudo apt-get install gcc-4.8 g++-4.8

Installing make
$ sudo apt-get install make Installing Java $ sudo apt-get install openjdk-7-jdk

Installing Node.js
$ wget https://nodejs.org/dist/v4.2.2/node-v4.2.2.tar.gz $ tar -xzf node-v4.2.2.tar.gz
$ cd node-v4.2.2 $ ./configure
$ make $ sudo make install

Installing gulp
$ npm install -g gulp $ npm install gulp

Weryfikowanie wersji

Java Version
$ java –version java version "1.7.0_91" OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-1~deb8u1+rpi1) OpenJDK Zero VM (build 24.91-b01, mixed mode) $ node –v
V4.2.2

$ npn -v 2.14.7 $ gulp -v
[09:51:28] CLI version 3.9.0

$ sudo gcc --version
gcc (Raspbian 4.8.4-1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc. This is free software; 
see the source for copying conditions. There is NO warranty; not even for 
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Instalowanie GO

$ git clone https://go.googlesource.com/go
$ cd go $ git checkout go1.4.3
$ cd src Building GO $ ./all.bash
$ vi /root/.bashrc In the .bashrc export GOROOT = $HOME/go
   export PATH = $PATH:$GOROOT/bin
   
$ go version
go version go1.4.3 linux/arm

Instalowanie panelu Kubernetes

$ git clone https://github.com/kubernetes/dashboard.git
$ cd dashboard $ npm install -g bower

Uruchomienie Dashboardu

$ git clone https://github.com/kubernetes/dashboard.git $ cd dashboard
$ npm install -g bower $ gulp serve
[11:19:12] Requiring external module babel-core/register
[11:20:50] Using gulpfile ~/dashboard/gulpfile.babel.js
[11:20:50] Starting 'package-backend-source'...
[11:20:50] Starting 'kill-backend'...
[11:20:50] Finished 'kill-backend' after 1.39 ms
[11:20:50] Starting 'scripts'...
[11:20:53] Starting 'styles'...
[11:21:41] Finished 'scripts' after 50 s
[11:21:42] Finished 'package-backend-source' after 52 s
[11:21:42] Starting 'backend'...
[11:21:43] Finished 'styles' after 49 s
[11:21:43] Starting 'index'...
[11:21:44] Finished 'index' after 1.43 s
[11:21:44] Starting 'watch'...
[11:21:45] Finished 'watch' after 1.41 s
[11:23:27] Finished 'backend' after 1.73 min
[11:23:27] Starting 'spawn-backend'...
[11:23:27] Finished 'spawn-backend' after 88 ms
[11:23:27] Starting 'serve'...
2016/02/01 11:23:27 Starting HTTP server on port 9091
2016/02/01 11:23:27 Creating API client for
2016/02/01 11:23:27 Creating Heapster REST client for http://localhost:8082
[11:23:27] Finished 'serve' after 312 ms
[BS] [BrowserSync SPA] Running...
[BS] Access URLs:
--------------------------------------
Local: http://localhost:9090/
External: http://192.168.1.21:9090/
--------------------------------------
UI: http://localhost:3001
UI External: http://192.168.1.21:3001
--------------------------------------
[BS] Serving files from: /root/dashboard/.tmp/serve
[BS] Serving files from: /root/dashboard/src/app/frontend
[BS] Serving files from: /root/dashboard/src/app

Pulpit nawigacyjny Kubernetes

Monitorowanie jest jednym z kluczowych elementów zarządzania dużymi klastrami. Do tego mamy szereg narzędzi.

Monitorowanie za pomocą Prometheusa

Jest to system monitorowania i alarmowania. Został zbudowany w SoundCloud i był open source w 2012 roku. Bardzo dobrze radzi sobie z danymi wielowymiarowymi.

Prometheus ma wiele komponentów do udziału w monitorowaniu -

• Prometheus - Jest to główny komponent, który przetwarza i przechowuje dane.

• Prometheus node explore - Pobiera macierze poziomu hosta i udostępnia je Prometeuszowi.

• Ranch-eye - jest haproxy i ujawnia cAdvisor statystyki do Prometeusza.

• Grafana - Wizualizacja danych.

• InfuxDB - Baza danych szeregów czasowych używana specjalnie do przechowywania danych od farmera.

• Prom-ranch-exporter - Jest to prosta aplikacja node.js, która pomaga w odpytywaniu serwera Rancher o status stosu usług.

Agent Sematext Docker

Jest to nowoczesny agent do zbierania metryk, zdarzeń i dzienników obsługujący platformę Docker. Działa jako mały kontener na każdym hoście platformy Docker i gromadzi dzienniki, metryki i zdarzenia dla wszystkich węzłów klastra i kontenerów. Wykrywa wszystkie kontenery (jeden pod może zawierać wiele kontenerów), w tym kontenery dla podstawowych usług Kubernetes, jeśli podstawowe usługi są wdrażane w kontenerach Docker. Po wdrożeniu wszystkie dzienniki i metryki są natychmiast dostępne po wyjęciu z pudełka.

Wdrażanie agentów w węzłach

Kubernetes udostępnia DeamonSets, które zapewniają, że pody są dodawane do klastra.

Konfigurowanie SemaText Docker Agent

Jest konfigurowany za pomocą zmiennych środowiskowych.

• Załóż darmowe konto na apps.sematext.com , jeśli jeszcze go nie masz.

• Utwórz aplikację SPM typu „Docker”, aby uzyskać token aplikacji SPM. Aplikacja SPM będzie przechowywać wskaźniki wydajności i zdarzenia Kubernetes.

• Utwórz aplikację Logsene, aby uzyskać token aplikacji Logsene. Aplikacja Logsene będzie przechowywać Twoje dzienniki Kubernetes.

• Edytuj wartości LOGSENE_TOKEN i SPM_TOKEN w definicji zestawu DaemonSet, jak pokazano poniżej.

• Pobierz najnowszy szablon sematext-agent-daemonset.yml (czysty tekst) (również pokazany poniżej).

• Przechowuj go gdzieś na dysku.

• Zastąp symbole zastępcze SPM_TOKEN i LOGSENE_TOKEN swoimi tokenami SPM i Logsene App.

Utwórz obiekt DaemonSet

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
   name: sematext-agent
spec:
   template:
      metadata:
         labels:
            app: sematext-agent
      spec:
         selector: {}
         dnsPolicy: "ClusterFirst"
         restartPolicy: "Always"
         containers:
         - name: sematext-agent
            image: sematext/sematext-agent-docker:latest
            imagePullPolicy: "Always"
            env:
            - name: SPM_TOKEN
               value: "REPLACE THIS WITH YOUR SPM TOKEN"
            - name: LOGSENE_TOKEN
               value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"
            - name: KUBERNETES
               value: "1"
            volumeMounts:
               - mountPath: /var/run/docker.sock
                  name: docker-sock
               - mountPath: /etc/localtime
                  name: localtime
            volumes:
               - name: docker-sock
                  hostPath:
                     path: /var/run/docker.sock
               - name: localtime
                  hostPath:
                     path: /etc/localtime

Uruchamianie platformy Docker agenta Sematext z kubectl

$ kubectl create -f sematext-agent-daemonset.yml
daemonset "sematext-agent-daemonset" created

Dziennik Kubernetes

Dzienniki kontenerów Kubernetes niewiele różnią się od dzienników kontenerów Docker. Jednak użytkownicy Kubernetes muszą przeglądać dzienniki dla wdrożonych podów. Dlatego bardzo przydatne jest posiadanie informacji specyficznych dla Kubernetes dostępnych do przeszukiwania dzienników, takich jak -

• Przestrzeń nazw Kubernetes
• Nazwa poda Kubernetes
• Nazwa kontenera Kubernetes
• Nazwa obrazu platformy Docker
• UID Kubernetes

Korzystanie z ELK Stack i LogSpout

Stos ELK zawiera Elasticsearch, Logstash i Kibana. Aby zebrać i przesłać dzienniki na platformę logowania, użyjemy LogSpout (chociaż istnieją inne opcje, takie jak FluentD).

Poniższy kod pokazuje, jak skonfigurować klaster ELK na Kubernetes i utworzyć usługę dla ElasticSearch -

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

Tworzenie kontrolera replikacji

apiVersion: v1
kind: ReplicationController
metadata:
   name: es
   namespace: elk
   labels:
      component: elasticsearch
spec:
   replicas: 1
   template:
      metadata:
         labels:
            component: elasticsearch
spec:
serviceAccount: elasticsearch
containers:
   - name: es
      securityContext:
      capabilities:
      add:
      - IPC_LOCK
   image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4
   env:
   - name: KUBERNETES_CA_CERTIFICATE_FILE
   value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
   - name: NAMESPACE
   valueFrom:
      fieldRef:
         fieldPath: metadata.namespace
   - name: "CLUSTER_NAME"
      value: "myesdb"
   - name: "DISCOVERY_SERVICE"
      value: "elasticsearch"
   - name: NODE_MASTER
      value: "true"
   - name: NODE_DATA
      value: "true"
   - name: HTTP_ENABLE
      value: "true"
ports:
- containerPort: 9200
   name: http
   protocol: TCP
- containerPort: 9300
volumeMounts:
- mountPath: /data
   name: storage
volumes:
   - name: storage
      emptyDir: {}

Kibana URL

For Kibana, we provide the Elasticsearch URL as an environment variable.

- name: KIBANA_ES_URL
value: "http://elasticsearch.elk.svc.cluster.local:9200"
- name: KUBERNETES_TRUST_CERT
value: "true"

Kibana UI will be reachable at container port 5601 and corresponding host/Node Port combination. When you begin, there won’t be any data in Kibana (which is expected as you have not pushed any data).