Despliegues controlados

Clase 22 de 33 • Curso de Kubernetes (2019)

Contenido del curso

Introducción a Kubernetes

Primer contacto con un cluster de kubernetes

Balanceo de carga y service discovery

Escalando nuestra aplicación

Optimizando el uso de nuestro cluster

Autorización y Namespaces

Fin del curso

32
Recomendaciones para implementar Kubernetes en tu organización o proyectos
10:16 min

Bonus

33
Clase en vivo: workflows de Kubernetes usando git
09:38 min

Tomar examen

Comentarios

Matías Luzzani

student•

Como usar la estrategia de rolling upgrades para desplegar nuevas versiones, minimizando el impacto a nuestros usuarios: Kubectl get deploy –o json: el output de todos los deployments que tenemos en nuestro sitio Kubectl get deploy –o json | jq “{name:.metadata.name} + .spec.strategy.rollingUpdate": itera sobre los ítems y trae de la metadata la estrategia del rollingupdate default. Esto va a mostrar los diferentes servicios. MAX SURGE: cuantos pods se crean a partir de los que tengo, o sea que si hay 100 hasta 25 pods pueden estar creándose al mismo momento por default MAX UNAVAILABLE: a lo sumo puede haber, en un determinado momento del deploy, un 25% de mis pods no disponibles por default.

Hacemos el rolling upgrade de la aplicación: kubectl set image deploy worker worker=dockercoins/worker:v0.2 Cambiamos la imagen del deploy y le decimos que worker tenga la imagen dockercoins/worker:0.2

Si le mandamos una imagen que no existe o está rota, va a mantener un minimo de 25% de los nodos trabajando como antes y asi no interrumpir el funcionamiento del servicio. Con kubectl rollout undo deploy worker hacemos un rollback a la versión anterior.

Para cambiar la estrategia de deployment: Kubectl edit deploy worker Si pongo maxsurge en 1, solo se va a crear como maximo un pod nuevo por cada nuevo deployment. Si pongo maxunavailable en 0, no van a haber pods unavailables a la hora de hacer deployments. Esta estrategia es bastante conservadora: quiero crear de a uno y hasta que ese no este disponible, no cambiar nada.

Amaury Centeno Arias

student•

Muchas gracias amigo

Roberto Rivera Salazar

student•

Minuto 2:10 del vídeo.

Primero instala jq, es un procesador JSON de línea de comandos ligero y flexible.

$ sudo apt-get install jq -y

Después, deberían poder ejecutar este comando sin problemas:

$ kubectl get deploy -o json | jq ".items[] | {name:.metadata.name} + .spec.strategy.rollingUpdate"

Gerardo Alberto Soto Alvarez del Castillo

student•

Pregunta de examen [Platzi & K8s]:

++maxSurge:++ es un campo opcional que ++indica el número máximo de Pods que pueden crearse por encima del numero deseado de Pods,++ si tengo 100 Pods y se empieza a actualizar con un 25%, puedo tener en un momento hasta 125 Pods (25 Pods eliminandose ++y/o++ 25 Pods creandose y 75 Pods normales).

++maxUnavailable++: es un campo opcional que ++indica el número máximo de Pods que pueden no estar disponibles durante el proceso de actualización++ (valor = int | %, if n=0 then n=25%) si tengo 100 Pods, y se empieza a actualizar la aplicación, con un 25%, tendré 75% de los Pods siempre funcionando. (25 Pods no disponibles)

Por lo tanto, si se combinan maxSurge y maxUnavailable, siempre se tendrán 50 Pods disponibles (50% de disponibilidad).

https://kubernetes.io/es/docs/concepts/workloads/controllers/deployment/#despliegue-mediante-actualizaci%C3%B3n-continua . ++Buena Práctica:++ Siempre al hacer un cambio o actualización en un Cluster, verificar que todos los Pods estén en su estado deseado (RUNNING) de lo contrario, es mejor hacer un RollOut y corregir el problema anterior.

Juan Pablo Jiménez Esclusa

student•

Explicación sobre rolling update en Kubernate.io

Sebastian Arca

student•

Esta es la que va ! Lo bueno de hacer el curso es que los conceptos de la documentación no abruman tanto :)

Hector Alexander

student•

ADMINISTRANDO DESPLIEGUES

#Ver deployments
kubectl get deploy -o json

#Actualizar imagen 
kubectl set image deploy <name> worker=<image>:<tag>

#ver deploys
kubectl get replicasets -w

#Editar deploy en tiempo de ejecuccion
kubectl edit deploy <name>

#Realizar en caso de falla
kubectl rollout undo deploy <name>

Jorge Guerrero Garrido

student•

Esta clase es muy buena! Gracias Marcos por esta clase y por el curso, eres un crack! ;) Saludos desde España!

Alberto Gurrion

student•

Caeria super bien una ruta de administracion de aplicaciones en Platzi que hable de estrategias avanzadas de k8s, openshift e Istio (Service Mesh). De cualquier forma este curso actual se ve muy bien. Gracias Marcos Lilljedahl!

Alejandro Parra

student•

que buena clase!

Nestor Julian Murphy

student•

maxUnavailable: máxima cantidad de pods no disponibles. (pods iniciando). Ejemplo con maxUnavailable 25%: De 100 pods, 25 están iniciándose y los demás están disponibles. maxSurge: Cuántos pods puedo crear a partir de los que ya existen. Ejemplo con maxSurge 25%: De 100 pods, 25 pueden estar creándose al mismo tiempo

Los valores de maxUnavailable y maxSurge pueden ser en porcentajes o en cantidades enteras positivas.

William Schnaider Torres Bermon

student•

Download and install JQ:https://stedolan.github.io/jq/download/

Gerardo Alberto Soto Alvarez del Castillo

student•

¿Todos los Pods que se eliminan o que tienen un error como un "ImagePullBackOff" al ser contenedores "dockers" se quedan almacenados en el disco duro del Host, o K8s los elimina por completo?

Julian Lamadrid

student•

Muy buena pregunta. Imagino que debe correr algún tipo de GarbageCollector, pero dejemos que respondan los que saben. En Docker se hacia con la directiva prune.

Angel de Jesus Gaspar Campos

student•

En la clase pasada vimos que para poder colocar un pod por cada nodo se usó el recurso de daemonsets.

¿Es posible tener una estrategia de actualización con maxSurge y maxUnavailable para el recurso de daemonsets? Gracias de antemano.

Josian Francisco Cáceres Suazo

student•

Despliegues Controlados

Es muy común desplegar nuevas versiones en nuestros clusters, lo que se hace es generar una imagen de docker nueva con una nueva versión de nuestro código o un feature nuevo o bugfix, por lo tanto es necesario llevar la nueva versión a nuestro cluster de la manera más fiel posible y si hay un error necesitamos de K8 nos ayude a evitar el despliegue sin tener una versión completa, para poder hacer un rollback y minimizar el impacto a nuestros usuarios

A continuación se muestra la estrategía rolling upgrates, que es el mecanismos que Kubernetes utiliza para actualizar nuestra aplicación usando los parámetros maxSurge y maxUnavailable

Se listan los diferentes servicios que están desplegados en nuestro cluster

En este ejemplo tenemos el servicio “hasher”, el maxUnavailable significa que a lo sumo puede haber un 25% en un determinado momento del deploy que nuestros nodos no estén disponibles, por lo tanto tendremos un 75% disponibles para responder al tráfico.
El maxSurge quiere decir cuantos Pods se crean a partir de los que tengo, es decir si tengo 100 Pods, hasta 25 se pueden estar creando a partir de los 100 que tengo

Para poder realizar el deploy se ejecuta el siguiente comando: kubectl set image deploy <name> worker=<image>:<tag> kubectl set image deploy worker worker=dockercoins/worker>v0.2 Posteriormente se puede visualizar los cambios a nivel de replica sets y servicios.

Si se desea realizar el cambio de la configuración del maxSurge o maxUnavalible se debe usar el siguiente comando: kubectl edit deploy worker

Para volver nuestra imagen a su estado anterior podemos usar este comando: kubectl rollout undo deploy worker

Renan Alejandro Montoya Martinez

student•

maxSurge y maxUnavailable

Jesús Henríquez

student•

De las mejores clases del curso. 👍🏻

Pablo Aquino

student•

kubectl get pods --selector=app=NAME
kubectl label pod NAME app- #eliminar un label de un pod 
kubectl get deploy -o json | jq ".items[] | {name:.metadata.name} + .spec.strategy.rollingUpdate"

kubectl get deploy -w
kubectl get replicaset -w
kubectl set image deploy NAME NAMEAPP=IMAGE:v2 ## deployar a una nueva imagen

kubectl rollout undo deploy NAME
kubectl edit deploy NAME

"name": "my-nginx"
"maxSurge": "25%"  #% max de pods creando
"maxUnavailable": "25%" #% max de pods no disponibles

Raul Cortes santibañez

student•

Porque en el comando mostrado en el video el parámetro para la imagen nueva se llama worker, cuál es su significado?

kubectl set image deploy worker -worker-=nombre_imagen

Diego Forero

Team Platzi•

Lo que indica el comando es lo siguiente: que todos los contenedores de deploy worker se actualicen y asigna a worker la nueva imagen de, entonces solo va a realizar la actualización de worker y va a dejar sin hacer deploy de los servicios de hasher, redis, rng, webui.

William Schnaider Torres Bermon

student•

Max Unavailable .spec.strategy.rollingUpdate.maxUnavailable is an optional field that specifies the maximum number of Pods that can be unavailable during the update process. The value can be an absolute number (for example, 5) or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by rounding down. The value cannot be 0 if .spec.strategy.rollingUpdate.maxSurge is 0. The default value is 25%.

Usuario anónimo

user•

Excelente clase :)

anthony mogrovejo

student•

capo !!! exceleten explicacion

ADMINISTRANDO DESPLIEGUES

#Ver deployments
kubectl get deploy -o json

#Actualizar imagen 
kubectl set image deploy <name> worker=<image>:<tag>

#ver deploys
kubectl get replicasets -w

#Editar deploy en tiempo de ejecuccion
kubectl edit deploy <name>

#Realizar en caso de falla
kubectl rollout undo deploy <name>

kubectl get pods --selector=app=NAME
kubectl label pod NAME app- #eliminar un label de un pod 
kubectl get deploy -o json | jq ".items[] | {name:.metadata.name} + .spec.strategy.rollingUpdate"

kubectl get deploy -w
kubectl get replicaset -w
kubectl set image deploy NAME NAMEAPP=IMAGE:v2 ## deployar a una nueva imagen

kubectl rollout undo deploy NAME
kubectl edit deploy NAME

Despliegues controlados

Introducción a Kubernetes

Introducción a Kubernetes: conceptos y aplicación práctica

Repaso de contenedores e introducción a k8s

De pods a contenedores

¿Cómo funciona la arquitectura de red de Kubernetes?

Modelos declarativos e imperativos

Visión general del modelo de red

Recomendaciones

Introducción a aplicación de prueba

Instalando nuestro primer cluster con Minikube, Kubeadm

Instalando nuestro primer cluster con Kubeadm

Desplegando el Cluster en AWS con EKS

Desplegando una aplicación de prueba con EKS

Primer contacto con un cluster de kubernetes

Usando kubectl

Creación y manejo de pods

Deployments y replica sets

Balanceo de carga y service discovery

Accediendo a nuestros PODS a través de servicios

Enrutando el tráfico utilizando servicios

Desplegando nuestra app en k8s

Escalando nuestra aplicación

Exponiendo servicios interna y externamente (kubectl-proxy)

Kubernetes dashboard

Balanceo de carga y Daemon sets