Presentamos en la meetup de docker nuestra experiencia (hasta ahora, junio 2016) con kubernetes. Al principio se introduce los conceptos básicos de kubernetes y luego contamos nuestra experiencia y workaround para obtener alguna funcionalidad.

1. Kubernetes en Restorando
Migrando los primeros servicios

2. ¿Quiénes somos?
Rodrigo Campos
rata
Juan Barreneche
jbarreneche
@jbarreneche

3. 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

4. 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

5. Node
Kubelet
Pod Pod Pod
Container Container Container
Node
Kubelet
Pod Pod Pod
Container Container Container
Kubernetes basic architecture
Node
Kubelet
Pod Pod Pod
Container Container Container
Kubernetes
Master

6. ¿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

7. 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)

8. - 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

9. 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!

10. ¿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

11. Nuestra experiencia con K8s

12. ¿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

13. ¿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

14. ● 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

15. 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

16. 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

17. 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!

19. 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.

20. ¿Preguntas?
¡Gracias!
Nos encantaría compartir experiencias con kubernetes:
Rodrigo Campos: rodrigo.campos@restorando.com, rodrigo@sdfg.com.ar
Juan Barreneche: jbarreneche@restorando.com

21. 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