Ahoj, Habr!
Na konci léta chceme připomenout, že nadále pracujeme na tomto tématu a rozhodli jsme se publikovat článek ze Stackoverflow, který ukazuje stav tohoto projektu na začátku června.
Příjemné čtení!
V době psaní tohoto článku má Kubernetes přibližně , a v posledních dvou letech jeho popularita vzrostla natolik, že se stabilně umisťuje mezi platformami. Letos má Kubernetes třetí místo. Připomeňme: Kubernetes je platforma určená k provozu a orchestraci kontejnerových pracovních zátěží.
Kontejnery vznikly jako speciální konstrukce pro izolaci procesů v Linuxu; od roku 2007 obsahují , a od roku 2002 – namespace. Kontejnery se ještě lépe utvářely v roce 2008, kdy se stal dostupný , a v Googlu vyvinuli svůj interní mechanismus nazvaný , kde „veškerá práce probíhá v kontejnerech“. Odtud se přeneseme do roku 2013, kdy vyšel první Docker, a kontejnery se definitivně dostaly mezi populární masová řešení. V té době byl hlavním nástrojem pro orchestraci kontejnerů , i když nebyl moc populární. První vydání Kubernetes se uskutečnilo v roce 2015, po kterém se tento nástroj de facto stal standardem v oblasti orchestrace kontejnerů.
Abychom se pokusili pochopit, proč je Kubernetes tak populární, zkusme odpovědět na několik otázek. Kdy se naposledy podařilo vývojářům dosáhnout shody o tom, jak nasazovat aplikace v produkčním prostředí? Kolik znáte vývojářů, kteří používají nástroje tak, jak jsou dodávány „z krabice“? Kolik dnes existuje správců cloudů, kteří nerozumí, jak aplikace fungují? Odpovědi na tyto otázky prozkoumáme v tomto článku.
Infrastruktura jako YAML
Ve světě, který přešel z Puppet a Chef na Kubernetes, byl jedním z největších změn přechod od „infrastruktury jako kódu“ k „infrastruktuře jako datům“ — konkrétně, jako YAML. Všechny zdroje v Kubernetes, které zahrnují pody, konfigurace, nasazené instance, svazky atd., lze snadno popsat v YAML souboru. Například:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80S tímto přístupem mají specialisté na DevOps nebo SRE mnohem snazší plně vyjádřit své pracovní zátěže, aniž by museli psát programový kód v jazycích jako Python nebo Javascript.
Další výhody organizace infrastruktury jako dat jsou následující:
- GitOps nebo správa verzí Git Operations Version. Tento přístup umožňuje uchovávat všechny YAML soubory Kubernetes v repozitářích git, díky čemuž můžete přesně sledovat, kdy byla změna provedena, kdo ji provedl a co bylo konkrétně změněno. To zvyšuje transparentnost operací v celé organizaci a zvyšuje efektivitu práce tím, že eliminuje nejasnosti, zejména v tom, kde by zaměstnanci měli hledat potřebné zdroje. Zároveň se stává jednodušší automaticky provádět změny v prostředcích Kubernetes pomocí běžného sloučení pull requestu.
- Škálovatelnost. Když jsou prostředky definovány jako YAML, operátorům clusteru je extrémně snadné změnit jedno nebo dvě čísla ve prostředku Kubernetes, čímž se změní princip jeho škálování. Kubernetes obsahuje mechanismus pro horizontální automatické škálování podů, pomocí kterého je snadné určit, jaké je minimální a maximální množství podů, které je potřeba v konkrétní nasazené konfiguraci pro zvládnutí nízké a vysoké úrovně provozu. Například pokud máte nasazenou konfiguraci, která potřebuje dodatečné zdroje kvůli náhlému nárůstu provozu, můžete změnit hodnotu maxReplicas 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 správa. YAML je vynikající pro posouzení toho, jak se určité věci nasazují v Kubernetes. Například vážný problém, který se týká zabezpečení, se týká toho, zda jsou vaše pracovní zátěže spuštěny pod uživatelským účtem, který nemá administrátorská práva. V tomto případě nám mohou pomoci nástroje jako , validátor YAML/JSON, plus , validátor politik, který zajistí, že kontext vašich pracovních zátěží neumožňuje kontejneru pracovat s administrátorskými právy. Pokud je to potřeba zajistit, mohou uživatelé aplikovat jednoduchou politiku , takto:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Kontejner by neměl běžet jako root"
}- Možnosti integrace s cloudovým poskytovatelem. Jedním z nejvýraznějších trendů v moderních technologiích je provozovat pracovní zátěže na zdrojích veřejných cloudových poskytovatelů. S pomocí komponenty Kubernetes umožňuje jakémukoli clusteru integrovat se s tím cloudovým poskytovatelem, na kterém běží. Například pokud uživatel spustil aplikaci v Kubernetes na AWS a chce zpřístupnit tuto aplikaci prostřednictvím služby, cloudový poskytovatel automaticky pomáhá vytvořit službu
LoadBalancer, která automaticky poskytne vyvažovač zátěže , aby přesměroval provoz na pod aplikací.
Škálovatelnost
Kubernetes se velmi dobře škáluje, což se vývojářům líbí. Existuje sada dostupných zdrojů, jako jsou pody, nasazení, StatefulSets, tajemství, ConfigMaps, atd. Pravda, uživatelé a vývojáři mohou přidávat i další zdroje ve formě .
Například pokud chceme definovat zdroj CronTab, mohli bychom učinit něco podobné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 přibližně takto:
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 vlastní operátory. – je speciální proces v klastru Kubernetes, který funguje podle vzoru „“. Pomocí operátoru může uživatel automatizovat správu CRD (vlastních definic zdrojů), výměnou informací s Kubernetes API.
V komunitě existuje několik nástrojů, pomocí nichž mohou vývojáři snadno vytvářet vlastní operátory. Mezi nimi je a jeho . Tento SDK poskytuje základ, na jehož základě může vývojář velmi rychle začít vytvářet operátor. Například, můžete začít z příkazového řádku přibližně takto:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorTakto se vytvoří veškerý stereotypní kód pro váš operátor, včetně souborů YAML a kódu na Golangu:
.
|____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 potřebné API a kontroler, takto:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceNakonec, poskládejte operátor a odešlete ho do vašeho kontejnerového registru:
$ operator-sdk build your.container.registry/youruser/myapp-operator Pokud vývojář potřebuje ještě větší kontrolu, může změnit stereotypní kód v souborech na Go. Například, pro úpravu specifikace kontroleru, lze provést změny v souboru controller.go.
Další projekt, , umožňuje vytvářet operátory pouze za použití deklarativních YAML souborů. Například, operátor pro Apache Kafka bude definován přibližně . Pomocí něj můžete jednoduše pomocí pár příkazů nainstalovat klastr Kafka na Kubernetes:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaA poté ho nastavit pomocí další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
V průběhu posledních několika let vycházely velké verze Kubernetes každé několik měsíců — tedy tři až čtyři velké vydání za rok. Počet nových funkcí zaváděných v každém z nich se nesnižuje. Co víc, ani v našich složitých časech není vidět známky zpomalení — podívejte se, jaká je nyní .
Nové možnosti umožňují flexibilnější clusterování operací při různorodých pracovních zátěžích. Kromě toho mají programátoři rádi větší kontrolu při nasazování aplikací přímo do produkce.
Komunita
Dalším vážný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ůznorodé komunity (speciální zájmové skupiny), zaměřené na prozkoumání různých oblastí Kubernetes, jak se tento projekt vyvíjí. Tyto skupiny neustále přidávají nové možnosti, což usnadňuje práci s Kubernetes.
Nadace Cloud Native Foundation také pořádá CloudNativeCon/KubeCon, která je v době psaní tohoto textu největší open-source konferencí na světě. Obvykle se koná třikrát ročně a shromažďuje tisíce profesionálů, kteří chtějí zlepšit Kubernetes a jeho ekosystém, a osvojuju si nové funkce, které se objevují každé tři měsíce.
Navíc v Cloud Native Foundation existuje , který spolu se SIGy zkoumá nové a stávající nadace zaměřené na cloudový ekosystém. Většina z těchto projektů pomáhá zlepšit silné stránky Kubernetes.
Nakonec věřím, že Kubernetes by neměl takový úspěch bez uvědomělých snah celé komunity, kde si lidé pomáhají navzájem, ale zároveň s radostí vítají nováčky.
Budoucnost
Jednou z hlavních výzev, s nimiž se vývojáři v budoucnu budou muset vypořádat, je schopnost soustředit se na detaily samotného kódu, nikoli na infrastrukturu, v níž pracuje. Tento trend odpovídá , která je dnes jednou z vedoucích. Již existují pokročilé rámce, například a , které využívají Kubernetes k abstrakci infrastruktury od vývojáře.
V tomto článku jsme pouze v obrysech přehledně prozkoumali současný stav Kubernetes – ve skutečnosti je to jen špička ledovce. Uživatelé Kubernetes mají k dispozici i mnoho dalších zdrojů, možností a konfigurací.
Zdroj: habr.com
