Kubernetes en RestorandoMigrando los primeros servicios

¿Quiénes somos?

Rodrigo Campos

rata

Juan Barreneche

jbarreneche

@jbarreneche

Agenda

● Kubernetes Intro● Primeros pasos con Kubernetes en Restorando

○ Cosas que nos fueron útiles○ Cosas que no, pero encontramos otra forma de hacerlas○ Cosas que nos faltan resolver

Kubernetes features

● Automatic binpacking● Horizontal scaling● Automated rollouts and rollbacks● Storage orchestration● Self-healing● Service discovery and load balancing● Secret and configuration management● Batch execution

NodeKubelet

Pod Pod Pod

Container Container Container

NodeKubelet

Pod Pod Pod

Container Container Container

Kubernetes basic architecture

NodeKubelet

Pod Pod Pod

Container Container Container

Kubernetes Master

¿Qué son los pods?

● Conjunto de 1 o más containers● Estos containers SIEMPRE se colocan en un mismo nodo

○ Modela grupo de apps que se corren en un host

● Comparten IP, namespace de red y storage● Ejemplos

○ File puller + web server: comparten volumen para servir los archivos, reusables por separado

○ App + interfaz con “el mundo exterior”○ En Restorando: nginx, heka y app

Deployments

● Especifica el “template” de los pods● Desired state: típicamente se especifica en un yaml/json● Especificamos y nos asegura (entre otras cosas):

○ Que siempre haya la cantidad de “réplicas” que especificamos■ Si un nodo muere, container crashea, etc.

○ Que los pods estén “vivos” y no reciban tráfico hasta estar listos■ Hay chequeos especiales para esto que veremos más adelante

○ Límites y garantías de recursos (CPU, mem)○ Deploys sin downtime (si queremos)

- name: nginx image: <registry>/nginx:v1.0 readinessProbe: initialDelaySeconds: 5 httpGet: path: /health port: 80 livenessProbe: initialDelaySeconds: 5 httpGet: path: /health port: 80 lifecycle: preStop: exec: command: ["nginx", "-s", "quit"]

apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: wido-webspec: replicas: 1 template: metadata: labels: project: wido role: web containers: - name: app image: <registry>/wido:1.0

Ejemplo de deployment

Hacer un deploy

● Se baja un pod viejo● Se levanta un pod nuevo● No se sigue hasta que está listo para recibir tráfico. Cuando está listo, se

repite hasta N● El nodo lo elige k8s automáticamente, se pueden poner restricciones

○ O hasta crear nuestro propio scheduler y usarlo en su lugar!

¿Y lo de configuration management?

● Otro yaml!● El objeto se llama “configMap”● Se puede montar en un path del fs o usarse como variable de entorno● Hace posible tener una imagen de nginx y correrla con distintas

configuraciones○ En vez de N imágenes

Nuestra experiencia con K8s

¿Por qué el cambio?

● El principal objetivo hoy es que los equipos sean más independientes○ No haya cuello de botella en “operaciones”

○ No coordinar para upgradear la versión de ruby con otros equipos

● Que tengan el control de “todo el stack” minimizando riesgos○ Configuraciones de nginx, etc.

● Que sea igual de fácil que hoy deployear

¿Qué tenemos hoy en k8s?

● Servicios web con HTTP/HTTPS en producción● Los desarrolladores pueden cambiar la config de todo el stack sin miedo

○ Nginx, heka, etc.

● Monitoreo● Interfaz web para que hagan deploy● Builds de imágenes automáticos una vez que se mergea un cambio

○ Auto-deploy on green posible, nadie se anima a usarlo

● La infraestructura manejada con terraform

● K8s crea los ELB de AWS● Pero todavía no permite configurar el cert SSL● Solución:

○ Exponer servicio internamente (dentro de K8s)○ Manejar el ELB por fuera de K8s

Exponer los servicios con ELB y HTTPS

Cambios de config sin miedo

● Es muy fácil tener un “syntax error” al cambiar configuración● Para evitar downtime por errores simples de config:

○ Configuraciones de nginx, heka, etc. con configmaps○ Cambio de configuración = nuevo configmap + deploy○ Si hay error, en un pod no se sigue con el deploy!

● La configuración de la app, por ahora, no usa configmaps○ Facilita la migración y es simple volver en caso de emergencias○ Y porque todavía no lo hicimos super feliz○ Kubernetes hoy no da nada mágico para crearlos/actualizarlos en un deployment

Monitoreo

● Kubernetes viene con grafana+influxdb● Nosotros usabamos signalfx

○ También hicieron un plugin para kubernetes con cAdvisor!

● Creamos un dashboard custom para ver la capacidad libre○ Estandarizamos el tamaño de los pods○ Podemos ver el número de pods disponibles

● Creamos/actualizamos dashboard customs para cada proyecto

Interfaz web para deploy

● Dashboard “built-in” no maneja deployments hoy○ Los va a manejar para v1.3 (beta que sale este viernes ya los maneja!)

● Nosotros usabamos samson (gihub.com/zendesk/samson)● Agregaron un plugin para kubernetes y seguimos con la misma interfaz!

○ Ellos también están migrando todo a kubernetes○ Les mandamos algunos parches (plugin ECR) y la estamos usando

● DEMO!

Lo que falta/Lo que viene

● Canary deployments○ Trivial con otro deployment con distintos labels!

● Hacer el cluster multi-zone○ Kubernetes ya lo soporta!

● Agregar jobs a samson (pronto)● Automatizar upgrade de nodos (pronto)● Migrar el gran “monolito”● Desarrollo local integrado con service-discovery, etc.

¿Preguntas?

¡Gracias!Nos encantaría compartir experiencias con kubernetes:

Rodrigo Campos: rodrigo.campos@restorando.com, rodrigo@sdfg.com.ar

Juan Barreneche: jbarreneche@restorando.com

Links interesantes

● Borg, Omega, and Kubernetes: Lessons learned from three container-management systems over a decade

○ http://queue.acm.org/detail.cfm?id=2898444● Curso online

○ https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615● KubeCon EU 2016

○ https://www.youtube.com/watch?v=Wyl4O3CHzV0● Query Kubernetes API objects using SQL

○ https://github.com/brendandburns/ksql