Как настроить входной контроллер NGINX на PMKFT

  • 26 марта, 17:07
  • 615
  • 0

Большинство кластеров Kubernetes используются для размещения контейнеров, которые обрабатывают входящие запросы от микросервисов к полноценным веб-приложениям. Передача этих входящих запросов в центральное местоположение, а затем их распространение через службы в Kubernetes - наиболее безопасный способ настройки кластера. Эта центральная точка входа является входным контроллером.

Наиболее распространенным продуктом, используемым в качестве входного контроллера для частных кластеров Kubernetes, является NGINX. NGINX обладает большинством функций, которые ищут предприятия, и будет работать как входной контроллер для Kubernetes независимо от того, на какой облачной платформе, платформе виртуализации или операционной системе Linux работает Kubernetes.

Первые шаги

Первый шаг, необходимый для использования NGINX в качестве контроллера Ingress в управляемом Platform9 кластере Kubernetes, - это наличие работающего кластера Kubernetes.

Как настроить входной контроллер NGINX на PMKFTКак настроить входной контроллер NGINX на PMKFT

В этом случае кластер, который мы будем использовать, называется «входной тест», и он указан как исправный. Это кластер с одним узлом, работающий на сервере Ubuntu 16.04.

% ssh root@64.227.56.189
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-173-generic x86_64)
root@pmkft:~# kubectl get nodes
NAME            STATUS   ROLES    AGE   VERSION
64.227.56.189   Ready    master   10h   v1.14.8
root@pmkft:~# kubectl get namespaces
NAME              STATUS   AGE
default           Active   11h
kube-node-lease   Active   11h
kube-public       Active   11h
kube-system       Active   11h

Выполнение «kubectl get node» и «kubectl get namespaces» подтверждает, что аутентификация работает, узлы кластера готовы, и нет настроенных контроллеров NGINX Ingress.

Обязательные компоненты для входного контроллера NGINX

Входной контроллер, поскольку он является ключевым компонентом Kubernetes, требует настройки для большего количества движущихся частей кластера, чем просто развертывание модуля и маршрута.

В случае NGINX его рекомендуемая конфигурация имеет три ConfigMaps:

  • Базовая конфигурация
  • DeploymentTCP 
  • Настройка UDP

Учетная запись службы для запуска находится в кластере, и этой учетной записи службы будет назначена пара ролей.

  • Роль кластера назначается учетной записи службы, что позволяет ей получать, перечислять и считывать конфигурацию всех служб и событий. Это может быть ограничено, если у вас будет несколько входных контроллеров. Но в большинстве случаев это излишне.
  • Специфическая роль пространства имен назначается учетной записи службы для чтения и обновления всех ConfigMaps и других элементов, относящихся к собственной конфигурации контроллера NGINX Ingress.

Последняя часть - это фактическое развертывание модуля в его собственном пространстве имен, позволяющее легко рисовать границы вокруг него для квот безопасности и ресурсов.

Развертывание указывает, на какие ConfigMaps будут ссылаться, образ контейнера и командная строка, которые будут использоваться, и любую другую конкретную информацию о том, как запустить настоящий контроллер NGINX Ingress.

NGINX имеет единственный файл, который они поддерживают в GitHub, связанный с  документацией Kubernetes, в котором вся эта конфигурация прописана в YAML и готова к развертыванию.

Чтобы применить эту конфигурацию, выполните команду:

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.28.0/deploy/static/mandatory.yaml

Которая будет генерировать следующий вывод:

namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.apps/nginx-ingress-controller created
limitrange/ingress-nginx created

Экспонирование входного контроллера NGINX

После того, как базовая конфигурация установлена, следующим шагом является предоставление контроллера входа NGINX внешнему миру, чтобы он мог начать получать соединения. Это может быть через балансировщик нагрузки, как в AWS, GCP или Azure. 

Другой вариант при развертывании в собственной инфраструктуре или у облачного провайдера с меньшими возможностями - создать службу с NodePort, чтобы разрешить доступ к Ingress Controller.

Используя предоставленный NGINX файл service-nodeport.yaml, который находится в GitHub, определите службу, работающую на портах 80 и 443. Его можно применить с помощью одной командной строки, как это делалось ранее.

root@pmkft:~# kubectl apply -fhttps://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.28.0/deploy/static/provider/baremetal/service-nodeport.yaml
service/ingress-nginx created

Проверьте NGINX Ingress Controller

Последний шаг - убедиться, что контроллер Ingress запущен.

root@pmkft:~# kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx
NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx   nginx-ingress-controller-6c7686c6b4-stnq7   1/1     Running   0          6m36s
root@pmkft:~# kubectl get services ingress-nginx --namespace=ingress-nginx
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.21.83.193   <none>        80:30757/TCP,443:31353/TCP   34m

Платформа 9 поддерживает helm3 и доступна всем, кто хочет развернуть ее с помощью этого метода, которым зачастую гораздо проще управлять.

Чтобы установить  контроллер NGINX Ingress  с помощью Helm, используйте схему stable / nginx-ingress, которая доступна в официальном репозитории. Если в кластере kubernetes включен RBAC, выполните: 

helm install stable / nginx-ingress --name ingress-nginx --set rbac.create = true

Предоставление сервисов с использованием NGINX Ingress Controller

Теперь, когда входной контроллер работает в кластере, вам нужно будет создать службы, которые используют его, используя хост, сопоставление URI или даже оба.

Пример отображения службы на основе хоста через входной контроллер с использованием типа «Ingress»:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    kubernetes.io/ingress.class: ingress-nginx
spec:
  rules:
  - host: host1.domain.ext
    http:
      paths:
      - backend:
          serviceName: hello-world
          servicePort: 80

Использование URI включает в себя ту же базовую компоновку, но с указанием более подробной информации в разделе «paths» файла yaml. Когда требуется шифрование TLS, вам необходимо хранить сертификаты внутри Kubernetes. 

Это можно сделать вручную или с помощью инструмента с открытым исходным кодом, такого как cert-manager. Файл yaml нуждается в небольшой дополнительной информации для включения TLS (сопоставление с порта 443 на порт 80 выполняется во входном контроллере):

Следующие шаги

Благодаря полнофункциональному кластерному и входному контроллеру, даже одному узлу, вы готовы приступить к созданию и тестированию приложений точно так же, как и в производственной среде, с такой же способностью тестировать файлы конфигурации и маршрутизацию трафика приложений. У вас просто есть некоторые ограничения пропускной способности, которые не будут иметь место на истинных многоузловых кластерах.

Источник перевода


0 комментариев
Сортировка:
Добавить комментарий