Docker Swarm, Kubernetes y Mesos son los marcos de orquestación de contenedores más populares. En su charla, Arun Gupta compara los siguientes aspectos de Docker, Swarm y Kubernetes:
- Desarrollo local.
- Funciones de despliegue.
- Aplicaciones multicontenedor.
- Descubrimiento de servicios.
- Escalar el servicio.
- Tareas de ejecución única.
- Integración con Maven.
- Actualización "continua".
- Creación de un clúster de base de datos Couchbase.
Como resultado, obtendrá una comprensión clara de lo que cada herramienta de orquestación tiene para ofrecer y aprenderá a utilizar estas plataformas de forma eficaz.
Arun Gupta es el tecnólogo jefe de productos de código abierto en Amazon Web Services, quien ha estado desarrollando las comunidades de desarrolladores de Sun, Oracle, Red Hat y Couchbase durante más de 10 años. Tiene una amplia experiencia trabajando en la dirección de equipos multifuncionales que desarrollan e implementan estrategias para campañas y programas de marketing. Lideró equipos de ingenieros de Sun, es uno de los fundadores del equipo Java EE y creador de la sucursal estadounidense de Devoxx4Kids. Arun Gupta es autor de más de 2 publicaciones en blogs de TI y ha dado charlas en más de 40 países.
La línea 55 contiene un COUCHBASE_URI que apunta a este servicio de base de datos, que también se creó utilizando el archivo de configuración de Kubernetes. Si observa la línea 2, puede ver el tipo: Servicio es el servicio que estoy creando llamado Couchbase-service, y el mismo nombre aparece en la línea 4. A continuación se muestran algunos puertos.
Las líneas clave son 6 y 7. En el servicio digo: "¡Oye, estas son las etiquetas que estoy buscando!", Y estas etiquetas no son más que nombres de pares de variables, y la línea 7 apunta a mi Couchbase-rs-pod. solicitud. Los siguientes son los puertos que brindan acceso a estas mismas etiquetas.
En la línea 19 creo un nuevo tipo ReplicaSet, la línea 31 contiene el nombre de la imagen y las líneas 24-27 apuntan a los metadatos asociados con mi pod. Esto es exactamente lo que busca el servicio y a lo que se debe realizar la conexión. Al final del archivo hay una especie de conexión entre las líneas 55-56 y 4, que dice: “¡usa este servicio!”
Entonces, comienzo mi servicio cuando hay un conjunto de réplicas y, como cada conjunto de réplicas tiene su propio puerto con la etiqueta correspondiente, se incluye en el servicio. Desde el punto de vista de un desarrollador, simplemente llama al servicio, que luego utiliza el conjunto de réplicas que necesita.
Como resultado, tengo un pod WildFly que se comunica con el backend de la base de datos a través del servicio Couchbase. Puedo usar la interfaz con varios pods WildFly, que también se comunica con el backend de Couchbase a través del servicio Couchbase.
Más adelante veremos cómo un servicio ubicado fuera del cluster se comunica a través de su dirección IP con elementos que se encuentran dentro del cluster y tienen una dirección IP interna.
Entonces, los contenedores sin estado son geniales, pero ¿qué tan bueno es usar contenedores con estado? Veamos la configuración del sistema para contenedores persistentes o con estado. En Docker, existen 4 enfoques diferentes para el diseño del almacenamiento de datos a los que debes prestar atención. El primero es implícito por contenedor, lo que significa que cuando se utilizan contenedores satateful Couchbase, MySQL o MyDB, todos comienzan con el Sandbox predeterminado. Es decir, todo lo que se almacena en la base de datos se almacena en el propio contenedor. Si el contenedor desaparece, los datos desaparecen junto con él.
El segundo es explícito por contenedor, cuando crea un almacenamiento específico con el comando de creación de volumen de Docker y almacena datos en él. El tercer enfoque por host está asociado con el mapeo de almacenamiento, cuando todo lo almacenado en el contenedor se duplica simultáneamente en el host. Si el contenedor falla, los datos permanecerán en el host. Este último es el uso de varios hosts Multi-Host, lo cual es recomendable en la etapa de producción de varias soluciones. Digamos que sus contenedores con sus aplicaciones se están ejecutando en el host, pero desea almacenar sus datos en algún lugar de Internet y para ello utiliza el mapeo automático para sistemas distribuidos.
Cada uno de estos métodos utiliza una ubicación de almacenamiento específica. Los datos implícitos y explícitos por contenedor se almacenan en el host en /var/lib/docker/volumes. Cuando se utiliza el método por host, el almacenamiento se monta dentro del contenedor y el contenedor en sí se monta en el host. Para multihosts se pueden utilizar soluciones como Ceph, ClusterFS, NFS, etc.
Si falla un contenedor persistente, el directorio de almacenamiento se vuelve inaccesible en los dos primeros casos, pero en los dos últimos casos se mantiene el acceso. Sin embargo, en el primer caso, puede acceder al repositorio a través de un host Docker que se ejecuta en una máquina virtual. En el segundo caso, los datos tampoco se perderán, porque has creado un almacenamiento explícito.
Si el host falla, el directorio de almacenamiento no está disponible en los primeros tres casos; en el último caso, la conexión con el almacenamiento no se interrumpe. Finalmente, la función compartida queda completamente excluida para el almacenamiento en el primer caso y es posible en el resto. En el segundo caso, puede compartir almacenamiento dependiendo de si su base de datos admite almacenamiento distribuido o no. En el caso de Por-Host, la distribución de datos solo es posible en un host determinado, y para un host múltiple se proporciona mediante la expansión del clúster.
Esto debe tenerse en cuenta al crear contenedores con estado. Otra herramienta Docker útil es el complemento Volumen, que funciona según el principio de "baterías presentes, pero deben ser reemplazadas". Cuando inicia un contenedor Docker, dice: "¡Oye, una vez que inicia un contenedor con una base de datos, puede almacenar sus datos en este contenedor!" Esta es la característica predeterminada, pero puedes cambiarla. Este complemento le permite utilizar una unidad de red o algo similar en lugar de una base de datos contenedora. Incluye un controlador predeterminado para el almacenamiento basado en host y permite la integración de contenedores con sistemas de almacenamiento externos como Amazon EBS, Azure Storage y discos persistentes GCE.
La siguiente diapositiva muestra la arquitectura del complemento Docker Volume.
El color azul representa el cliente Docker asociado con el host Docker azul, que tiene un motor de almacenamiento local que le proporciona contenedores para almacenar datos. El verde indica el cliente de complemento y el demonio de complemento, que también están conectados al host. Brindan la oportunidad de almacenar datos en un almacenamiento de red del tipo de Storage Backend que necesite.
El complemento Docker Volume se puede utilizar con el almacenamiento Portworx. El módulo PX-Dev es en realidad un contenedor que usted ejecuta y que se conecta a su host Docker y le permite almacenar datos fácilmente en Amazon EBS.
El cliente Portworx le permite monitorear el estado de varios contenedores de almacenamiento que están conectados a su host. Si visitas mi blog, podrás leer cómo aprovechar Portworx al máximo con Docker.
El concepto de almacenamiento en Kubernetes es similar al de Docker y está representado por directorios a los que puede acceder su contenedor en un pod. Son independientes de la vida útil de cualquier contenedor. Los tipos de almacenamiento más comunes disponibles son hostPath, nfs, awsElasticBlockStore y gsePersistentDisk. Echemos un vistazo a cómo funcionan estas tiendas en Kubernetes. Normalmente, el proceso de conectarlos consta de 3 pasos.
La primera es que alguien del lado de la red, generalmente un administrador, le proporciona almacenamiento persistente. Hay un archivo de configuración PersistentVolume correspondiente para esto. A continuación, el desarrollador de la aplicación escribe un archivo de configuración llamado PersistentVolumeClaim, o una solicitud de almacenamiento de PVC, que dice: "Tengo 50 GB de almacenamiento distribuido aprovisionados, pero para que otras personas también utilicen su capacidad, le digo a este PVC que actualmente tengo". sólo necesita 10 GB". Finalmente, el tercer paso es que tu solicitud se monte como almacenamiento, y la aplicación que tiene el pod, o conjunto de réplicas, o algo similar, comience a usarlo. Es importante recordar que este proceso consta de los 3 pasos mencionados y es escalable.
La siguiente diapositiva muestra el contenedor de persistencia de Kubernetes de la arquitectura de AWS.
Dentro del rectángulo marrón que representa el clúster de Kubernetes, hay un nodo maestro y dos nodos trabajadores, indicados en amarillo. Uno de los nodos trabajadores contiene un pod naranja, almacenamiento, un controlador de réplica y un contenedor Docker Couchbase verde. Dentro del clúster, encima de los nodos, un rectángulo violeta indica el Servicio accesible desde el exterior. Esta arquitectura se recomienda para almacenar datos en el propio dispositivo. Si es necesario, puedo almacenar mis datos en EBS fuera del clúster, como se muestra en la siguiente diapositiva. Este es un modelo típico de escalamiento, pero hay un aspecto financiero a considerar al usarlo: almacenar datos en algún lugar de la red puede ser más costoso que en un host. A la hora de elegir soluciones de contenedorización, este es uno de los argumentos de peso.
Al igual que con Docker, puedes utilizar contenedores Kubernetes persistentes con Portworx.
Esto es lo que en la terminología actual de Kubernetes 1.6 se llama "StatefulSet": una forma de trabajar con aplicaciones con estado que procesa eventos sobre la parada del Pod y la realización de Graceful Shutdown. En nuestro caso, dichas aplicaciones son bases de datos. En mi blog puedes leer cómo crear un StatefulSet en Kubernetes usando Portworx.
Hablemos del aspecto del desarrollo. Como dije, Docker tiene 2 versiones: CE y EE, en el primer caso estamos hablando de una versión estable de Community Edition, que se actualiza una vez cada 3 meses, a diferencia de la versión EE actualizada mensualmente. Puedes descargar Docker para Mac, Linux o Windows. Una vez instalado, Docker se actualizará automáticamente y es muy fácil comenzar.
Para Kubernetes, prefiero la versión Minikube: es una buena manera de comenzar con la plataforma creando un clúster en un solo nodo. Para crear clústeres de varios nodos, la elección de versiones es más amplia: son kops, kube-aws (CoreOS+AWS), kube-up (obsoleto). Si desea utilizar Kubernetes basado en AWS, le recomiendo unirse a AWS SIG, que se reúne en línea todos los viernes y publica una variedad de materiales interesantes sobre cómo trabajar con AWS Kubernetes.
Veamos cómo se realiza la actualización continua en estas plataformas. Si hay un grupo de varios nodos, utiliza una versión específica de la imagen, por ejemplo, WildFly:1. Una actualización continua significa que la versión de la imagen se reemplaza secuencialmente por una nueva en cada nodo, uno tras otro.
Para hacer esto, utilizo el comando Docker Service Update (nombre del servicio), en el que especifico la nueva versión de la imagen WildFly:2 y el método de actualización update-parallelism 2. El número 2 significa que el sistema actualizará 2 imágenes de la aplicación. al mismo tiempo, luego una actualización de 10 segundos retrasa 10 segundos, después de lo cual las siguientes 2 imágenes se actualizarán en 2 nodos más, etc. Este sencillo mecanismo de actualización continua se proporciona como parte de Docker.
En Kubernetes, una actualización continua funciona así. El controlador de replicación rc crea un conjunto de réplicas de la misma versión y cada pod en este webapp-rc recibe una etiqueta ubicada en etcd. Cuando necesito un pod, utilizo el servicio de aplicaciones para acceder al repositorio etcd, que me proporciona el pod usando la etiqueta especificada.
En este caso, tenemos 3 pods en el controlador de replicación ejecutando la aplicación WildFly versión 1. Al actualizar en segundo plano, se crea otro controlador de replicación con el mismo nombre e índice al final - - xxxxx, donde x son números aleatorios, y con las mismas etiquetas. Ahora el Servicio de aplicaciones tiene tres pods con la versión anterior de la aplicación y tres pods con la nueva versión en el nuevo controlador de replicación. Después de esto, se eliminan los pods antiguos, se cambia el nombre del controlador de replicación con los nuevos pods y se pone en funcionamiento.
Pasemos al seguimiento. Docker tiene muchos comandos de monitoreo integrados. Por ejemplo, la interfaz de línea de comandos de Docker Container Statistics le permite mostrar información sobre el estado de los contenedores en la consola cada segundo: uso del procesador, uso del disco, carga de la red. La herramienta Docker Remote API proporciona datos sobre cómo se comunica el cliente con el servidor. Utiliza comandos simples, pero se basa en la API REST de Docker. En este caso, las palabras REST, Flash, Remote significan lo mismo. Cuando te comunicas con el host, es una API REST. La API remota de Docker le permite obtener más información sobre la ejecución de contenedores. Mi blog describe los detalles del uso de este monitoreo con Windows Server.
La supervisión de los eventos del sistema Docker cuando se ejecuta un clúster de múltiples hosts permite obtener datos sobre una falla del host o una falla del contenedor en un host específico, servicios de escalado y similares. A partir de Docker 1.20, incluye Prometheus, que integra puntos finales en aplicaciones existentes. Esto le permite recibir métricas a través de HTTP y mostrarlas en paneles.
Otra característica de monitoreo es cAdvisor (abreviatura de asesor de contenedores). Analiza y proporciona datos de rendimiento y uso de recursos de contenedores en ejecución, proporcionando métricas de Prometheus listas para usar. Lo especial de esta herramienta es que sólo proporciona datos de los últimos 60 segundos. Por lo tanto, debe poder recopilar estos datos y colocarlos en una base de datos para poder monitorear un proceso a largo plazo. También se puede utilizar para mostrar gráficamente las métricas del panel utilizando Grafana o Kibana. Mi blog tiene una descripción detallada de cómo usar cAdvisor para monitorear contenedores usando el panel de Kibana.
La siguiente diapositiva muestra cómo se ve la salida del punto final de Prometheus y las métricas disponibles para mostrar.
En la parte inferior izquierda verá métricas para solicitudes HTTP, respuestas, etc., a la derecha está su visualización gráfica.
Kubernetes también incluye herramientas de monitoreo integradas. Esta diapositiva muestra un clúster típico que contiene un nodo maestro y tres nodos trabajadores.
Cada uno de los nodos de trabajo contiene un cAdvisor que se inicia automáticamente. Además, existe Heapster, un sistema de recopilación de métricas y monitoreo del rendimiento compatible con la versión 1.0.6 y superior de Kubernetes. Heapster le permite recopilar no solo métricas de rendimiento de cargas de trabajo, pods y contenedores, sino también eventos y otras señales generadas por todo el clúster. Para recopilar datos, se comunica con el Kubelet de cada módulo, almacena automáticamente la información en la base de datos de InfluxDB y la envía como métricas al panel de Grafana. Sin embargo, tenga en cuenta que si utiliza miniKube, esta función no está disponible de forma predeterminada, por lo que tendrá que utilizar complementos para el seguimiento. Por lo tanto, todo depende de dónde ejecuta los contenedores y qué herramientas de monitoreo puede usar de forma predeterminada y cuáles necesita instalar como complementos separados.
La siguiente diapositiva muestra paneles de Grafana que muestran el estado de ejecución de mis contenedores. Hay bastantes datos interesantes aquí. Por supuesto, existen muchas herramientas comerciales de monitoreo de procesos de Docker y Kubernetes, como SysDig, DataDog, NewRelic. Algunas de ellas tienen un periodo de prueba gratuito de 30 años, para que puedas probar y encontrar la que más te convenga. Personalmente, prefiero usar SysDig y NewRelic, que se integran bien con Kubernetes. Existen herramientas que se integran igualmente bien en las plataformas Docker y Kubernetes.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com