Cześć, Habr!
Na koniec lata chcemy przypomnieć, że nadal pracujemy nad tematem i postanowiliśmy opublikować artykuł z Stackoverflow, ilustrujący stan tego projektu na początku czerwca.
Życzymy miłej lektury!
W momencie pisania tego artykułu Kubernetes ma około , a w ciągu ostatnich dwóch lat jego popularność wzrosła do tego stopnia, że nieprzerwanie znajduje się wśród platform. W tym roku Kubernetes zajmuje trzecie miejsce. Przypominamy: Kubernetes to platforma zaprojektowana do uruchamiania i orkiestracji obciążeń aplikacji kontenerowych.
Kontenery powstały jako specjalna konstrukcja do izolacji procesów w systemie Linux; od 2007 roku zawierają , a od 2002 są to przestrzenie nazw. Kontenery lepiej uformowały się w 2008 roku, kiedy stały się dostępne , a w Google opracowano wewnętrzny mechanizm o nazwie , gdzie „wszystkie operacje są wykonywane w kontenerach”. Przenieśmy się do 2013 roku, kiedy odbyła się pierwsza wersja Dockera, a kontenery ostatecznie przeszły do grupy popularnych rozwiązań masowych. Wówczas głównym narzędziem do orkiestracji kontenerów był , chociaż nie cieszył się dużą popularnością. Pierwsza wersja Kubernetes miała miejsce w 2015 roku, po czym to narzędzie de facto stało się standardem w dziedzinie orkiestracji kontenerów.
Aby spróbować zrozumieć, dlaczego Kubernetes jest tak popularny, spróbujmy odpowiedzieć na kilka pytań. Kiedy ostatni raz programiści byli w stanie dojść do porozumienia co do tego, jak wdrażać aplikacje w produkcji? Ilu znasz programistów, którzy używają narzędzi w takim stanie, w jakim są one dostarczane „prosto z pudełka”? Ilu jest dziś administratorów chmurowych, którzy nie rozumieją, jak działają aplikacje? Odpowiedzi na te pytania omówimy w tym artykule.
Infrastruktura jako YAML
W świecie, który przeszedł od Puppet i Chef do Kubernetes, jedną z największych zmian było przejście od „infrastruktury jako kodu” do „infrastruktury jako danych” — konkretnie, jako YAML. Wszystkie zasoby w Kubernetes, takie jak pod, konfiguracje, wdrożone egzemplarze, woluminy itd., można łatwo opisać w pliku YAML. Na przykład:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Dzięki takiemu podejściu specjaliści DevOps lub SRE mogą w pełni wyrażać swoje obciążenia robocze, bez konieczności pisania kodu w językach takich jak Python czy Javascript.
Inne zalety organizacji infrastruktury jako danych są następujące:
- GitOps lub wersjonowanie operacji Git. Takie podejście pozwala trzymać wszystkie pliki YAML Kubernetes w repozytoriach git, co umożliwia dokładne śledzenie, kiedy dokonano zmian, kto je wprowadził i co dokładnie zostało zmienione. Dzięki temu zwiększa się przejrzystość działań w całej organizacji oraz efektywność pracy, poprzez eliminację niejasności, zwłaszcza w tym, gdzie pracownicy powinni szukać potrzebnych im zasobów. Z drugiej strony, łatwiej jest automatycznie wprowadzać zmiany do zasobów Kubernetes – poprzez standardowe łączenie pull-requestów.
- Skalowalność. Gdy zasoby są definiowane w formacie YAML, operatorom klastra bardzo łatwo jest zmienić jedną lub dwie liczby w zasobie Kubernetes, zmieniając tym samym zasady jego skalowania. Kubernetes ma mechanizm poziomego automatycznego skalowania podów, który pozwala zdefiniować, jakie jest minimalne i maksymalne liczba podów potrzebnych w konkretnej wdrożonej konfiguracji, aby radzić sobie z niskim i wysokim poziomem ruchu. Na przykład, jeśli wdrożyłeś konfigurację, która wymaga dodatkowych zasobów z powodu nagłego wzrostu ruchu, to wskaźnik maxReplicas można zmienić z 10 na 20:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: myapp
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-deployment
minReplicas: 1
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50- Bezpieczeństwo i zarządzanie. YAML jest doskonały do oceny, jak różne elementy są wdrażane w Kubernetes. Na przykład, poważnym problemem związanym z zapewnieniem bezpieczeństwa jest to, czy Twoje obciążenia robocze są uruchamiane z użytkownika, który nie ma uprawnień administratora. W tym przypadku mogą być przydatne takie narzędzia jak , walidator YAML/JSON, oraz , walidator polityk, który pozwala upewnić się, że kontekst Obciążenia robocze nie pozwalają na uruchamianie kontenera z uprawnieniami administratora. Jeśli jest to konieczne, użytkownicy mogą zastosować prostą politykę , w ten sposób:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Kontenery nie mogą działać jako root"
}- Opcje integracji z dostawcą chmury. Jednym z najbardziej zauważalnych trendów w nowoczesnych technologiach jest uruchamianie obciążeń roboczych na zasobach publicznych dostawców chmur. Dzięki komponentowi Kubernetes pozwala każdemu klastrowi zintegrować się z tym dostawcą chmury, na którym działa. Na przykład, jeśli użytkownik uruchomił aplikację w Kubernetes na AWS i chce otworzyć dostęp do tej aplikacji przez usługę, dostawca chmury automatycznie pomaga utworzyć usługę
LoadBalancer, która automatycznie udostępni balansujący ruch , aby przekierować ruch do podów aplikacji.
Rozszerzalność
Kubernetes jest bardzo dobrze skalowalny, co podoba się programistom. Istnieje zestaw dostępnych zasobów, takich jak pody, wdrożenia, StatefulSets, sekrety, ConfigMaps, itd. Prawda, użytkownicy i programiści mogą dodawać inne zasoby w formie .
Na przykład, jeśli chcemy zdefiniować zasób CronTab, moglibyśmy zrobić coś takiego:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.my.org
spec:
group: my.org
versions:
- name: v1
served: true
storage: true
Schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
Później możemy tworzyć zasób CronTab mniej więcej w ten sposób:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Inną opcją rozszerzalności w Kubernetes jest to, że programista może pisać własne operatory. – to specjalny proces w klastrze Kubernetes, działający według wzorca „”. Dzięki operatorowi użytkownik może zautomatyzować zarządzanie CRD (niestandardowymi definicjami zasobów), wymieniając informacje z API Kubernetes.
W społeczności istnieje kilka narzędzi, które umożliwiają programistom łatwe tworzenie własnych operatorów. Wśród nich znajduje się i jego . Ten SDK zapewnia podstawę, na której programista może bardzo szybko rozpocząć tworzenie operatora. Można na przykład rozpocząć od wiersza poleceń w ten sposób:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorW ten sposób tworzony jest cały stereotypowy kod dla twojego operatora, w tym pliki YAML i kod w Golang:
.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.goNastępnie można dodać potrzebne API i kontroler, w ten sposób:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceA następnie, w końcu, skompilować operatora i przesłać go do rejestru twojego kontenera:
$ operator-sdk build your.container.registry/youruser/myapp-operator Jeśli programista potrzebuje jeszcze większej kontroli, może zmienić stereotypowy kod w plikach Go. Na przykład, aby zmienić specyfikację kontrolera, można wprowadzić zmiany w pliku controller.go.
Inny projekt, , umożliwia tworzenie operatorów przy użyciu wyłącznie deklaratywnych plików YAML. Na przykład operator dla Apache Kafka można zdefiniować mniej więcej w ten sposób: . Dzięki temu można zainstalować klaster Kafka na Kubernetes w zaledwie kilku komendach:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaA następnie skonfigurować go za pomocą jeszcze jednej komendy:
$ kubectl kudo install kafka --instance=my-kafka-name
-p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181
-p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m
-p BROKER_COUNT=5 -p BROKER_MEM=4096m
-p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3
-p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20
Innowacje
W ciągu ostatnich kilku lat większe wydania Kubernetes odbywają się co kilka miesięcy – czyli około trzy-cztery duże wydania w roku. Liczba nowych funkcji wprowadzanych w każdym z nich nie maleje. Co więcej, nie widać oznak spowolnienia nawet w tych trudnych czasach – zobacz, jaka jest teraz .
Nowe możliwości pozwalają na bardziej elastyczne klasterowanie operacji przy różnorodnych obciążeniach roboczych. Ponadto programiści cenią sobie pełniejszą kontrolę przy wdrażaniu aplikacji bezpośrednio w środowisku produkcyjnym.
Społeczność
Kolejnym istotnym aspektem popularności Kubernetes jest siła jego społeczności. W 2015 roku, po osiągnięciu wersji 1.0, Kubernetes został sponsorowany .
Istnieją również różnorodne społeczności (specjalne grupy zainteresowań), które koncentrują się na rozwoju różnych obszarów Kubernetes, w miarę jak projekt się rozwija. Grupy te nieustannie dodają nowe możliwości, co sprawia, że praca z Kubernetes staje się coraz bardziej komfortowa.
Cloud Native Foundation organizuje również CloudNativeCon/KubeCon, która, w momencie pisania tego tekstu, jest największą konferencją open source na świecie. Zazwyczaj odbywa się trzy razy w roku i gromadzi tysiące profesjonalistów, którzy pragną ulepszyć Kubernetes i jego ekosystem, a także poznać nowe możliwości pojawiające się co trzy miesiące.
Co więcej, w Cloud Native Foundation istnieje , który wspólnie z SIG-ami rozpatruje nowe i istniejące fundacji, skupione na ekosystemie chmurowym. Większość z tych projektów pomaga wzmocnić możliwości Kubernetes.
W końcu wierzę, że Kubernetes nie odniósłby takiego sukcesu bez świadomych wysiłków całej społeczności, w której ludzie wspierają się nawzajem, ale jednocześnie chętnie przyjmują nowicjuszy.
Przyszłość
Jednym z głównych wyzwań, z którymi deweloperzy będą musieli zmierzyć się w przyszłości, jest umiejętność skupienia się na szczegółach samego kodu, a nie na infrastrukturze, w której działa. To właśnie tym trendom odpowiada , która jest dzisiaj jednym z wiodących rozwiązań. Już istnieją zaawansowane frameworki, takie jak i , które wykorzystują Kubernetes do abstrahowania infrastruktury od dewelopera.
W tym artykule w zarysie przyjrzeliśmy się obecnemu stanowi Kubernetes – w rzeczywistości to tylko wierzchołek góry lodowej. Użytkownicy Kubernetes mają do dyspozycji wiele innych zasobów, możliwości i konfiguracji.
Źródło: habr.com
