Hola Habr!
A finals d'estiu us volem recordar que seguim treballant el tema i va decidir publicar un article de Stackoverflow que demostra l'estat de coses d'aquest projecte a principis de juny.
Gaudeix de llegir
En el moment d'escriure aquest article, l'edat de Kubernetes és d'aprox. , i durant els darrers dos anys la seva popularitat ha crescut tant que se'l va classificar constantment plataformes. Kubernetes ocupa el tercer lloc aquest any. Per resumir: Kubernetes és una plataforma dissenyada per executar i orquestrar càrregues de treball en contenidors.
Els contenidors van començar com un disseny especial per aïllar processos a Linux; els contenidors s'han inclòs des del 2007 , i des de 2002 - espais de noms. Els contenidors es van dissenyar encara millor el 2008, quan va estar disponible , i Google va desenvolupar el seu propi mecanisme corporatiu intern anomenat , on "tot el treball es fa en contenidors". Des d'aquí avancem ràpidament fins al 2013, quan es va produir el primer llançament de Docker, i finalment els contenidors es van convertir en una solució popular popular. En aquell moment, l'eina principal per a l'orquestració de contenidors era , tot i que no era molt popular. Kubernetes es va llançar per primera vegada el 2015, després del qual aquesta eina es va convertir en l'estàndard de facto en el camp de l'orquestració de contenidors.
Per intentar entendre per què Kubernetes és tan popular, intentem respondre algunes preguntes. Quan va ser l'última vegada que els desenvolupadors van poder posar-se d'acord sobre com desplegar aplicacions en producció? Quants desenvolupadors coneixeu que utilitzen les eines tal com es proporcionen des de la caixa? Quants administradors de núvol hi ha avui dia que no entenen com funcionen les aplicacions? Veurem les respostes a aquestes preguntes en aquest article.
Infraestructura com a YAML
Al món que va passar de Puppet and Chef a Kubernetes, un dels canvis més importants va ser el pas de "infraestructura com a codi" a "infraestructura com a dades", concretament, com YAML. Tots els recursos de Kubernetes, que inclouen pods, configuracions, instàncies desplegades, volums, etc., es poden descriure fàcilment en un fitxer YAML. Per exemple:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Aquesta vista facilita que els professionals de DevOps o SRE expressin completament les seves càrregues de treball sense haver d'escriure codi en llenguatges com Python o Javascript.
Altres avantatges d'organitzar la infraestructura com a dades inclouen:
- Control de versions de GitOps o Git Operations. Aquest enfocament us permet mantenir tots els fitxers YAML de Kubernetes als repositoris git, de manera que podeu fer un seguiment exacte de quan es va fer un canvi, qui l'ha fet i què ha canviat exactament. Això augmenta la transparència de les operacions a tota l'organització i millora l'eficiència operativa eliminant l'ambigüitat, especialment quan els empleats haurien de buscar els recursos que necessiten. Al mateix temps, és més fàcil fer canvis automàticament als recursos de Kubernetes simplement fusionant una sol·licitud d'extracció.
- Escalabilitat. Quan els recursos es defineixen com a YAML, és molt fàcil per als operadors de clúster canviar un o dos números en un recurs de Kubernetes, canviant així la seva escala. Kubernetes proporciona un mecanisme per a l'escala automàtica horitzontal de pods, que es pot utilitzar per determinar de manera convenient quin és el nombre mínim i màxim de pods necessaris en una configuració de desplegament particular per gestionar nivells baixos i alts de trànsit. Per exemple, si heu desplegat una configuració que requereix capacitat addicional a causa d'un augment sobtat de trànsit, maxReplicas es pot canviar de 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- Seguretat i gestió. YAML és ideal per avaluar com es despleguen les coses a Kubernetes. Per exemple, un problema de seguretat important és si les vostres càrregues de treball s'executen com a usuari no administrador. En aquest cas, potser necessitem eines com ara , validador YAML/JSON, a més , un validador de polítiques per garantir que el context les vostres càrregues de treball no permeten que el contenidor s'executi amb privilegis d'administrador. Si això és necessari, els usuaris poden aplicar una política senzilla , com això:
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- Opcions d'integració amb un proveïdor de núvol. Una de les tendències més destacades de l'alta tecnologia actual és executar càrregues de treball en proveïdors de núvols públics. Utilitzant el component Kubernetes permet que qualsevol clúster s'integri amb el proveïdor de núvol en què s'executa. Per exemple, si un usuari executa una aplicació a Kubernetes a AWS i vol exposar aquesta aplicació mitjançant un servei, el proveïdor de núvol ajuda a crear el servei automàticament
LoadBalancerque proporcionarà automàticament l'equilibrador de càrrega per redirigir el trànsit als pods d'aplicacions.
Expandabilitat
Kubernetes és molt extensible i als desenvolupadors els encanta. Hi ha un conjunt de recursos disponibles com ara pods, desplegaments, StatefulSets, secrets, ConfigMaps, etc. És cert que els usuaris i desenvolupadors poden afegir altres recursos al formulari .
Per exemple, si volem definir un recurs CronTab, llavors podríeu fer alguna cosa com això:
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
Més tard podem crear un recurs CronTab com això:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Una altra opció per a l'extensibilitat a Kubernetes és que el desenvolupador pugui escriure les seves pròpies declaracions. és un procés especial al clúster de Kubernetes que funciona segons el "" Amb l'ajuda d'un operador, l'usuari pot automatitzar la gestió de CRD (definicions de recursos personalitzades) intercanviant informació amb l'API de Kubernetes.
Hi ha diverses eines a la comunitat que faciliten als desenvolupadors la creació dels seus propis operadors. Entre ells - i . Aquest SDK proporciona una base a partir de la qual un desenvolupador pot començar ràpidament a crear un operador. Suposem que podeu començar des de la línia d'ordres alguna cosa com això:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorAixò crea tot el codi estàndard per al vostre operador, inclosos els fitxers YAML i el codi 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.goA continuació, podeu afegir les API i el controlador necessaris, com aquest:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceAleshores, finalment, munta l'operador i envia'l al registre del teu contenidor:
$ operator-sdk build your.container.registry/youruser/myapp-operator
Si el desenvolupador vol encara més control, es pot canviar el codi boilerplate dels fitxers Go. Per exemple, per modificar les especificitats del controlador, podeu fer canvis al fitxer controller.go.
Un altre projecte , us permet crear declaracions utilitzant només fitxers YAML declaratius. Per exemple, un operador per a Apache Kafka es definiria aproximadament . Amb ell, podeu instal·lar un clúster Kafka a la part superior de Kubernetes amb només un parell d'ordres:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaI després configureu-lo amb una altra ordre:
$ 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
Innovació
Durant els últims anys, les principals versions de Kubernetes han sortit cada pocs mesos, és a dir, de tres a quatre llançaments importants per any. El nombre de novetats introduïdes en cadascun d'ells no disminueix. A més, no hi ha indicis de desacceleració fins i tot en aquests temps difícils: mireu quina és la situació ara .
Les noves capacitats us permeten agrupar les operacions de manera més flexible en diferents càrregues de treball. A més, els programadors gaudeixen d'un major control quan despleguen aplicacions directament a la producció.
Comunitat
Un altre aspecte important de la popularitat de Kubernetes és la força de la seva comunitat. El 2015, en arribar a la versió 1.0, Kubernetes va ser patrocinat per .
També hi ha diverses comunitats (Grups d'interès especial) centrat a treballar en diferents àrees de Kubernetes a mesura que el projecte evoluciona. Aquests grups estan afegint noves funcions constantment, fent que el treball amb Kubernetes sigui més còmode i còmode.
La Fundació Cloud Native també acull CloudNativeCon/KubeCon, que, en el moment d'escriure, és la conferència de codi obert més gran del món. Normalment se celebra tres cops l'any, reuneix milers de professionals que volen millorar Kubernetes i el seu ecosistema, així com conèixer noves funcions que apareixen cada tres mesos.
A més, Cloud Native Foundation ho té , que, juntament amb els SIG, revisen nous i existents fons centrats en l'ecosistema del núvol. La majoria d'aquests projectes ajuden a millorar els punts forts de Kubernetes.
Finalment, crec que Kubernetes no tindria tant èxit com ho té sense els esforços conscients de tota la comunitat, on la gent s'uneix però al mateix temps acull els nouvinguts al redil.
El futur
Un dels principals reptes que hauran d'afrontar els desenvolupadors en el futur és la capacitat de centrar-se en els detalls del codi en si, i no en la infraestructura en què s'executa. Compleix amb aquestes tendències , que és un dels principals en l'actualitat. Ja existeixen marcs avançats, p. и , que utilitzen Kubernetes per abstraure la infraestructura del desenvolupador.
En aquest article, només hem ratllat la superfície de l'estat actual de Kubernetes; de fet, només és la punta de l'iceberg. Els usuaris de Kubernetes tenen molts altres recursos, capacitats i configuracions a la seva disposició.
Font: www.habr.com