Ciao, Habr!
Alla fine dell'estate vogliamo ricordare che stiamo continuando a lavorare sul tema 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à è aumentata così tanto che è costantemente tra le Quest'anno, Kubernetes occupa il terzo posto. Ricordiamo: Kubernetes è una piattaforma progettata per l'esecuzione e l'orchestrazione di carichi di lavoro in container.
I container sono nati come una costruzione speciale per isolare i processi in Linux; dal 2007 i container includono , e dal 2002 i namespace. I container si sono evoluti ulteriormente nel 2008, quando è stata resa disponibile , mentre in Google hanno sviluppato il loro meccanismo interno chiamato , dove "tutto il lavoro avviene nei container." Ci spostiamo quindi nel 2013, quando è stata rilasciata la prima versione di Docker, e i container sono definitivamente entrati nel novero delle soluzioni popolari di massa. All'epoca, lo strumento principale per l'orchestrazione dei container era , anche se non godeva di una popolarità sfrenata. La prima versione di Kubernetes è stata rilasciata nel 2015, dopo di che questo strumento è diventato de facto lo standard nel campo dell'orchestrazione dei container.
Per cercare di capire perché Kubernetes sia così popolare, cerchiamo di rispondere a qualche domanda. Quando è stata l'ultima volta che gli sviluppatori sono riusciti a trovare un accordo su come distribuire le applicazioni in produzione? Quanti sviluppatori conoscete che utilizzano gli strumenti così come vengono forniti "out of the box"? Quanti oggi sono gli amministratori di cloud che non capiscono come funzionano le applicazioni? Le risposte a queste domande verranno esaminate in questo articolo.
Infrastruttura come YAML
Nel mondo, che da Puppet e Chef è passato a Kubernetes, uno dei cambiamenti più grandi è 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, ecc., 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 impostazione, per i professionisti di DevOps o SRE è più facile esprimere completamente i propri carichi di lavoro, senza dover scrivere codice in lingue come Python o Javascript.
Altri vantaggi dell'organizzazione dell'infrastruttura dei dati, in particolare, sono:
- GitOps, o controllo delle versioni delle operazioni Git. Questo approccio consente di mantenere tutti i file YAML di Kubernetes nei repository git, permettendo di tracciare esattamente quando è stata effettuata una modifica, chi l'ha effettuata e cosa è esattamente cambiato. Ciò aumenta la trasparenza delle operazioni all'interno dell'intera organizzazione e migliora l'efficienza del lavoro eliminando ambiguità, in particolare riguardo a dove i dipendenti devono cercare le risorse di cui hanno bisogno. Allo stesso tempo, diventa più semplice apportare automaticamente modifiche alle risorse Kubernetes, tramite una normale fusione di pull request.
- Scalabilità. Quando le risorse sono definite come YAML, agli operatori del cluster diventa estremamente semplice modificare uno o due numeri nella risorsa Kubernetes, cambiando così i principi della sua scalabilità. Kubernetes prevede un meccanismo per l'autoscalamento orizzontale dei pod, che consente di definire facilmente qual è il numero minimo e massimo di pod richiesti in una particolare configurazione distribuita per gestire livelli di traffico bassi o alti. Ad esempio, se hai distribuito una configurazione che richiede ulteriori risorse a causa di un improvviso aumento del 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 è particolarmente adatto per valutare come certe cose vengono distribuite in Kubernetes. Ad esempio, una seria preoccupazione riguardante la sicurezza è se i tuoi carichi di lavoro vengano eseguiti da un utente che non ha diritti di amministratore. In questo caso, strumenti come possono tornare utili , un validatore YAML/JSON, più , un validatore di politiche, che garantisce che il contesto Il carico di lavoro non consente al contenitore di funzionare con privilegi da amministratore. Se questo deve essere garantito, gli utenti possono applicare una semplice policy , 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 è l'esecuzione dei carichi di lavoro sulle risorse dei fornitori di cloud pubblici. Con il componente Kubernetes consente a qualsiasi cluster di integrarsi con il fornitore di cloud su cui è in esecuzione. Ad esempio, se un utente ha avviato un'applicazione in Kubernetes su AWS e desidera aprire l'accesso a quest'applicazione attraverso un servizio, il fornitore di cloud aiuta a creare automaticamente un servizio
LoadBalancer, che fornirà automaticamente un bilanciatore di carico , per reindirizzare il traffico ai pod delle applicazioni.
Scalabilità
Kubernetes è molto scalabile, e questo piace agli sviluppatori. Esiste un insieme di risorse disponibili, come pod, deployment, StatefulSets, segreti, ConfigMaps, ecc. Infatti, gli utenti e gli sviluppatori possono aggiungere altre risorse sotto forma di .
Ad esempio, se vogliamo 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 di scalabilità in Kubernetes è che lo sviluppatore può scrivere i propri operatori. è un processo speciale nel cluster Kubernetes, che segue il modello del "". Con l'operatore, l'utente può automatizzare la gestione delle CRD (definizioni delle risorse personalizzate), scambiando informazioni con l'API di Kubernetes.
Nella community ci sono diversi strumenti attraverso i quali gli sviluppatori possono facilmente creare i propri operatori. Tra questi c'è e i suoi . Questo SDK fornisce una base da cui lo sviluppatore può iniziare a creare un operatore molto rapidamente. Ad esempio, si può iniziare dalla riga di comando in questo modo:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorIn questo modo si crea tutto il codice di base per il tuo operatore, inclusi 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.goPoi si possono 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=MyAppServiceDopo di che, infine, si compila l'operatore e lo si invia al registro del tuo container:
$ operator-sdk build your.container.registry/youruser/myapp-operator Se lo sviluppatore ha bisogno di un controllo ancora più completo, può modificare il codice di base nei file Go. Ad esempio, per modificare le specifiche del controller, si possono 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 può essere definito in questo modo . Con esso si può installare un cluster Kafka sopra Kubernetes con poche righe di comando:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaE poi configurarlo con un altro 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, grandi versioni di Kubernetes sono state rilasciate ogni pochi mesi, ovvero tre o quattro grandi versioni all'anno. Il numero di nuove funzionalità introdotte in ognuna di esse non diminuisce. Inoltre, non ci sono segni di rallentamento nemmeno nei nostri tempi difficili: guardate com'è adesso .
Nuove opportunità consentono di clusterizzare le operazioni in modo più flessibile in presenza di carichi di lavoro diversi. Inoltre, agli sviluppatori piace avere un controllo più completo nel distribuire le applicazioni direttamente in produzione.
La comunità
Un altro aspetto serio della popolarità di Kubernetes risiede nella forza della sua comunità. Nel 2015, al raggiungimento della versione 1.0, Kubernetes è stato sponsorizzato .
Esistono anche diverse comunità (special interest groups), mirate a esplorare diverse aree di Kubernetes man mano che questo progetto si sviluppa. Questi gruppi aggiungono costantemente nuove funzionalità, rendendo l'utilizzo di Kubernetes sempre più comodo.
La Cloud Native Foundation organizza anche 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, così come di apprendere nuove funzionalità che emergono ogni tre mesi.
Inoltre, nella Cloud Native Foundation c'è , che, insieme agli SIG, analizza nuovi e attuali della fondazione focalizzati sull'ecosistema cloud. La maggior parte di questi progetti contribuisce a migliorare i punti di forza di Kubernetes.
Infine, credo che Kubernetes non avrebbe avuto tale successo senza il costante impegno dell'intera comunità, dove le persone si sostengono a vicenda, ma, allo stesso tempo, accolgono volentieri i nuovi arrivati.
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 è uno dei più avanzati. Esistono già framework avanzati, come e , che utilizzano Kubernetes per astrarre l'infrastruttura dallo sviluppatore.
In questo articolo abbiamo solo brevemente esaminato lo stato attuale di Kubernetes: in realtà, è solo la punta dell'iceberg. Gli utenti di Kubernetes hanno a disposizione anche molte altre risorse, opportunità e configurazioni.
Fonte: habr.com
