Большинство кластеров Kubernetes используются для размещения контейнеров, которые обрабатывают входящие запросы от микросервисов к полноценным веб-приложениям. Передача этих входящих запросов в центральное местоположение, а затем их распространение через службы в Kubernetes - наиболее безопасный способ настройки кластера. Эта центральная точка входа является входным контроллером.
Наиболее распространенным продуктом, используемым в качестве входного контроллера для частных кластеров Kubernetes, является NGINX. NGINX обладает большинством функций, которые ищут предприятия, и будет работать как входной контроллер для Kubernetes независимо от того, на какой облачной платформе, платформе виртуализации или операционной системе Linux работает Kubernetes.
Первые шаги
Первый шаг, необходимый для использования NGINX в качестве контроллера Ingress в управляемом Platform9 кластере Kubernetes, - это наличие работающего кластера Kubernetes.
В этом случае кластер, который мы будем использовать, называется «входной тест», и он указан как исправный. Это кластер с одним узлом, работающий на сервере 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 -f
https://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 комментариев
Добавить комментарий