Čau Habr!
Na konci léta chceme připomenout, že na tématu nadále pracujeme a rozhodla se počátkem června publikovat článek ze Stackoverflow demonstrující stav věcí v tomto projektu.
Užijte si čtení!
V době psaní tohoto článku je stáří Kubernetes cca. , a za poslední dva roky jeho obliba vzrostla natolik, že se trvale umisťuje mezi platformy. Kubernetes je letos třetí. Pro rekapitulaci: Kubernetes je platforma navržená pro spouštění a orchestraci kontejnerizovaných úloh.
Kontejnery začaly jako speciální návrh pro izolaci procesů v Linuxu; kontejnery jsou součástí od roku 2007 a od roku 2002 – jmenné prostory. Kontejnery byly navrženy ještě lépe do roku 2008, kdy byly k dispozici a Google vyvinul svůj vlastní interní firemní mechanismus nazvaný , kde „veškerá práce probíhá v kontejnerech“. Odtud se rychle přesuneme do roku 2013, kdy došlo k prvnímu vydání Dockeru, a kontejnery se konečně staly oblíbeným masovým řešením. V té době byl hlavním nástrojem pro orchestraci kontejnerů , i když nebyl příliš populární. Kubernetes byl poprvé vydán v roce 2015, poté se tento nástroj stal de facto standardem v oblasti orchestrace kontejnerů.
Abychom se pokusili pochopit, proč je Kubernetes tak populární, zkusme si odpovědět na pár otázek. Kdy se naposledy vývojáři dokázali shodnout na tom, jak nasadit aplikace do produkce? Kolik znáte vývojářů, kteří používají nástroje tak, jak jsou poskytovány? Kolik je dnes cloudových správců, kteří nechápou, jak aplikace fungují? Na odpovědi na tyto otázky se podíváme v tomto článku.
Infrastruktura jako YAML
Ve světě, který přešel od Puppet and Chef ke Kubernetes, byl jednou z největších změn přechod z „infrastruktury jako kódu“ na „infrastrukturu jako data“ – konkrétně jako YAML. Všechny prostředky v Kubernetes, které zahrnují pody, konfigurace, nasazené instance, svazky atd., lze snadno popsat v souboru YAML. Například:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Toto zobrazení usnadňuje profesionálům DevOps nebo SRE plně vyjádřit své pracovní zatížení, aniž by museli psát kód v jazycích jako Python nebo Javascript.
Mezi další výhody organizace infrastruktury jako dat patří:
- GitOps nebo Git Operations Version Control. Tento přístup vám umožňuje uchovávat všechny soubory Kubernetes YAML v git repozitářích, takže můžete přesně sledovat, kdy byla změna provedena, kdo ji provedl a co přesně se změnilo. To zvyšuje transparentnost operací v celé organizaci a zlepšuje provozní efektivitu odstraněním nejednoznačnosti, zejména tam, kde by zaměstnanci měli hledat zdroje, které potřebují. Zároveň je snazší automaticky provádět změny zdrojů Kubernetes pouhým sloučením požadavku na stažení.
- Škálovatelnost. Když jsou prostředky definovány jako YAML, je pro operátory clusteru extrémně snadné změnit jedno nebo dvě čísla v prostředku Kubernetes, čímž se změní jeho škálování. Kubernetes poskytuje mechanismus pro horizontální automatické škálování modulů, který lze použít k pohodlnému určení minimálního a maximálního počtu modulů, které jsou vyžadovány v konkrétní konfiguraci nasazení pro zvládnutí nízké a vysoké úrovně provozu. Pokud jste například nasadili konfiguraci, která vyžaduje další kapacitu kvůli náhlému nárůstu provozu, lze maxReplicas změnit 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- Bezpečnost a management. YAML je skvělý pro hodnocení toho, jak jsou věci nasazeny v Kubernetes. Například hlavní bezpečnostní problém se týká toho, zda vaše úlohy běží jako uživatel, který není správcem. V tomto případě můžeme potřebovat nástroje jako např , validátor YAML/JSON a navíc , validátor zásad, který zajistí, že kontext vaše pracovní zatížení neumožňuje spuštění kontejneru s oprávněními správce. Pokud je to vyžadováno, mohou uživatelé použít jednoduchou zásadu jako toto:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Možnosti integrace s poskytovatelem cloudu. Jedním z nejpozoruhodnějších trendů v dnešních špičkových technologiích je provozovat pracovní zátěž na veřejných poskytovatelích cloudu. Použití komponenty Kubernetes umožňuje integraci jakéhokoli clusteru s poskytovatelem cloudu, na kterém běží. Pokud například uživatel spustí aplikaci v Kubernetes na AWS a chce tuto aplikaci zpřístupnit prostřednictvím služby, poskytovatel cloudu pomůže službu automaticky vytvořit.
LoadBalancerkterý automaticky poskytne load balancer k přesměrování provozu do aplikačních modulů.
Rozšiřitelnost
Kubernetes je velmi rozšiřitelný a vývojáři ho milují. Existuje sada dostupných zdrojů, jako jsou moduly, nasazení, StatefulSets, tajemství, ConfigMaps, atd. Je pravda, že uživatelé a vývojáři mohou do formuláře přidat další zdroje .
Například pokud chceme definovat zdroj CronTab, pak byste mohli udělat něco takového:
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
Později můžeme vytvořit zdroj CronTab něco takového:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Další možností rozšiřitelnosti v Kubernetes je, že vývojář může psát své vlastní příkazy. je speciální proces v clusteru Kubernetes, který funguje podle „" S pomocí operátora může uživatel automatizovat správu CRD (vlastní definice zdrojů) výměnou informací s Kubernetes API.
V komunitě existuje několik nástrojů, které vývojářům usnadňují vytváření vlastních operátorů. Mezi nimi - a . Tato sada SDK poskytuje základ, ze kterého může vývojář rychle začít vytvářet operátora. Řekněme, že můžete začít z příkazového řádku něco takového:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorTím se vytvoří veškerý standardní kód pro vašeho operátora, včetně souborů YAML a kódu 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.goPoté můžete přidat požadovaná rozhraní API a řadič takto:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServicePoté nakonec sestavte operátor a odešlete jej do registru vašeho kontejneru:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Pokud chce vývojář ještě větší kontrolu, standardní kód v souborech Go lze změnit. Chcete-li například upravit specifika řadiče, můžete provést změny v souboru controller.go.
Další projekt , umožňuje vytvářet příkazy pouze pomocí deklarativních souborů YAML. Například operátor pro Apache Kafka by byl definován přibližně . S ním můžete nainstalovat cluster Kafka na Kubernetes pomocí několika příkazů:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaA pak jej nakonfigurujte pomocí jiného příkazu:
$ 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
Inovace
Během několika posledních let vycházely hlavní verze Kubernetes každých pár měsíců – to znamená tři až čtyři hlavní verze ročně. Počet novinek představených v každém z nich neklesá. Navíc ani v těchto těžkých časech nejeví známky zpomalení – podívejte se, jaká je situace nyní .
Nové funkce vám umožňují flexibilnější clusterové operace napříč různými pracovními zátěžemi. Programátoři navíc mají větší kontrolu při nasazování aplikací přímo do výroby.
Společenství
Dalším hlavním aspektem popularity Kubernetes je síla jeho komunity. V roce 2015, po dosažení verze 1.0, byl Kubernetes sponzorován .
Existují také různé komunity (Special Interest Groups) zaměřené na práci v různých oblastech Kubernetes, jak se projekt vyvíjí. Tyto skupiny neustále přidávají nové funkce, díky nimž je práce s Kubernetes pohodlnější a pohodlnější.
Cloud Native Foundation také pořádá CloudNativeCon/KubeCon, což je v době psaní tohoto článku největší open source konference na světě. Obvykle se koná třikrát ročně a spojuje tisíce profesionálů, kteří chtějí zlepšit Kubernetes a jeho ekosystém a také se naučit nové funkce, které se objevují každé tři měsíce.
Kromě toho má Cloud Native Foundation , která spolu se SIGy recenzuje nové i stávající prostředky zaměřené na cloudový ekosystém. Většina těchto projektů pomáhá zlepšit silné stránky Kubernetes.
A konečně věřím, že Kubernetes by nebyl tak úspěšný, jak je, bez vědomého úsilí celé komunity, kde lidé drží pospolu, ale zároveň vítají nováčky ve skupině.
Budoucnost
Jednou z hlavních výzev, se kterou se budou muset vývojáři v budoucnu vypořádat, je schopnost soustředit se na detaily samotného kódu, a ne na infrastrukturu, ve které běží. Splňuje tyto trendy , která dnes patří k předním. Pokročilé frameworky již existují, např. и , které používají Kubernetes k abstrahování infrastruktury od vývojáře.
V tomto článku jsme pouze načrtli povrch současného stavu Kubernetes – ve skutečnosti je to jen špička ledovce. Uživatelé Kubernetes mají k dispozici mnoho dalších zdrojů, možností a konfigurací.
Zdroj: www.habr.com