надо отслеживать • Под(ы) в кластере - «вещь в себе», без подачи входящих данных/запросов они бесполезны • Если подов много, надо балансировать между ними нагрузку • Есть сервисы, но по умолчанию они не работают вне кластера • Хотим кнопку "Сделать хорошо" для разработчиков :-) • Хотим, чтобы пользователи были счастливы (без 5xx)
оттуда трафик по подам: apiVersion: v1 kind: Service metadata: name: my-nodeport-service selector: app: my-app spec: type: NodePort ports: - name: http port: 80 targetPort: 80 nodePort: 30036 protocol: TCP Использовать когда есть белые адреса на нодах и хочется простоты (за счёт доступности) Документация
с его API для балансировщика. Получает «белый» IP от провайдера. Позволяет получить любой трафик . Каждому сервису нужен свой облачный балансер :-( Использовать в облаках для простых приложений (или нет: MetalLB). Документация
my-ingress spec: backend: serviceName: other servicePort: 8080 rules: - host: foo.mydomain.com http: paths: - backend: serviceName: foo servicePort: 8080 - host: mydomain.com http: paths: - path: /bar/* backend: serviceName: bar ServicePort: 8080 Маршрут по умолчанию на other Вхост foo.mydomain.com маршрутизировать на сервис foo Пути вида /bar/ вхоста mydomain.com маршрутизировать на сервис bar
Документация на стандартный ингресс- контроллер • Kubernetes NodePort vs LoadBalancer vs In gress? When should I use what? • Kubedex ingress comparison • Интеграция с DNS-провайдером