Al final del verano, queremos recordarles que seguimos trabajando en el tema de Kubernetes y decidimos publicar un artículo sobre Stackoverflow demostrando el estado de cosas en este proyecto a principios de junio.
¡Disfruta leyendo!
En el momento de escribir este artículo, Kubernetes tiene aproximadamente seis años y su popularidad ha aumentado en los últimos dos años y se ha clasificado constantemente entre las plataformas más favorecidas . Kubernetes ocupa el tercer lugar este año. Como recordatorio, Kubernetes es una plataforma para ejecutar y orquestar cargas de trabajo en contenedores.
Los contenedores se originaron como una construcción especial para el aislamiento de procesos en Linux; Los contenedores han sido cgroups desde 2007 y espacios de nombres desde 2002. Los contenedores tomaron forma aún mejor en 2008, cuando LXC estuvo disponible , y Google desarrolló su propio mecanismo interno llamado Borg.donde “todo el trabajo se realiza en contenedores”. A partir de aquí, avance rápido hasta 2013, cuando tuvo lugar el primer lanzamiento de Docker, y los contenedores finalmente pasaron a la categoría de soluciones masivas populares. En ese momento, Mesos era la principal herramienta para orquestar contenedores , aunque no era muy popular. El primer lanzamiento de Kubernetes tuvo lugar en 2015, después de lo cual esta herramienta se convirtió en el estándar de facto en el campo de la orquestación de contenedores.
Para intentar comprender por qué Kubernetes es tan popular, intentemos responder algunas preguntas. ¿Cuándo fue la última vez que los desarrolladores pudieron ponerse de acuerdo sobre cómo implementar aplicaciones en producción? ¿Cuántos desarrolladores conoces que utilizan herramientas tal como se proporcionan de fábrica? ¿Cuántos administradores de la nube hay hoy en día que no entienden cómo funcionan las aplicaciones? Consideraremos las respuestas a estas preguntas en este artículo.
Infraestructura como YAML
En el mundo que pasó de Puppet and Chef a Kubernetes, uno de los mayores cambios ha sido el paso de la infraestructura como código a la infraestructura como datos, específicamente como YAML. Todos los recursos de Kubernetes, que incluyen pods, configuraciones, instancias implementadas, volúmenes, etc., se pueden describir fácilmente en un archivo YAML. Por ejemplo:
apiVersion: v1
kind: Pod
metadata:
name: site
labels:
app: web
spec:
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80Esta vista facilita que DevOps o SRE expresen por completo sus cargas de trabajo sin tener que escribir código en lenguajes como Python o Javascript.
Otras ventajas de organizar la infraestructura como datos, en particular, son las siguientes:
- GitOps Git Operations Version. YAML- Kubernetes git, , , , . , , , , . , Kubernetes – pull-.
- . YAML, Kubernetes, . Kubernetes , , , , . , , - , maxReplicas 10 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- . YAML , Kubernetes. , , , , - , . conftest, YAML/JSON, Open Policy Agent, , , SecurityContext . , rego, :
package main
deny[msg] {
input.kind = "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot = true
msg = "Containers must not run as root"
}- . – . cloud-provider Kubernetes , . , Kubernetes AWS ,
LoadBalancer, Amazon Elastic Load Balancer, .
Kubernetes es muy extensible y a los desarrolladores les encanta. Hay una colección de recursos disponibles, como vainas, barridos,
StatefulSetssecretos ConfigMaps, etc. Sin embargo, los usuarios y desarrolladores pueden agregar otros recursos en forma de definiciones de recursos personalizadas .
Por ejemplo, si quisiéramos definir un recurso
CronTab, podríamos hacer algo como esto:
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 tarde, podemos crear un recurso CronTab similar a esto:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Otra opción de extensibilidad en Kubernetes es que el desarrollador puede escribir sus propios operadores. Un operador es un proceso especial en un clúster de Kubernetes que opera en un patrón de " bucle de control " . Con la ayuda de un operador, el usuario puede automatizar la gestión de CRD (definiciones de recursos personalizadas) intercambiando información con la API de Kubernetes.
Hay varias herramientas en la comunidad que facilitan a los desarrolladores la creación de sus propios operadores. Entre ellos se encuentran Operator Framework y su Operator SDK . Este SDK proporciona un marco desde el cual un desarrollador puede comenzar a crear una declaración muy rápidamente. Digamos que puede comenzar desde la línea de comando algo como esto:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorEsto crea todo el código estereotipado para su operador, incluidos los archivos YAML y el código 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.goLuego, puede agregar la API y el controlador que desee, así:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceLuego, finalmente, recoge el operador y envíalo al registro de tu contenedor:
$ operator-sdk build your.container.registry/youruser/myapp-operatorSi el desarrollador necesita aún más control, puede cambiar el código estereotipado en los archivos Go. Por ejemplo, para modificar las especificaciones del controlador, puede realizar cambios en el archivo
controller.go.
Otro proyecto, KUDO , le permite crear declaraciones utilizando solo archivos YAML declarativos. Por ejemplo, un operador para Apache Kafka se definiría así . Con él, puede instalar un clúster de Kafka sobre Kubernetes con solo un par de comandos:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaY luego configúrelo con otro 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
Innovación
Durante los últimos años, las principales versiones de Kubernetes se han lanzado cada pocos meses, es decir, de tres a cuatro versiones principales por año. El número de nuevas funcionalidades implementadas en cada uno de ellos no disminuye. Además, no hay signos de desaceleración incluso en nuestros tiempos difíciles: observe la actividad actual del proyecto Kubernetes en Github .
Las nuevas capacidades le permiten agrupar operaciones de manera más flexible en una variedad de cargas de trabajo. Además, a los programadores les gusta tener más control al implementar aplicaciones directamente en producción.
Comunidad
Otro aspecto importante de la popularidad de Kubernetes es la fuerza de su comunidad. En 2015, al alcanzar la versión 1.0, Kubernetes fue patrocinado por Cloud Native Computing Foundation .
También hay una variedad de comunidades SIG (Grupos de interés especial) que se centran en diferentes áreas de Kubernetes a medida que evoluciona el proyecto. Estos grupos agregan constantemente nuevas funciones para que trabajar con Kubernetes sea más conveniente y conveniente.
Cloud Native Foundation también alberga CloudNativeCon / KubeCon, que es la conferencia de código abierto más grande del mundo en el momento de escribir este artículo. Normalmente, se lleva a cabo tres veces al año y reúne a miles de profesionales que quieren mejorar Kubernetes y su ecosistema, así como dominar las nuevas funciones que aparecen cada tres meses.
Además, Cloud Native Foundation cuenta con un Comité de Supervisión Técnica que, junto con los SIG, revisa los proyectos nuevos y existentes de la fundación enfocados en el ecosistema de la nube. La mayoría de estos proyectos ayudan a mejorar las fortalezas de Kubernetes.
Finalmente, creo que Kubernetes no habría tenido tanto éxito sin los esfuerzos deliberados de toda la comunidad, donde las personas se aferran unas a otras, pero al mismo tiempo, aceptan con gusto a los recién llegados en sus filas.
Futuro
Uno de los principales desafíos a los que los desarrolladores tendrán que enfrentarse en el futuro es la capacidad de centrarse en los detalles del código en sí, en lugar de en la infraestructura en la que opera. Es a estas tendencias a las que responde el paradigma de la arquitectura sin servidor , que es uno de los principales en la actualidad. Ya existen marcos avanzados como Knative y OpenFaas que usan Kubernetes para abstraer la infraestructura del desarrollador.
En este artículo, solo hemos echado un vistazo al estado actual de Kubernetes; de hecho, esto es solo la punta del iceberg. Los usuarios de Kubernetes tienen muchos otros recursos, capacidades y configuraciones a su disposición.