Установка Ingress для Minikube

В прошлой статье я рассказывал о том, как установить и настроить Minikube. Так же я кратко рассказал о том, зачем вообще Minikube нужен. В этой публикации мы поговорим о том, как наши приложения в контейнере выпускаются во внешний мир за пределами кластера Kubernetes. Для этого используется контроллер Ingress. Я постараюсь показать основные моменты того, как выполняется установка Ingress для Minikube.

Это будет статья по основным командам для так называемого быстрого развертывания (quick deploy). Подробное руководство по установки Ingress контроллера есть в официальной документации.

Немного вводных

В качестве контроллера Ingress я буду использовать NGINX Ingress Controller. Есть еще один вариант Ingress контроллера – Ingress NGINX Controller. Я буду говорить именно про первый их них. Возможно, я напишу отдельную статью или дополню эту статью про установку второго варианта Ingress, но попозже.

Оперционная система, на которой развернут мой Minikube – Ubuntu 22.04.

Установка Ingress для Minikube

Добавление Ingress контроллера в кластер Minikube – тоже довольно простая операция:

minikube addons enable ingress

Запуститься процесс установки расширения. Дождитесь окончания процесса добавления расширения. Пример листинга успешного добавления расширения:

roman@roman-virtual-machine:~$ minikube addons enable ingress
💡  ingress is an addon maintained by Kubernetes. For any concerns contact minikube on GitHub.
You can view the list of minikube maintainers at: https://github.com/kubernetes/minikube/blob/master/OWNERS
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
    ▪ Using image k8s.gcr.io/ingress-nginx/controller:v1.2.1
🔎  Verifying ingress addon...
🌟  The 'ingress' addon is enabled
roman@roman-virtual-machine:~$ 

После добавления расширения в нашем кластере Minikube появятся дополнительные поды. проверим их состояние:

kubectl get pods -n ingress-nginx

roman@roman-virtual-machine:~$ kubectl get pods -n ingress-nginx
NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-scdts        0/1     Completed   0          5m43s
ingress-nginx-admission-patch-z2k5m         0/1     Completed   1          5m43s
ingress-nginx-controller-5959f988fd-kcjhk   1/1     Running     0          5m43s
roman@roman-virtual-machine:~$ 

Пример использования Ingress

Я постараюсь привести наглядный пример того, как можно выполнить маршрутизацию запросов к контроллеру Ingress.

Например, реализуем следующую схему:

Например, URL запрос itproblog.ru/v1 будет перенаправлен на приложение v1.0, а запрос itproblog.ru/v2 будет перенаправлен на приложение v2.0.

Сначала опишем два развертывания и два сервиса, которые создадут две версии некоего приложения и опубликуют его. Для удобства я помещу описание обоих развертываний в один файл apps.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: appv1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: v1
  template:
    metadata:
      labels:
        app: v1
    spec:
      containers:
      - name: appv1
        image: gcr.io/google-samples/hello-app:1.0

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: appv2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: v2
  template:
    metadata:
      labels:
        app: v2
    spec:
      containers:
      - name: appv2
        image: gcr.io/google-samples/hello-app:2.0

---
apiVersion: v1
kind: Service
metadata:
  name: appv1-service
  labels:
    app: v1
spec:
  ports:
    - port: 8080
      nodePort: 30005
  type: NodePort
  selector:
    app: v1

---
apiVersion: v1
kind: Service
metadata:
  name: appv2-service
  labels:
    app: v2
spec:
  ports:
    - port: 8080
      nodePort: 30006
  type: NodePort
  selector:
    app: v2

Хотя для публикации приложений наиболее безопасный и рекомендуемый тип сервиса – это ClusterIP, но конкретно для моего примера выбор типа сервиса для публикации приложений особого значения не имеет. Однако, для боевого развертывания тип сервиса NodePort строго противопоказан.

Создадим наши развертывания и публикации:

kubectl apply -f apps.yaml

Убедимся, что обе поды развернуты успешно:

kubectl get pods

roman@roman-virtual-machine:~$ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
appv1-7b4cbb6b79-fq4kx   1/1     Running   0          119s
appv2-58c66fd479-z4f5x   1/1     Running   0          119s
roman@roman-virtual-machine:~$ 

Так же проверим, что созданы сервисы, которые мы определили в файле apps.yaml:

kubectl get services

roman@roman-virtual-machine:~$ kubectl get services
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
appv1-service   NodePort    10.107.114.68   <none>        8080:30005/TCP   16m
appv2-service   NodePort    10.96.3.109     <none>        8080:30006/TCP   16m
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP          3h20m
roman@roman-virtual-machine:~$ 

А вот теперь мы можем добавить объект класса Ingress, который будет выполнять маршрутизацию. Я сохраню конфигурацию в файле ingress.yaml:

apiVersion: networking.k8s.io/v1   
kind: Ingress   
metadata:   
  name: appingress  
  annotations:   
    nginx.ingress.kubernetes.io/rewrite-target: /$1   
spec:   
  rules:   
    - host: itproblog.ru  
      http:   
        paths:   
          - path: /v1  
            pathType: Prefix   
            backend:   
              service:   
                name: appv1-service
                port:   
                  number: 8080
          - path: /v2
            pathType: Prefix   
            backend:   
              service:   
                name: appv2-service
                port:   
                  number: 8080

Создадим Ingress сервис:

kubectl apply -f ingress.yaml

Убедимся, что сервис создан:

kubectl get ingress

roman@roman-virtual-machine:~$ kubectl get ingress
NAME         CLASS   HOSTS          ADDRESS          PORTS   AGE
appingress   nginx   itproblog.ru   192.168.59.100   80      12m
roman@roman-virtual-machine:~$ 

Поскольку я будут проверять имя itproblog.ru, то предварительно мне необходимо в файл /etc/hosts таргетироватьэто имя на IP-адрес Ingress контроллера:

roman@roman-virtual-machine:~$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	roman-virtual-machine
192.168.59.100	itproblog.ru

Теперь настал момент выполнить проверку нашего Ingress контроллера. Мы будем отправлять запросы по следующим адресам:

http://itproblog.ru/v1
http://itproblog.ru/v2

Сначала отправим запрос для приложения версии v1:

curl http://itproblog.ru/v1

roman@roman-virtual-machine:~$ curl http://itproblog.ru/v1
Hello, world!
Version: 1.0.0
Hostname: appv1-7b6977746d-n854q
roman@roman-virtual-machine:~$ 

Маршрут отработал корректно. Теперь попробуем отправить запрос для приложения v2:

curl http://itproblog.ru/v2

roman@roman-virtual-machine:~$ curl http://itproblog.ru/v2
Hello, world!
Version: 2.0.0
Hostname: appv2-f67db8c8c-ttfkg
roman@roman-virtual-machine:~$ 

Как видно из листинга и скриншотов – оба маршрута отработали коррерктно и строго в соответствии с той логикой, которую я настроил.

Это был довольно простой и базовый пример использования Ingress контроллера. Надеюсь, информация будет вам полезна.