Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



25.02.2020

Koszty w górę

Zmiany w licencjach VMware
24.02.2020

VPN na nowo

WireGuard w Linuksie
24.02.2020

Wydajność pod kontrolą

Citrix Analytics for Performance
24.02.2020

Zaawansowany backup

Veeam Availability Suite v10
20.02.2020

Serwery Enterprise

OVHCloud stawia na Ryzeny
20.02.2020

Monitory dla biznesu

Newline IP
20.02.2020

Przemysłowe SSD

Dyski Transcend M.2 NVMe
23.01.2020

Google Project Zero

Inicjatywa Google Project Zero
23.01.2020

Ochrona tylko w chmurze

Kaspersky Security Cloud Free

Kubernetes – orkiestracja kontenerów

Data publikacji: 18-12-2019 Autor: Grzegorz Adamowicz
Przepływ danych od klienta do...

Wśród administratorów i programistów nie ma już chyba osoby, która nie słyszałaby o konteneryzacji i Dockerze. Wiele firm używa tej technologii do „upakowywania” swoich aplikacji, co ułatwia instalowanie ich na serwerach i udostępnianie klientom.

 

Kolejną generacją technologii konteneryzacji są systemy służące do orkiestracji i zarządzania usługami. Wynika to bezpośrednio z mikrousługowej architektury budowania aplikacji stanowiącej rozwinięcie architektury zorientowanej na usługi (Service Oriented Architecture, SOA), a także ze zmian w organizowaniu aplikacji zainstalowanych na serwerach zmierzających konsekwentnie w kierunku coraz powszechniejszego wykorzystywania maszyn wirtualnych oraz konteneryzacji. Najpopularniejszym tego typu narzędziem, które stosowane jest dziś w zdecydowanej większości projektów jest Kubernetes. Warto w tej kategorii wymienić też Docker Swarm, Apache Mesos (z Mesosphere Marathon), Core­OS Fleet, Amazon Elastic Container Service (ECS oraz Fargate), Cloud Foundry Diego czy Azure Container Service. Kubernetes powstało w Google i jest w tej chwili rozwijane pod opieką Cloud Native Computing Foundation. Pierwsze wersje silnika zostały udostępnione w 2014 roku i były napisane w języku C++, później przepisano je na Go. Kubernetes w wersji 1.0 zostało wydane w lipcu 2015 i od tamtego czasu jest aktywnie rozwijane przez społeczność. Zastosowaniem narzędzia jest orkiestracja kontenerów, która polega na kontroli całego cyklu życia usługi: od jej utworzenia, poprzez zmiany i monitoring, na usunięciu kończąc.


W przypadku kontenerów w cykl życia wpisują się następujące elementy:

 

  • konfiguracja zależności między usługami (np. gdy określona usługa musi mieć możliwość dostępu do usługi bazy danych),
  • monitoring usług i serwerów,
  • alokacja zasobów (dysk, czas procesora, pamięć),
  • deployment i zarządzanie zmianami,
  • dostępność usług wewnątrz kontenerów (tzw. health check),
  • dostęp do usług z zewnątrz,
  • skalowanie,
  • Service Discovery, czyli wykrywanie usług w klastrze i podpinanie ich pod load balancer,
  • migracje kontenerów między hostami w klastrze, gdy jeden z serwerów przestanie działać.

 

Wszystkie zasoby (obiekty) w Kubernetes definiujemy za pomocą plików YAML, warto więc przedstawić przykładowe definicje poszczególnych obiektów.

 

> POD

 

Podstawową jednostką organizacyjną w Kubernetes jest Pod. Składa się on z pojedynczego lub wielu kontenerów, można również podłączyć do niego współdzielony dysk wirtualny. Pody są zarządzane przez klaster Kubernetes i mogą być uruchamiane i zatrzymywane dynamicznie, w zależności od dostępnych zasobów. Wewnątrz klastra każdy Pod ma przydzielony adres IP, który może się zmieniać. Przy definiowaniu nowego Poda zazwyczaj wykorzystuje się takie obiekty jak Usługa (Service), Kontroler (Controller), Deployment lub Zadania (Jobs), ale możliwe jest też zdefiniowanie pojedynczego Poda:


apiVersion: v1
kind: Pod
metadata:,

       name: one-pod
       labels:
           app: one-pod
spec:
       containers:
        – name: one-pod-container
        image: ubuntu:18.04
            command: ['/bin/bash', '-c', 'while true; do echo
"Cześć IT Professional"; sleep 360; done']

 

Na podstawie takiego pliku YAML Kubernetes utworzy Pod o nazwie „one-pod” z jednym kontenerem, który będzie wyświetlał napis „Cześć IT Professional”. Każdy Pod lub zestaw Podów może mieć dodatkowo zdefiniowane różnego rodzaju testy sprawności. Może to być zapytanie HTTP, standardowy test połączenia TCP czy nawet komenda wykonana wewnątrz kontenera. Należy pamiętać, że po utworzeniu Poda nie będzie powiązania między kontenerami a definicją z pliku YAML. Jeśli kontener przestanie działać, to Kubernetes (a właściwie Kontroler) nie będzie próbowało go uruchomić ponownie – kontener zostanie po prostu usunięty.


> DEPLOYMENT

 

Aby upewnić się, że Pod będzie zawsze dostępny, można użyć obiektu Deployment. Obiekt ten zwykle już zawiera definicję Poda i dodatkowe informacje, np. liczbę i typy kontenerów, które chcemy uruchomić, czy port, na którym nasłuchuje aplikacja. Definiując usługę w ten sposób, mamy już nieco więcej kontroli nad takimi aspektami jak liczba uruchomionych kontenerów czy aktualizacja obrazu, z którego kontener będzie uruchamiany.

 

apiVersion: apps/v1
kind: Deployment
metadata:
      name: nginx-hello-deployment
spec:
selector:
      matchLabels:
           app: nginx-hello-service
replicas: 2
template:
      metadata:
          labels:
             app: nginx-hello-service
      spec:
           containers:
           – name: nginx-hello
              image: nginxdemos/hello:0.2
              ports:
              – containerPort: 80


Powyższy przykład definiuje Deployment o nazwie nginx-hello-deployment i Pod oznaczony etykietą (matchLabels i labels) nginx-hello-service, na który składają się dwa kontenery (replicas: 2) o nazwie nginx-hello. Użyliśmy tu obrazu nginxdemos/hello w wersji 0.2 i deklarujemy, że usługa otworzy port 80. Po utworzeniu tego obiektu w klastrze powinny znaleźć się dwa działające kontenery. Należy pamiętać, że aktualizacja liczby replik w Deployment nie spowoduje dodania lub usunięcia kontenerów w Podzie. Jedynym sposobem włączenia możliwości aplikowania zmian w Deploymencie jest zmiana obrazu lub jego wersji.

 

> KONTROLER REPLIKACJI

 

Kontroler Replikacji jest usługą, dzięki której Pody będą dostępne zawsze w tej liczbie, jaką zdefiniowaliśmy. W praktyce usługa usuwa kontenery, jeśli jest ich uruchomionych za dużo, i uruchamia nowe, jeśli jest ich za mało. Dotyczy to również sytuacji, kiedy Pod przestanie działać lub zostanie ręcznie usunięty. Kontroler Replikacji można utworzyć ręcznie, ale nie jest to zalecane – w oficjalnej dokumentacji znajdziemy rekomendację, by zamiast tego używać obiektu Deployment.

 

[...]

 

Doświadczony inżynier systemów. Specjalizuje się w automatyzacji procesów i monitoringu aplikacji rozproszonych. Propagator ruchu open source. Organizator wydarzeń związanych z IT. Freelancer. W wolnych chwilach twórca fantastyki i fantastyki naukowej. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"