Entrada

Entrada frente a servicio

Existen similitudes entre el servicio del equilibrador de carga y las ingresiones. Ambos pueden exponer servicio fuera del clúster, pero hay algunas diferencias significativas.

Capa de operación

La entrada funciona en la capa de aplicación del modelo de red OSI, mientras que el servicio funciona únicamente en el nivel de transporte. La entrada comprende el protocolo HTTP/HTTPS, este servicio solo actúa sobre el reenvío basado en IP y en el puerto, lo que significa que no se preocupa por los detalles del Protocolo de la capa de aplicación (HTTP/HTTPS). Las entrada pueden funcionar en el nivel de transporte, pero el servicio hace lo mismo, de modo’que tampoco tiene sentido que la entrada lo haga, a menos que haya una razón especial para hacerlo.

Modo de reenvío

El proxy de la capa de aplicación se hace muy prácticamente de la misma manera que un equilibrador de carga Web tradicional. Un proxy típico de equilibrador de carga web que se encuentra entre el equipo A (cliente) y B (servidor), funciona en la capa de aplicación. Es consciente de los protocolos de la capa de aplicación (HTTP/HTTPS), por lo que la interacción entre el cliente y el servidor no parece transparente para el equilibrador de carga. Básicamente, crea dos conexiones cada una con el origen, (A) y el destino, (B), el equipo. El equipo A no sabe siquiera de la existencia del equipo B. Para el equipo A, el proxy es el único elemento al que habla y que no le preocupa cómo y dónde obtiene el proxy sus datos.

Número de IP públicas.

Cada servicio de la entrada necesita una dirección IP pública si está expuesta directamente en el exterior del clúster. Cuando la entrada es un front-end a todos estos servicios, una IP pública es suficiente para facilitar la vida de los administradores de la nube.

Objeto de entrada

Antes de profundizar en el objeto Ingress, la mejor forma de hacerse una idea es mirar la definición de YAML:

Puede ver que parece bastante sencillo. La especificación define solo un elemento – que son las reglas. Las reglas indican que un host, que es el Juniper dirección URL, puede tener dos rutas posibles en la cadena de la dirección URL. La ruta de acceso es cualquier cosa que siga al host en la dirección URL, en este caso, son/dev y/QA. A continuación, cada ruta se asocia a un servicio diferente. Cuando la entrada vea que llegan solicitudes HTTP, se envía a través de proxy el tráfico de cada servicio de ruta de URL asociado. Cada servicio, como hemos’aprendido en esta sección de servicio, entregará la solicitud a su ruta de acceso de back-end correspondiente. Que’lo compartiron. En realidad, es uno de los tres tipos de inentradas que Kubernetes admite – hoy ingresos de fan-out sencillos. Los otros dos tipos de entrada se tratarán más adelante en este capítulo.

Acerca de URL, host y ruta de acceso

Los términos host y ruta se usan frecuentemente en la documentación de entrada de Kubernetes. El host es un nombre de dominio completo del servidor. La ruta de acceso o dirección URL es el resto de la parte de cadena después del host en una dirección URL. Si el caso es una de las que tienen un puerto en la dirección URL, entonces es la cadenadespués del puerto.

Eche un vistazo a la siguiente dirección URL:

El host es www.juniper.net, lo que siga al puerto 1234 se denomina ruta, mi/recurso en este ejemplo. Si una dirección URL no tiene ningún puerto, las cadenas que siguen al host serán la ruta de acceso. Para obtener más detalles, puede leer el documento RFC 1738, pero para el propósito de este libro, comprender lo que se introduce aquí será suficiente.

Si ahora piensa que Kubernetes establece algunas reglas y que las reglas son solo para indicar al sistema que dirija las solicitudes entrantes a diferentes servicios, basadas en las direcciones URL, básicamente se trata de un alto nivel. La Figure 1 ilustra la interdependencia entre los tres objetos Kubernetes: entrada, servicio y conjunto Pod.

Figure 1: Entrada, servicio y conjunto Pod

En la práctica hay otras cosas que debe comprender, para tratar las reglas de entrada, necesita al menos un componente más denominado el controlador de entrada.

Controladora de entrada

Un controlador de entrada es responsable de la lectura de las reglas de entrada y, a continuación, la programación de las reglas en el proxy, – que realiza el trabajo real que distribuye el tráfico en función del host o la dirección URL.

Los controladores de entrada los suelen implementar otros proveedores. Los distintos entornos de Kubernetes tienen distintos controladores de entrada en función de la necesidad del clúster. Cada controladora de entrada cuenta con su propia implementación para programar las reglas de entrada. La conclusión es que debe haber un controlador de entrada en ejecución en el clúster.

Algunos proveedores de controladores de entrada son:

• nginx

• gce

• haproxy

• fichero

• f5

• istio

• personalizar

Puede implementar cualquier número de controladores de entrada dentro de un clúster. Al crear una entrada, debe anotar cada entrada con las Ingress adecuadas. clase para indicar qué controlador de entrada debe utilizarse (si existe más de una en el clúster) o no.

La anotación utilizada en los objetos de entrada se explicará en la sección anotación.

Ejemplos de entrada

Existen tres tipos de Ingress:

• Ingreso de servicio único

• Entrada de fanout sencilla

• Entrada de hospedaje virtual basada en nombres

’Echamos un vistazo a las sencillas fanout Ingress, por lo’que ahora veamos un ejemplo YAML File, para los otros dos tipos de Ingress.

Ingreso de servicio único

Ésta es la forma más sencilla de entrada. La entrada recibirá una dirección IP externa, por lo que el servicio se puede exponer al público, sin embargo, no tiene reglas definidas, por lo que no analiza el host ni la ruta de acceso en las direcciones URL. Todas las solicitudes van al mismo servicio.

Entrada de fanout sencilla

Lo extraídamos al principio de esta sección. En comparación con la entrada de servicio único, las fanout de entrada sencilla son más prácticas. ’No solo puede exponer el servicio a través de una IP pública, sino que también puede hacer enrutamiento de URL o salida de fan basada en la ruta de acceso. Éste es un escenario de uso muy común cuando una compañía desea dirigir el tráfico a cada uno de’los servidores dedicados de su departamento según el sufijo de dirección URL después del nombre de dominio.

Host virtual INGRESS

El host virtual basado en nombres es similar a la fanout de la entrada simple que puede realizar el enrutamiento de URL basado en reglas. La potencia única de este tipo de entrada es que permite enrutar el tráfico HTTP hacia varios nombres de host con la misma dirección IP. El ejemplo aquí puede no ser práctico (a menos que un día se fusionen los dos dominios) pero es lo suficientemente bueno como para exhibir la idea. En el archivo YAML se definen dos hosts, “las direcciones URL juniperhr” y “junipersales” , respectivamente. Aunque la asignación de entrada se realizará con una sola IP pública, según el host de la dirección URL, las peticiones hacia la misma IP pública seguirán estando enrutadas hacia los distintos servicios de servidor. Eso’es lo que se denomina un ingreso de alojamiento virtual y’s es un estudio de caso muy detallado en el capítulo 4 para que lo explore.

Controlador de entrada múltiple

Puede tener varias controladoras de entrada en un clúster, pero es necesario que el clúster sepa cuál elegir. Por ejemplo, en el capítulo 4’hablamos acerca de’contrail controlador de entrada integrado, que no nos impide instalar otro controlador de ingress de terceros, como el controlador nginx Ingress. En su lugar, acabamos teniendo dos controladores de entrada en el mismo clúster con los nombres:

• opencontrail (predeterminado)

• nginx

La’implementación de contrail s es la predeterminada, por lo’que no tendrá que seleccionarla específicamente. Para seleccionar nginx como la controladora de ingreso, utilice esta anotación. Kubernetes.io/ingress.class:

Esto le indicará’a contrail s opencontrail de la entrada del controlador que omita la configuración de entrada.