Короткий ответ
TLS-сертификат подключается через поле tls в манифесте Ingress со ссылкой на Secret типа kubernetes.io/tls, а маршрутизация по путям задаётся списком rules[].http.paths с указанием pathType и backend-сервиса для каждого пути; сам Ingress-контроллер терминирует TLS и далее обычно общается с backend по HTTP внутри кластера.
Как это работает подробнее
Ingress-контроллер слушает порт 443, использует сертификат и ключ из указанного Secret для TLS handshake, после чего расшифрованный HTTP-запрос маршрутизируется согласно правилам host/path. pathType: Prefix сопоставляет по префиксу пути, Exact — только точное совпадение, что важно для корректной работы нескольких правил с пересекающимися путями.
Пример кода
manifest.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: shop }
spec:
ingressClassName: nginx
tls:
- hosts: ["shop.example.com"]
secretName: shop-tls
rules:
- host: shop.example.com
http:
paths:
- path: /api
pathType: Prefix
backend: { service: { name: api, port: { number: 8080 } } }
- path: /
pathType: Prefix
backend: { service: { name: frontend, port: { number: 80 } } }Что использовать на практике
- Практика. для автоматического выпуска и обновления сертификатов обычно используют cert-manager, который сам создаёт и обновляет Secret с TLS-сертификатом (например, через Let's Encrypt), избавляя от ручного управления сроком действия. При нескольких
hostв одном Ingress каждый может указывать на разные сервисы, что позволяет обслуживать несколько доменов одним контроллером и одним внешним IP.
Подводные камни
- Риски. указывать в
tls.hostsдомен, не совпадающий с доменом в сертификате Secret — TLS handshake завершится ошибкой несоответствия имени; не учитывать порядок правил при пересекающихся путях разныхpathType, что может привести к неожиданной маршрутизации; забывать, что backend-сервис должен существовать и иметь готовые endpoints — иначе Ingress-контроллер вернёт 502/503 несмотря на корректно настроенный TLS.