¡Hola, Habr!
A finales de verano, queremos recordar que seguimos trabajando en el tema y hemos decidido publicar un artículo de Stackoverflow que muestra el estado actual de este proyecto a principios de junio.
¡Disfruta la lectura!
Al momento de redactar este artículo, la edad de Kubernetes es de aproximadamente , y en los últimos dos años, su popularidad ha crecido tanto que constantemente se encuentra entre las Este año, Kubernetes ocupa el tercer lugar. Recordemos: Kubernetes es una plataforma diseñada para ejecutar y orquestar cargas de trabajo en contenedores.
Los contenedores surgieron como una construcción especial para aislar procesos en Linux; desde 2007, los contenedores incluyen , y desde 2002, espacios de nombres. Los contenedores se consolidaron aún más en 2008, cuando se volvió accesible , y en Google se desarrolló un mecanismo interno llamado , donde 'todo el trabajo se realiza en contenedores'. Retrocedamos a 2013, cuando se lanzó la primera versión de Docker, y los contenedores finalmente se convirtieron en soluciones masivas populares. En ese momento, la herramienta principal para orquestar contenedores era , aunque no gozaba de gran popularidad. La primera versión de Kubernetes se lanzó en 2015, después de lo cual esta herramienta se convirtió en el estándar de facto en el ámbito de la orquestación de contenedores.
Para intentar entender por qué Kubernetes es tan popular, tratemos de responder algunas preguntas. ¿Cuándo fue la última vez que los desarrolladores lograron llegar a un acuerdo sobre cómo desplegar aplicaciones en producción? ¿Cuántos desarrolladores conocen que utilizan herramientas tal como se proporcionan 'de fábrica'? ¿Cuántos administradores de la nube hoy en día no entienden cómo funcionan las aplicaciones? Analizaremos las respuestas a estas preguntas en este artículo.
Infraestructura como YAML
En un mundo que ha pasado de Puppet y Chef a Kubernetes, uno de los cambios más significativos fue el paso de 'infraestructura como código' a 'infraestructura como datos' — específicamente, como YAML. Todos los recursos en Kubernetes, que incluyen pods, configuraciones, instancias desplegadas, volúmenes, etc., pueden describirse 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: 80Con esta representación, los especialistas en DevOps o SRE pueden expresar completamente sus cargas de trabajo sin necesidad de escribir código en lenguajes como Python o Javascript.
Otros beneficios de organizar la infraestructura de datos son:
- GitOps o control de versiones de Git Operations Version. Este enfoque permite mantener todos los archivos YAML de Kubernetes en repositorios git, lo que permite rastrear exactamente cuándo se realizó un cambio, quién lo realizó y qué exactamente se modificó. Esto aumenta la transparencia de las operaciones dentro de toda la organización y mejora la eficiencia al eliminar ambigüedades, particularmente en cuanto a dónde deben buscar los empleados los recursos que necesitan. Al mismo tiempo, se hace más fácil realizar automáticamente cambios en los recursos de Kubernetes mediante una simple fusión de pull requests.
- Escalabilidad. Cuando los recursos se definen en forma de YAML, a los operadores del clúster les resulta extremadamente sencillo modificar uno o dos números en el recurso de Kubernetes, cambiando así sus principios de escalado. Kubernetes cuenta con un mecanismo para el escalado automático horizontal de pods, mediante el cual se puede definir fácilmente cuántos pods mínimos y máximos se requieren en una configuración desplegada específica para manejar volúmenes de tráfico bajos y altos. Por ejemplo, si has desplegado una configuración que necesita más recursos debido a un repentino aumento de tráfico, puedes cambiar el parámetro maxReplicas 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- Seguridad y gestión. YAML es excelente para evaluar cómo se despliegan ciertas cosas en Kubernetes. Por ejemplo, un problema serio relacionado con la seguridad es si tus cargas de trabajo se están ejecutando bajo un usuario sin privilegios de administrador. En este caso, herramientas como , un validador YAML/JSON, más , un validador de políticas, que asegura que el contexto Las cargas de trabajo de su entorno no permiten que el contenedor funcione con privilegios de administrador. Si es necesario, los usuarios pueden aplicar una política simple , de esta manera:
paquete principal
denegar[msg] {
input.kind = "Despliegue"
no input.spec.template.spec.securityContext.runAsNonRoot = verdadero
msg = "Los contenedores no deben ejecutarse como root"
}- Opciones de integración con el proveedor de la nube. Una de las tendencias más notables en las tecnologías modernas es ejecutar cargas de trabajo en las instalaciones de proveedores de nube pública. A través del componente Kubernetes permite que cualquier clúster se integre con el proveedor de nube en el que se está ejecutando. Por ejemplo, si un usuario ha implementado una aplicación en Kubernetes en AWS y desea acceder a esta aplicación a través de un servicio, el proveedor de nube ayuda a crear automáticamente el servicio
LoadBalancer, que proporcionará automáticamente un equilibrador de carga , para redirigir el tráfico a los pods de las aplicaciones.
Escalabilidad
Kubernetes se escala muy bien, y a los desarrolladores les gusta eso. Existe un conjunto de recursos disponibles, como pods, despliegues, StatefulSets, secretos, ConfigMaps, etc. Sin embargo, los usuarios y desarrolladores pueden añadir otros recursos en forma de .
Por ejemplo, si queremos 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
Luego podemos crear un recurso CronTab de manera similar a esta:
apiVersion: "my.org/v1"
kind: CronTab
metadata:
name: my-cron-object
spec:
cronSpec: "* * * * */5"
image: my-cron-image
replicas: 5
Otra forma de escalabilidad en Kubernetes es que el desarrollador puede escribir sus propios operadores. – es un proceso especial en el clúster de Kubernetes que sigue el patrón de "". Con el operador, el usuario puede automatizar la gestión de CRD (definiciones de recursos personalizadas), intercambiando información con la API de Kubernetes.
En la comunidad hay varias herramientas que facilitan a los desarrolladores crear sus propios operadores. Entre ellas está y su . Este SDK proporciona una base a partir de la cual el desarrollador puede comenzar a crear rápidamente un operador. Por ejemplo, se puede empezar desde la línea de comandos así:
$ operator-sdk new my-operator --repo github.com/myuser/my-operatorAsí se crea todo el código estereotipado para su operador, incluyendo archivos YAML y código en 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 se pueden añadir las API y el controlador necesarios, así:
$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService
$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppServiceDespués, finalmente, compila el operador y súbelo al registro de tu contenedor:
$ operator-sdk build your.container.registry/youruser/myapp-operator Si el desarrollador necesita un control aún más completo, puede modificar el código estereotipado en los archivos Go. Por ejemplo, para cambiar la especificidad del controlador, se pueden hacer modificaciones en el archivo controller.go.
Otro proyecto, , permite crear operadores usando solo archivos YAML declarativos. Por ejemplo, un operador para Apache Kafka se definiría más o menos así . Con él, se puede instalar un clúster de Kafka sobre Kubernetes con sólo un par de comandos:
$ kubectl kudo install zookeeper
$ kubectl kudo install kafkaY luego configurarlo 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
Innovaciones
En los últimos años, las grandes versiones de Kubernetes se lanzan cada pocos meses, es decir, de tres a cuatro grandes lanzamientos al año. La cantidad de nuevas características implementadas en cada una de ellas no disminuye. Además, no se observan signos de desaceleración incluso en nuestros tiempos difíciles: miren cuál es la .
Las nuevas capacidades permiten una mayor flexibilidad en la agrupación de operaciones al enfrentar diversas cargas de trabajo. Además, a los programadores les gusta tener un control más completo al desplegar aplicaciones directamente en producción.
Comunidad
Otro aspecto importante de la popularidad de Kubernetes radica en la fuerza de su comunidad. En 2015, cuando alcanzó la versión 1.0, Kubernetes fue patrocinado .
También existen diversas comunidades (grupos de interés especiales) que se enfocan en diferentes áreas de Kubernetes a medida que este proyecto se desarrolla. Estos grupos continuamente agregan nuevas capacidades, lo que hace que trabajar con Kubernetes sea cada vez más cómodo.
La Cloud Native Foundation también lleva a cabo CloudNativeCon/KubeCon, que, al momento de escribir este texto, es la mayor conferencia de código abierto en el mundo. Generalmente se celebra tres veces al año y reúne a miles de profesionales que desean mejorar Kubernetes y su ecosistema, así como dominar nuevas capacidades que surgen cada tres meses.
Además, en la Cloud Native Foundation hay , que, junto con los SIGs, revisa nuevos y existentes proyectos 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 tendría tanto éxito sin los esfuerzos conscientes de toda la comunidad, donde la gente se apoya mutuamente, pero al mismo tiempo, recibe con gusto a los nuevos miembros.
El futuro
Uno de los principales desafíos que los desarrolladores tendrán que enfrentar en el futuro es la habilidad de enfocarse en los detalles del propio código, y no en la infraestructura en la que opera. Precisamente estas tendencias son respondidas por , que hoy en día es una de las más prominentes. Ya existen frameworks avanzados, como y , que utilizan Kubernetes para abstraer la infraestructura del desarrollador.
En este artículo solo hemos esbozado el estado actual de Kubernetes; en realidad, esto es solo la punta del iceberg. Los usuarios de Kubernetes también tienen a su disposición muchos otros recursos, capacidades y configuraciones.
Fuente: habr.com
