Docker meetup :: Kubernetes en Restorando

Kubernetes en Restorando
Migrando 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

Node
Kubelet
Pod Pod Pod
Container Container Container
Node
Kubelet
Pod Pod Pod
Kubernetes basic architecture
Node
Kubelet
Pod Pod Pod
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/v1beta1
kind: Deployment
metadata:
name: wido-web
spec:
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

¿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!

Docker meetup :: Kubernetes en Restorando

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

Docker meetup :: Kubernetes en Restorando

Más contenido relacionado

La actualidad más candente (20)

Destacado (17)

Similar a Docker meetup :: Kubernetes en Restorando (20)

Último (20)

Docker meetup :: Kubernetes en Restorando

Notas del editor