Конфигурация Ingress в Kubernetes с использованием Azure Container Service

В посте о запуске приложения .NET Core 2 в Kubernetes я создам Service, чтобы открыть доступ к .NET Core 2 Webapi. Service получит публичный IP-адрес. Конфигурация выглядит так:

apiVersion: v1
kind: Service
metadata:
name: myapiservice
spec:
ports:
- port: 80
selector:
app: mywebapi
type: LoadBalancer

Схема выглядит так:

У нас есть три пода, которые содержат один и тот же образ контейнера Docker. Мы открываем доступ через интернет к контейнеру webapi. Это делается с помощью Service в Kubernetes, настроенного как LoadBalancer.

Теперь создаем еще один webapi и также открываем к нему доступ через интернет. Нам нужно развернуть те же самые части, которые были созданы ранее. Таким образом, три пода и Service настроены как LoadBalancer. Схема выглядит так:

Схема не очень расширяема, хотя с 2 webapi’s/services это можно сделать. Но что если у нас есть 25 webapi’s? Максимальное количество общедоступных IP-адресов, которые можно использовать в Azure, по умолчанию — 20. Недостатком является то, что потребитель должен знать несколько IP-адресов для вызова webapi.
Ingress решает эту проблему и имеет некоторые дополнительные удобные функции.

Ingress в помощь

С Ingress сервисы, принадлежащие подам, где запускаются контейнеры, не помечены как LoadBalancer, но настроены как NodeType. Таким образом, у сервисов нет публичного IP-адреса. Вы разворачиваете следующие следующие компоненты рядом с подами и Services:

Ingress: содержит сопоставление между URL-адресами и сервисами. Также имеется конфигурация, связанная с Ingress Controller.
Ingress Controller: под, который запускает Controller Ingress и nginx (в своем примере я использую Nginx, Kubernetes также поддерживает другие контроллеры).
Nginx имеет файл конфигурации, в котором описывается способ балансировки и маршрутизации трафика. Ingress автоматически генерирует файл конфигурации Nginx.
Ingress Service: Ingress Controller нуждается в общедоступном IP-адресе. Ingress Service заботится об этом. У нас только 1 общедоступный IP-адрес для всех наших webapi.

Пошаговая конфигурация Ingress

Я предполагаю, что вы настроили кластер Kubernetes, чтобы ServiceAccount имел доступ к вашему приватному реестру Docker. В этом посте вы узнаете, как предоставить доступ Azure Container Registry.

1. Разверните поды.

Обратите внимание, какую версию изображения Docker Container вы используете.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mywebapi-deployment
spec:
replicas: 3
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: mywebapi
spec:
containers:
- name: mywebapi
image: pnk8sdemocrwe.azurecr.io/myservice/mywebapi:1
ports:
- containerPort: 80
imagePullPolicy: Always
kubectl apply -f DeployPodMyWebApi.yaml

2. Разверните Service для подов.

На этот раз мы разворачиваем службу с типом NodePort вместо LoadBalancer.

apiVersion: v1
kind: Service
metadata:
name: myapiservice
spec:
ports:
- port: 80
selector:
app: mywebapi
type: NodePort
kubectl apply -f DeployServiceMyApiService.yaml

3. Разверните Ingress Controller.

Обратите внимание, что Ingress Controller развернут в пространстве имен kube-system. В настоящий момент nginx-ingress-controller: 0.9.0-beta.15 — последняя версия Docker Image. Вы можете проверить последнюю версию здесь: https://github.com/kubernetes/ingress-nginx/releases

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-ingress-controller
labels:
k8s-app: nginx-ingress-controller
namespace: kube-system
spec:
replicas: 1
template:
metadata:
labels:
k8s-app: nginx-ingress-controller
annotations:
prometheus.io/port: '10254'
prometheus.io/scrape: 'true'
spec:
# hostNetwork makes it possible to use ipv6 and to preserve the source IP correctly regardless of docker configuration
# however, it is not a hard dependency of the nginx-ingress-controller itself and it may cause issues if port 10254 already is taken on the host
# that said, since hostPort is broken on CNI (https://github.com/kubernetes/kubernetes/issues/31307) we have to use hostNetwork where CNI is used
# like with kubeadm
# hostNetwork: true
# Check latest version here: https://github.com/kubernetes/ingress-nginx/releases
terminationGracePeriodSeconds: 60
containers:
- image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.15
name: nginx-ingress-controller
ports:
- containerPort: 80
hostPort: 80
- containerPort: 443
hostPort: 443
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
args:
- /nginx-ingress-controller
- --default-backend-service=$(POD_NAMESPACE)/default-http-backend
kubectl apply -f DeployIngressController.yaml

4. Разверните Ingress Service.

До сих пор у нас не было общедоступного IP-адреса, нам нужен только один. Service позаботится об этом. Он уже настроен на использование портов 80 и 443. Service также разворачивается в пространстве имен kube-system.

apiVersion: v1
kind: Service
metadata:
name: ingressservice
namespace: kube-system
spec:
ports:
- port: 80
name: http
- port: 443
name: https
selector:
k8s-app: nginx-ingress-controller
type: LoadBalancer
kubectl apply -f DeployServiceIngressService.yaml

5. Разверните Ingress.

Пока настроен только http-трафик, serviceName myapiservice относится к имени службы, развернутой на шаге 2. Есть две аннотации. Первая аннотация необязательна и указывает, какой Ingress Controller мы хотим использовать. Таким образом, вы можете развернуть несколько Ingress Controllers. Вторая аннотация указывает nginx переписать URL-адрес. Сервис указывается на: http://mymicroservices.xpirit.nl/mywebapi и ведет на mywebapi .NET Core 2 webapi. Если оставить эту аннотацию, webapi называется как: http://192.168.0.1/mywebapi. Очевидно, что вы хотите назвать его http://192.168.0.1. Таким образом, имя пути, предназначенного для маршрутизации трафика, удаляется, когда вызов перенаправляется на ваш модуль.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myingress
annotations:
kubernetes.io/ingress.class: nginx
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: mymicroservices.xpirit.nl
http:
paths:
- path: /mywebapi
backend:
serviceName: myapiservice
servicePort: 80
kubectl apply -f DeployIngress.yaml

Если у вас нет имени домена для сервиса, но вы хотите получить доступ к вашим услугам по IP-адресу, то можно удалить хост. Конфигурация выглядит так:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myingress
annotations:
kubernetes.io/ingress.class: nginx
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /mywebapi
backend:
serviceName: myapiservice
servicePort: 80

Если у вас больше сервисов, расширьте маршрутизацию:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myingress
annotations:
kubernetes.io/ingress.class: nginx
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /mywebapi
backend:
serviceName: myapiservice
servicePort: 80
- path: /myotherwebapi
backend:
serviceName: myotherapiservice
servicePort: 80

Теперь вы можете получить доступ к сервису по пути, который настроили в Ingress, или общедоступному IP-адресу, который открывается службой Ingress.

6. Бекенд по умолчанию.

В конце Deploymentfile Ingress Controller настроен бекенд по умолчанию. Его также необходимо развернуть. Под нуждается в Service. Он возвращает 404, когда Ingress Controller не может успешно смаршрутизировать запрос в соответствии с правилами сопоставления. Оба развертывания настроены в пространстве имен kube-system.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: default-http-backend
labels:
k8s-app: default-http-backend
namespace: kube-system
spec:
replicas: 1
template:
metadata:
labels:
k8s-app: default-http-backend
spec:
terminationGracePeriodSeconds: 60
containers:
- name: default-http-backend
# Any image is permissable as long as:
# 1. It serves a 404 page at /
# 2. It serves 200 on a /healthz endpoint
image: gcr.io/google_containers/defaultbackend:1.4
livenessProbe:
httpGet:
path: /healthz
port: 8080
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
ports:
- containerPort: 8080
resources:
limits:
cpu: 10m
memory: 20Mi
requests:
cpu: 10m
memory: 20Mi
---
apiVersion: v1
kind: Service
metadata:
name: default-http-backend
namespace: kube-system
labels:
k8s-app: default-http-backend
spec:
ports:
- port: 80
targetPort: 8080
selector:
k8s-app: default-http-backend
kubectl apply -f DeployDefaultBackend.yaml

В случае проблем

Конфигурация должна совершаться в строгом порядке. Результат работы можно посмотреть в DefaultBackendService. В случае проблем проведите указанные ниже проверки.

  • Проверьте метки и соответствующие селекторы.
  • Проверьте порты подов.
  • Проверьте, есть ли возможность получить доступ к сервису из кластера Kubernetes.
    Начните с уровня под, уровня Service, а затем уровня Ingress.
    Уровень под в качестве примера:
    1) получите имя любого пода:
    kubectl get pods;
    2) получите приглашение в выбранный под:
    kubectl exec -it "mypodname" bash;
    3) curl IP-адрес пода, где работает webapi
    curl -vvv -L -k https://13.81.52.80.
  • Проверьте файл nginx.conf. Его можно прочитать:
    1) получите имя пода, в котором работает Ingress Controller:
    kubectl get pods -n kube-system;
    2) подключитесь к контейнеру:
    kubectl exec -it "myingresscontrollerpodname" -n kube-system bash;
    3) откройте сгенерированный файл конфигурации nginx:
    cat /etc/nginx/nginx.conf.

Оригинал: Configure Ingress on Kubernetes using Azure Container Service.