Kubernetes 101
Introduction
Primitivos de contenedores
• No olviden revisar la charla de Juan Carlos del meetup de
Mayo de 2018:
• https://cloudnative.mx/meetup-mayo-2018-creando-un-
contenedor-desde-0/
Retos de contenedores
• En un sistema distribuido o arquitectura de microservicios, los
contenedores van a ejecutarse en multiples máquinas. No solo en una sola.
• El tráfico de red debe poder moverse entre distintas máquinas y coordinar
tanto ips, nombres de dominios, puertos, etc.
• Se debe poder utilizar de forma efectiva los recursos de cómputo que se
tengan disponibles.
• Monitoreo del ciclo de vida.
• Manejo de credenciales de los Docker Registries.
• Un largo etc…
• Aquí surge la necesidad de la orquestación. Los contenedores por si
mismos no son suficientes.
Orquestación de
contenedores
Orquestación
•El proceso de despliegue de múltiples contenedores
para implementar una aplicación se puede optimizar a
través de la automatización.
•Esto se vuelve cada vez más valioso a medida que
crece la cantidad de contenedores y servidores. Este
tipo de automatización se conoce como orquestación.
•Las herramientas de orquestación generalmente se
ejecutan sobre multiples máquinas, formando un
clúster. Donde cada nodo del cluster proporciona un
conjunto de recursos que se pueden suministrar a los
contenedores.
Características de la
Orquestación
• Aprovisionamiento de máquinas.
• Instanciar un conjunto de contenedores
• Reinicio (rescheduling) de contenedores fallidos
• Enlace (networking) de contenedores a través de interfaces
definidas
• Exponer servicios a máquinas fuera del clúster
• Escalar o reducir el clúster, agregando o eliminando
contenedores
Kubernetes
Intro a Kubernetes
• Kubernetes es "un software Open Source para automatizar el despliegue, escalado y
administración de aplicaciones en contenedores",
• Conectar los contenedores a través de múltiples hosts, escalarlos cuando sea
necesario, implementar aplicaciones sin tiempo de inactividad y “service Discovery”
entre otros, son desafíos realmente difíciles.
• Kubernetes aborda esos desafíos desde el principio con un conjunto de primitivos y
una poderosa API.
• Un aspecto clave de Kubernetes es que se basa en 15 años de experiencia en Google.
• La infraestructura de Google comenzó a alcanzar gran escala antes de que las
máquinas virtuales se volvieran omnipresentes en el centro de datos y los contenedores
proporcionaran una solución de grano fino para agrupar los clústeres de manera
eficiente.
• La eficiencia en el uso de clusters y la administración de aplicaciones distribuidas ha
estado en el centro de los desafíos de Google.
Origen
• En griego “κυβερνήτης”, significa el timonel o piloto de la
nave.
• Kubernetes es el piloto de un barco de contenedores.
• https://www.youtube.com/watch?v=4ht22ReBjno
Alternativas
• Docker Swarm es la solución de Docker Inc. Ha sido rediseñado
recientemente y está basado en SwarmKit. Está integrado con el Docker
Engine.
• Apache Mesos es un programador (scheduler) de centro de datos, que
puede ejecutar contenedores mediante el uso de diversos frameworks.
Marathon es el framework que le permite orquestar contenedores.
• Nomad de HashiCorp, los creadores de Vagrant y Consul, es otra
solución para administrar aplicaciones en contenedores. Nomad
programa (schedule) tareas definidas en trabajos. Tiene un controlador
Docker que le permite definir un contenedor en ejecución como una
tarea.
• Rancher es un sistema agnóstico de orquestador de contenedores, que
proporciona un panel único con interfaz para administrar aplicaciones.
Es compatible con Mesos, Swarm, Kubernetes, así como su sistema
nativo, Cattle.
Google y Kubernetes
• Lo que principalmente distingue a Kubernetes de otros es su herencia. Kubernetes está
inspirado en Borg, el sistema interno utilizado por Google para administrar sus
aplicaciones (por ejemplo, Gmail, Apps, GCE).
• Con Google vertiendo las valiosas lecciones que aprendieron al escribir y operar Borg
durante más de 15 años en Kubernetes, esto hace que Kubernetes sea una elección
segura cuando se tiene que decidir qué sistema usar para administrar los contenedores.
• Cuando usamos Gmail, Google Docs, GCE o cualquier otro servicio de Google, se está
utilizando una aplicación en contenedor administrada por Borg en todo el mundo
• Borg fue un secreto de Google durante mucho tiempo, pero ya no.
• Borg es el sistema de orquestación para administrar todas las aplicaciones de Google a
escala.
• Borg finalmente fue descrito públicamente en 2015.
• Para obtener más información acerca de las ideas detrás de Kubernetes, se puede leer
este documento https://research.google.com/pubs/pub43438.html
Componentes de
Kubernetes
• El siguiente tweet de Julia Evans explica de forma sencilla
los distintos componentes de Kubernetes
• https://twitter.com/b0rk/status/872822361199972352
Componentes
• Está formado por un administrador central (también conocido como
master) y algunos nodos worker.
• El administrador ejecuta un API server, un scheduler, un controller y
también un sistema de almacenamiento para mantener el estado del
clúster.
• Kubernetes expone una API (a través del API server): puede
comunicarse con la API usando un cliente local llamado kubectl.
• El scheduler ve las solicitudes de contenedores en ejecución que llegan
a la API y encuentra un nodo adecuado para ejecutar ese contenedor.
• Cada nodo en el clúster ejecuta dos procesos: un kubelet y un proxy de
servicio. El kubelet recibe solicitudes para ejecutar los contenedores y
los vigila en el nodo local. El proxy crea y administra reglas de red para
exponer el contenedor en la red.
Características
•Está formado de un administrador y un conjunto de nodos.
•Tiene un scheduler para colocar contenedores en un
clúster.
•Tiene un API server y una capa de persistencia con etcd.
•Tiene un controller para conciliar estados.
•Se implementa en máquinas virtuales o máquinas bare
metal, en nubes públicas o on-premise.
•Está escrito en Go Lang.
Desarrollo de Kubernetes
• Google lo donó a la Cloud Native Computing Foundation
(CNCF) en Julio de 2015.
• La CNCF esta formada por muchas empresas.
• La CNCF posee los derechos reservados del desarrollo y
marcas registradas.
• Para contribuir con código, se debe firmar un acuerdo con
la CNCF
Componentes de la
arquitectura
•Master (Control plane)
•etcd cluster
•API server
•scheduler
•controller manager
•Worker (minion)
•kubelet
•proxy (kube-proxy)
•Container engine
•Network overlay (Opcional)
Arquitectura
Nodos master
• El API server expone una interfaz REST a todos los recursos de
Kubernetes y es altamente configurable.
• La principal responsabilidad del scheduler es colocar los contenedores en
el nodo del clúster de acuerdo con diversas políticas, métricas y requisitos
de recursos. También se puede configurar mediante indicadores de línea
de comando.
• El Controller Manager es responsable de conciliar el estado real del clúster
con el estado deseado, tal como se especifica a través de la API. Es un
bucle de control que realiza acciones basadas en el estado observado del
clúster y el estado deseado. El controller manager también es
configurable.
• El nodo master se puede configurar en una configuración de múltiples
masters para alta disponibilidad. Los schedulers y los controller managers
pueden elegir un líder, mientras que los API servers pueden ser elegidos
por un balanceador de carga.
Nodos workers
• Ejecutan el kube-proxy y kubelet, así como Container
Engine (Docker Engine), pero soporta rkt, entre otros.
• kubelet interactúa con el Container Engine también
instalado en todos los nodos y se asegura de que los
contenedores que necesitan ejecutarse se estén
ejecutando realmente.
• El kube-proxy está a cargo de administrar la conectividad
de la red a los contenedores.


Estado del cluster
• Kubernetes necesita una capa de persistencia.
Tradicionalmente, esto podría implementarse con una base
de datos relacional. Sin embargo, en un sistema altamente
escalable, una base de datos relacional (por ejemplo, MySQL,
PostgreSQL) puede convertirse en un único punto de falla.
• Las DB distribuidas de key-value están diseñados para
ejecutarse en múltiples nodos. Los datos se replican entre los
nodos y tienen una gran consistencia. Son tolerantes a fallas
en el sentido de que, al fallar la máquina, seguirán
funcionando.
• Zookeeper, Consul y etcd son ejemplos de DB distribuidas de
key-value.
• Kubernetes usa etcd.
ETCD
• Se puede ejecutar en un solo nodo (aunque pierda su característica
distribuida y, por lo tanto, su tolerancia a la falla). Debajo usa un algoritmo de
elección de líder para proporcionar una gran coherencia del estado
almacenado entre los nodos (Raft).
• Una discusión sobre etcd está fuera del alcance de este curso; sin embargo,
debe familiarizarse con su configuración y operaciones.
• https://github.com/coreos/etcd
• http://container-solutions.com/raft-explained-part-1-the-consenus-problem/
• https://raft.github.io
• El número de nodos del cluster importa y mucho:
• https://coreos.com/etcd/docs/latest/v2/admin_guide.html#optimal-cluster-
size
Pods
• En Kubernetes, la unidad de cómputo minima no es un
contenedor, sino lo que llamamos un pod.
• Un pod es un grupo de contenedores compartidos que
comparten la misma dirección IP.
• Desde una perspectiva de redes, un pod puede verse
como una máquina virtual de hosts físicos.
• La red necesita asignar direcciones IP a los pods, y
necesita proporcionar rutas de tráfico entre todos los pods
en cualquier nodo.
Instalación de
Kubernetes
Consideraciones
• Kubernetes puede correr en cualquier infraestructura.
• Puede ejecutarse en:
• bare-metal
• Virtual Machines on-premise
• VMs
• Cloud privada
• Cloud publica
• Los escenarios y casos de uso pueden ser demasiados.
• No existe una forma correcta o unica de instalar.
¿Que alternativas concretas
hay?
• Se puede revisar la documentación de Kubernetes en donde se
describen muchas de las alternativas existentes.
• https://kubernetes.io/docs/setup/pick-right-solution/
• Es abrumante la cantidad de opciones.
• Existen proveedores que facilitan herramientas para instalar y
mantener un cluster.
• Es importante conocer y saber el proceso de instalación, pero se
recomienda que esta labor sea la menos complicada posible.
• Es decir, elegir una forma externa, tratar de no invertir recursos
en la instalación.
Recomendaciones
•minikube
•Ideal para aprender y probar configuración de aplicaciones.
•No usar para probar rendimiento, muchos entornos de pruebas,
QA o producción.
•Kubeadm
•CoreOS Tectonic
•OnPremise, AWS
•Kops
•AWS
Configuraciones de despliegue
• Despliegue de nodo único
• Todos los componentes se ejecutan en el mismo servidor. Esto es ideal para probar,
aprender y desarrollar Kubernetes.
• Un solo nodo mastery múltiples workers
• Una instancia de un nodo, etcd, que se ejecuta en el nodo principal con el API server, el
scheduler y el controller manager.
• Múltiples nodos master en HA y múltiples workers
• El API server estará siendo usado por un balanceador de carga, el schedulery el controler
managerr elegirán un líder. La instalación de etcd todavía puede ser de un solo nodo.
• Clúster de etcd con HA, con nodos master en HA y múltiples workers
• Esta sería la configuración más avanzada y resiliente. etcd se ejecutaría como un clúster
verdadero, que proporcionaría HA y se ejecutaría en nodos diferentes a los nodos master
de Kubernetes.
Kubernetes
The Hard Way
https://github.com/kelseyhightower/kubernetes-the-hard-way
Instalación de un cluster
con Kops en AWS
kubectl
•Cliente cli para interactuar con el Api Server de Kubernetes.
•Herramienta de trabajo para cualquier administrador o
desarrollador que interactua con el cluster.
•https://kubernetes.io/docs/tasks/tools/install-kubectl/
•Configuración (kubeconfig):
•$HOME/.kube/config
•En ese archivo se configuran los endpoints del Api Server
y credenciales.
•Por default toma ese archiva (el contexto default) para
conectarse.

Cloud Native Mexico - Introducción a Kubernetes

  • 1.
  • 2.
    Primitivos de contenedores •No olviden revisar la charla de Juan Carlos del meetup de Mayo de 2018: • https://cloudnative.mx/meetup-mayo-2018-creando-un- contenedor-desde-0/
  • 4.
    Retos de contenedores •En un sistema distribuido o arquitectura de microservicios, los contenedores van a ejecutarse en multiples máquinas. No solo en una sola. • El tráfico de red debe poder moverse entre distintas máquinas y coordinar tanto ips, nombres de dominios, puertos, etc. • Se debe poder utilizar de forma efectiva los recursos de cómputo que se tengan disponibles. • Monitoreo del ciclo de vida. • Manejo de credenciales de los Docker Registries. • Un largo etc… • Aquí surge la necesidad de la orquestación. Los contenedores por si mismos no son suficientes.
  • 5.
  • 6.
    Orquestación •El proceso dedespliegue de múltiples contenedores para implementar una aplicación se puede optimizar a través de la automatización. •Esto se vuelve cada vez más valioso a medida que crece la cantidad de contenedores y servidores. Este tipo de automatización se conoce como orquestación. •Las herramientas de orquestación generalmente se ejecutan sobre multiples máquinas, formando un clúster. Donde cada nodo del cluster proporciona un conjunto de recursos que se pueden suministrar a los contenedores.
  • 7.
    Características de la Orquestación •Aprovisionamiento de máquinas. • Instanciar un conjunto de contenedores • Reinicio (rescheduling) de contenedores fallidos • Enlace (networking) de contenedores a través de interfaces definidas • Exponer servicios a máquinas fuera del clúster • Escalar o reducir el clúster, agregando o eliminando contenedores
  • 8.
  • 9.
    Intro a Kubernetes •Kubernetes es "un software Open Source para automatizar el despliegue, escalado y administración de aplicaciones en contenedores", • Conectar los contenedores a través de múltiples hosts, escalarlos cuando sea necesario, implementar aplicaciones sin tiempo de inactividad y “service Discovery” entre otros, son desafíos realmente difíciles. • Kubernetes aborda esos desafíos desde el principio con un conjunto de primitivos y una poderosa API. • Un aspecto clave de Kubernetes es que se basa en 15 años de experiencia en Google. • La infraestructura de Google comenzó a alcanzar gran escala antes de que las máquinas virtuales se volvieran omnipresentes en el centro de datos y los contenedores proporcionaran una solución de grano fino para agrupar los clústeres de manera eficiente. • La eficiencia en el uso de clusters y la administración de aplicaciones distribuidas ha estado en el centro de los desafíos de Google.
  • 10.
    Origen • En griego“κυβερνήτης”, significa el timonel o piloto de la nave. • Kubernetes es el piloto de un barco de contenedores. • https://www.youtube.com/watch?v=4ht22ReBjno
  • 11.
    Alternativas • Docker Swarmes la solución de Docker Inc. Ha sido rediseñado recientemente y está basado en SwarmKit. Está integrado con el Docker Engine. • Apache Mesos es un programador (scheduler) de centro de datos, que puede ejecutar contenedores mediante el uso de diversos frameworks. Marathon es el framework que le permite orquestar contenedores. • Nomad de HashiCorp, los creadores de Vagrant y Consul, es otra solución para administrar aplicaciones en contenedores. Nomad programa (schedule) tareas definidas en trabajos. Tiene un controlador Docker que le permite definir un contenedor en ejecución como una tarea. • Rancher es un sistema agnóstico de orquestador de contenedores, que proporciona un panel único con interfaz para administrar aplicaciones. Es compatible con Mesos, Swarm, Kubernetes, así como su sistema nativo, Cattle.
  • 12.
    Google y Kubernetes •Lo que principalmente distingue a Kubernetes de otros es su herencia. Kubernetes está inspirado en Borg, el sistema interno utilizado por Google para administrar sus aplicaciones (por ejemplo, Gmail, Apps, GCE). • Con Google vertiendo las valiosas lecciones que aprendieron al escribir y operar Borg durante más de 15 años en Kubernetes, esto hace que Kubernetes sea una elección segura cuando se tiene que decidir qué sistema usar para administrar los contenedores. • Cuando usamos Gmail, Google Docs, GCE o cualquier otro servicio de Google, se está utilizando una aplicación en contenedor administrada por Borg en todo el mundo • Borg fue un secreto de Google durante mucho tiempo, pero ya no. • Borg es el sistema de orquestación para administrar todas las aplicaciones de Google a escala. • Borg finalmente fue descrito públicamente en 2015. • Para obtener más información acerca de las ideas detrás de Kubernetes, se puede leer este documento https://research.google.com/pubs/pub43438.html
  • 13.
    Componentes de Kubernetes • Elsiguiente tweet de Julia Evans explica de forma sencilla los distintos componentes de Kubernetes • https://twitter.com/b0rk/status/872822361199972352
  • 15.
    Componentes • Está formadopor un administrador central (también conocido como master) y algunos nodos worker. • El administrador ejecuta un API server, un scheduler, un controller y también un sistema de almacenamiento para mantener el estado del clúster. • Kubernetes expone una API (a través del API server): puede comunicarse con la API usando un cliente local llamado kubectl. • El scheduler ve las solicitudes de contenedores en ejecución que llegan a la API y encuentra un nodo adecuado para ejecutar ese contenedor. • Cada nodo en el clúster ejecuta dos procesos: un kubelet y un proxy de servicio. El kubelet recibe solicitudes para ejecutar los contenedores y los vigila en el nodo local. El proxy crea y administra reglas de red para exponer el contenedor en la red.
  • 16.
    Características •Está formado deun administrador y un conjunto de nodos. •Tiene un scheduler para colocar contenedores en un clúster. •Tiene un API server y una capa de persistencia con etcd. •Tiene un controller para conciliar estados. •Se implementa en máquinas virtuales o máquinas bare metal, en nubes públicas o on-premise. •Está escrito en Go Lang.
  • 17.
    Desarrollo de Kubernetes •Google lo donó a la Cloud Native Computing Foundation (CNCF) en Julio de 2015. • La CNCF esta formada por muchas empresas. • La CNCF posee los derechos reservados del desarrollo y marcas registradas. • Para contribuir con código, se debe firmar un acuerdo con la CNCF
  • 18.
    Componentes de la arquitectura •Master(Control plane) •etcd cluster •API server •scheduler •controller manager •Worker (minion) •kubelet •proxy (kube-proxy) •Container engine •Network overlay (Opcional)
  • 19.
  • 20.
    Nodos master • ElAPI server expone una interfaz REST a todos los recursos de Kubernetes y es altamente configurable. • La principal responsabilidad del scheduler es colocar los contenedores en el nodo del clúster de acuerdo con diversas políticas, métricas y requisitos de recursos. También se puede configurar mediante indicadores de línea de comando. • El Controller Manager es responsable de conciliar el estado real del clúster con el estado deseado, tal como se especifica a través de la API. Es un bucle de control que realiza acciones basadas en el estado observado del clúster y el estado deseado. El controller manager también es configurable. • El nodo master se puede configurar en una configuración de múltiples masters para alta disponibilidad. Los schedulers y los controller managers pueden elegir un líder, mientras que los API servers pueden ser elegidos por un balanceador de carga.
  • 21.
    Nodos workers • Ejecutanel kube-proxy y kubelet, así como Container Engine (Docker Engine), pero soporta rkt, entre otros. • kubelet interactúa con el Container Engine también instalado en todos los nodos y se asegura de que los contenedores que necesitan ejecutarse se estén ejecutando realmente. • El kube-proxy está a cargo de administrar la conectividad de la red a los contenedores.
  • 22.
    
 Estado del cluster •Kubernetes necesita una capa de persistencia. Tradicionalmente, esto podría implementarse con una base de datos relacional. Sin embargo, en un sistema altamente escalable, una base de datos relacional (por ejemplo, MySQL, PostgreSQL) puede convertirse en un único punto de falla. • Las DB distribuidas de key-value están diseñados para ejecutarse en múltiples nodos. Los datos se replican entre los nodos y tienen una gran consistencia. Son tolerantes a fallas en el sentido de que, al fallar la máquina, seguirán funcionando. • Zookeeper, Consul y etcd son ejemplos de DB distribuidas de key-value. • Kubernetes usa etcd.
  • 23.
    ETCD • Se puedeejecutar en un solo nodo (aunque pierda su característica distribuida y, por lo tanto, su tolerancia a la falla). Debajo usa un algoritmo de elección de líder para proporcionar una gran coherencia del estado almacenado entre los nodos (Raft). • Una discusión sobre etcd está fuera del alcance de este curso; sin embargo, debe familiarizarse con su configuración y operaciones. • https://github.com/coreos/etcd • http://container-solutions.com/raft-explained-part-1-the-consenus-problem/ • https://raft.github.io • El número de nodos del cluster importa y mucho: • https://coreos.com/etcd/docs/latest/v2/admin_guide.html#optimal-cluster- size
  • 24.
    Pods • En Kubernetes,la unidad de cómputo minima no es un contenedor, sino lo que llamamos un pod. • Un pod es un grupo de contenedores compartidos que comparten la misma dirección IP. • Desde una perspectiva de redes, un pod puede verse como una máquina virtual de hosts físicos. • La red necesita asignar direcciones IP a los pods, y necesita proporcionar rutas de tráfico entre todos los pods en cualquier nodo.
  • 25.
  • 26.
    Consideraciones • Kubernetes puedecorrer en cualquier infraestructura. • Puede ejecutarse en: • bare-metal • Virtual Machines on-premise • VMs • Cloud privada • Cloud publica • Los escenarios y casos de uso pueden ser demasiados. • No existe una forma correcta o unica de instalar.
  • 27.
    ¿Que alternativas concretas hay? •Se puede revisar la documentación de Kubernetes en donde se describen muchas de las alternativas existentes. • https://kubernetes.io/docs/setup/pick-right-solution/ • Es abrumante la cantidad de opciones. • Existen proveedores que facilitan herramientas para instalar y mantener un cluster. • Es importante conocer y saber el proceso de instalación, pero se recomienda que esta labor sea la menos complicada posible. • Es decir, elegir una forma externa, tratar de no invertir recursos en la instalación.
  • 28.
    Recomendaciones •minikube •Ideal para aprendery probar configuración de aplicaciones. •No usar para probar rendimiento, muchos entornos de pruebas, QA o producción. •Kubeadm •CoreOS Tectonic •OnPremise, AWS •Kops •AWS
  • 29.
    Configuraciones de despliegue •Despliegue de nodo único • Todos los componentes se ejecutan en el mismo servidor. Esto es ideal para probar, aprender y desarrollar Kubernetes. • Un solo nodo mastery múltiples workers • Una instancia de un nodo, etcd, que se ejecuta en el nodo principal con el API server, el scheduler y el controller manager. • Múltiples nodos master en HA y múltiples workers • El API server estará siendo usado por un balanceador de carga, el schedulery el controler managerr elegirán un líder. La instalación de etcd todavía puede ser de un solo nodo. • Clúster de etcd con HA, con nodos master en HA y múltiples workers • Esta sería la configuración más avanzada y resiliente. etcd se ejecutaría como un clúster verdadero, que proporcionaría HA y se ejecutaría en nodos diferentes a los nodos master de Kubernetes.
  • 30.
  • 31.
    Instalación de uncluster con Kops en AWS
  • 32.
    kubectl •Cliente cli parainteractuar con el Api Server de Kubernetes. •Herramienta de trabajo para cualquier administrador o desarrollador que interactua con el cluster. •https://kubernetes.io/docs/tasks/tools/install-kubectl/ •Configuración (kubeconfig): •$HOME/.kube/config •En ese archivo se configuran los endpoints del Api Server y credenciales. •Por default toma ese archiva (el contexto default) para conectarse.