A technical overview of kubernetes (in spanish). We, at Restorando, are running it in production for 6+ months.
This was presented at the AWS meet up, with some other guys talking about other options to run Docker in production on AWS. We talked about kubernetes (what we are using :))
Some animations are not correctly shown here, sorry about that.
4. La idea es desacoplar
● Desacoplar apps de servers
○ Así los podemos tratar como ganado y no como mascotas
○ Más uptime y fácil escalar
○ Aprovechar mejor los recursos (varias apps en un server)
○ La gente de infra se encarga de la infra, la gente de la app se encarga de su app
● Linux desacopla software de las arquitecturas de HW (x86, arm, etc.)
○ Kubernetes la aplicación de la infraestructura
● Provee una capa sobre la que las aplicaciones corren
○ No importa el cloud provider (AWS, Azure, etc.) ni si es bare-metal
○ La aplicación no se entera de lo que hay debajo
○ Puede correr federado entre distintos cloud providers y bare-metal
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. Solo importa el desired state
Desired State Current State
Reconciliation loop
Container A y B corriendo
Container A, B y C corriendo
Borrar C
7. ¿Qué es un Pod?
● (no es así realmente, ya veremos bien)
● Pensemos en un pod como un container al que le definimos cosas
● Al que le definimos:
○ La imagen de docker y versión a correr
○ La memoria que puede usar
○ El CPU que tiene disponible
○ El usuario que lo va a correr, etc.
8. Deployments
● Se usa en lugar de pods
● Encargado de que haya la cantidad que queremos
○ Si un nodo muere, levanta el container en otro
○ Si un nodo levanta con ese pod corriendo, lo matará
● Sabe cuándo los “pods” están listos
○ Hay checkeos “standard” que vamos a ver para esto
● Nos maneja los deploy sin downtime
○ Ya vemos a ver cómo
● Desired state: típicamente se especifica en un yaml/json
10. 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!
11. Servicios: exponer los pods
● Selecciona en base a labels, los pods que se van a exponer
○ Todos los pods con label “project: myapp”
● Se crea entonces (generalmente):
○ Una IP estática que apuntará a los pods que correspondan (load balancing)
○ Un nombre de dns para service discovery
○ Crea load balancer del cloud provider si queremos también
○ Solo se exponen pods que pasen el readiness check
● Comunicación intra-cluster puede ver una IP estática
○ Atrás se hace load balancing y deploys sin downtime fácilmente
○ Los pods se pueden mover de un nodo a otro Y el servicio re-routea
○ Es decir, desacopla
12. Servicios y deploy
my-app
Ver: 0.1
Labels:
project: my-app
my-app
Ver: 0.1
Labels:
project: my-app
Deployment: My app
version=0.1, replicas=2
Service: My app
matchLabels: project:myapp
14. ¿Qué son los pods realmente?
● Conjunto de 1 o más containers, mínima unidad de deployment
● Modela grupo de apps que se corren en un host
○ SIEMPRE en un mismo nodo
○ Misma IP, namespace de red, IPC entre ellos, etc.
● Idea: desacoplar
○ Tambien separation of concerns, reusable, != CPU/mem limits, monitoreo preciso
● Ejemplos
○ File puller + web server: comparten volumen para los archivos
○ Mysql + adapter de phometheus
○ App + interfaz con “el mundo exterior”
○ En Restorando: nginx, heka y app
17. Kubernetes features
● Automatic binpacking
● Horizontal autoscaling
● Cluster autoscaling
● Automated rollouts and rollbacks
● Storage orchestration
○ Dynamic volume provisioning
● Self-healing
● Service discovery and load balancing
● Secret and configuration management
● Batch and scheduled execution
● Canary deployments
● Container runtime independant
○ Docker, Rocket, Hyper, etc.
● Run Stateful and stateless apps
● Federated
● Extensible (3rd party API)
● Operators (recién anunciados por CoreOS)
● Hosted on Google cloud and Azure
● Minikube para correr local
● Partners y enterprise support
○ Training, certification and KMSP program
● Kubernetes on kubernetes (kaboom!)
● Viene con UI!
● Integraciones con todo lo que
necesitamos nosotros
○ SignalFX, Samson, AWS, etc.
18. No free meal
● Un layer de abstracción más
○ Hay que entenderlo, etc.
● Containers (docker o cualquiera) se meten mucho con el OS
○ Problemas en esa capa probablemente implican lidiar con el kernel
○ Todo bien cuando funcionan, pero cuando no? No es tan fácil
● Resolver el monitoreo
○ Prometheus, Integraciones con servicios hosted. Viene con cadvisor
○ Más cosas para monitorear: hosts, containers, kubernetes, cantidad de pods app X, etc.
● Cambia, quizás, la forma de deploy
○ Nosotros usabamos una interfaz web, open source, que agregó soporte
○ En general MUCHAS cosas tienen soporte para k8s
19. 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 (muy básico, pero simple y rápido de hacer)
○ https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
○ https://training.linuxfoundation.org/linux-courses/system-administration-training/kuberne
tes-fundamentals
● Operators
○ https://coreos.com/blog/introducing-operators.html
○ https://coreos.com/blog/introducing-the-etcd-operator.html
● KubeCon EU 2016 (viejo ya, tipo 3 releases desde eso)
○ https://www.youtube.com/watch?v=Wyl4O3CHzV0
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
Docker es solo una parte de la foto. Sin un orchestrator, tenemos más problemas que soluciones
Master con etcd. Nodos iguales con “kubelet” y pods
Crear un container es solo modificar el desired state, el reconciliation loop se encarga de crearlo al ver la diferencia.
Esto es el principio de self-healing
Los checkeos: un pod se asigna a un nodo, se baja la imagen de docker, se la levanta, levanta el interprete, etc. Todo lleva tiempo, hasta ese momento no queremos que reciba tráfico, queremos saber cuando ya están “listos”
Desired state, describe lo que queremos, no cómo hacerlo
El readiness y liveness acá es igual, podrían ser distintos (probar que estén todas las dependencias up, por ejemplo db)
Acá son un httpget, pueden ser ejecutar un comando en el container, conectarse por TCP nomás.
Muy flexible y configurable
Todo tiene labels pero muchos los saqué por espacio
Con esto vimos:
Automatic binpacking Y los puertos no conflictuan!
Horizontal scaling (hay automatico tambien!)
Automated rollouts and rollbacks
Self-healing
Pensar en pod como mínima unidad para escalar
Los puertos con otros pods no conflictuan porque cada uno tiene su IP!
Sidecar: extend and enhance the "main" container (primer ejemplo)
Ambassador containers: container que splits read/writes y se conecta a redis
Adapter containers: interfaz con el mundo exterior
Kubernetes está hecho con microservicios, todas las partes son reemplazables e integrables con otros
Automatic Horizonatal Scaling