Ciao, Habr!
Alla fine dell'estate vogliamo ricordare che stiamo continuando a lavorare sull'argomento e abbiamo deciso di pubblicare un articolo di Stackoverflow che mostra lo stato attuale di questo progetto all'inizio di giugno.
Buona lettura!
Al momento della scrittura di questo articolo, Kubernetes ha circa , e negli ultimi due anni la sua popolarità è cresciuta così tanto che è costantemente tra le Quest'anno Kubernetes occupa il terzo posto. Ricordiamo: Kubernetes è una piattaforma progettata per eseguire e orchestrare carichi di lavoro in container.
I container sono nati come una costruzione speciale per l'isolamento dei processi in Linux; dal 2007, all'interno dei container, ci sono , mentre dal 2002 esistono spazi dei nomi. I container si sono definiti ancora meglio nel 2008, quando è diventato disponibile , e in Google hanno sviluppato il loro meccanismo interno chiamato , dove "tutto il lavoro viene svolto in container". Da qui ci spostiamo al 2013, quando è avvenuto il primo rilascio di Docker, e i container sono finalmente diventati una soluzione popolare di massa. A quel tempo, lo strumento principale per l'orchestrazione dei container era , tuttavia, non ha goduto di una popolarità sfrenata. Il primo rilascio di Kubernetes è avvenuto nel 2015, dopo di che questo strumento è diventato de facto lo standard nell'orchestrazione di container.
Per cercare di capire perché Kubernetes sia così popolare, proviamo a rispondere a qualche domanda. Quando è stata l'ultima volta in cui gli sviluppatori sono riusciti a trovare un consenso su come distribuire le applicazioni in produzione? Quanti sviluppatori conoscete che utilizzano strumenti così come sono forniti "out of the box"? Quanti sono oggi i cloud administrator che non comprendono come funzionano le applicazioni? Le risposte a queste domande le esamineremo in questo articolo.
Infrastruttura come YAML
Nel mondo che da Puppet e Chef è passato a Kubernetes, uno dei cambiamenti più significativi è stato il passaggio da "infrastruttura come codice" a "infrastruttura come dati" — nello specifico, come YAML. Tutte le risorse in Kubernetes, che includono pod, configurazioni, istanze distribuite, volumi e altro, possono essere facilmente descritte in un file YAML. Ad esempio:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Con questa rappresentazione, è più facile per i professionisti di DevOps o SRE esprimere completamente i loro carichi di lavoro, senza la necessità di scrivere codice in linguaggi come Python o Javascript.
Altri vantaggi dell'organizzazione dell'infrastruttura dei dati, in particolare, sono:
- GitOps o controllo versione delle Operazioni Git. Questo approccio consente di mantenere tutti i file YAML di Kubernetes in repository git, permettendo di tracciare esattamente quando è stata apportata una modifica, chi l'ha effettuata e cosa è stato cambiato. Questo aumenta la trasparenza delle operazioni all'interno dell'intera organizzazione e migliora l'efficienza eliminando ambiguità, in particolare riguardo a dove i dipendenti devono cercare le risorse di cui hanno bisogno. Allo stesso tempo, diventa più facile apportare modifiche automaticamente alle risorse di Kubernetes tramite una semplice fusione di pull request.
- Scalabilità. Quando le risorse sono definite in formato YAML, è estremamente semplice per gli operatori del cluster modificare uno o due numeri nelle risorse di Kubernetes, cambiando così le modalità di scalabilità. Kubernetes prevede un meccanismo per l'auto-scaling orizzontale dei pod, attraverso il quale è facile definire qual è il numero minimo e massimo di pod necessari in una specifica configurazione distribuita, per gestire carichi di traffico bassi e alti. Ad esempio, se hai distribuito una configurazione che richiede ulteriori risorse a causa di un picco improvviso di traffico, puoi modificare il valore di maxReplicas da 10 a 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- Sicurezza e gestione. YAML è eccellente per valutare come le varie risorse vengano distribuite in Kubernetes. Per esempio, un problema serio riguardo la sicurezza è se i tuoi carichi di lavoro vengono eseguiti da un utente senza privilegi di amministratore. In questo caso, strumenti come , un validatore YAML/JSON, oltre a , un validatore delle politiche, permettendo di verificare che il dei tuoi carichi di lavoro non consenta al contenitore di eseguire con privilegi da amministratore. Se è necessario garantirlo, gli utenti possono applicare una semplice politica , in questo modo:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "I contenitori non devono essere eseguiti come root"
}- Opzioni di integrazione con il fornitore di cloud. Una delle tendenze più evidenti nelle moderne tecnologie è eseguire carichi di lavoro sulle infrastrutture dei fornitori di cloud pubblici. Utilizzando il componente Kubernetes consente a qualsiasi cluster di integrarsi con il provider cloud su cui è in esecuzione. Ad esempio, se un utente avvia un'applicazione su Kubernetes su AWS e desidera rendere accessibile questa applicazione tramite un servizio, il provider cloud aiuta a creare automaticamente il servizio.
LoadBalancer, che fornirà automaticamente un bilanciatore di carico , per reindirizzare il traffico verso i pod delle applicazioni.
Scalabilità
Kubernetes è altamente scalabile e questo è molto apprezzato dagli sviluppatori. Esiste un insieme di risorse disponibili, come pod, deployment, StatefulSets, segreti, ConfigMaps, ecc. Tuttavia, gli utenti e gli sviluppatori possono aggiungere altre risorse sotto forma di .
Ad esempio, se volessimo definire una risorsa CronTab, potremmo fare qualcosa di simile:
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
In seguito, possiamo creare una risorsa CronTab in questo modo:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Un'altra opzione per l'estendibilità in Kubernetes è che gli sviluppatori possono scrivere i propri operatori. – è un processo speciale all'interno del cluster Kubernetes che segue il modello "". Con un operatore, è possibile automatizzare la gestione delle CRD (Definizioni di Risorse Personalizzate), condividendo informazioni con l'API di Kubernetes.
Nella comunità ci sono diversi strumenti che facilitano agli sviluppatori la creazione dei propri operatori. Tra questi c'è il e ai suoi . Questo SDK fornisce una base da cui gli sviluppatori possono iniziare rapidamente a creare un operatore. Ad esempio, si può partire dalla riga di comando in questo modo:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorIn questo modo vengono generati tutto il codice standard per il tuo operatore, compresi i file YAML e il codice in 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.goDopo, puoi aggiungere le API e il controller necessari, in questo modo:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceSuccessivamente, infine, compila l'operatore e caricalo nel tuo registro di contenitori:
$ operator-sdk build your.container.registry/youruser/myapp-operator Se lo sviluppatore richiede un controllo ancora più completo, può modificare il codice standard nei file Go. Ad esempio, per cambiare la logica del controller, si può apportare modifiche al file controller.go.
Un altro progetto, , consente di creare operatori utilizzando solo file YAML dichiarativi. Ad esempio, un operatore per Apache Kafka sarà definito in modo simile . Con esso, è possibile installare un cluster Kafka su Kubernetes con solo un paio di comandi:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaE poi configurarlo con un'altra comando:
$ 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
Innovazioni
Negli ultimi anni, le grandi versioni di Kubernetes vengono rilasciate ogni pochi mesi — tre o quattro grandi versioni all'anno. Il numero di nuove funzionalità implementate in ciascuna di esse non diminuisce. Inoltre, non ci sono segni di rallentamento nemmeno nei nostri tempi difficili — guarda quale è ora .
Le nuove funzionalità consentono di clusterizzare le operazioni in modo più flessibile, considerando una varietà di carichi di lavoro. Inoltre, agli sviluppatori piace avere un controllo più completo durante il deployment delle applicazioni direttamente in produzione.
Comunità
Un altro aspetto significativo della popolarità di Kubernetes è la forza della sua comunità. Nel 2015, al lancio della versione 1.0, Kubernetes è stato sponsorizzato .
Esistono anche diverse comunità (gruppi speciali di interesse) dedicati allo sviluppo di varie aree di Kubernetes mentre questo progetto si evolve. Questi gruppi continuano ad aggiungere nuove funzionalità, rendendo l'uso di Kubernetes sempre più semplice e accessibile.
La Cloud Native Foundation organizza anche il CloudNativeCon/KubeCon, che, al momento della scrittura di questo testo, è la più grande conferenza open source al mondo. Di solito si tiene tre volte all'anno e riunisce migliaia di professionisti desiderosi di migliorare Kubernetes e il suo ecosistema, oltre a scoprire nuove funzionalità che emergono ogni tre mesi.
Inoltre, nella Cloud Native Foundation c'è un , che, insieme ai SIG, esamina nuovi progetti e quelli esistenti della fondazione, focalizzati sull'ecosistema cloud. La maggior parte di questi progetti contribuisce a migliorare i punti di forza di Kubernetes.
Finalmente, credo che Kubernetes non avrebbe avuto successo senza gli sforzi consapevoli di tutta la comunità, dove le persone si sostengono a vicenda, ma, allo stesso tempo, accolgono con gioia i neofiti.
Futuro
Una delle principali sfide che gli sviluppatori dovranno affrontare in futuro è la capacità di concentrarsi sui dettagli del codice stesso, piuttosto che sull'infrastruttura in cui opera. È a queste tendenze che risponde , che oggi è tra le più elevate. Già esistono framework avanzati, come e , che utilizzano Kubernetes per astrare l'infrastruttura dallo sviluppatore.
In questo articolo abbiamo solo accennato allo stato attuale di Kubernetes: in realtà, è solo la punta dell'iceberg. Gli utenti di Kubernetes hanno a disposizione molte altre risorse, possibilità e configurazioni.
Fonte: habr.com
