Saltar al contenido

Archivos de categoría Desarrollo

Microservicios con Kubernetes

Microservicios con Kubernetes

Para explicar como funcionan los microservicios con Kubernetes se va a usar la misma aplicación que todos usan para realizar la demostración. Es una aplicación simple, pero completa, desarrollada por Docker para demostrar las diversas características disponibles en la ejecución de un cluster de aplicaciones en Docker. Vamos a explicar la aplicación. Es es una aplicación de votación que proporciona una interfaz para que un usuario vote y otra interfaz para mostrar los resultados. La aplicación consta de varios componentes:

  • aplicación microserviciosLa aplicación de votación: es una aplicación web desarrollada en Python para proporcionar al usuario una interfaz para elegir entre dos opciones, un gato y un perro.
  • Cuando realiza una selección, el voto se almacena en Redis, una base de datos en la memoria.
  • El voto es procesado por el trabajador, que es una aplicación escrita. NET que toma el nuevo voto y actualiza la base de datos de persistencia.
  • La base de datos persistente se encuentra en postgreSQL y tiene una tabla con el número de votos para cada categoría.
  • Finalmente, el resultado de la votación se muestra en una interfaz web que es otra aplicación web desarrollada en Nodejs. Lee el recuento de votos de la base de datos postgreSQL y lo muestra al usuario.

 

La aplicación de ejemplo está construida con una combinación de diferentes microservicios con Kubernetes, diferentes herramientas de desarrollo y múltiples plataformas de desarrollo, como Python, NodeJS,. NET, etc Esta aplicación de muestra se utilizará para mostrar como configurar un cluster de aplicaciones completa que consta de diversos componentes en Docker.

Se va a crear el cluster en un solo motor Docker usando los comandos de ejecución. Supongamos que todas las imágenes de las aplicaciones ya están compiladas y están disponibles en el repositorio de Docker.

Creación del cluster

  • Comenzamos con la capa de datos. Primero, ejecutamos el comando “docker run redis” para iniciar una instancia de Redis. Agregaremos el parámetro -d para ejecutar este contenedor en segundo plano y también nombraremos el contenedor redis. Nombrar los contenedores es importante.
  • A continuación, implementaremos la base de datos PostgreSQL en segundo plano, llamando al contenedor “db”. Ejecutando el comando “docker run postgres”.
  • Vamos con los servicios de la aplicación. Implementamos una aplicación front-end para la interfaz de votación ejecutando una instancia de imagen de la aplicación de votación. Ejecutamos el comando “docker run”, asignando el nombre al voto de la instancia. Como se trata de un servidor web, tiene una instancia de interfaz de usuario web que se ejecuta en el puerto 80. Publicaremos ese puerto a 5000 en el sistema host para que podamos acceder a él desde un navegador.
  • A continuación, implementaremos la aplicación web de resultados que muestra los resultados al usuario. Para ello, implementará un contenedor utilizando la imagen de la aplicación de resultados y publicará el puerto 80 en el puerto 5001 del host. De esta manera, podemos acceder a la interfaz de usuario web de la aplicación resultante en un navegador.
  • Finalmente implementamos el trabajador ejecutando una instancia de la imagen del trabajador.

 

Todas las instancias se ejecutan en el host, pero no puede funcionar. Hemos ejecutado con éxito todos los diferentes contenedores, pero en realidad no los hemos vinculado. No le hemos dicho a la aplicación web de votación que use la instancia particular de Redis. Podría haber múltiples instancias de Redis ejecutándose. No le hemos dicho al trabajador y la aplicación resultante que usen la base de datos postgreSQL particular que ejecutamos. Para vincularlos usamos enlaces. Link es una opción de línea de comando que se puede usar para vincular dos contenedores.

Comunicación

Por ejemplo, el servicio web de la aplicación de votación depende del servicio de Redis cuando se inicia el servidor web. En el código de la aplicación web, hay un parámetro que busca un servicio de Redis que se esté ejecutando en el host Redis. Pero el contenedor de la aplicación de votación no puede resolver un host con el nombre redis. Agregamos una opción de enlace para vincularlo al contenedor de Redis agregando una opción –link al comando Docker Run y especificando el nombre del contenedor de redis, que es en este caso un redis seguido de dos puntos y el nombre del host que está buscando la aplicación de votación. Es por eso que nombramos el contenedor cuando lo ejecutamos la primera vez.

Lo que se está haciendo es crear una entrada en el archivo de host, etc. en el contenedor de la aplicación de votación, agregando una entrada con el nombre de host redis con una IP interna del contenedor de redis. Del mismo modo, agregamos un enlace para que la aplicación de resultados se comunique con la base de datos agregando una opción de enlace para referir la base de datos con el nombre “db”, como puede ver en este nuestro código fuente de la aplicación. Finalmente, la aplicación de trabajo requiere acceso tanto a la base de datos Redis como a la base de datos Postgres. Por lo tanto, agregamos dos enlaces a la aplicación de trabajo, un enlace para vincular los redis y el otro enlace para vincular la base de datos postgres.

Fuentes de la aplicación de ejemplo de microservicios con Kubernetes: https://github.com/dockersamples/example-voting-app

0 Seguir leyendo →

Servicios en Kubernetes

Servicios en Kubernetes.

Los servicios en Kubernetes permiten la comunicación entre varios componentes dentro y fuera de la aplicación. Los servicios de Kubernetes ayudan a conectar aplicaciones con otras aplicaciones o usuarios. Supongamos que una aplicación tiene grupos de PODs que ejecutan varias secciones. Un grupo puede servir a nuestra interfaz. Otro grupo ejecuta procesos de back-end. Y un tercer grupo se conecta a una fuente de datos externa. Los servicios permiten la conectividad entre estos grupos  y hacen que los módulos de back end y front end se comuniquen a una fuente de datos externa. Por lo tanto, los servicios permiten un acoplamiento flexible entre los micro servicios en las aplicaciones.

Hasta ahora hablamos sobre cómo las cápsulas se comunican entre sí a través de redes internas. Pero hay otros aspectos de las redes como la comunicación externa. Si tenemos un POD con una aplicación web ejecutándose en él, no podemos acceder a la página directamente como un usuario externo. Cómo el nodo Kubernetes está en la misma red que el ordenador donde se ejecuta (por ejemplo 192.168.1.2 y 192.168.1.10) y la red de POD interna está en otra (por ejemplo 10.244.0.2), no se puede acceder directamente.

Desde el nodo Kubernetes (192.168.1.2) sí se puede acceder a la página web de los PODs haciendo un curl o, si el nodo tiene una GUI, abriríamos una página web en el navegador y veríamos la página web en un navegador siguiendo la dirección http://10.244.0.2. Pero esto es desde el interior del nodo Kubernetes. Si se quiere acceder desde el ordenador sin tener que ingresar en el nodo Kubernetes, simplemente accediendo a la IP, se necesita algo en el medio que  ayude a asignar la solicitud al nodo desde nuestro ordenador a través del nodo hasta el POD que ejecuta el contenedor web.

Los servicios en Kubernetes

Aquí es donde entra en juego los servicios en Kubernetes. Es un objeto como los PODs, los conjuntos de réplicas o los despliegues que vimos en otros artículos. Su función es la de escuchar un puerto en el nodo y reenviar la solicitud en ese puerto a un puerto en el POD. Este tipo de servicio se conoce como un servicio de puerto de nodo porque escucha el puerto en el nodo y reenvía las solicitudes a los PODs.

kubernetes servicesHay otros tipos de servicios disponibles, como el ClusterIP. En este caso, el servicio crea una IP virtual dentro del clúster para permitir la comunicación entre diferentes servicios en Kubernetes, como un conjunto de servidores front-end a un conjunto de servidores back-end. Otro tipo es un balanceador que proporciona equilibrio de carga para aplicaciones en proveedores de nube. Un ejemplo es la distribución de la carga a través de diferentes servidores web en su nivel de front-end.

Puerto de nodo.

Hemos visto que un servicio puede ayudarnos asignando un puerto en el nodo a un puerto en el POD. Para la tarea hay tres puertos involucrados. El puerto en el POD, que es donde se está ejecutando el servidor web real (puerto 80). Se conoce como el puerto de destino porque allí es donde el servicio reenvía la solicitud. El segundo puerto es el puerto del servicio en sí, y se conoce simplemente como el puerto. Estos términos son desde el punto de vista del servicio. De hecho, el servicio es como un servidor virtual dentro del nodo.

Dentro del clúster, tiene su propia dirección IP, denomina da IP del clúster del servicio. Finalmente tenemos el puerto en el nodo en sí mismo que usamos para acceder al servidor web externamente y que se conoce como el puerto del nodo (puerto 30008). Los puertos de nodo solo pueden estar en un rango válido que, por defecto, es de 30000 a 32767.

Creación

Para crear los servicios, al igual que se crea un conjunto de réplicas, despliegues o PODs, se utiliza un archivo de definición. La estructura de alto nivel del archivo sigue siendo la misma, con las secciones apiVersion, kind, metadata y spec. La versión de API es “v1”, el tipo es “Service”, los metadatos tendrán un nombre del servicio y, opcionalmente, etiquetas, y por último las especificaciones que es la parte más crucial del archivo. Como especificaciones tenemos “type” y “ports”. El tipo se refiere al tipo de servicio que estamos creando: “NodePort”, “NodeIP” o “NodeBalancer”.

Los puertos es una lista con información sobre cada servicio, y cada uno de ellos hay que ingresar la información de “targetPort”, “port” y “nodePort”. De ellos el único campo obligatorio es el puerto, si no se proporciona un puerto de destino, se supone que es el mismo que el puerto y si no proporciona un puerto de nodo, se asigna automáticamente un puerto libre en el rango válido entre 30000 y 32767. Se pueden tener múltiples asignaciones de puertos en un solo servicio.

Conexión

En toda la información anterior falta algo importante, no hay nada que conecte el servicio al POD. Se especifica el puerto de destino, pero podría haber cientos de otros PODs con servicios web ejecutándose en el mismo puerto. Para especificar el POD se hace como con los conjuntos de réplicas, usando la técnica de las etiquetas y selectores para vincularlos. Sabemos que el POD se creó con una etiqueta, así que llevamos esa etiqueta al archivo de definición de servicio. Tenemos una nueva propiedad en la sección de especificaciones llamada “selector”. Al igual que en un conjunto de réplicas y los archivos de definición de despliegues debajo del selector se pone una lista de etiquetas para identificar el POD. Para esto se hace referencia al archivo de definición de POD, extrayendo las etiquetas y colocándolas debajo de la sección del selector. Esto vincula el servicio al POD.

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  spec:
    type: NodePort
    ports:
      - targetPort: 80
        port: 80
        nodePort: 30008
selector:
  app: myapp
  type: front-end

Una vez terminado, se crea el servicio utilizando el comando “kubectl create -f <archivo def.>”. Para ver el servicio creado se ejecuta el comando “kubectl get services” que lista los servicios creados. Ahora podemos usar el puerto para acceder al servicio web mediante curl o un navegador web. Se puede utilizar “kubectl describe service” para obtener más información.

Múltiples nodos en los servicios en Kubernetes

kubernetes varios podsHasta ahora hemos hablado de un servicio asignado a un solo POD, pero no es lo normal. Habitualmente se tienen múltiples PODs en el entorno de producción, con varias instancias de una aplicación web ejecutándose para tener mayor disponibilidad y mejor equilibrio de carga. En este caso, hay múltiples POPDs similares que ejecutan la aplicación y todos tienen las mismas etiquetas, ya que la misma etiqueta se usa como selector durante la creación del servicio. Cuando se crea el servicio, busca un POD coincidente con la etiqueta y encuentra varios de ellos. El servicio selecciona automáticamente todos los PODs como puntos finales para reenviar las solicitudes, por lo que no hay que hacer ninguna configuración adicional. El algoritmo que se utiliza para equilibrar la carga entre todos los PODs es aleatorio. Por lo tanto, el servicio actúa como un balanceador de carga.

kuvernetes varios nodosSi los PODs se distribuyen en múltiples nodos separados, Kubernetes crea automáticamente un servicio que abarca todos los nodos y asigna ese puerto de destino al mismo puerto de nodo en todos ellos. De esta manera, se puede acceder a la aplicación usando la IP de cualquier nodo en el clúster y usando el mismo número de puerto.

Para resumir, ya sea un solo POD en un solo nodo, múltiples PODs en un solo nodo o múltiples PODs en múltiples nodos, el servicio se define exactamente igual sin que se tenga que realizar ningún paso adicional durante la creación del servicio. Cuando los PODs se eliminan o agregan el servicio se actualiza automáticamente haciendo que sea altamente flexible y adaptable. Una vez creado, normalmente no se tendrá que hacer ningún cambio de configuración adicional.

Cluster IP de Kubernetes.

Kubernetes ClusterIPUna aplicación web generalmente tiene diferentes tipos de PODs que alojan diferentes partes. Es posible que tenga una serie de PODs que ejecutan un servidor web front-end, otro conjunto que ejecutan una parte back-end, otro más ejecutan un almacén de valores clave y otro conjunto pueden ejecutar una base de datos persistente como mySQL. El servidor front-end web debe comunicarse con los servidores back-end y los servidores back-end deben comunicarse con la base de datos, así como con los servicios de valores clave, etc.

Todos los PODs tienen una dirección IP asignada, pero son estáticas. Además, los PODs pueden apagarse en cualquier momento y crearse nuevos. Por lo tanto, no se puede confiar en estas direcciones IP para la comunicación interna entre la aplicación. Por último, los PODs de front-end necesitan conectarse a los de back-end, pero ¿a cual y quién toma esa decisión?

Un servicio de Kubernetes puede ayudarnos a agrupar los PODs y proporcionar una interfaz única para acceder a ellos en un grupo. Por ejemplo, un servicio creado para los de back-end ayudará a agrupar todos ellos y proporcionará una única interfaz para que otros PODs accedan a este servicio. Las solicitudes se envían a uno de los PODs al azar gracias a este servicio. Del mismo modo, se pueden crear servicios adicionales para el servidor de claves que permita que los módulos de back-end accedan a ese sistema.

Creación

Esto nos permite implementar de manera fácil y efectiva una aplicación basada en microservicios en el clúster de Kubernetes. Cada capa ahora puede escalar o moverse según sea necesario sin afectar la comunicación entre los diversos servicios. Cada servicio recibe una IP y un nombre asignados dentro del clúster y ese es el nombre que deben usar otros PODs para acceder al servicio. Este tipo de servicio se conoce como IP de clúster.

Para crear un servicio se usa la misma plantilla predeterminada con su “apiVersion”, “kind”, “metadatos” y “spec”. La apiVersion es v1, el tipo es “Service”, le daremos un nombre al servicio en los metadatos, por ejemplo “back-end”. Bajo las especificación tenemos el “type” y “Ports”. El tipo es “IP de clúster”, de hecho, la IP de clúster es el tipo predeterminado, por lo que incluso si no se especifica, automáticamente asumirá que ese tipo es IP de clúster en los puertos. Y, por último, tenemos un puerto de destino, que es el puerto donde está expuesto el back-end, y el puerto de servicio que es donde está expuesto el servicio. Por último hay que copiará las etiquetas de la definición del POD debajo del selector y eso debería ser todo.

Más información: https://kubernetes.io/docs/concepts/services-networking/service/

0 Seguir leyendo →

Redes en Kubernetes

Redes en Kubernetes

Para entender las redes en Kubernetes empezaremos viendo un clúster de Kubernetes de un solo nodo. El nodo tiene una dirección IP, digamos que es 192.168.1.2. Esta es la dirección IP que usamos para acceder al nodo Kubernetes con ssh, etc. Recuerde que si está utilizando una configuración de miniKube, esa es la dirección IP de la máquina virtual de miniKube dentro de su Hipervisor. El ordenador donde se ejecuta tendrá una dirección IP diferente, algo como 192.168.1.10. Por lo tanto, es importante comprender cómo están configuradas las máquinas virtuales.

Redes en Kubernetes un solo nodoEn el clúster de kubernets de un solo nodo, hemos creado un solo POD. El POD aloja un contenedor. A diferencia del mundo Docker, donde siempre se asigna una dirección IP a un contenedor, en el mundo de los Kubernetes la dirección IP se asigna a un POD, por lo que cada POD en Kubernetes obtiene su propia dirección IP interna.

Cuando Kubernetes se configura inicialmente, se crea una red privada interna con una dirección, por ejemplo 10.244.0.0 y todos los PODs están unidos a ella. Cuando implementa varios PODs, todos obtienen una IP separada asignada desde esta red. Los PODs pueden comunicarse entre sí a través de estas IP, pero el acceso al otro POD usando esta dirección IP interna puede no ser una buena idea, ya que está sujeto a cambios cuando se recrean los PODs. Es fácil y simple de entender cuando se trata de redes en un solo nodo.

Varios nodos

Si tenemos dos nodos ejecutando Kubernetes y tienen direcciones IP 192.168.1.2 y 192.168.1.3 asignados a ellos. Hay que tener en cuenta que no son parte del clúster todavía, pero cada uno de ellos tiene un solo POD desplegado. Estos PODs están conectados a una red interna y tienen sus propias direcciones IP asignadas. Si se observan las direcciones de red internas, puede ver que sean las mismas, por ejemplo 10.244.0.0 y los módulos desplegados también tienen la misma dirección. Esto no funcionará bien con los nodos que forman parte del mismo clúster, ya que los PODs tienen las mismas direcciones IP asignadas y eso generará conflictos de IP en la red. Ahora bien, ese es un problema para cuando el clúster de Kubernetes esté configurado.

Redes en Kubernetes varios nodosKubernetes no configura automáticamente ningún tipo de red para manejar estos problemas. De hecho, Kubernetes espera que establezcamos redes para cumplir con ciertos requisitos fundamentales. Los principales son que todos los contenedores/PODs en un clúster de Kubernetes deben poder comunicarse entre sí sin tener que configurar NAT. Otro requisito es que todos los nodos deben poder comunicarse con los contenedores y viceversa sin usar NAT. Kubernetes espera que configuremos una solución de red que cumpla con estos criterios.

Soluciones ya implementadas

Afortunadamente, no tenemos que configurarlo por nuestra cuenta, ya que hay múltiples soluciones preconstruidas disponibles. Algunos de ellos son las redes Cisco SCI, Cilium, Flannel, WMWare NSX T y Kaliko. Dependiendo de la plataforma en la que se esté implementando el clúster de Kubernetes, puede usar una de esas soluciones.

Redes en Kubernetes solucionCon la configuración de red personalizada, ya sea de Flannel o Kaliko, ahora se pueden administrar las redes e IPSs en los nodos y asignar una dirección de red diferente para cada red en el nodo. Esto crea una red virtual de todos los PODs y nodos donde a todos se les asigna una dirección IP única y mediante el enrutamiento simple la red de clúster permite la comunicación entre los diferentes PODs o nodos para cumplir con los requisitos de red de Kubernetes. Por lo tanto, todos los PODs ahora pueden comunicarse entre sí utilizando la dirección IP asignada.

Para ver la información de las IPs asignadas se puede usar el comando “kubectl get pods -o wide”.

Más información: https://kubernetes.io/docs/concepts/cluster-administration/networking/

0 Seguir leyendo →

Despliegues en Kubernetes

Despliegues en Kubernetes

En este artículo hablaremos sobre los despliegues en Kubernetes. Por un rato dejaremos los PODs y las réplicas y nos centraremos en implementar su aplicación en un entorno de producción. Hay muchos casos en los que nos puede ayudar Kubernetes. Por ejemplo, podemos tener un servidor web que debe implementarse en un entorno de producción. No se necesita una, sino muchas de esas instancias del servidor web en ejecución. Además, cada vez que las versiones más nuevas estén disponibles en el registro de Docker, nos gustaría actualizar las instancias sin problemas. Pero hay que tener en cuenta que no se quieren actualizar todas a la vez ya que puede afectar a los usuarios que acceden.

Es decir, se quieren actualizar una tras otra, una actualización continua. Podría ser también que una de las actualizaciones resultó en un error inesperado y hay que deshacer el cambio. Otro caso puede ser que queramos realizar múltiples cambios en el entorno, como actualizar las versiones subyacentes del servidor web, escalar el entorno o modificar las asignaciones de recursos, etc. No queremos aplicar cada cambio inmediatamente después de ejecutar el comando; si no aplicar una pausa mientras se realicen los cambios y luego reanudar para que todos los cambios se desplieguen juntos.

Todas estas capacidades están disponibles con Kubernetes. Ya sabemos que los PODs que implementan instancias únicas de las aplicaciones están encapsulados. Múltiples PODs se implementan utilizando controladores de replicación o conjuntos de réplicas. Así que ahora es el turno de la implementación, que es un objeto de Kubernetes que ocupa un lugar más alto en la jerarquía. La implementación nos brinda la capacidad de actualizar las instancias subyacentes sin problemas utilizando actualizaciones continuas, deshacer cambios y pausar y reanudar los cambios según sea necesario.

Implementación

Para realizar los despliegues en Kubernetes, al igual que con los componentes anteriores, primero creamos el archivo de definición de la implementación, el contenido del archivo de definición de implementación es similar al archivo de definición del conjunto de réplicas, excepto por el tipo. Si revisamos el contenido del archivo, tiene una versión API que es “apps/v1”, metadatos que tienen nombres y etiquetas y una especificación que tiene una plantilla, réplicas y selector. La plantilla tiene una definición de POD dentro de ella.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
    type: front-end
spec:
  template:
  metadata:
    name: myapp-pod
    labels:
      app: myapp
      type: front-end
  spec:
    containers:
      - name: nginx-container
        image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

comandos de despliegue con kubernetesUna vez que el archivo está listo, se ejecuta el comando “kubectl create -f deployment-definition.yml” especificando el archivo de definición de despliegue. Luego se puede ejecutar el comando “kubectl get deployments” para ver el despliegue recién creado. El despliegue crea automáticamente un conjunto de réplicas, por lo que si se ejecuta el comando “kubectl get replicaset”, se podrá ver un nuevo conjunto de réplicas con el nombre del despliegue.

Los conjuntos de réplica finalmente crean PODs, por lo que ejecutando el comando “kubectl get pods” se pueden ver los POD con el nombre del despliegue y el conjunto de réplicas. Hasta el momento no hay mucha diferencia entre el conjunto de réplicas y los despliegues, excepto por el hecho de que el despliegue creó un nuevo objeto de Kubernetes llamado deployment. Para ver todos los objetos creados a la vez se puede ejecutar el comando “kubectl get all”, que mostrará los despliegues creados, el conjunto de réplicas y los tres PODs que se crearon como parte del despliegue. Con más detalle se puede ejecutar “kubectl describe deployment”

Actualización y vuelta atrás

Cuando se crean despliegues en Kubernetes por primera vez, se desencadena un objeto “deployment”. Cada despliegue nuevo crea una nueva revisión del objeto “deployment”, así que llamemos a la primera, revisión 1. Cuando la aplicación se actualice, es decir, cuando la versión del contenedor se actualice a una nueva, se desencadenará una nueva implementación y se creará una nueva revisión de despliegue llamada revisión 2. Esto nos ayuda a realizar un seguimiento de los cambios realizados en nuestros despliegues y nos permite volver a una versión anterior si es necesario. Se puede ver el estado de un despliegue ejecutando el comando “kubectl rollout status <despliegue>” seguido del nombre del despliegue. Para mostrará las revisiones y el historial se ejecuta el comando “kubectl rollout history <despliegue>” seguido del nombre del despliegue.

Hay dos tipos de estrategias. Si, por ejemplo, se tienen cinco réplicas de su instancia de aplicación web implementada. Una forma de actualizarlos a una versión más nueva es destruirlos y luego crear una versión más nueva de las instancias de la aplicación. Lo que significa es destruir las cinco instancias en ejecución y luego implementar cinco nuevas instancias de la nueva versión de la aplicación. El problema es que durante el período posterior a la caída de las versiones anteriores y antes de que una versión nueva esté activada, la aplicación está inactiva y no es accesible para los usuarios. Esta estrategia se conoce como “Recreación” y, afortunadamente, no es la estrategia de despliegue predeterminada.

La segunda estrategia es donde no los destruimos todos a la vez. Eliminamos la versión anterior y presentamos una versión más nueva una por una. De esta manera, la aplicación nunca se cae y la actualización es perfecta. Esta estrategia de “Actualización continua” es la estrategia de despliegue predeterminada.

Actualización

Cuando se habla de actualizar, podrían ser cosas diferentes. Se puede actualizar la versión de una aplicación, la versión de los contenedores, sus etiquetas, el número de réplicas, etc. Como ya tenemos un archivo de definición de despliegue, es fácil para nosotros modificar estos archivos. Una vez que hacemos los cambios necesarios, ejecutamos el comando “kubectl apply -f <despliegue>” para aplicar los cambios, creando una nueva revisión del despliegue. También se puede usar el comando “kubectl set image <despliegue>” para actualizar la imagen de la aplicación, pero hacerlo de esta manera hace que el archivo de definición del despliegue no esté acorde con lo desplegado.

Para ver la diferencia entre las estrategias de recreación y de actualización continua se puede ejecutar el comando “kubectl describe”. Con ella se puede ver la información detallada sobre los despliegues. Cuando se usa la estrategia de recreación, los eventos indican que el antiguo conjunto de réplica se redujo a cero primero. Luego los nuevos conjuntos de réplica se escalan hasta cinco. Sin embargo, cuando se usa la estrategia de actualización continua, el antiguo conjunto de réplicas se redujo en uno cada vez. Luego se van ampliando simultáneamente el nuevo conjunto de réplicas de una en una.

Cuando se crea un nuevo despliegue, primero se crea un conjunto de réplicas automáticamente. A a su vez se crea la cantidad de PODs necesarios para cumplir con la cantidad de réplicas. Cuando se actualiza el objeto “deployment” de kubernetes, se crea un nuevo conjunto de réplicas en segundo plano. Y luego comienza a implementar los contenedores allí al mismo tiempo que elimina los PODs en el antiguo conjunto de réplicas. Sigue así una estrategia de actualización continua. Esto se puede ver cuando intenta enumerar los conjuntos de réplicas utilizando el comando “kubectl get replicaset”.

Revertir un cambio realizado en los despliegues en Kubernetes

Si, una vez que se actualiza la aplicación, nos damos cuenta que algo no está bien con la nueva versión y se quiere revertir la actualización. Las implementaciones de Kubernetes le permiten retroceder a una revisión anterior para deshacer el cambio. Se ejecuta el comando “kubectl rollout undo <despliegue>” destruirá el POD en el nuevo conjunto de réplicas y traerá las más antiguas al conjunto de réplicas. Así la aplicación vuelve a su formato anterior. Cuando se compara la salida del comando “kubectl get replicaset” antes y después de revertir se nota esta diferencia. Antes de la reversión, el primer conjunto de réplicas tenía 0 PODs y las nuevas réplicas tenían cinco pods siendo al contrario cuando finaliza la reversión.

Cuando utilizamos el comando “kubectl run” para crear un POD, este comando crea un despliegue y no solo un POD. Esta es la razón por la cual el resultado del comando dice que se creó el “deployment”. Solo es una forma de crear un despliegue especificando solo el nombre de una imagen y no usar un archivo de definición. El conjunto de réplica necesario y los PODs se crean automáticamente en el backend. Pero siempre se recomienda usar un archivo de definición, ya que así se puede guardar el archivo, consultarlo en el repositorio de código y modificarlo más tarde según sea necesario.

  • Creación: “kubectl create -f deployment-definition.yml”
  • Listado: “kubectl get deployments”
  • Actualización “kubectl apply -f deployment-definition.yml” y “kubectl set image deployment/myapp-deployment nginx=nginx:1.9.1”
  • Información: “kubectl rollout status deployment/myapp-deployment” y “kubectl rollout history deployment/myapp-deployment”
  • Rollback: “kubectl rollout undo deployment/myapp-deployment”

Más información en https://kubernetes.io/es/docs/concepts/workloads/controllers/deployment/

0 Seguir leyendo →

Replicación en Kubernetes

Replicación en Kubernetes

En este artículo se explica la replicación en Kubernetes y su controlador. Los controladores son los cerebros detrás de Kubernetes. Son los procesos que monitorizan el estado de los objetos y responden en consecuencia. Vamos a ver un controlador en particular, el de replicación. Lo primero es conocer qué es una réplica y por qué necesitamos un controlador de replicación.

Casos de uso

Supongamos que tenemos un solo POD ejecutando una aplicación. Si falla, los usuarios ya no podrán acceder. Para evitar que los usuarios pierdan el acceso a la aplicación es mejor tener más de una instancia funcionando al mismo tiempo. De esa forma, si uno falla, todavía tenemos la aplicación ejecutándose en la otra. El controlador de replicación ayuda a ejecutar varias instancias en el clúster, proporcionando una alta disponibilidad. Esto no significa que no se pueda usar un controlador de replicación si solo hay un POD. Incluso con un solo POD, el controlador de replicación puede ayudar a abrir automáticamente un nuevo POD cuando el existente falla. El controlador de replicación asegura que el número especificado se esté ejecutando en todo momento, incluso si es solo uno.

Otra razón por las que se necesita un controlador de replicación es crear múltiples rutas para compartir la carga entre ellas. Si tenemos un solo POD que sirve a un conjunto de usuarios, y aumentamos los PODs, pero nos quedáramos sin recursos, podríamos desplegar PODs adicionales en los otros nodos del clúster. Así que el controlador de replicación abarca varios nodos en el clúster. Nos ayuda a equilibrar la carga a través de múltiples rutas en diferentes nodos, así como a escalar nuestra aplicación.

Hay dos términos similares: controlador de replicación y conjunto de replicas (Replica set). Ambos tienen el mismo propósito pero no es lo mismo. El controlador de replicación es la tecnología más antigua y está siendo reemplazada por el conjunto de réplicas que es la nueva forma recomendada de configurar la replicación. Sin embargo, todo lo que veremos en este artículo es aplicable a ambas tecnologías. Hay diferencias menores en la forma en que funciona cada uno, pero lo veremos más adelante.

Creación de un controlador de replicación.

Se comienza creando un archivo de definición de controlador de replicación como cualquier archivo de definición de Kubernetes (ver YAML orientado a Kubernetes). Para “apiVersion” usaremos “v1” y para “kind” utilizamos “ReplicationControler”. Para el apartado de “metadata” necesitaremos datos parecidos a los PODs, que son un “name” con un nombre propio y las “labels” que se quiera, por ejemplo “app” y “type”. La siguiente es la parte más crucial del archivo de definición y es la especificación escrita como “spec”.

La sección de especificaciones define lo que hay dentro del objeto que estamos creando. En este caso, el controlador de replicación crea varias instancias de un POD. Así que hay que especificar el POD que debe replicar en una sección llamada “template”. En esta sección se define el POD que debe crear cada vez que lo necesite. La estructura de la definición es la misma que se usaba en los apartados “metadata” y “spec” en la definición de los POD. Hemos anidado los archivos de definición juntos, el controlador de replicación es el padre y la definición de POD es el hijo.

Para indicar cuántas réplicas necesitamos en el controlador de replicación hay que agregar otra propiedad a la especificación llamada “replicas” y colocando la cantidad de réplicas que necesita debajo.

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
        - name: nginx-container
          image: nginx
  replicas: 3

Ejecución de la replicación en Kubernetes

Una vez que el archivo está listo, se ejecuta el comando de creación “kubectl create -f rc-definition.yml”. Cuando se crea el controlador de replicación, primero crea la parte utilizando la plantilla de definición de PODs tantas como sea necesario (en nuestro ejemplo, 3). Se puede ver la lista de controladores de replicación creados, ejecutando el comando “kubectl get replicationcontroller”. También podemos ver la cantidad de réplicas que se necesitaban, la cantidad actual creada y cuántas de ellos están en ejecución. Para ver los PODs que fueron creados por el controlador de replicación, se ejecuta el comando “kubectl get parts”. Mostrará los tres PODs en ejecución. Tenga en cuenta que todos ellos comienzan con el nombre del controlador de replicación, que es mi “muapp-rc”, lo que indica que todos fueron creados automáticamente por el mismo controlador de replicación.

Conjunto de réplicas

Para el conjunto de réplicas, es muy similar al controlador de replicación, también tiene las cuatro secciones habituales (apiVersion, kind, metadata y spec). El valor para la versión de API es un poco diferente: “apps/v1”. Si te equivocas es probable que se produzca un error que indica que no coincide con “kind” de tipo “ReplicaSet” que es el dato que se pone en el siguiente apartado. En “metadata” agregamos “name” y “labels” igual que en anteriores ocasiones. En la sección “spec” también tendremos la definición del POD a replicar y la cantidad de replicas a crear, igual que para el controlador de replicación.

La diferencia importante entre el controlador de replicación y el conjunto de réplicas es la necesidad de un parametro llamado “selector” que ayuda al conjunto de réplicas a identificar qué partes se encuentran controlados por él. El conjunto de réplicas también puede administrar PODs que no se crearon como parte de la réplica. Se definen estos PODs por sus labels:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
        - name: nginx-container
          image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

El selector no es un campo obligatorio en el caso de un controlador de replicación, pero es también está disponible. El selector de conjunto de réplicas también ofrece muchas otras opciones para hacer coincidir etiquetas.

Etiquetas y selectores

Veamos un ejemplo para entender la relación entre etiquetas y selectores. Supongamos que implementamos tres instancias de una aplicación web en tres PODs. Nos gustaría crear un controlador de replicación o un conjunto de réplicas para garantizar que tengamos tres partes activas en cualquier momento. Entonces se puede usar para monitorizar partes existentes si ya estaban creadas o, en caso de que no se hayan creado, el conjunto de réplicas las creará. La función del conjunto de réplicas es monitorizar las partes y, si alguna de ellas falla, implementar nuevas.

Para que sepa qué PODs monitorizar, ya que podría haber cientos de PODs en el clúster que ejecutan diferentes aplicaciones, es donde entran en juego las etiquetas. Podríamos proporcionar estas etiquetas como un filtro para el conjunto de réplicas en la sección “selector” para que de esta manera, el conjunto de réplicas sepa qué partes monitorizar. El mismo concepto de etiquetas y selectores se usa en muchos otros lugares de Kubernetes. En el momento de ejecutar la replica ya hay suficientes PODs creados que coinciden con las etiquetas definidas, entonces el controlador de replicación no implementará una nueva instancia de POD.

etiquetas en la replicacion de kubernetes

Escalar el conjunto de réplicas.

Si hemos comenzado con tres réplicas y en el futuro decidimos escalar a seis hay varias formas de actualizar el conjunto de réplicas.

El primero es actualizar el número de réplicas en el archivo de definición a seis, luego ejecutar el comando “kubectl replace -f replicaset-definition.yml”.

La segunda forma de hacerlo es ejecutar el comando “kubectl scale –replicas=6 -f replicaset-definition.yml”

Otra forma es ejecutar el comnado “kubectl scale –replicas=6 replicaset myapp-replicaset”

En las dos últimas opciones el archivo no se modifica, por lo que si en un futuro vuelve a ejecutarlo, el número de réplica será de nuevo el original.

También hay opciones disponibles para escalar automáticamente el conjunto de réplicas en función de la carga, pero ese es un tema avanzado

Resumen de comandos de replicación en Kubernetes

  • Creación: kubectl create -f replicaset-definition.yml –> Comando de creación de un conjunto de réplicas o cualquier objeto en Kubernetes.
  • Listado: kubectl get replicaset –> Muestra la lista de conjuntos de réplicas creados
  • Borrado: kubectl delete replicaset myapp-replicaset –> Elimina un conjunto de réplica y todos los PODs que controla
  • Edición: kubectl replace -f replicaset-definition.yml –> Reemplaza o actualizar el conjunto de réplica y también el conjunto de réplica d
  • Escalado: kubectl scale –replicas=6 -f replicaset-definition.yml –> Escala de control de replicas

 

Más información en https://kubernetes.io/es/docs/concepts/workloads/controllers/replicationcontroller/

0 Seguir leyendo →

YAML orientado a Kubernetes

Archivos YAML orientados a Kubernetes.

Yaml en KubernetesYAML se utiliza para la configuración de despliegues con Kubernetes. Si se conocen otros formatos de estructura de datos como XML o JSON, este formato se entenderá fácilmente. Un archivo YAML orientado a Kubernetes se utiliza para representar datos. En este caso, los datos de configuración de Kubernetes. Las reglas son las mismas que ya se vieron en Docker Compose

La forma más simple es un listado de pares clave-valor separados por dos puntos + espacio (Es importante el espacio después de los dos puntos):

Fruit: Apple
Vegetable: Carrot
Liquid: Water
Meat: Chicken

Listas

Para representar una matriz se utiliza la clave seguida de dos puntos y en las siguientes lineas un guión con cada uno de los valores:

Fruits:
  - Apple
  - Orange
  - Banana

Vegetables:
  - Carrot
  - Cauliflower
  - Tomato

Diccionarios

Para representar un conjunto de propiedades agrupadas bajo un elemento (un diccionario), se coloca la clave y en las siguientes lineas las claves+valor de cada uno de ellos anteponiendo espacios. Siempre el mismo número de espacios para que estén alineados:

Banana:
  Calories: 105
  Fat: 0.4 g
  Carbs: 27 g

Grapes:
  Calories: 62
  Fat: 0.3 g
  Carbs: 27 g

Listas de diccionarios

Si algunos de los pares clave-valor tuviera diferentes espacios, YAML entendería que son propiedades de los anteriores elementos. Esto daría como resultado un error de sintaxis que le indicará que los valores no están permitidos, ya que el anterior ya tiene un valor. Cada clave puede tener un valor o un listado. Por esta razón, los espacios son importantes en un archivo YAML orientado a Kubernetes.

Si subimos de nivel, podemos tener listas que tienen diccionarios que tienen propiedades:

Fruits:
  - Banana:
    Calories: 105
    Fat: 0.4 g
    Carbs: 27 g

  - Grapes:
    Calories: 62
    Fat: 0.3 g
    Carbs: 27

Vistos los ejemplo, podem

os resumir que existen tres tipos de estructuras: Listas, Diccionarios y listas de diccionarios. El diccionario es una colección desordenada, mientras que las listas son colecciones ordenadas. Varios elementos con las mismas propiedades se pueden representar con esos elementos en diferente orden, serían los mismos. Sin embargo, si dos listas tienen los mismos elementos, pero en orden diferente, las listas son diferentes.

Por último decir que el hash (#) es el caracter de comentario, cualquier linea que comience con un # será ignorada.

Configuración de PODs con YAML orientado a Kubernetes

Kubernetes utiliza archivos YAML como entradas para la creación de objetos como POD, réplicas, servicios de implementación, etc. Todos estos siguen una estructura similar. El archivo de definición de Kubernetes siempre contiene 4 campos de nivel superior: La versión de API, tipo, metadatos y especificaciones. Estas son las propiedades de nivel superior o nivel raíz. Estos también son campos obligatorios, por lo que deben estar en el archivo de configuración:

  • apiVersion: Esta es la versión de la API de Kubernetes que se utiliza para crear los objetos. Dependiendo de lo que se esté tratando de crear, se debe usar la versión API correcta. Los valores posibles para este campo son v1, apps, beta, etc…
  • kind: Es el tipo de objeto que se quiere crear, puede ser un POD (pod), una replica (ReplicaSet), una implementación (Deployment) o un servicio (Service).
  • metadata: Son datos sobre el objeto, como sus etiquetas, su nombre, etc. Tiene estructura de un diccionario. Por lo tanto, todo lo que se encuentra debajo de los metadatos está un poco a la derecha.
  • spec:

 

Especifica el objeto que vamos a crear. La información es diferente para diferentes objetos, por lo que es importante comprender o consultar la sección de documentación para obtener el formato correcto para cada uno. Si solo creamos un POD con un solo contenedor spec sería un diccionario con una serie de propiedades específicas como son “containers” (lista de nombres e imagenes)

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx
  env:
    - name: VARIABLE_ENTORNO
      value: valor

Ejecución

Una vez creado el archivo desde la linea de comando ejecutar “kubectl create -f pod-definition.yml” para que Kubernetes cree el POD. Usando el comando “kubectl get pods” se puede ver la lista de pods disponibles. Para ver información detallada sobre el pod se ejecuta el comando “kubectl describe pod myapp-pod”. Mostrará las etiquetas, los contenedores que forman parte de él y los eventos asociados.

A la hora de crear un archivo YAML orientado a Kubernetes se puede usar una herramienta de validación como esta: https://kubeyaml.com/

0 Seguir leyendo →

PODs de Kubernetes

PODs de Kubernetes

jubernetes podsEn esta artículo hablaremos sobre los PODs de Kubernetes. Asumo que Kubernetes ya esta configurado y funcionando tal como se indicó en el artículo . También asumimos que la aplicación que quiere desplegarse está desarrollada, creada su imagen y disponible en un repositorio de Docker. La configuración realizada de Kubernetes puede ser una de un solo nodo o una configuración de múltiples nodos. Pero todos los servicios deben estar en estado de ejecución. Nuestro objetivo final es implementar nuestra aplicación en forma de contenedores. En un conjunto de máquinas que están configuradas como nodos de trabajo en un clúster. Para entender más sobre Kubernetes o su instalación se pueden leer los artículos Visión general de KubernetesInicialización de Kubernetes

Los contenedores para Kubernetes no se implementan directamente en los nodos de trabajo, se encapsulan en un objeto de Kubernetes conocido como POD. Un POD es una instancia única de una aplicación y es el objeto más pequeño que se puede crear en Kubernetes. El caso más simple de POD es el de una sola instancia. Instancia de una aplicación encapsulada en un contenedor y ejecutándose en un clúster de Kubernetes de un solo nodo. Si el número de usuarios que acceden a la aplicación aumenta, se deben agregar instancias adicionales de la aplicación para compartir la carga.

Instancias de los PODs

La primera pregunta que surge es ¿dónde añadir instancias adicionales? Debemos crear un POD completamente nuevo con una nueva instancia de la misma aplicación. Así que ahora tendremos dos instancias de la misma aplicación ejecutándose en dos PODs separados en el mismo sistema o nodo de Kubernetes. Si la carga de usuarios aumenta y el nodo actual no tiene capacidad suficiente, entonces podemos implementar PODs adicionales en otro nodo en el clúster. Así, se tendrá un nuevo nodo agregado al clúster, expandiendo la capacidad física. Los PODs generalmente tienen una relación uno a uno con los contenedores que ejecutan una aplicación. Para incrementar la capacidad se crean nuevos PODs y para reducirla, se eliminan PODs existentes. No es necesario agregar contenedores adicionales a ningún POD para escalar la aplicación.

Pero no estamos restringidos a tener un solo contenedor en un solo POD. Un POD puede tener múltiples contenedores, pero lo normal es que no tengan múltiples contenedores del mismo tipo. Si la intención es escalar una aplicación, necesitamos crear PODs adicionales. Pero a veces se puede tener un escenario en el que es necesario un contenedor auxiliar. Éste contenedor podría estar haciendo algún tipo de tarea de soporte para la aplicación. Procesar los datos ingresados por el usuario, procesar un archivo cargado por el usuario, etc… Se desea que estos contenedores auxiliares vivan junto a su contenedor de aplicaciones.

En ese caso, puede tener ambos contenedores. De este modo, cuando se crea un nuevo contenedor de aplicaciones, también se crean sus asistente. Y cuando muere, los auxiliares también mueren ya que son parte de la misma cápsula. Los contenedores del mismo POD pueden comunicarse entre sí directamente ya que están como un host local. Además comparten el mismo espacio de red y también pueden compartir el mismo espacio de almacenamiento.

Encapsulación

Supongamos que estamos desarrollando un proceso o un script para implementar una aplicación en un host Docker. Simplemente desplegaríamos la aplicación utilizando un comando “docker run”. La aplicación funciona bien y los usuarios pueden acceder a ella. Cuando aumenta la carga, implementamos más instancias de nuestra aplicación las veces que necesitemos. Pero en algún momento en el futuro, la aplicación se desarrolla más, crece y se vuelve compleja. Aparece un nuevo contenedor auxiliar que ayuda a la aplicación para procesar o buscar datos de otros lugares. con una relación uno a uno con nuestro contenedor de aplicaciones. Por lo tanto, necesitan comunicarse directamente con los contenedores de aplicaciones y acceder a los datos de esos contenedores.

Con esto necesitaríamos establecer la conectividad de red entre esos contenedores nosotros mismos. Para ello utilizamos enlaces y redes personalizadas y tendríamos que crear volúmenes compartidos entre los contenedores. Y lo más importante, necesitaríamos monitorizar el estado del contenedor de la aplicación y cuando muera eliminar manualmente manualmente el contenedor y/o los auxiliares. Cuando se despliega un nuevo contenedor, tendremos que implementar el nuevo contenedor auxiliar.

Con los PODs, Kubernetes hace todo esto automáticamente. Solo tenemos que definir en qué consisten los contenedores POD. Así los contenedores dentro de un POD de forma predeterminada tendrán acceso al mismo almacenamiento, el mismo espacio de nombres de red y el mismo destino, ya que se crearán y destruirán juntos. Incluso si la aplicación no fuera tan compleja y pudiéramos vivir con un solo contenedor, Kubernetes necesita que se creen los PODs, pero esto es bueno a largo plazo. De esta manera la aplicación estará equipada para cambios arquitectónicos y podrá escalarse en el futuro. Sin embargo, también hay que tener en cuenta que los PODs con múltiples contenedores son un caso de uso poco frecuente.

Despliegue de PODs en Kubernetes

El comando “kubectl run nombrePOD” despliega un contenedor creando un POD. Pero para crear el POD automáticamente necesita desplegar una instancia de una imagen Docker. Para eso se necesita especificar el nombre de la imagen usando el parámetro –image que se descargará desde el repositorio Docker Hub: “kubectl run nombre –image python”. Se puede configurar Kubernetes para extraer la imagen de Docker Hub público o un repositorio privado. Ahora que tenemos un POD creado, podemos ver la lista de pods disponibles en el cluster con el comando “kubectl get pod”. Si se usa con la opción “-o wide” mostrará el listado de PODs con la IP asignada a cada uno de ellos y el nodo donde esta. También se puede utilizar el comando “kubectl describe pods” para mostrar más información sobre los PODs que hay en el cluster.

Documentación oficial sobre PODs: PODs Documentation

0 Seguir leyendo →

Inicialización de Kubernetes

Inicialización de Kubernetes

En esta inicialización de Kubernetes vamos a ver diversas opciones para construir una aplicación que se ejecute en cluster. Hay muchas maneras de configurarlo, cómo configurarlo nosotros mismos localmente en nuestros ordenadores o en máquinas virtuales usando soluciones como Minikube o MicroK8s. Estas son soluciones para desarrolladores o para aquellos que solo quieren jugar y aprender la herramienta de administración. Se usa para arrancar y administrar grupos de Kubernetes. También se pueden utilizar soluciones alojadas en Hostings. Permiten configurarlo en un entorno de nube como Google cloud platform, Amazon Web Service, Microsoft Azure o Cloud de IBM. Estas son solo algunas de las muchas opciones disponibles para implementar el clúster de componentes de equipos.

La forma más fácil de comenzar es con Minikube, que puede configurarse en un sistema local. Vimos en el anterior artículo los diferentes componentes de Kubernetes, con sus nodos maestros y de trabajo. También vimos como el servidor API, el almacen etcd de valores clave, los controladores y el planificador se instalan en el maestro. El kubelet y el runtime en los nodos de trabajo. Nos llevaría mucho tiempo y esfuerzo configurar e instalar todos estos componentes en diferentes sistemas de forma individual. Minikube agrupa todos estos componentes diferentes en una sola imagen que proporciona un nodo único preconfigurado para coordinar un clúster. De esta forma podemos comenzar en cuestión de minutos.

Paquetes

El paquete completo está empaquetado en una imagen iso y está disponible en línea para descargar. Ahora no tienes que hacerlo tú mismo. Minikube proporciona una utilidad de línea de comandos ejecutable. Con ella se descargará automáticamente el ISO. Lo implementará en una plataforma de virtualización como Oracle VirtualBox, por lo que se debe tener instalado en el sistema. Para Windows se puede usar VirtualBox o Hyper V, y para Linux se puede usar VirtualBox o KVM. Para interactuar con el cluster debe tener el componente kubectl, que es una herramienta de línea de comandos. Por lo que necesita tres cosas para que esto funcione: Una máquina virtual, Kubectl y el ejecutable de Kubernetes.

Referencias

Instalación de MiniKube: https://kubernetes.io/docs/tasks/tools/install-minikube/

Instalación de VirtualBox: https://www.virtualbox.org/wiki/Downloads

Descarga de MiniKube para Windows: https://github.com/kubernetes/minikube/releases

Si se usa Minikube con una aplicación de virtualización diferente a Virtualbox, hay que especificar la opción “–vm-driver” así “minikube start –vm-driver=<driver_name>”. Para saber más sobre este tema ir a https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver

Inicialización de Kubernetes paso a paso

Vamos a ver cómo implementar una versión básica de Kubernetes con la utilidad Minikube.

Primero vamos al sitio web de Kubernetes, que es https://kubernetes.io y vamos a las instrucciones sobre cómo instalar Minikube. Así que vamos a la sección de documentación y en la parte superior izquierda aparecerá la sección de configuración. Allí es donde tenemos la documentación sobre las diversas opciones disponibles para instalar Kubernetes y comenzar con Kubernetes. Algo más abajo están las instrucciones para configurarlo en una máquina local y en diferentes hosts de terceros . Lo que nos interesa es Minikube, que es una opción para configurar Kubernetes en una máquina local.

Preparación

Antes de comenzar se debe tener la tecnología de virtualización habilitada en el BIOS del ordenador. Por lo tanto, debe asegurarse de tener la tecnología de virtualización instalada o habilitada. Para hacerlo, hay que entrar en la configuración de la BIOS y asegurarse de que esté habilitado. También se puede entrar en VirtualBox ya que es compatible con los tres sistemas operativos más comunes. Tambien se puede utilizar VMware Fusion o Hiperkit en MAC; KVM en Linux; Hyper-V en WIndows). Entrando en VIrtualBox y tratando de implementar una nueva máquina virtual haciendo clic en el botón “nuevo”. Aparecerán las Versiones de sistemas operativos que se pueden virtualizar. Si aparece alguno de 64 bits, lo más probable es que esté habilitada la tecnología de virtualización. Si no hay ninguno con 64 bits, es posible que no lo tenga habilitado.

Una vez comprobados los dos requisitos previos, el siguiente paso es instalar kube control, que es la utilidad de línea de comandos kubectl. Si en la página de Kubernetes se hace clic en instalar kubectl, y luego en el sistema operativo deseado, mostrará instrucciones para instalar kubectl. Realmente no se hace una instalación, es solo un ejecutable para descargar. Hay que guardarlo en el ordenador local

Minikube

El siguiente paso para esta inicialización de Kubernetes es instalar MiniKube haciendo click en e enlace que aparece debajo del anterior. De nuevo, no es realmente una instalación, solo descarga el ejecutable. Aparecerán las versiones disponibles, por lo que se descarga la más apropiada para el sistema operativo que esté instalado en el ordenador local. Si estamos en Windows, será necesario cambiar el nombre para añadirle la extensión .exe

Inicializacion de Kubernetes

De regreso a la documentación, en la primera página, se puede ver la Guía de inicio rápido. Las instrucciones indican que se debe ejecutar el comando de inicio de Minikube. Hay que tener en cuenta que no hay que entrar manualmente en VirtualBox y crear máquinas virtuales. Minikube extraerá automáticamente la imagen desde Internet. Luego la implementará como una máquina virtual, por lo que no hay que hacer nada manualmente. Solo asegurarse que la máquina virtual de Oracle instalada y funcionando y que se descargaron los dos ejecutables.

Al ejecutar la orden “minikube.exe start” desde la linea de comando se descarga el ISO de Minikube. Luego crea la imagen en la máquina virtual. Por último ejecuta todas las tareas de configuración, como obtener la dirección IP y configurar el clúster y localkube, etc. Básicamente, se está configurando el clúster de Kubernetes. Ahora tenemos el clúster de Kubernetes como un clúster de nodo único instalado y configurado en cuestión de minutos. Puede verse ejecutando el comando “kubectl get nodes” que  enumerará todos los nodos en un clúster y parecerá un listado con un solo nodo.

Comprobación

Para asegurarse que todo está funcionando se puede ejecutar el comando “kubectl run hello-minikube –image=k8s.gcr.io/echoserver:1.4 –port=8080”. Si se ejecuta ahora el comando “kubectl get pods”, se ve que el pod está ejecutándose que es básicamente un contenedor. En realidad es un servidor web, por lo que hay que acceder a la página web para ver su funcionamiento. Pero antes hay que ejecutar “kubectl expose deployment hello-minikube –type=NodePort” para hacerlo visible. Para conocer la URL donde debemos ir se ejecuta el comando “minikube service hello-minikube –url” que nos dará una URL en formato http://<IP>:<PUERTO> para acceder a la dirección donde está expuesta la aplicación. Si se usa esa combinación en un navegador, se accede a la página web.

Antes de terminar esta inicialización de Kubernetes, vamos a limpiar. Así que se ejecuta el comando “cubectl delete deployment hello-minicube”

0 Seguir leyendo →

Visión general de Kubernetes

Visión general de Kubernetes

Vamos a ver una visión general de Kubernetes, también conocido como K8s. Fue construido por Google en base a su experiencia en la ejecución de contenedores. Ahora es un proyecto de código abierto y es una de las mejores y más populares tecnologías de organización de contenedores. La página oficial es https://kubernetes.io/

Contenedores y su organización.

Para entender qué son los contenedores nos vamos a centrar en los más populares, los contenedores de Docker. Para aprender más sobre Docker puede acudir a los artículos sobre este tema que hay en este blog:

Introducción a Docker: https://www.statdeveloper.com/primeros-pasos-con-docker/

Imagenes de Docker: https://www.statdeveloper.com/creacion-de-imagenes-para-docker/

Docker Compose: https://www.statdeveloper.com/docker-compose/

Automatización de despliegue en Docker: https://www.statdeveloper.com/automatizacion-de-despliegues-en-docker/

En resumen, podemos decir que Docker es un proyecto para automatizar el despliegue de aplicaciones dentro de contenedores. Proporciona una capa adicional de abstracción y automatización de aplicaciones en múltiples sistemas operativos.​

Mediante el uso de contenedores, los recursos pueden ser aislados y restringidos. Permite otorgar a los procesos la capacidad de tener una visión propia del sistema operativo con su propio identificador. Aisla la estructura del sistema de archivos, y las interfaces de red. Todos los contenedores ejecutándose en un mismo Host comparten el mismo núcleo, pero cada contenedor está restringido a usar una cantidad definida de recursos como CPU, memoria y E / S.

Gestión de despliegues

vision general de kubernetesTradicionalmente, los desarrolladores desarrollaron aplicaciones y luego las entregan a los DevOps para implementarlo y administrarlo en entornos de producción. Lo hacen proporcionando un conjunto de instrucciones, como información sobre cómo se deben configurar los hosts, qué requisitos previos se deben instalar en el host y cómo se deben configurar las dependencias, etc.

El equipo de operaciones utiliza esta guía para configurar la aplicación. Dado que el equipo de operaciones no desarrolló la aplicación, suelen tener dificultades para configurarla. Cuando encuentran un problema, trabajan con los desarrolladores para resolverlo.

Con Docker, una parte importante del trabajo involucrado en la configuración de la infraestructura ahora está en manos de los desarrolladores. La guía que los desarrolladores crearon ahora se puede agrupar fácilmente en un archivo acoplable para crear una imagen para las aplicaciones. Esta imagen ahora se puede ejecutar en cualquier plataforma de contenedor y se garantiza que se ejecutará de la misma manera en todas partes.

El equipo de operaciones ahora puede usar la imagen para implementar la aplicación. Dado que la imagen ya estaba funcionando cuando el desarrollador la creó y las operaciones no la están modificando, continúa funcionando de la misma manera cuando se implementa en producción.

Visión general de la Estructura en Kubernetes

Para ver la estructura de Kubernetes vamos a empezar con los nodos. Un nodo es una máquina, física o virtual en la que está instalado Kubernetes. Un nodo es una máquina de trabajo y ahí es donde Kubernetes lanzará los contenedores. Si el nodo en el que se ejecuta la aplicación falla, la aplicación se cae. Por lo tanto, es mejor tener más de un nodo. Un clúster es un conjunto de nodos agrupados. De esta manera, si falla un nodo, todavía se puede acceder a la aplicación desde los otros nodos. Además, tener múltiples nodos ayuda a compartir la carga.

Para administrar el clúster de nodos, almacenar la información sobre los miembros del clúster, monitorizarlos o mover la carga de trabajo cuando un nodo falla existe el Maestro. El maestro es otro nodo con Kubernetes que está configurado para vigilar los nodos en el clúster y es responsable de la orquestación real de los contenedores en los nodos de trabajo.

Componentes

Cuando se instala Kubernetes en un sistema, se instalan varios componentes. Un servicio Kubelet, un servidor API y un servicio etcd,

API Server: El servidor API actúa como el front-end para Kubernetes. Los usuarios, los dispositivos de administración, las interfaces de línea de comandos, todos hablan con el servidor API para interactuar con el clúster de Kubernetes.

etcd Key-value store: El almacén distribuido de claves de valores etcd almacena todos los datos utilizados para administrar el clúster. Cuando se tienen múltiples nodos y múltiples Maestros en un clúster, etcd almacena toda esa información en todos los nodos del clúster de manera distribuida. Etcd es responsable de implementar bloqueos dentro del clúster para garantizar que no haya conflictos entre los Maestros.

Scheduler: El Programador es responsable de distribuir el trabajo o los contenedores en varios nodos. Busca contenedores recién creados y los asigna a nodos.

Controllers: Los controladores son el cerebro detrás de la organización. Son responsables de ver y responder cuando los nodos, contenedores o puntos finales caen. Los controladores toman decisiones para traer nuevos contenedores en tales casos.

Container runtime: Es el software subyacente que se utiliza para ejecutar contenedores. En nuestro caso vamos a utilizar Docker. Pero también hay otras opciones como Rocket o CRI-O.

Kubelet: Es el agente que se ejecuta en cada nodo del clúster. Es el agente responsable de asegurarse de que los contenedores se ejecuten en los nodos como se esperaba.

Distribución en la visión general de Kubernetes.

Hemos visto que hay dos tipos de servidores (Master y Worker)  y un conjunto de componentes que componen Kubernetes.

En el nodo de trabajo es donde se alojan los contenedores y para ejecutar los contenedores necesitamos que se instale el Container runtime (Docker). También tiene el agente Kubelet que es el encargado de interactuar con un maestro.

El servidor maestro tiene el API server y eso es lo que lo hace maestro. Los trabajadores usan este componente para enviar información y recoger las acciones solicitadas por el maestro. Toda la información recopilada se almacena en el almacén de valores clave etc key-value store en el maestro. El maestro también tiene el Controller y el Scheduler.

Utilidades de línea de comando

También vamos a ver un poco sobre una de las utilidades de línea de comando conocida como kube o kubectl. La herramienta kubectl se usa para implementar y administrar aplicaciones en un clúster de Kubernetes. Para obtener información del clúster, para obtener el estado de otros nodos en el clúster y para administrar muchas otras cosas. El comando “kubectl run <aplicacion>” se usa para implementar una aplicación en el clúster. El comando “kubectl cluster-info” se usa para ver información sobre el clúster y el comando “kubectl get-nodes” se usa para enumerar todos los nodos que forman parte del clúster.

0 Seguir leyendo →

Automatización de despliegues en Docker

Docker Orchestration: Automatización de despliegues en Docker

Automatización de despliegues en DockerLa automatización de despliegues en Docker también se denomina “Docker Orchestration. Hasta ahora hemos visto que con Docker puede ejecutar una sola instancia de la aplicación con un simple comando “Docker run” (ver Práctica con el comando run de Docker). Por ejemplo, para ejecutar una aplicación basada en node js, está en el comando docker run node js. Pero esa es solo una instancia de la aplicación en un host docker. Si aumenta el número de usuarios y esa instancia ya no puede manejar la carga, se implementa una instancia adicional ejecutando el comando docker run varias veces. Es algo que tiene que hacerse manualmente. Se debe vigilar de cerca la carga y el rendimiento de la aplicación e implementar instancias adicionales. Y si un contenedor fallara, hay que ser capaz de detectarlo y ejecutar el comando docker run nuevamente para implementar otra instancia de esa aplicación. 

Pero, si el host falla y es inaccesible entonces los contenedores alojados en ese host también se vuelven inaccesibles. Para resolver este problema se necesitaría un ingeniero dedicado que pueda sentarse y monitorear el funcionamiento y el estado de los contenedores y tomar las medidas necesarias para remediar la situación. Pero cuando se tienen implementadas grandes aplicaciones con decenas de miles de contenedores, ese no es un enfoque práctico.

Solución

Por lo tanto, para la automatización de despliegues en Docker se pueden crear scripts para ayudar a abordar estos problemas hasta cierto punto. La orquestación de contenedores es solo una solución para eso. Es una solución que consiste en un conjunto de herramientas y scripts que pueden ayudar a alojar contenedores en un entorno de producción. Por lo general, una solución de orquestación de contenedores consta de múltiples hosts Docker que pueden alojar contenedores de esa manera. Si uno falla, se podría acceder a través de los demás. Una solución de organización de contenedores le permite implementar fácilmente cientos o miles de instancias de una aplicación con un solo comando. Este es un comando utilizado para el enjambre Docker. 

Analizaremos el comando en sí un poco. Algunas soluciones de orquestación pueden ayudar a aumentar automáticamente el número de instancias. Cuando los usuarios aumentan y reducir el número de instancias cuando la demanda disminuye. Algunas soluciones incluso pueden ayudar a agregar automáticamente hosts adicionales para admitir la carga del usuario y no solo a agrupar y escalar las soluciones de orquestación de contenedores. También brinda soporte para la creación de redes avanzadas entre los contenedores en diferentes hosts, así como equilibrar la carga de las solicitudes entre los diferentes contenedores. También brindan soporte para compartir almacenamiento entre el host, así como soporte para la gestión de la configuración y la seguridad dentro del clúster.

Aplicaciones para la automatización de despliegues en Docker

Hoy en día, existen múltiples soluciones de orquestación de contenedores. Docker tiene Docker Swarm, Google los Kubernetes o Apache ofrece MESOS. Aunque Docker Swarm es realmente fácil de configurar y de iniciar, carece de algunas de las funciones avanzadas de escalado automático requeridas para aplicaciones complejas de gran producción. Por otro lado, MESOS es bastante difícil de configurar y de iniciar, pero admite muchas características avanzadas. Kubernetes podría decirse que es el más popular de todos, aunque es un poco difícil de configurar y de iniciar, ofrece muchas opciones para personalizar las implementaciones y tiene soporte de muchos proveedores diferentes, ya que es compatible con todos los proveedores de servicios en la nube como GCP, Azure y AWS. Es uno de los proyectos mejor clasificados en github.

Docker Swarm

Docker Swarn tiene muchos conceptos que cubrir y requiere su propio artículo, pero vamos a explicar rápidamente algunos de los detalles básicos para tener una breve idea de lo que es.

Puede combinar varias máquinas Docker en un solo cluster. Se encarga de la automatización de despliegues en Docker distribuyendo sus servicios y sus instancias de aplicación en hosts separados para una alta disponibilidad y para el equilibrio de carga en diferentes sistemas y hardware. Para configurar Docker Swarm primero se debe tener varios hosts con Docker instalados. Luego se debe designar a uno de ellos para que sea el gerente, el maestro o el administrador de Swarm y otros como esclavos o trabajadores. Una vez hecho se ejecuta el comando “docker swarm init” en el administrador de Swarm para que se inicialice el administrador. La respuesta de ese comando proporcionará la orden que se debe ejecutar en los trabajadores para unirse al administrador.

Después de unirse al cluster, los trabajadores (también conocidos como nodos) estarán listos para crear servicios e implementarlos en el clúster de Swarm ejecutando el comando “docker run” específico. Esto crea una nueva instancia de contenedor de la aplicación.

Automatización

Para ejecutar varias instancias de un servidor sería ejecutar el comando “docker run” en cada nodo de trabajo, pero eso no es lo ideal, ya que podría tener que iniciar sesión en cada nodo. Además tendría que configurar el balanceo de carga y monitorizar el estado de cada instancia. Por último, si las instancias fallan, hay que reiniciarlas a mano. Sería una tarea imposible, por lo que la orquestación de Docker Swarm hace todo esto por nosotros. 

El componente clave de la orquestación de Swarm es el servicio Docker. Es una o más instancias de una sola aplicación o servicio que se ejecuta en todo el sitio, en todos los nodos en el clúster de Swarmbre. Se podría crear un servicio Docker para ejecutar varias instancias de un servidor web en todos los nodos de trabajo en mi clúster de Swarm. Para esto, se ejecuta el comando “docker service create –replicas=<N> web-server” en el nodo del administrador.

Como se ve, se especifica el nombre de la imagen y se usa la opción “replicas” para especificar el número de instancias del servidor web que deben ejecutarse. Con esto se obtienen instancias del servidor web distribuidas en los diferentes nodos de trabajo. El comando “service” de creación del servicio es similar al comando de ejecución “run”, ya que tiene las mismas opciones, como la variable de entorno -e, -p para publicar puertos, la opción de red para conectar el contenedor a una red, etc. 

Kubernetes

Con Docker se puede ejecutar una sola instancia de una aplicación usando comando “docker run”. Con Kubernetes, usando su linea de comando, conocida como control de kube. Ayuda a la automatización de despliegues en Docker ejecutando mil instancias de la misma aplicación con un solo comando (kubectl run –replicas=1000 web-server). Puede ampliarlo hasta dos mil o que lo haga automáticamente. Las instancias y la infraestructura se pueden ampliar y reducir en función de la carga del usuario. Se pueden acumular instancias de la aplicación de forma continua, una a una con un solo comando. Si algo sale mal, puede ayudar a revertir las imágenes con un solo comando. Kubernetes puede ayudar a probar nuevas características de una aplicación actualizando solo un porcentaje de las instancias creando nodos de prueba. 

La arquitectura Kubernetes proporciona soporte para muchas redes diferentes y el almacenamiento cubre cualquier estructura de almacenamiento. Admite muchas variedades de mecanismos de autenticación y autorización. Los principales proveedores de servicios en la nube tienen soporte nativo para Kubernetes. Los usuarios de Kubernetes usan Docker para alojar aplicaciones en forma de contenedores. Pero no tiene por qué ser Docker, ya Kubernetes admite como nativos otros como un Rocket o CRI-O.

Arquitectura

La arquitectura de Kubernetes es un clúster compuesto por un conjunto de nodos. Un nodo es una máquina física o virtual en la que se instala un conjunto de herramientas de Kubernetes. El nodo es una máquina de trabajo y es donde Kubernetes lanzará los contenedores. Si el nodo en el que el la aplicación se está ejecutando falla, la aplicación deja de funcionar, por lo que se debe tener más de 1 nodo. Un clúster es un conjunto de nodos agrupados, si un nodo falla, la aplicación es accesible desde otros nodos.

El responsable de administrar este clúster es quien tiene la información sobre el resto de los miembros. Es quien monitoriza los nodos y quien mueve la carga de trabajo. Este es el master. El master es un nodo con los componentes de control de Kubernetes instalados. El master vigila los nodos en el clúster y es responsable de la orquestación real de los contenedores.

Cuando se instala Kubernetes en un sistema, en realidad está instalando los siguientes componentes: un servidor API, un servidor etcd, un servicio kubelet, un motor de tiempo de ejecución de contenedores (Docker), un grupo de controladores y el planificador (Scheduler).

Componentes

El servidor API actúa como interfaz para Kubernetes. La línea de comandos hablan con el servidor API para interactuar con el clúster de componentes. El etcd es un almacén de valores de clave distribuido utilizado por Kubernetes para almacenar todos los datos utilizados para administrar el clúster. Cuando hay múltiples nodos y múltiples maestros en un clúster, etcd almacena toda esa información en todos los nodos en el clúster de manera distribuida. etcd es responsable de implementar registros dentro del clúster para garantizar que no haya conflictos entre los maestros.

El planificador es responsable de distribuir el trabajo de los contenedores en múltiples nodos, busca contenedores recién creados y los asigna a los nodos. Los controladores son el cerebro detrás de la orquestación, son responsables de responder cuando los contenedores de nodos caen. Los controladores toman decisiones para abrir nuevos contenedores en esos casos. El motor de tiempo de ejecución (runtime container) es el software que se utiliza para ejecutar contenedores, que, en nuestro en caso, es Docker. Finalmente kubelet es el agente que se ejecuta en cada nodo del clúster y es el responsable de asegurarse de que los contenedores se estén ejecutando en las nodos tal como se esperaba.

La utilidad de línea de comando conocida como kube, ya que también es una herramienta de control. kube se usa para implementar y administrar aplicaciones en un clúster de Kubernetes, para obtener información relacionada con el clúster, para obtener el estado de los nodos en el clúster y muchas otras cosas. 

El comando “kubectl run <aplicacion>” se usa para implementar una aplicación en el clúster, el comando “kubectl cluster-info” se usa para ver información sobre el clúster y el comando “kubectl get nodes” muestra los nodos que forman parte del clúster.

Hay más información en la web de Kubernetes: https://kubernetes.io/es/

 

0 Seguir leyendo →