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

Published in

Southbridge

6 min readJan 8, 2018

В посте о запуске приложения .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: Alwayskubectl apply -f DeployPodMyWebApi.yaml

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

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

apiVersion: v1
kind: Service
metadata:
  name: myapiservice
spec:
  ports:
    - port: 80
  selector:
    app: mywebapi
  type: NodePortkubectl 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-backendkubectl 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: LoadBalancerkubectl 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: 80kubectl 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-backendkubectl 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.

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

Ingress в помощь

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

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

Written by Igor Olemskoi