Pod patrones de diseño recipiente y apreciado
Este papel de acabado lecciones de la tecnología de nube nativa clase abierta CNCF y Alibaba organizado conjuntamente 4: comprensión de los patrones de la vaina y el diseño del envase. El curso, Alibaba Un experto técnico de alto nivel, CNCF oficial Embajador Zhang Lei es por eso que necesitamos introducir el mecanismo de aplicación de la vaina, la vaina y patrones de diseño de contenedores detallada, no se puede perder.
Los compartir gira en curso alrededor de las tres partes siguientes:
- ¿Por qué la vaina;
- mecanismo de aplicación de la vaina;
- contenedores patrones detallados de diseño.
En primer lugar, ¿por qué la necesidad de la vaina
El concepto básico del contenedor
Ahora miramos a la primera pregunta: ¿Por qué necesitamos la vaina? Sabemos que la vaina es Kubernetes proyecto dentro de un concepto muy importante, sino también una unidad atómica muy importante de la programación, pero ¿por qué necesitamos un concepto? Cuando usamos envase acoplable es, no hay tal declaración. De hecho, si se quiere entender la vaina, hay que entender primero el contenedor, por lo que en primer lugar para mirar el concepto de contenedor:
La naturaleza del recipiente es en realidad un proceso, se aísla una vista, proceso con recursos limitados.
recipiente de proceso que PID = 1 es la propia aplicación, cuyos medios de administración de máquinas virtuales son iguales a la infraestructura de gestión, ya que estamos en la gestión de la máquina, pero la gestión del recipiente era igual a la gestión directa de la propia aplicación. Esto es lo inmutable, dijo antes de que un mejor encarna la infraestructura, y esta vez, su aplicación es equivalente a su infraestructura, que debe ser inmutable.
En el caso del ejemplo anterior premisa, Kubernetes ¿qué es? Sabemos que muchas personas dicen que es Kubernetes era de la nube de sistema operativo, esto es muy interesante, porque si es así, es esta imagen la vasija del paquete de instalación del software del sistema operativo, una analogía es la relación entre ellos.
Ejemplos reales de los sistemas operativos
Si Kubernetes es el sistema operativo, entonces podríamos fijamos en el ejemplo del sistema operativo real.
Ejemplos Hay un programa llamado Helloworld, Helloworld este programa se compone realmente de un conjunto de procesos, necesidad de tomar nota aquí que el proceso es prácticamente idéntico al hilo de Linux.
Debido a que Linux es un proceso ligero de hilo, por lo que si usted va a ver Helloworld en pstree desde un sistema Linux, verá este Helloworld en realidad está compuesto de cuatro hilos, es decir, {api, principal, registro, cálculo } . En otras palabras, cuatro de estos hilos trabajan juntos, compartiendo los recursos del programa Helloworld, formado un programa de Helloworld situación real de trabajo.
Este es un sistema operativo dentro de un grupo de proceso o hilo estableció un muy real ejemplo, el anterior es un grupo de proceso conceptual.
Entonces puede que desee para pensar, que en un verdadero sistema operativo, un programa a menudo se gestionarán de acuerdo con el grupo de procesos. Kubernetes analogía es un sistema operativo, como Linux. Para el recipiente hemos mencionado anteriormente que se puede comparar con el proceso, que está en frente de la rosca Linux. Pod entonces ¿qué es? Vaina es en realidad un grupo de procesos que acabamos de mencionar, es decir donde el grupo de hilos de Linux.
concepto de grupo de procesos
Cuando se trata de grupo de proceso, en primer lugar, sugieren que usted tiene al menos una comprensión conceptual, a continuación vamos a explicar en detalle.
O el ejemplo anterior: programa Helloworld que consiste en cuatro procesos, compartirá algunos recursos y archivos entre estos procesos. Así que ahora hay una pregunta: Si usted dice que ahora el programa de Helloworld contenedor en funcionamiento, ¿cómo hacerlo?
Por supuesto, una de las soluciones más natural es que ahora voy a empezar un recipiente acoplable, que se extiende cuatro procesos. Pero hay un problema de este tipo, en cuyo caso el contenedor dentro del proceso PID = 1 ¿Quién es éste? Por ejemplo, debería ser mi plato, entonces la pregunta es: "¿Quién" también es responsable de gestionar los tres procesos restantes que?
El problema central es que el diseño del recipiente en sí es un modelo de "solo proceso", no significa que el recipiente sólo puede jugar un proceso, debido a la aplicación del recipiente es igual al proceso, sólo puede ir a gestionar el proceso de PID = 1, entonces el otro hasta de hecho, el proceso es un estado administrado. Por lo que el proceso de solicitud de servicio en sí tiene la capacidad de "gestión de procesos".
Por ejemplo, el programa tiene la capacidad de sistema Helloworld, o directamente al contenedor 1 PID = proceso directamente en systemd, de lo contrario la aplicación, o el contenedor hay manera de gestionar un número de procesos. Debido PID = 1 es el propio proceso de aplicación, si ponemos este PID = 1 para matar el proceso o su propia durante la operación murió, los tres procesos restantes de los recursos no se recuperó, esto es muy, muy un problema grave.
Y realmente convertir esto en una misma aplicación systemd, o ejecutar un systemd el interior del contenedor dará lugar a otro problema: lo que la gestión de la embarcación ya no tenga gestionar la aplicación en sí, mientras que la gestión es equivalente a systemd, aquí el problema es muy claro. Por ejemplo, corro dentro del programa contenedor o proceso se systemd, luego el siguiente, esto no está fuera de la aplicación? No se fallará ella? No es inusual fracaso? En realidad no hay manera de saber directamente, porque el buque es gestionado por systemd. Esta es una razón por la ejecute un programa complejo a menudo más difícil en el interior del contenedor.
Una vez más le ayudará a resolver: Puesto que el recipiente es en realidad un modelo "único proceso" , por lo que si inicia varios procesos en el depósito, sólo uno puede ser utilizado como proceso PID = 1, y esta vez, si el PID = 1 proceso de colgar, o impedir su salida, huérfanos después a los tres procesos se convertirán naturalmente, nadie puede gestionarlos, nadie puede recuperar sus recursos, esta es una situación muy mala.
Nota: El modelo "de un solo proceso" de contenedor Linux, en referencia al ciclo de vida de un recipiente es equivalente al proceso PID ciclo de vida = 1 (proceso de aplicación de contenedor), en lugar de que el recipiente no puede crear múltiples procesos. Por supuesto, en circunstancias normales, el proceso de aplicación de contenedor no tiene la capacidad de gestionar el proceso, para que a través de ssh ejecutivo u otros procesos que se crea en el contenedor, una vez que la salida anormal (como la terminación SSH) es muy fácil llegar a ser un proceso huérfano.
A su vez, de hecho, un systemd puede ejecutar dentro del contenedor, lo utilizan para gestionar todos los otros procesos. Esto crea el segundo problema: de hecho, no hay manera de gestionar directamente mi solicitud, ya que mi solicitud sea asumida por systemd, entonces el ciclo de vida del estado de la aplicación en este momento no es igual al ciclo de vida del envase. Este modelo de gestión es en realidad una muy, muy complejo.
Pod = "grupo de procesos"
En el interior kubernetes, Vaina de hecho es kubernetes para su proyecto puede ser abstraídos de un proceso análogo al concepto de grupo.
Se mencionó anteriormente, los cuatro procesos compuesta de una aplicación Helloworld, en Kubernetes que efectivamente se define como una vaina tiene cuatro contenedores, hay que ser muy cuidadosos para entender este concepto.
Que en la actualidad hay cuatro diferentes responsabilidades, procesos de colaboración mutua, la necesidad de ir corriendo en el recipiente, en el que Kubernetes no las pone en un recipiente, ya que se encontrará con dos problemas. Entonces, ¿cómo hacerlo en Kubernetes en ella? Se separan los procesos son cuatro de cuatro recipientes separados puesta en marcha, y que se definen en el interior con una vaina.
Así que cuando el Kubernetes Helloworld que tire hacia arriba cuando se vea en realidad cuatro contenedores, comparten ciertos recursos, estos recursos pertenecen a la vaina, por lo que dicha bolsita en Kubernetes sólo hay una unidad lógica, no es un verdadero esto es algo que corresponde a dicha vaina, y otros no. Hasta algo realmente existe físicamente, es decir, cuatro contenedores. Cuatro envases, o una combinación de una pluralidad de recipientes llamado Pod. Y tiene que haber un concepto muy claro, Kubernetes Pod es una unidad de asignación de recursos, debido a que el interior del recipiente que desee compartir ciertos recursos, la vaina también Kubernetes unidades de expedición atómicas.
diseño de la vaina se mencionó anteriormente, ni Kubernetes que quieren proyectar, pero tan pronto como los Borg de Google I + D, se ha encontrado que un problema de este tipo. Esto a su papel Borg hay muy, muy clara descripción. En términos simples, los ingenieros de Google encontrar en Borg tras el despliegue de aplicaciones, en muchas escenas hay una relación similar a "procesos y grupo de procesos" de. Más específicamente, tienden a tener estrechos vínculos de cooperación antes de que estas aplicaciones, por lo que deben ser desplegadas en la misma máquina y compartir cierta información.
Estos son los conceptos de grupos de procesos, sino también el uso de la vaina.
¿Por qué debe ser Pod unidad atómica de programación?
Aquí podríamos tener algunos problemas: A pesar de lo que pasa con este grupo es un proceso, pero ¿por qué debería vaina sí mismo como un concepto abstracto fuera de él? O puede el Pod mediante la programación de este asunto a deshacerse de él? ¿Por qué la vaina debe ser Kubernetes dentro de la unidad atómica de programación?
A continuación explicamos con un ejemplo.
Si hay dos contenedores, que están cooperando estrechamente, por lo que deben ser desplegados en un interior de la vaina. En concreto, el primer buque llamado la App, es el contenedor de servicios, será escribir un archivo de registro; un segundo recipiente llamado el LogCollector, hacia adelante se acaba de escribir el archivo de registro de contenedores de aplicaciones a parte final Elasticsearch.
Recursos necesita dos recipientes es la siguiente: envase App necesita 1G de memoria, la memoria necesidad 0,5 G LogCollector, y el entorno de clúster actual memoria disponible es tal situación: memoria de 1,25 G, Nodo_B:: Node_A memoria 2G.
Si dice que no ahora concepto Pod, sólo dos contenedores, dos contenedores que se ejecuta en estrecha colaboración una sola máquina. Sin embargo, si el planificador primera aplicación programada para Node_A arriba, entonces qué va a pasar? A continuación, encontrará: LogCollector en realidad no hay manera de programar el Node_A debido a la insuficiencia de recursos. De hecho, en esta ocasión la propia aplicación entera tiene un problema, la programación ha fallado, tendrá que ser reprogramado.
Lo anterior es un ejemplo muy típico de un fallo de grupo de programación. Inglés se llama: Tarea co-programación problema, el problema no es decir que no puede ser resuelto, en el que muchos proyectos, estos problemas tienen soluciones.
Por ejemplo, en el interior de mesos, que va a hacer una cosa que se llama acaparamiento recursos (acaparamiento de recursos): es decir, cuando todo está preparado Affinity constreñido se alcanzan tareas, comenzó unificada, esta es una solución muy típico grupo de programación.
Por lo que "Aplicación" y "LogCollector" Estos dos buques mencionados anteriormente, en mesos, y no dirán de inmediato programado, pero ambos recipientes y así sucesivamente se presentan al completo, comenzó unificado. También traerá nuevos problemas, en primer lugar la eficiencia de la programación se pierde debido a la necesidad de esperar. Debido a que no tendrá que esperar fuera surgirá una situación, es un callejón sin salida, una situación que se espera de uno al otro. Estos mecanismos mesos no necesitan ser tratados, sino que también aporta una complejidad adicional.
Otra solución es la solución de Google. Es en el sistema Omega (Borg es la próxima generación) en el interior, hizo una solución muy compleja y muy potente, llamado el cronograma optimista. Por ejemplo: si la situación anormal de estos conflictos, la primera programación, y establecer un mecanismo de reversión muy sutil, por lo que después del conflicto, para resolver el problema de volver a rodar. La manera de ser relativamente más elegante y más eficiente, pero su mecanismo de aplicación es muy compleja. Esto muchas personas pueden entender, es la configuración de bloqueo pesimista deben ser más simple que el bloqueo optimista.
Y al igual que un problema de tareas co-programación, en Kubernetes, vaya directamente resuelto por tal concepto una vaina. Debido a que en Kubernetes en tal un LogCollector App contenedor y el contenedor debe pertenecer a una vaina, que es inevitablemente un unidades Pod de planificación en la programación, por lo que el problema es inexistente.
Pod entender de nuevo
Después de hablar delante de tal conocimiento, tenemos que entender lo que una vez más la vaina, la vaina dentro del primer contenedor es una "relación íntima súper".
Aquí es una palabra "super" que todos debemos entender, lo normal es que existe una relación llamada la intimidad, la intimidad es cierto puede ser resuelto a través de la programación.
Por ejemplo, ahora hay dos Pod, que necesitan para funcionar en el mismo host, por lo que pertenece a la relación íntima, el programador puede ciertamente ayuda para hacerlo. Sin embargo, para las relaciones íntimas súper, hay un problema, es decir, que debe ser resuelto por la vaina. Porque si no es super estrecha relación dada, entonces todo el Pod o toda la aplicación no se puede iniciar.
Lo que es super relación íntima? Más o menos divididos en las siguientes categorías:
- Por ejemplo, el intercambio de archivos se llevará a cabo entre los dos procesos mencionados anteriormente es un ejemplo de ello, escribir un diario, un registro de lectura;
- Entre dos procesos necesitan ser local o localhost Socket para comunicarse, esta es la intimidad comunicación ultra-local;
- Entre dos recipientes o micro-servicios, que debe suceder con mucha frecuencia las llamadas RPC, por razones de rendimiento, y la esperanza son relaciones muy íntimas;
- Dos contenedores o aplicaciones que necesitan compartir un poco de espacio de nombres Linux. El ejemplo más común de una manera simple, es decir, que tienen una necesidad de añadir contenedor de Red Espacio de nombres a otro contenedor. Para que pueda ver el dispositivo de red a otro contenedor, y su información de la red.
Al igual que más de unas pocas relaciones son relaciones muy íntima, que se resuelven en Kubernetes pasará a través del concepto de la vaina.
Ahora que entendemos el concepto de diseño de la vaina de este tipo, para entender por qué es necesario Pod. Se resuelve dos problemas:
- Se describe cómo la intimidad de ultra;
- ¿Cómo vamos contenedor para las relaciones íntimas de ultra o hacer negocios está unificada, que es una de las demandas más importantes de la vaina.
Dos, mecanismo de aplicación de la vaina
Pod problema que hay que resolver
tal cosa como Pod, sí es un concepto lógico. Que en la máquina, si se trata de la forma de lograrlo? Esto es lo que queremos explicar la segunda pregunta.
Dado que la vaina para resolver este problema, el núcleo es cómo hacer que el intercambio más eficiente de ciertos recursos y datos entre varios recipientes en una vaina.
Porque entre el recipiente fue separado originalmente por Linux Espacio de nombres y cgroups, ahora es práctica para resolver es cómo romper este aislamiento y luego compartir ciertas cosas y ciertas informaciones. Esta es la vaina está diseñado para resolver el problema central.
Así solución específica se divide en dos partes: la red y el almacenamiento.
1. Red de Intercambio
La primera pregunta es cómo en la vaina más contenedores a una red compartida? He aquí un ejemplo:
Por ejemplo, ahora hay una vaina, que incluye un recipiente A y un recipiente B, que es necesario compartir dos Red de Espacio de nombres. En Kubernetes en solución es la siguiente: que será en cada Pod, el contenedor Infra adicional de un recipiente para una pequeña parte de la general Pod Red de Espacio de nombres.
Infra contenedor es un espejo muy pequeño, alrededor de 100 ~ 200 KB, que está escrito en lenguaje ensamblador, está siempre en un estado de contenedores "pausa". Desde entonces Con tal un recipiente Infra, todos los otros recipientes serán añadidos al recipiente de red de espacio de nombres Infra Únase espacio de nombres por cierto.
Por lo que una vaina de todos los contenedores en el interior, que ven el punto de vista de la red es exactamente el mismo. Es decir: ven equipos de red, dirección IP, dirección MAC, etc., asociado con la información de la red, de hecho, es un todo, éste proviene de la Infra contenedor Pod por primera vez creado. Esta es una solución para resolver el recurso compartido de red de la vaina.
Pod en la que no debe ser una dirección IP, es la dirección de la correspondiente red de espacio de nombres Pod, y también la dirección de contenedores Infra IP. Así que vemos es una, y todos los demás recursos de la red, son una vaina A y la vaina son compartidos por todos los buques en. Esta es la implementación de la red de la vaina.
Debido a una necesidad que existe correspondiente a dicho recipiente intermedio, todo el interior de la vaina, contenedor Infra se debe iniciar primero. Vaina y todo el ciclo de vida es equivalente al contenedor Infra ciclo de vida, el contenedor A y B son independientes. Esta es la razón por Kubernetes el interior, se permite actualizar la vaina en el espejo de una sola persona, a saber: que hacer esta operación, toda la vaina no reconstruir, no se reiniciará, es muy importante para un diseño.
2. Almacenamiento compartido
Segunda pregunta: ¿cómo la vaina de almacenamiento compartido? Vaina de almacenamiento compartido es relativamente simple.
Por ejemplo, ahora hay dos contenedores, uno es Nginx, el otro es muy común contenedor, puso unos papeles en Nginx, me dejó a través del acceso a Nginx. Por lo tanto, necesita compartir este directorio. Comparto archivos o comparte el directorio en el Pod que es muy simple, de hecho, el volumen se convierte en un nivel Pod. Entonces todos los contenedores es que todos pertenecen a la misma recipiente Pod, que todo el volumen de acción.
Por ejemplo, en el ejemplo anterior, este volumen se llama el-datos compartidos, pertenece nivel de la vaina, por lo que en cada contenedor puede ser directamente DECLARACIÓN: Para montar los-datos compartidos este volumen, siempre y cuando se declara que monte el volumen, que vaya a este directorio en el contenedor, de hecho vemos es el mismo. Esta es Kubernetes por Pod para compartir el contenedor de almacenamiento a una práctica.
Así, en el ejemplo anterior, el contenedor de aplicaciones App de escribir un diario, siempre y cuando el registro se escribe en un volumen, siempre y cuando el soporte de la declaración del mismo volumen, el volumen puede ser inmediatamente otro recipiente LogCollector para ver. Estos se almacenan de una manera para lograr Pod.
En tercer lugar, detallado contenedores patrones de diseño
Ahora sabemos por qué vaina, la vaina también entender esto al final es la forma de lograr. Finalmente, sobre esta base, una mirada detallada en el concepto de Kubernetes muy defensora, llamó a los patrones de diseño de contenedores.
por ejemplo
A continuación vendrá a usted para explicar con un ejemplo.
Por ejemplo, ahora tengo una apelación muy común: ahora quiero publicar una aplicación, la aplicación está escrito en Java, hay una necesidad de ponerlo en la web directorio APP de WAR Tomcat bolsa, para que pueda ponerlo en marcha. Pero tal guerra como Tomcat paquete o contenedor de un caso así, cómo hacerlo, cómo publicar? Y hay varias prácticas.
La primera realización: la guerra y puede ser empaquetado en un espejo en el interior de Tomcat. Pero esto presenta un problema, que es ahora el espejo es en realidad lo frota en dos cosas. Así pues, si quiero actualizar la guerra o que quiero actualizar Tomcat, usted tiene que volver a hacer una nueva imagen, que es más problemático;
La segunda manera: sólo hay un espejo empaquetado Tomcat. Es un Tomcat, pero requiere el uso de grandes volúmenes de datos, tales rutaServidor, desde la sede de la GUERRA montar en nuestros contenedores de Tomcat, colgando a mi directorio de aplicación web, por lo que este recipiente para permitir que más tarde, en el interior se puede usar.
Pero esta vez se encuentra un problema: Este enfoque seguro que necesitará para mantener un sistema de almacenamiento distribuido. Debido a que los contenedores pueden primera apertura en el host A anterior, la segunda vez para reiniciar el B puede subir, algo que es un contenedor que se pueden migrar, su estado no se mantiene. Es necesario mantener un sistema de almacenamiento distribuido, ya sea en el recipiente A o en B, se puede encontrar en el paquete WAR, encontrar los datos.
Tenga en cuenta que incluso con sistemas de almacenamiento distribuido hacer volumen, también tiene que ser responsable de mantener el volumen en el paquete WAR. Por ejemplo: Usted tiene que escribir un único conjunto de Kubernetes volumen plug-in para la vaina antes de cada inicio, iniciar la aplicación necesaria paquete WAR en el volumen, y luego utilizan la montura se puede aplicar a.
Esta operación aporta complejidad es aún relativamente alto, y el propio buque no deben depender de una tarjeta de memoria persistente (utilizado para gestionar volumen en el contenido del paquete WAR).
InitContainer
Por lo tanto, no hemos considerado, al igual que esta combinación, no hay manera más general? Incluso en los Kubernetes locales, bajo ninguna circunstancia también pueden utilizar el almacenamiento distribuido, se puede jugar, puede ser liberado.
De hecho, hay método en el Kubernetes dentro, como esta combinación, llamada Init del envase.
Un ejemplo es el mismo: en yaml en el mapa, la primera definen un contenedor de inicio, es sólo una cosa, es para copiar el paquete WAR una imagen de espejo a un volumen interior de, que se retiró de la final de esta operación, por lo Init de contenedores los usuarios pueden iniciar antes de que el buque, y en estricta conformidad con la definición con el fin de ejecutar la orden.
Entonces, la clave es sólo una copia por ejemplo al directorio de destino: directorio de APP es en realidad un volumen. Y hemos mencionado anteriormente, una pluralidad de contenedores en el interior de la vaina, volumen que puede ser compartida, por lo que ahora el contenedor Tomcat, sólo un espejo empaquetado Tomcat. Pero cuando se inicia, a declarar el uso del directorio de APP como mi volumen, y llevarlos a montar en el directorio de la aplicación Web.
Y esta vez, como ya se ha ejecutado a través de un recipiente Init, se ha completado la operación de copia, por lo que este volumen que ha existido durante la aplicación WAR: que sample.war, absolutamente ya existe dentro de este volumen. El segundo paso hasta el tiempo de ejecución se inicia el contenedor Tomcat, para colgar el volumen, para ser capaz de encontrar una copia de la parte interior sample.war delante.
De esta manera es posible describir: El Pod es un autónomo, puede soportar una vaina han permitido con éxito en cualquier Kubernetes el mundo encima. No se preocupe acerca de almacenamiento no se distribuye, de volumen no es persistente, que debe ser publicado.
Este es un modo mediante la combinación de dos funciones diferentes del recipiente, y un número de aplicaciones en tal disposición de tal manera tal, una imagen uniforme desempaquetado Init Recipiente, Pod hacerlo con un ejemplos muy típicos. Un concepto de este tipo, en Kubernetes que es una muy clásicos patrones de diseño de envase, llamado: "Sidecar".
Buque de modo de diseño: Sidecar
¿Cuál es el coche lateral? Ese hecho, en el interior de la vaina, se puede definir un contenedor especial, para llevar a cabo algunas de las principales necesidades de negocio de contenedores de trabajo auxiliares, tales como nuestro ejemplo anterior citado, de hecho, habría hecho una cosa, el Init del envase, se trata de un coche lateral, es responsable de la imagen de espejo de la guerra copiado en el directorio compartido para, de manera que sea capaz de utilizarlos Tomcat.
¿Qué otras operaciones que tienen? Por ejemplo:
Originalmente tenga que hacer algo en el interior del contenedor necesidad de SSH a hacer, se puede escribir un guión, una serie de condiciones previas, de hecho, puede ser como Sidecar, u otra forma de resolver a través de contenedores como Init;
Por supuesto, no es un ejemplo típico de esto es mi recopilación de registros, la propia recopilación de registros es un proceso, es un recipiente pequeño, entonces se pueden agrupar en la vaina que hacer dentro de esta colección;
Otra cosa muy importante es la aplicación de depuración, de hecho, ahora toda la aplicación de depuración puede definir una pequeñas aplicaciones adicionales Pod contenedores de nuevo en el interior, que puede ir de la vaina de aplicación ejecutivo de espacio de nombres;
Ver otros recipientes condición, que es lo que puede hacer que trabajan. No hay necesidad de más tiempo para SSH para conectarse al ver el envase, siempre que el componente de vigilancia montado en un pequeño recipiente adicional dentro de ella, y luego usarlo como un coche lateral puesta en marcha, para colaborar con el negocio principal del contenedor, por lo que las mismas operaciones también pueden ser monitoreados sidecar manera de hacerlo por.
Esta práctica una ventaja muy evidente es el hecho de que la accesibilidad desacoplada de mi contenedor de servicios, por lo que yo era capaz de liberar de forma independiente los contenedores Sidecar, y más importante aún, esta capacidad puede ser reutilizado, que es la misma que la vigilancia Sidecar o en el registro del coche lateral, puede ser compartida sociedad entera. Este es un poderoso patrón de diseño.
Sidecar: aplicación y recopilación de registros
A continuación, vamos a ver en Sidecar refinamiento detallado de un modelo de este tipo, sino que también tiene una serie de otros escenarios.
Por ejemplo, la recopilación de registros de aplicación, el contenedor de servicios mencionado en un volumen interior de registro de escritura, y como el volumen de la vaina que se comparte, por lo que los registros de contenedores - es decir, el coche lateral contenedor debe ser compartida por el volumen, directamente en el archivo de registro leer, y luego almacenada a un interior de almacenamiento remoto o reenviado a otro ejemplo. Ahora común en la industria de procesos componente de registro o registro Fluentd, básicamente funciona de esta manera.
Sidecar: recipiente de agente
Sidecar segundo uso, que puede ser llamado como un recipiente de proxy Proxy. Lo que se llama el agente envase?
Si hay una vaina ahora necesita tener acceso a un sistema externo, o algunos servicios externos, pero estos sistemas externos es un clúster, a continuación, en esta ocasión cómo un unificadas y de manera sencilla, mediante una dirección IP, poner estos grupos tienen acceso a? Una forma es: modificar el código. Debido a que el código de dirección grabada en estos grupos; Además hay un método de desacoplamiento, es decir, por el contenedor de proxy Sidecar.
En pocas palabras, una sola escritura una pequeña Proxy tales, para manejar cluster de servicios de conexión externa, que se expone fuera sólo una dirección IP en él. Así pues, el servicio proxy contenedor de acceso principal, y estos servicios están conectados a un grupos de proxy, clave Pod aquí es que hay una pluralidad de contenedores a través de localhost comunicación directa, porque pertenecen a la misma red de espacio de nombres, misma vista de la red, por lo que dos localhost comunicación, y sin pérdida de rendimiento.
Así, además de hacer el desacoplamiento fuera recipiente de agente, y no se degrade el rendimiento, lo más importante, como un código de contenedor proxy y puede ser reutilizado en toda la empresa.
Sidecar: adaptador del recipiente
Sidecar tercer modo de diseño - adaptador del recipiente adaptador, adaptador hace qué?
Ahora API de negocio expuestos, por ejemplo, hay un formato de una API es A, pero ahora hay un sistema externo a ir a visitar a mi negocio de contenedores, que sólo sabe de un formato es API B, por lo que hacer un trabajo, es decir, cómo encontrar una manera de deshacerse del negocio de contenedores, va a cambiar el código de negocio. Pero, de hecho, puede ayudar a hacer esto por un adaptador capa de conversión.
Ahora veamos un ejemplo: empresa ahora expuesta interfaz de vigilancia de contenedores es / métricas, puede visitar los parámetros de la URL de esta nave puede conseguir. Pero ahora, este sistema de vigilancia, el acceso URL es / salud mejoró, sólo sé exponer URL comprobación de estado de salud, con el fin de hacer el seguimiento, la métrica no saben. Entonces, ¿cómo hacer esto? Sería necesario cambiar el código, pero no se puede cambiar el código, pero adicionales de escritura de un adaptador, para todas las solicitudes de la salud remitido a las métricas en él, por lo que esta exposición adaptador externo es un enlace vigilancia de la salud , que puede, en su negocio y el trabajo lata.
Esta clave está en el contenedor entre la vaina es localhost través de la comunicación directa, por lo que no hay pérdida de rendimiento y un recipiente de este tipo pueden ser reutilizados en Adaptador de empresa conjunto, estos son los beneficios de los patrones de diseño nos ha traído.
Esta sección resume
- Pod es proyecto Kubernetes en la realización de "modo de diseño contenedor" mecanismo de núcleo;
- "Modo de diseño del envase" Google Borg es una de las mejores prácticas de gestión de la masiva agrupación de contenedor, es también una de las bases Kubernetes depender de aplicaciones compleja coreografía;
- Toda la naturaleza "modo de diseño" son: la disociación y la reutilización.
Comentarios del instructor
Vaina y el diseño de contenedores patrones dentro del sistema Kubernetes es un conocimiento básico de los puntos más importantes, espero que los lectores pueden tratar con cuidado para averiguar y señor. A continuación, le sugiero que vaya antes de que una nueva mirada a la empresa o equipo de uso Pod propio camino, no es más o menos adoptado el denominado "contenedor rica" El diseño de la misma? Este diseño es sólo una forma de transición, formará a un montón de muy malos hábitos de operación y mantenimiento. Sugiero fuertemente que usted adopta progresivamente los patrones de diseño del envase pensamiento desacoplamiento rica contenedor, dividirlos en varios contenedores para formar una vaina. Esta es la razón por la Alibaba actual "nube integral" en una campaña para promover el contenido importante de la obra.