Puntos clave: Kubernetes Ingress están un objeto API que gestiona las reglas de enrutamiento para acceder a servicios en un clúster Kubernetes, mejorando la seguridad y el balanceo de carga. Simplifica la exposición al servicio al actuar como un único punto de entrada.
- Ingress consta de un objeto API y un controlador de entrada para el enrutamiento del tráfico.
- Soporta múltiples protocolos, autenticación y enrutamiento basado en contenido.
En cualquier clúster Kubernetes, las aplicaciones deben poder conectarse con el mundo exterior para proporcionar a los usuarios finales acceso a la aplicación. Kubernetes Ingress están una opción disponible—echemos un vistazo.
¿Qué es Kubernetes Ingress?
Kubernetes Ingress están un objeto API que proporciona reglas de enrutamiento para gestionar el acceso a los servicios dentro de un clúster Kubernetes. Esto normalmente utiliza protocolos HTTPS y HTTP para facilitar el enrutamiento.
El ingreso están la opción ideal para un entorno de producción. Los usuarios pueden exponer servicios dentro del clúster Kubernetes sin tener que Crea múltiples balanceadores de carga ni exponer servicios manualmente.
Además, K8s Ingress ofrece un único punto de entrada para el clúster, permitiendo a los administradores gestionar fácilmente las aplicaciones y diagnosticar cualquier problema de enrutamiento. Esto disminuye la superficie de ataque del clúster, aumentando automáticamente la seguridad general.
Algunos casos de utiliza de la entrada Kubernetes incluyen:
- Proporcionar URLs accesibles externamente para los servicios
- Tráfico de balanceo de carga
- Ofreciendo alojamiento virtual basado en nombres
- SSL de terminación (capa de sockets seguros) o TLS (seguridad de la capa de transporte)
Kubernetes Ingress soporta múltiples protocolos, autenticación, enrutamiento basado en contenido, etc., y permite a los usuarios gestionarlos y configura fácilmente en clústeres de Kubernetes.
Kubernetes Ingress consta de dos componentes principales:
- Objeto API de entrada. El objeto API indica los servicios que deben exponerse fuera del clúster. Consiste en las reglas de enrutamiento.
- Controlador de Ingress. El Controlador de Ingress están la implementación real de Ingress. Normalmente están un balanceador de carga que enruta el tráfico desde la API hacia los servicios deseados dentro del clúster Kubernetes.
¿Qué es un controlador Ingress?
La implementación real de Kubernetes Ingress, el controlador Ingress es responsable del enrutamiento del tráfico desde fuentes externas hacia los servicios apropiados en el clúster Kubernetes. Los controladores de entrada soportan enrutamiento tanto a través de la capa de transporte (OSI - Capa 4) como de la capa de aplicación (OSI - Capa 7) en el modelo OSI.
El enrutamiento a la capa de aplicación está preferido sobre el enrutamiento simple de la capa de transporte porque ofrece mayor control, como el balanceo de carga del tráfico externo basado en las solicitudes. Los controladores Ingress no son iniciados automáticamente con un clúster Kubernetes ni forman parte del binario predeterminado "kube-controller-manager".
Kubernetes ofrece soporte integrado para controladores de entrada AWS, GCE y nginx , y también soporta integración con controladores de entrada de terceros. La elección del controlador de entrada depende de:
- Requisitos de tu solicitud
- El entorno anfitrión
En pocas palabras, el controlador Ingress está una aplicación que se ejecuta dentro del clúster Kubernetes y provisiona un balanceador de carga según los requisitos de Ingress. (El balanceador de carga puede ser un balanceador de carga por software, un balanceador de carga externo por hardware o un balanceador de carga en la nube, cada tipo requiere diferentes implementaciones de controlador.)
Ingreso vs alternativas para exponer servicios
Usar Ingress no está la única forma de exponer servicios.
Un recurso de servicio Kubernetes proporciona una forma abstracta de exponer un conjunto de pods de aplicación objetivo como un servicio de red. Al mismo tiempo, Kubernetes utiliza métodos ClusterIP, NodePort y Load Balancer para exponer servicios tanto internamente dentro de los nodos como externamente fuera del clúster.
- ClusterIP están el tipo de servicio predeterminado que expone servicios usando una IP interna del clúster. Este método expone solo el servicio dentro del clúster y está inaccesible externamente.
- NodePort expone el servicio usando un puerto estático asociado al nodo deseado. La configuración de NodePort Crea automáticamente el ClusterIP para enrutar el tráfico internamente. Los usuarios pueden acceder al servicio externamente usando la dirección IP del nodo y el puerto expuesto.
- LoadBalancer expone el servicio usando el balanceador de carga del proveedor de nube y crea automáticamente los NodePorts y ClusterIPs necesarios para enrutar el tráfico deseado.
(Conoce sobre NodePort, Port y TargetPort.)
Exponer y gestionar servicios individualmente están ineficientes y no escalables en grandes clústeres Kubernetes. Así es como Ingress se convierte en la solución ideal: actuando como punto de entrada para todo el clúster Kubernetes. Esto permite a los usuarios:
- Gestiona todas las reglas de enrutamiento desde un recurso centralizado
- Exponer múltiples servicios bajo una sola dirección IP
Creación de un recurso Ingress
Ahora veamos cómo Crea un recurso Ingress.
Como con cualquier otro recurso en Kubernetes, el recurso Ingress también consiste en campos apiVersion, kind y metadatos con las reglas y configuraciones deseadas bajo la sección de especificaciones.
Configuración simple de Ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/app-root: /test_app
name: testapproot
namespace: default
spec:
rules:
- host: testapproot.mycluster.com
http:
paths:
- backend:
serviceName: http-svc
servicePort: 80
path: /
Al definir un recurso de entrada, el nombre del objeto de entrada debe cumplir con convenciones válidas de nombres DNS en subdominios. Además, se pueden usar anotaciones para configura recursos de entrada con opciones específicas. En el archivo YAML anterior, utiliza la opción "nginx.ingress.kubernetes.io/app-root" para Define la raíz de la aplicación que el controlador de entrada necesita redirigir cuando están se llama la ruta raíz (ruta: /).
Diferentes tipos de controles de entrada incluirán distintos soportes de anotación, y el usuario debe modificar las anotaciones para adaptarlas al controlador deseado.
Reglas de ingreso
Las reglas de entrada son el núcleo de Kubernetes Ingress. Define qué ocurre con el tráfico entrante y a qué servicios debe dirigirse ese tráfico. Cada regla HTTP consta de múltiples campos para Define correctamente la regla.
- Host está un parámetro opcional que define a qué host se aplica la regla. Cuando el parámetro host no está definido, la regla se está aplicada a todo el tráfico HTTP entrante.
- Rutas se refiere a la lista de rutas asociadas a un backend que son asociadas. Tanto el host como la ruta deben coincidir para enrutar correctamente el tráfico al servicio deseado.
- El backend están eldestino al que debe dirigirse finalmente el tráfico entrante. Esto puede ser un servicio Kubernetes o un backend de recurso personalizado para indicar otro recurso bajo el mismo espacio de nombres (por ejemplo, bucket de almacenamiento).
Cualquier solicitud que no coincida con ninguna de las reglas definidas será dirigida al backend por defecto. Este backend por defecto está formando parte del controlador de entrada y no está especificado en el recurso de entrada.
Definición de múltiples reglas de entrada
Ahora que tenemos una mejor comprensión del recurso de entrada, podemos Ve cómo Define múltiples reglas de entrada con diferentes hosts y backends.
Tipos de entrada
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: myapp
spec:
rules:
- host: "app.mycluster.com"
http:
paths:
- pathType: Prefix
path: "/home"
backend:
serviceName: http-app
servicePort: 80
- pathType: Prefix
path: "/admin"
backend:
serviceName: http-app
servicePort: 8080
- host: "data.mycluster.com"
http:
paths:
- pathType: Prefix
path: "/charts"
backend:
serviceName: http-charts
servicePort: 81
En la configuración anterior, hemos configurado tres reglas de enrutamiento para dos hosts diferentes que consumen servicios distintos.
Presentador: "app.mycluster.com"
Esta sección consta de dos reglas que solo se aplican al tráfico dirigido a app.mycluster.com. Si la ruta de URL coincide con /home o /admin, el tráfico Obtén dirigido a diferentes puertos del mismo servicio.
Presentador: "data.mycluster.com"
La regla única configurada se aplicará al tráfico dirigido a data.mycluster.com host, y si la ruta de URL coincide con /charts, dirigirá el tráfico al puerto 81 del servicio "http-charts".
Tipos de rutas de acceso Kubernetes
Al definir reglas, el camino debe incluir un tipo de camino correspondiente para validar correctamente las reglas. Kubernetes tiene tres tipos de camino:
- Esto coincide con las configuraciones de una IngressClass definida en un controlador Ingress. Se tratará como un tipo de ruta separado o igual que los tipos Prefijo o Exacto, dependiendo de la implementación de la clase.
- Podemos utilizar este tipo cuando el usuario necesita hacer coincidir una ruta de URL exactamente con la sensibilidad de mayúsculas y minúsculas.
- Esto coincidirá con la URL según el prefijo de ruta dividido por la barra diagonal (/). Esto también está sensible a mayúsculas minúsculas, y el proceso de emparejamiento se está realizando de elemento a elemento en la URL.
Ahora veamos algunos escenarios de emparejamiento de caminos.
| Tipo de camino | Camino | Solicitud de ejemplo | Partido |
| Exacto | /test | www.example.com/test | Sí |
| Exacto | /test | www.example.com/test/ | No |
| Prefijo | /test | www.example.com/test www.example.com/test/ | Sí (ambas URLs) |
| Prefijo | /test/usuario | www.example.com/test/us | No |
En casos en los que son disponibles múltiples coincidencias para una solicitud, se dará preferencia a la solicitud con la ruta de coincidencia más larga. Si ambos caminos son una coincidencia exacta, el controlador de entrada seleccionará el tipo exacto de ruta sobre el prefijo para aplicar la regla de entrada necesaria.
(Profundiza en todos los escenarios de emparejamiento en la documentación oficial de Kubernetes.)
En Kubernetes son tres tipos de Ingress;
- Servicio único. Esto está respaldado por un solo servicio donde un solo servicio está expuesto. Para Define esto, especifica un backend por defecto sin reglas.
- Simple fanout. El tipo de fanout está cuando se está utilizado un único punto de entrada (una sola dirección IP) para exponer múltiples servicios. Allí, el tráfico de URL se enruta al destino deseado según la solicitud. Este método permite a los usuarios Reduce el número de balanceadores de carga y gestiona fácilmente el enrutamiento dentro del clúster.
- Alojamiento virtual basado en nombres. Este método puede usarse para enrutar tráfico desde una única entrada (dirección IP) a diferentes hosts dentro del clúster. Aquí, el tráfico se está dirigido primero a un host específico antes de que se están realizados cualquier otro enrutamiento.
Los usuarios pueden asegurar un ingreso especificando un secreto con una clave TLS compatible y un certificado. El recurso de entrada soporta un único puerto TLS (443) y asume la terminación TLS en el punto de entrada. Luego las comunicaciones internas se realizan mediante texto plano.
Gestiona los servicios mejor, con mayor seguridad
Kubernetes Ingress proporciona un recurso unificado para gestionar y enrutar el tráfico a tus aplicaciones en un clúster Kubernetes sin tener que gestionar manualmente los servicios y balanceos de carga.
Lecturas relacionadas
- BMC DevOps Blog
- Mejores prácticas de Kubernetes para mejorar la eficiencia del clúster
- Cómo funcionan juntos los contenedores y los kubernetes
- Kubernetes vs Docker Swarm: Comparando herramientas de orquestación de contenedores
- Seguridad Docker: 14 mejores prácticas para proteger contenedores Docker
- El estado actual de los contenedores: Resumen del informe
Guía Kubernetes
- ¿Qué es Kubernetes (K8s)? Un tutorial básico de Kubernetes
- Mejores prácticas de Kubernetes para mejorar la eficiencia del clúster
- Mejores Prácticas: Cómo Diseñar Aplicaciones para Kubernetes
- Kubernetes Pods: Una introducción
- Kubernetes ReplicaSets: Una breve introducción
- Despliegues de Kubernetes completamente explicados
- Cómo utilizar y gestionar los DaemonSets de Kubernetes
- Cómo funcionan los servicios de Kubernetes
- Uso de Kubernetes Port, TargetPort y NodePort
- Creación y uso de ConfigMaps en Kubernetes
- Introducción a Kubernetes Secrets
- Fundamentos de las redes de Kubernetes
- Explicación de Kubernetes Ingress
- Introducción a las Listas de Helm de Kubernetes
- ¿Qué están el patrón de operador Kubernetes?
- Despliegue de PostgreSQL como un StatefulSet en Kubernetes
- Definición de Recursos Personalizados (CRDs) de Kubernetes Explicada
- 3 Patrones Kubernetes para aplicaciones nativas en la nube
- Explicación de los recursos de cómputo de Kubernetes
- Kubernetes Security for DevOps Pipelines
- Uso de spinnaker con Kubernetes para entrega continua
- Multi-Clústeres Kubernetes: Cómo y por qué utilizarlos
- Monitorización de Kubernetes: Una guía completa
- Kubernetes vs Docker: Una comparación rápida
- Kubernetes vs Docker Swarm: Comparando herramientas de orquestación de contenedores
- Kubernetes vs OpenShift: ¿Cuál es la diferencia?
- Certificaciones Kubernetes: Cómo y por qué Obtén la certificación
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.