--- reviewers: - raelga title: Ingress content_type: concept description: >- Permite que sean accesibles los servicios de red HTTP (o HTTPS) usando un mecanismo de configuración consciente del protocolo, que entiende conceptos como URIs, nombres de host, rutas y más. El concepto de Ingress te permite mapear el tráfico a diferentes backend basado en las reglas que defines a través de la API de Kubernetes. weight: 30 --- {{< feature-state for_k8s_version="v1.19" state="stable" >}} {{< glossary_definition term_id="ingress" length="all" >}} {{< note >}} El recurso Ingress está congelado. Las nuevas características se añaden al [API del Gateway](/docs/concepts/services-networking/gateway/) {{< /note >}} ## Terminología Para mayor claridad, esta guía define los siguientes términos: * Nodo: Una máquina worker en Kubernetes, parte de un clúster. * Clúster: Un conjunto de Nodos que ejecutan aplicaciones en contenedores, administrados por Kubernetes. Para este ejemplo, y para los despliegues más comunes de Kubernetes, los nodos en el clúster no son parte del internet público. * Enrutador Edge: un enrutador que refuerza la política de seguridad del cortafuegos para tu clúster. Esto podría ser una puerta de entrada administrada por un proveedor de la nube o una pieza física de hardware. * Red del clúster: un conjunto de enlaces, lógicos o físicos, que facilitan la comunicación dentro de un clúster de acuerdo con el [modelo de redes](/docs/concepts/cluster-administration/networking/) de Kubernetes. * Service: Un {{< glossary_tooltip term_id="service" >}} que identifica un conjunto de Pods que utilizan selectores de {{< glossary_tooltip text="label" term_id="label" >}}. A menos que se indique de otra manera, los Services se asumen que tienen IPs virtuales que solo se pueden enrutar dentro de la red del clúster. ## ¿Qué es un Ingress? Un [Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io) expone rutas HTTP y HTTPS desde el exterior del clúster a los {{< link text="servicios" url="es/docs/concepts/services-networking/service/" >}} dentro del clúster. El control del tráfico es controlado por las reglas definidas en el recurso Ingress. Aquí tienes un ejemplo simple de un Ingress que envía todo su tráfico a un Service: {{< figure src="/docs/images/ingress.svg" alt="ingress-diagram" class="diagram-large" caption="Figure. Ingress" link="https://mermaid.live/edit#pako:eNqNkstuwyAQRX8F4U0r2VHqPlSRKqt0UamLqlnaWWAYJygYLB59KMm_Fxcix-qmGwbuXA7DwAEzzQETXKutof0Ovb4vaoUQkwKUu6pi3FwXM_QSHGBt0VFFt8DRU2OWSGrKUUMlVQwMmhVLEV1Vcm9-aUksiuXRaO_CEhkv4WjBfAgG1TrGaLa-iaUw6a0DcwGI-WgOsF7zm-pN881fvRx1UDzeiFq7ghb1kgqFWiElyTjnuXVG74FkbdumefEpuNuRu_4rZ1pqQ7L5fL6YQPaPNiFuywcG9_-ihNyUkm6YSONWkjVNM8WUIyaeOJLO3clTB_KhL8NQDmVe-OJjxgZM5FhFiiFTK5zjDkxHBQ9_4zB4a-x20EGNSZhyaKmXrg7f5hSsvufUwTMXThtMWiot5Jh6p9ffimHijIezaSVoeN0uiqcfMJvf7w" >}} Un Ingress se puede configurar para otorgar URLs a los Services que son accesibles desde el exterior, para hacer balance de cargas del tráfico, finalizar SSL/TLS y ofrecer alojamiento virtual basado en nombres. Un [controlador de Ingress](/docs/concepts/services-networking/ingress-controllers) es responsable de complementar el Ingress, comúnmente con un balanceador de cargas, aunque también puedes configurar tu enrutador edge con frontends adicionales para ayudar a manejar el tráfico. Un Ingress no expone puertos o protocolos arbitrariamente. Exponer servicios distintos de HTTP o HTTPS al internet usa un servicio de tipo [Service.Type=NodePort](/es/docs/concepts/services-networking/service/#tipo-nodeport) o [Service.Type=LoadBalancer](/es/docs/concepts/services-networking/service/#loadbalancer). ## Prerrequisitos Debes tener un [controlador de Ingress](/docs/concepts/services-networking/ingress-controllers) para satisfacer a un Ingress. Crear únicamente un recurso Ingress no tiene ningún efecto. Puede que necesites desplegar un controlador Ingress controller. Puedes elegir de un número de [controladores de Ingress](/docs/concepts/services-networking/ingress-controllers). Idealmente, todos los controladores de Ingress deberían encajar con la especificación de referencia. En realidad, los distintos controladores de Ingress operan ligeramente diferente. {{< note >}} Asegúrate de revisar la documentación del controlador de Ingress para entender las precauciones de usarlo. {{< /note >}} ## El recurso Ingress Un ejemplo mínimo de un recurso Ingress: {{% code_sample file="service/networking/minimal-ingress.yaml" %}} Un Ingress necesita los campos `apiVersion`, `kind`, `metadata` y `spec`. El nombre del objeto Ingress debe ser un [nombre de subdominio DNS](es/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. Para información general sobre cómo trabajar con archivos de configuración, mira [desplegando aplicaciones](/es/docs/tasks/run-application/run-stateless-application-deployment/), [configurando contenedores](/docs/tasks/configure-pod-container/configure-pod-configmap/), [administrando recursos](/docs/concepts/cluster-administration/manage-deployment/). Los Ingress usan anotaciones frecuentemente para configurar algunas opciones dependiendo del controlador de Ingress. Distintos [controladores de Ingress](/docs/concepts/services-networking/ingress-controllers) soportan anotaciones diferentes. Revisa la documentación para tu elección del controlador de Ingress para saber qué anotaciones son soportadas. La [especificación Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec) tiene toda la información que necesitas para configurar un balanceador de cargas o un servidor proxy. Mucho más importante, contiene un listado de reglas que emparejan contra todas las peticiones entrantes. El recurso Ingress solo soporta reglas para dirigir el tráfico HTTP(S). Si se omite la `ingressClassName`, se define una [clase Ingress por defecto](#default-ingress-class). Existen algunos controladores de Ingress, que trabajan sin la definición de una `IngressClass` por defecto. Se recomienda especificar el `IngressClass` por defecto como se muestra [abajo](#default-ingress-class). ### Reglas del Ingress Cada regla HTTP contiene la siguiente información: * Un host opcional. En este ejemplo, no se define un host así que la regla se aplica a todo el tráfico de entrada HTTP a través de la dirección IP especificada. Cuando se proporciona un host (por ejemplo, foo.bar.com), las reglas se aplican a ese host. * Un listado de rutas (por ejemplo, `/testpath`), cada una de las cuales tiene un backend asociado con un `service.name` y un `service.port.name` o un `service.port.number`. Tanto el host como la ruta deben coincidir con el contenido de una petición de entrada antes que el balanceador de cargas dirija el tráfico al Service referenciado. * Un backend es una combinación de un Service y un puerto como se describe en la [documentación del Service](/es/docs/concepts/services-networking/service/) o un [recurso personalizado backend](#resource-backend) a través de un {{< glossary_tooltip term_id="CustomResourceDefinition" text=" CRD" >}}. Las peticiones HTTP (y HTTPS) al Ingress que coinciden con el host y la ruta de la regla se envían al backend del listado. Un `defaultBackend` se configura frecuentemente en un controlador de Ingress para dar servicio a cualquier petición que no coincide con una ruta en la especificación. ### DefaultBackend {#default-backend} Un Ingress sin reglas envía todo el tráfico a un único backend y `.spec.defaultBackend` está en el backend que debería manejar las peticiones en ese caso. El `defaultBackend` es una opción de configuración convencional del [controlador Ingress ](/docs/concepts/services-networking/ingress-controllers) y no se especifica en tus recursos del Ingress. Si no se especifican reglas `.spec.rules`, se debe especificar `.spec.defaultBackend`. Si no se establece un `defaultBackend`, las peticiones que no coincidan con ninguna de las reglas las decidirá el controlador ingress (consulta la documentación de tu controlador de ingress para saber cómo maneja este caso). Si ninguno de los hosts o rutas coincide con la petición HTTP en los objetos Ingress, el tráfico será enrutado a tu backend predeterminado. ### Resource backends {#resource-backend} Un `Resource` backend es una referencia de objeto (ObjectRef en inglés) a otro recurso de Kubernetes dentro del mismo espacio de nombres que el objeto Ingress. Este `Resource` es mutuamente exclusivo con el Service, y la validación fallará si ambos se especifican. Un uso común para un `Resource` backend es para ingresar datos a un backend de almacenamiento de datos con activos estáticos. {{% code_sample file="service/networking/ingress-resource-backend.yaml" %}} Luego de crear el Ingress mencionado arriba, puedes verlo con el siguiente comando: ```bash kubectl describe ingress ingress-resource-backend ``` ``` Name: ingress-resource-backend Namespace: default Address: Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets Rules: Host Path Backends ---- ---- -------- * /icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets Annotations: Events: ``` ### Tipos de ruta Se requiere que cada ruta de un Ingress tenga un tipo de ruta correspondiente. Las Rutas que no incluyen un `pathType` explícito fallarán la validación. Hay 3 tipos de rutas soportadas: * `ImplementationSpecific`: Con este tipo de ruta, la coincidencia depende de la IngressClass. Las implementaciones pueden tratar esto como un `pathType` separado o tratarlas de forma idéntica a los tipos de ruta `Prefix` o `Exact`. * `Exact`: Coincide la ruta de la URL exactamente con sensibilidad a mayúsculas y minúsculas. * `Prefix`: Coincide basado en el prefijo de una ruta URL dividida por `/`. La coincidencia es sensible a mayúsculas y minúsculas, y hecha en un elemento de la ruta por elemento. Un elemento de la ruta refiere a la lista de etiquetas en la ruta dividida por el separador `/`. Una petición es una coincidencia para la ruta _p_ si cada _p_ es un elemento prefijo de _p_ de la ruta requerida. {{< note >}} Si el último elemento de una ruta es una subcadena de caracteres del último elemento de la solicitud de ruta, no es una coincidencia (por ejemplo: `/foo/bar` coincide con `/foo/bar/baz`, pero no coincide con `/foo/barbaz`). {{< /note >}} ### Ejemplos | Tipo | Ruta(s) | Ruta de la(s) peticion(es) | ¿Coincide? | |----------|-----------------------------------|----------------------------|----------------------------------------| | Prefijo | `/` | (todas las rutas) | Sí | | Exacto | `/foo` | `/foo` | Si | | Exacto | `/foo` | `/bar` | No | | Exacto | `/foo` | `/foo/` | No | | Exacto | `/foo/` | `/foo` | No | | Prefijo | `/foo` | `/foo`, `/foo/` | Si | | Prefijo | `/foo/` | `/foo`, `/foo/` | Si | | Prefijo | `/aaa/bb` | `/aaa/bbb` | No | | Prefijo | `/aaa/bbb` | `/aaa/bbb` | Si | | Prefijo | `/aaa/bbb/` | `/aaa/bbb` | Si, ignora la barra diagonal | | Prefijo | `/aaa/bbb` | `/aaa/bbb/` | Si, coincide con barra diagonal | | Prefijo | `/aaa/bbb` | `/aaa/bbb/ccc` | Si, coincide con la subruta | | Prefijo | `/aaa/bbb` | `/aaa/bbbxyz` | No, no coincide con el prefijo de cadena | | Prefijo | `/`, `/aaa` | `/aaa/ccc` | Si, coincide con el prefijo `/aaa` | | Prefijo | `/`, `/aaa`, `/aaa/bbb` | `/aaa/bbb` | Si, coincide con el prefijo `/aaa/bbb` | | Prefijo | `/`, `/aaa`, `/aaa/bbb` | `/ccc` | Si, coincide con el prefijo`/` | | Prefijo | `/aaa` | `/ccc` | No, usa el backend predeterminado | | Mezclado | `/foo` (Prefijo), `/foo` (Exacto) | `/foo` | Si, prefiere la coincidencia exacta | #### Múltiples coincidencias En algunos casos, muchas rutas dentro de un Ingress coincidirán con una petición. En esos casos, la precedencia se le dará al primero con la ruta más larga que coincide. Si dos rutas todavía coinciden por igual, se le dará precedencia a las rutas con una coincidencia de ruta exacta sobre las rutas que contienen prefijos. ## Comodines Hostname Los hosts pueden ser coincidencias exactas (por ejemplo “`foo.bar.com`”) o un comodín (por ejemplo “`*.foo.com`”). Las coincidencias precisas requieren que el encabezado `host` coincida con el campo `host`. Las coincidencias de comodín requieren que el encabezado `host` sea igual al sufijo de la regla del comodín. | Host | Encabezado Host | ¿Coincidencia? | |-------------|-------------------|-----------------------------------------------------| | `*.foo.com` | `bar.foo.com` | Coincide basado en el sufijo común | | `*.foo.com` | `baz.bar.foo.com` | No coincide, el comodín solo cubre una etiqueta DNS | | `*.foo.com` | `foo.com` | No coincide, el comodín solo cubre una etiqueta DNS | {{% code_sample file="service/networking/ingress-wildcard-host.yaml" %}} ## La Clase Ingress Los Ingress pueden ser implementados por distintos controladores, comúnmente con una configuración distinta. Cada Ingress debería especificar una clase, una referencia a un recurso IngressClass que contiene información adicional incluyendo el nombre del controlador que debería implementar la clase. {{% code_sample file="service/networking/external-lb.yaml" %}} El campo `.spec.parameters` de un IngressClass te permite hacer referencia a otro recurso que proporciona la configuración relacionada con esa IngressClass. El tipo específico de parámetros a usar depende del controlador de Ingress que especificas en el campo `spec.controller` de la IngressClass. ### Alcance de IngressClass Dependiendo de tu controlador de ingress, podrías ser capaz de usar parámetros que se establecen en todo el clúster, o solamente para un namespace. {{< tabs name="tabs_ingressclass_parameter_scope" >}} {{% tab name="Clúster" %}} El alcance por defecto de los parámetros IngressClass es para todo el clúster. Si estableces el campo `spec.parameters` y no estableces el campo `spec.parameters.scope`, entonces el IngressClass se refiere al recurso cuyo alcance es todo el clúster. El atributo `kind` (en combinación con el `apiGroup`) de los parámetros se refiere a la API con alcance a todo el clúster (posiblemente un recurso personalizado), y el `name` de los parámetros identifica al recurso del clúster específico para esa API. Por ejemplo: ```yaml --- apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: external-lb-1 spec: controller: example.com/ingress-controller parameters: # Los parámetros para este IngressClass se especifican en un # ClusterIngressParameter (API group k8s.example.net) llamado # "external-config-1". Esta definición le indica a Kubernetes # de buscar por un parámetro de recurso con alcance a todo el clúster. scope: Cluster apiGroup: k8s.example.net kind: ClusterIngressParameter name: external-config-1 ``` {{% /tab %}} {{% tab name="Namespaced" %}} {{< feature-state for_k8s_version="v1.23" state="stable" >}} Si estableces el campo `spec.parameters` y el `spec.parameters.scope` al `Namespace`, entonces el IngressClass se refiere al recurso cuyo alcance es el namespace. También debes establecer el campo `namespace` dentro de `spec.parameters` con el Namespace que contiene los parámetros que quieres usar. El atributo `kind` (en combinación con `apiGroup`) de los parámetros se refiere a la API restringida por un Namespace (por ejemplo: ConfigMap), y el `name` de los parámetros identifica al recurso específico en el namespace que has especificado en `namespace`. Los parámetros con alcance al Namespace ayudan al operador del clúster a delegar el control sobre la configuración (por ejemplo, ajustes del balanceador de cargas, definición de una API gateway) que se usa para una carga de trabajo. Si utilizas un parámetro con alcance al Namespace entonces: - El equipo operador del clúster necesita aprobar los cambios de un equipo distinto cada vez que se aplica un nuevo cambio a la configuración. - O el equipo operador del clúster debe definir específicamente estos controles de acceso, tales como asociaciones de roles [RBAC](/docs/reference/access-authn-authz/rbac/) y mapeos, que permitan a la aplicación hacer cambios al recurso de parámetros con alcance al clúster. La API de la IngressClass por sí misma siempre tiene alcance al clúster. Aquí hay un ejemplo de una IngressClass que hace referencia a parámetros que están restringidos por un Namespace: ```yaml --- apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: external-lb-2 spec: controller: example.com/ingress-controller parameters: # Los parámetros para esta IngressClass se especifican en un # IngressParameter (API group k8s.example.com) llamado "external-config", # que está en el namespace "external-configuration". scope: Namespace apiGroup: k8s.example.com kind: IngressParameter namespace: external-configuration name: external-config ``` {{% /tab %}} {{< /tabs >}} ### Anotación deprecada Antes que el recurso IngressClass y el campo `ingressClassName` se añadieran a Kubernetes 1.18, las clases Ingress se especificaban con una anotación `kubernetes.io/ingress.class` en el Ingress. Esta anotación nunca se definió formalmente, pero era ampliamente soportada por los controladores de Ingress. El nuevo campo `ingressClassName` en los recursos Ingress es un reemplazo para esa anotación, pero no es un equivalente directo. Mientras que la anotación se utilizaba generalmente para hacer referencia al nombre del controlador de Ingress que debería implementar el Ingress, el campo es una referencia a un recurso IngressClass que contiene configuración adicional del Ingress, incluyendo el nombre del controlador Ingress. ### IngressClass por defecto {#default-ingress-class} Puedes marcar un ingressClass en particular por defecto para tu clúster. Establecer la anotación `ingressclass.kubernetes.io/is-default-class` a `true` en un recurso IngressClass asegurará que los nuevos Ingress sin un campo `ingressClassName` especificado sean asignados a esta IngressClass por defecto. {{< caution >}} Si tienes más de una IngressClass marcada por defecto en tu clúster, el controlador de admisión impide crear objetos que no tienen un `ingressClassName` especificado. Puedes resolver esto asegurándote que como máximo 1 IngressClass está marcado como el predeterminado en tu clúster. {{< /caution >}} Existen algunos controladores de ingress, que funcionan sin una definición de una `ingressClass`. Se recomienda especificar el `IngressClass` predeterminado: {{% code_sample file="service/networking/default-ingressclass.yaml" %}} ## Tipos de Ingress ### Ingress respaldado por un único servicio {#single-service-ingress} Hay conceptos existentes de Kubernetes que te permiten exponer un Service único (mirar [alternativas](#alternativas)). También puedes hacerlo con un Ingress especificando un *backend predeterminado* sin reglas. {{% code_sample file="service/networking/test-ingress.yaml" %}} Si lo creas usando `kubectl apply -f` podrías mirar el estado del Ingress que has creado: ```bash kubectl get ingress test-ingress ``` ``` NAME CLASS HOSTS ADDRESS PORTS AGE test-ingress external-lb * 203.0.113.123 80 59s ``` Donde `203.0.113.123` es la IP asignada por el controlador Ingress para satisfacer este Ingress. {{< note >}} Los controladores de Ingress y los balanceadores de carga pueden tardar un minuto o dos en asignar una dirección IP. Hasta entonces, se podrá ver la dirección marcada como ``. {{< /note >}} ### Abanico Simple Una configuración de abanico enruta el tráfico de una única dirección IP a más de un Service, basado en la URI HTTP solicitada. Un Ingress te permite tener el número de balanceadores de carga al mínimo. Por ejemplo, una configuración como: {{< figure src="/docs/images/ingressFanOut.svg" alt="ingress-fanout-diagram" class="diagram-large" caption="Figure. Ingress Fan Out" link="https://mermaid.live/edit#pako:eNqNUslOwzAQ_RXLvYCUhMQpUFzUUzkgcUBwbHpw4klr4diR7bCo8O8k2FFbFomLPZq3jP00O1xpDpjijWHtFt09zAuFUCUFKHey8vf6NE7QrdoYsDZumGIb4Oi6NAskNeOoZJKpCgxK4oXwrFVgRyi7nCVXWZKRPMlysv5yD6Q4Xryf1Vq_WzDPooJs9egLNDbolKTpT03JzKgh3zWEztJZ0Niu9L-qZGcdmAMfj4cxvWmreba613z9C0B-AMQD-V_AdA-A4j5QZu0SatRKJhSqhZR0wjmPrDP6CeikrutQxy-Cuy2dtq9RpaU2dJKm6fzI5Glmg0VOLio4_5dLjx27hFSC015KJ2VZHtuQvY2fuHcaE43G0MaCREOow_FV5cMxHZ5-oPX75UM5avuXhXuOI9yAaZjg_aLuBl6B3RYaKDDtSw4166QrcKE-emrXcubghgunDaY1kxYizDqnH99UhakzHYykpWD9hjS--fEJoIELqQ" >}} Requeriría un Ingress como este: {{% code_sample file="service/networking/simple-fanout-example.yaml" %}} Cuando creas el Ingress con `kubectl apply -f`: ```shell kubectl describe ingress simple-fanout-example ``` ``` Name: simple-fanout-example Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo service1:4200 (10.8.0.90:4200) /bar service2:8080 (10.8.0.91:8080) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 22s loadbalancer-controller default/test ``` El controlador de Ingress aprovisiona un balanceador de cargas específico para la implementación que satisface al Ingress, mientras los Services (`service1`, `service2`) existan. Cuando sea así, podrás ver la dirección del balanceador de cargas en el campo de dirección. {{< note >}} Dependiendo del [controlador de Ingress](/docs/concepts/services-networking/ingress-controllers/) que uses, puede que necesites crear un [Service](/es/docs/concepts/services-networking/service/) default-http-backend. {{< /note >}} ### Hosting virtual basado en nombre Los hostings virtuales basados en el nombre soportan enrutado de tráfico HTTP a nombres hosts múltiples con la misma dirección IP. {{< figure src="/docs/images/ingressNameBased.svg" alt="ingress-namebase-diagram" class="diagram-large" caption="Figure. Ingress Name Based Virtual hosting" link="https://mermaid.live/edit#pako:eNqNkl9PwyAUxb8KYS-atM1Kp05m9qSJJj4Y97jugcLtRqTQAPVPdN_dVlq3qUt8gZt7zvkBN7xjbgRgiteW1Rt0_zjLNUJcSdD-ZBn21WmcoDu9tuBcXDHN1iDQVWHnSBkmUMEU0xwsSuK5DK5l745QejFNLtMkJVmSZmT1Re9NcTz_uDXOU1QakxTMJtxUHw7ss-SQLhehQEODTsdH4l20Q-zFyc84-Y67pghv5apxHuweMuj9eS2_NiJdPhix-kMgvwQShOyYMNkJoEUYM3PuGkpUKyY1KqVSdCSEiJy35gnoqCzLvo5fpPAbOqlfI26UsXQ0Ho9nB5CnqesRGTnncPYvSqsdUvqp9KRdlI6KojjEkB0mnLgjDRONhqENBYm6oXbLV5V1y6S7-l42_LowlIN2uFm_twqOcAW2YlK0H_i9c-bYb6CCHNO2FFCyRvkc53rbWptaMA83QnpjMS2ZchBh1nizeNMcU28bGEzXkrV_pArN7Sc0rBTu" >}} El siguiente Ingress le dice al balanceador de cargas de respaldo de enrutar las peticiones basadas en el [encabezado del Host ](https://tools.ietf.org/html/rfc7230#section-5.4). {{% code_sample file="service/networking/name-virtual-host-ingress.yaml" %}} Si creas un recurso Ingress sin ningún host definido en las reglas, luego cualquier tráfico web a la dirección IP de tu controlador Ingress puede coincidir sin requerir un host virtual basado en el nombre. Por ejemplo, el siguiente Ingress enruta el tráfico solicitado para `first.bar.com` a `service1`, `second.bar.com` a `service2`, y cualquier tráfico cuyo encabezado de petición del host no coincida con `first.bar.com` y `second.bar.com` a `service3`. {{% code_sample file="service/networking/name-virtual-host-ingress-no-third-host.yaml" %}} ### TLS Puedes segurizar un Ingress especificando un {{< glossary_tooltip term_id="secret" >}} que contiene una clave privada TLS y un certificado. El recurso Ingress solo soporta un puerto TLS, el 443, y asume la terminación TLS en el punto del ingress (El tráfico al Service y sus Pods es en texto plano). Si la sección de configuración TLS especifica hosts diferentes, se multiplexan en el mismo puerto de acuerdo con el hostname especificado a través de la extensión TLS SNI (teniendo el cuenta que el controlador de Ingress soporte SNI). El secreto TLS debe contener claves llamadas `tls.crt` y `tls.key` que contiene el certificado y llave privad para usar TLS. Por ejemplo: ```yaml apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: default data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` Al hacer referencia a este secreto en un Ingress le indica al controlador Ingress de segurizar el canal desde el cliente al balanceador de cargas usando TLS. Necesitas asegurarte que el secreto TLS que has creado viene de un certificado que contiene un nombre común (CN), también conocido como Nombre de dominio calificado (FQDN en inglés) para `https-example.foo.com`. {{< note >}} Ten en cuenta que TLS no funcionará en la regla predeterminada porque los certificados estarían emitidos para todos los sub-dominios posibles. Por lo tanto, los `hosts` en la sección `tls` tienen que coincidir explícitamente con el `host` en la sección `rules`. {{< /note >}} {{% code_sample file="service/networking/tls-example-ingress.yaml" %}} {{< note >}} Hay una diferencia entre las características TLS soportadas por varios controladores Ingress. Mira la documentación en [GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), o cualquier otro controlador Ingress específico de plataforma para entender cómo funciona el TLS en tu entorno. {{< /note >}} ### Balanceo de cargas {#load-balancing} Un controlador de Ingress está configurado por defecto con algunos ajustes de política de balanceo de cargas que aplica a todos los Ingress, como los algoritmos de balanceo de cargas, esquema de pesos del backend y otros. Otros conceptos más avanzados de balanceo de cargas (ej., sesiones persistentes, pesos dinámicos) no están expuestos todavía a través del Ingress. En su lugar, obtienes estas características a través del balanceador de cargas usado por un Service. Vale la pena apuntar que aunque las revisiones de salud no se exponen directamente a través del Ingress, existen conceptos paralelos en Kubernetes tales como [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) que permiten lograr el mismo resultado final. Revisa la documentación específica del controlador para conocer cómo manejar estas revisiones de salud (por ejemplo: [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)). ## Actualizando un Ingress Para actualizar un Ingress existente a un nuevo Host, puedes actualizarlo editando el recurso: ```shell kubectl describe ingress test ``` ``` Name: test Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo service1:80 (10.8.0.90:80) Annotations: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 35s loadbalancer-controller default/test ``` ```shell kubectl edit ingress test ``` Esto muestra un editor con la configuración existente en formato YAML. Modifícalo para incluir el nuevo Host: ```yaml spec: rules: - host: foo.bar.com http: paths: - backend: service: name: service1 port: number: 80 path: /foo pathType: Prefix - host: bar.baz.com http: paths: - backend: service: name: service2 port: number: 80 path: /foo pathType: Prefix #.. ``` Luego de guardar tus cambios, kubectl actualiza el recurso en el servidor API, que le indica al controlador Ingress de reconfigurar el balanceador de cargas. Verifica esto: ```shell kubectl describe ingress test ``` ``` Name: test Namespace: default Address: 178.91.123.132 Default backend: default-http-backend:80 (10.8.2.3:8080) Rules: Host Path Backends ---- ---- -------- foo.bar.com /foo service1:80 (10.8.0.90:80) bar.baz.com /foo service2:80 (10.8.0.91:80) Annotations: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 45s loadbalancer-controller default/test ``` Puedes lograr el mismo resultado invocando `kubectl replace -f` en un fichero YAML de Ingress. ## Fallos a través de zonas de disponibilidad Las técnicas para distribuir el tráfico entre dominios de falla difieren entre los proveedores de la nube. Revisa la documentación del [Ingress controller](/docs/concepts/services-networking/ingress-controllers) relevante para detalles. ## Alternativas Puedes exponer un Service de muchas maneras que no involucran directamente el recurso Ingress: * Usa un [Service.Type=LoadBalancer](es/docs/concepts/services-networking/service/#loadbalancer) * Usa un [Service.Type=NodePort](es/docs/concepts/services-networking/service/#tipo-nodeport) ## {{% heading "whatsnext" %}} * Aprende sobre la API del [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) * Aprende sobre [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/) * [Configurar un Ingress en Minikube con el controlador NGINX](/docs/tasks/access-application-cluster/ingress-minikube/)