☸️ Как разрешить незащищенные реджестри в кластере OpenShift / OKD 4.x |

☸️ Как разрешить незащищенные реджестри в кластере OpenShift / OKD 4.x | Сертификаты
Содержание
  1. Certificate report
  2. Checking certificate expiration for openshift container platform – red hat customer portal
  3. For master interal api
  4. For master public api
  5. For wildcard router
  6. How do i configure custom certs using intermediate cert for api and router
  7. Json report
  8. Openshift – как заменить сертифицированный ca etcd в кластере openshift origin –
  9. Other example playbooks
  10. Test the certificates
  11. To define the wildcard router certificate
  12. What about the pods that already run with old certs in their secrets?
  13. А вот теперь это было действительно легко!
  14. Добавление узла в кластер
  15. Запуск на openshift (code ready containers)
  16. Кластеры
  17. Конфигурация dhcpd
  18. Конфигурация dns
  19. Масштабирование и удаление кластера openshift
  20. Подготовка окружающей инфраструктуры
  21. Получаем программу установки и ключи
  22. Проблемы с загрузкой rhcos
  23. Сборка на кук-е
  24. Удаление узла из кластера
  25. Устанавливаем кластер
  26. Установка кластера openshift
  27. Шаг 1 – запускаем свой кластер openshift
  28. Шаг 1 – собираем наш контейнерный образ
  29. Шаг 2 – выполняем сборку и развертывание приложения в кластере openshift
  30. Шаг 2 – отправляем наш контейнер в репозиторий контейнерных образов
  31. Шаг 3 – делаем expose сервиса для доступа извне
  32. Шаг 3 – запускаем kubernetes
  33. Шаг 4 – развертываем наш контейнерный образ
  34. Шаг 5 – открываем доступ к нашему сервису
  35. Шаг 6 – ставим балансировщик нагрузки
  36. Шаг 7 – настраиваем ingress
  37. Заключение

Certificate report

First of all you can create a certificate report from OpenShift cluster:

ansible-playbook -i /etc/ansible/hosts /usr/share/ansible/openshift-ansible/playbooks/certificate_expiry/easy-mode.yaml

This will create reports into /tmp.

Next you can verify from remote host that the certs verify correct using openssl s_client:

Checking certificate expiration for openshift container platform – red hat customer portal

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

For master interal api

Change master internal API port:

# openssl s_client -CAfile /etc/origin/master/master.server.crt -connect 127.0.0.1:8443|grep Verify
depth=1 CN = openshift-signer@1516734585
verify return:1
depth=0 CN = 172.30.0.1
verify return:1
    Verify return code: 0 (ok)

For master public api

Change master address and name, and verify port:

$ openssl s_client   -CAfile certs/ca.cert.pem  -connect master.148.251.233.173.nip.io:8443 -servername master.148.251.233.173.nip.io |grep Verify
depth=2 C = FI, ST = Uusimaa, L = Helsinki, O = ITSE, OU = HQ, CN = ITSE root CA, emailAddress = ikke@iki.fi
verify return:1
depth=1 C = FI, ST = Uusimaa, O = ITSE, OU = branch office, CN = ITSE intermediate CA, emailAddress = ikke@iki.fi
verify return:1
depth=0 C = FI, ST = Uusimaa, L = Helsinki, O = ITSE, OU = branch office, CN = master.148.251.233.173.nip.io, emailAddress = ikke@iki.fi
verify return:1
    Verify return code: 0 (ok)

For wildcard router

Change router address and name:

$ openssl s_client   -CAfile certs/ca.cert.pem  -connect master.148.251.233.173.nip.io:443 -servername apps.148.251.233.173.nip.io |grep Verify
depth=2 C = FI, ST = Uusimaa, L = Helsinki, O = ITSE, OU = HQ, CN = ITSE root CA, emailAddress = ikke@iki.fi
verify return:1
depth=1 C = FI, ST = Uusimaa, O = ITSE, OU = branch office, CN = ITSE intermediate CA, emailAddress = ikke@iki.fi
verify return:1
depth=0 C = FI, ST = Uusimaa, L = Helsinki, O = ITSE, OU = cloud, CN = *.apps.148.251.233.173.nip.io, emailAddress = ikke@iki.fi
verify return:1
    Verify return code: 0 (ok)

How do i configure custom certs using intermediate cert for api and router

The use case is for organisations who are buying intermediate certificate from their certificate authority. The intermediate certificate allows organisation to create themselves valid SSL certs for their web serving hosts, whatever SSL services they provide.

Note, for OpenShift you don’t need intermediate certificate, but can use just regular host certificate. That’s different use case.

Json report

There are two top-level keys in the saved JSON results: data and summary.

The data key is a hash where the keys are the names of each host examined and the values are the check results for the certificates identified on each respective host.


The summary key is a hash that summarizes the total number of certificates:

The summary from the JSON data can be easily checked for warnings or expirations using a variety of command-line tools. For example, using grep you can look for the word summary and print out the two lines after the match (-A2):

$ grep -A2 summary $HOME/cert-expiry-report.yyyymmddTHHMMSS.json
    "summary": {
        "warning": 16,
        "expired": 0

Openshift – как заменить сертифицированный ca etcd в кластере openshift origin –

Мы работаем с OpenShift Origin 1.4 (OSE 3.4), и срок действия сертификата CA для etcd истек в выходные. Похоже, кластер все еще функционирует. Тем не менее, я предполагаю, что это бомба замедленного действия. Что приводит меня к моему вопросу. Кто-нибудь знает безопасный способ обновления сертификатов?

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

https://docs.openshift.org/latest/install_config/redeploying_certificates.html

Я решил эту проблему вчера утром. Вот полное описание ситуации и того, что я сделал для ее разрешения на случай, если кто-то с такой же проблемой увидит это.

У нас работает кластер OpenShift origin 1.4, который изначально был установлен как 1.1 и был обновлен во всех версиях за последний год. В прошлую субботу истек срок действия сертификатов CA, Server и Peer для etcd. Это вызвало ряд ошибок в журналах нашего сервера, но кластер etcd и openshift продолжал работать. Однако, когда я вызвал ту же ситуацию в нашей среде разработки и перезапустил службы, узлы etcd отказались соединяться друг с другом, и кластер openshift не запустился.

Про сертификаты:  Сертификация пиротехники: сроки, цены

Если вы находитесь в такой же ситуации, НЕ перезапускайте etcd или ваши основные сервисы, если у вас нет плана игры для устранения проблемы и вы готовы к этому.

Документы OpenShift для повторного развертывания сертификатов гласят, что использование playbook redeploy-reports.yaml не создает никаких сертификатов CA. Я протестировал это в нашей среде разработки и подтвердил, что он не восстанавливает сертификат etcd CA. Ни один не делает playbook redeploy-etcd-Certificates.yaml. Это означает, что вы должны запустить playbook redeploy-openshift-ca.yml и затем playbook redeploy-certificate.yml, чтобы решить эту проблему. В итоге у вас будут все новые сертификаты для всего в кластере. Я был почти уверен, что это займет значительное количество времени и потенциально может привести к сбою, когда redeploy-openshift-ca попытается перезапустить etcd и увидит просроченные серверные и одноранговые сертификаты.

Чтобы устранить эту проблему, я нашел команду, использованную в playbook redeploy-openshift-ca.yaml, которая генерирует сертификат etcd CA и запускает его вручную. После этого я запустил playbook redeploy-etcd-reports.yaml.

cd /etc/etcd/ca/ 
export SAN=etcd-signer
openssl req -config openssl.cnf -newkey rsa:4096 -keyout ca.key 
    -new -out ca.crt -x509 -extensions etcd_v3_ca_self -batch 
    -nodes -days 1825 -subj /CN=etcd-signer@`date  %s`
ansible-playbook -i hosts_file -vv  
    /usr/share/ansible/openshift-ansible/playbooks/byo/openshift-cluster/redeploy-etcd-certificates.yml

При попытке перезапустить первый узел etcd не удалось перезапустить плейбук redeploy-etcd-сертификаты, так как два других узла все еще работали с просроченными сертификатами. Чтобы решить эту проблему, я вручную перезапустил сервисы для всех трех узлов etcd, и все прошло правильно. Затем я перезапустил playbook redeploy-etcd-сертификаты для хорошей меры. Он завершился правильно во второй раз, и наша среда снова счастлива.

@aleks спасибо за помощь.

Other example playbooks

To run any of these example playbooks:

$ cd /usr/share/ansible/openshift-ansible
$ ansible-playbook -v -i <inventory_file> 
    playbooks/openshift-checks/certificate_expiry/<playbook>

Test the certificates

Here are few ways you can verify the certs.

To define the wildcard router certificate

The wild card router is defined the following way in ansible inventory:

What about the pods that already run with old certs in their secrets?

After this change you might have some existing services running in pods, that need their certificate refreshened. At this point of time there is no automation for that. For example I run into kubernetes service-catalog having failure with certs (503 SSL error in logs). In such case here is an example how to fix it:

cat /etc/origin/service-catalog/ca.crt | base64
oc edit apiservice/v1beta1.servicecatalog.k8s.io

update ca_bundle field with the base64 encoded content from the first command.

А вот теперь это было действительно легко!

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

И здесь в игру вступает OpenShift, который идет в ногу со временем и предлагает Kubernetes, ориентированный в первую очередь на разработчика. Была вложена масса усилий, чтобы заточить платформу OpenShift именно под разработчика, включая создание таких инструментов, как S2I, ODI, Developer Portal, OpenShift Operator Framework, интеграция с IDE, Developer Catalogues, интеграция с Helm, мониторинг и многие другие.

Надеемся, что эта статься была для вас интересной и полезной. А найти дополнительные ресурсы, материалы и другие полезные для разработки на платформе OpenShift вещи можно на портале Red Hat Developers.

Добавление узла в кластер

[ocp@shift-is01 ~]$ ./bin/oc scale --replicas=4 machineset ocp45-64clc-worker -n openshift-machine-api
machineset.machine.openshift.io/ocp45-64clc-worker scaled

[ocp@shift-is01 ~]$ ./bin/oc get machinesets -n openshift-machine-api

NAME                 DESIRED   CURRENT   READY   AVAILABLE   AGE
ocp45-64clc-worker   4         4         3       3           61m

[ocp@shift-is01 ~]$ ./bin/oc get nodes

NAME                       STATUS   ROLES    AGE     VERSION
ocp45-64clc-master-0       Ready    master   75m     v1.18.3 6025c28
ocp45-64clc-master-1       Ready    master   75m     v1.18.3 6025c28
ocp45-64clc-master-2       Ready    master   75m     v1.18.3 6025c28
ocp45-64clc-worker-f7bw2   Ready    worker   57m     v1.18.3 6025c28
ocp45-64clc-worker-hvjmn   Ready    worker   9m27s   v1.18.3 6025c28
ocp45-64clc-worker-m277w   Ready    worker   57m     v1.18.3 6025c28
ocp45-64clc-worker-wcjj7   Ready    worker   57m     v1.18.3 6025c28

Запуск на openshift (code ready containers)

А теперь посмотрим, как это все делается на Red Hat OpenShift Container Platform (OCP).

Как в случае с minikube, мы выбираем схему с одноузловым кластером OpenShift в форме Code Ready Containers (CRC). Раньше это называлось minishift и базировалось на проекте OpenShift Origin, а теперь это CRC и построено на Red Hat’овской OpenShift Container Platform.

Здесь мы, извините, не можем сдержаться и не сказать: «OpenShift прекрасен!»

Изначально мы думали написать, что разработка на OpenShift ничем не отличается от разработки на Kubernetes. И по сути так оно и есть. Но в процессе написания этого поста мы вспомнили, сколько лишних движений приходится совершать, когда у вас нет OpenShift, и поэтому он, повторимся, прекрасен.

Давайте пробежимся по процессу и посмотрим, что нам потребуется сделать.

Итак, в примере с minikube мы начинали с Docker… Стоп, нам больше не надо, чтобы на машине был установлен Docker.

И локальный git нам не нужен.И Maven не нужен.И не надо руками создавать контейнерный образ.И не надо искать какой-нибудь репозиторий контейнерных образов.И не надо устанавливать ingress-контроллер.И конфигурировать ingress тоже не надо.

Вы поняли, да? Чтобы развернуть и запустить наше приложение на OpenShift, не нужно ничего из вышеперечисленного. А сам процесс выглядит следующим образом.

Кластеры

Итак, для нашего «Hello World» нужны кластеры. Сразу скажем «нет» всяким публичным облакам, чтобы не платить за сервера, реестры, сети, передачу данных и т.д. Соответственно, мы выбираем простой одноузловой кластер на

Про сертификаты:  Сертификат качества изготовителя производителя - ООО «Астелс»

(для КУК) и

(для кластера OpenShift). Оба этих варианта реально просты в установке, но потребуют довольно много ресурсов на вашем ноуте.

Конфигурация dhcpd


Здесь ничего специфичного, выделяем пул адресов (192.168.111.100 -192.168.111.150) под серверы OpenShift:

[ocp@shift-is01 ~]$ sudo cat /etc/dhcp/dhcpd.conf 
authoritative;
ddns-update-style interim;
default-lease-time 14400;
max-lease-time 14400;

        option routers                  192.168.111.1;
        option broadcast-address        192.168.111.255;
        option subnet-mask              255.255.255.0;
        option domain-name-servers      192.168.111.10;
        option domain-name              «ocp45.demo.local»;
        subnet 192.168.111.0 netmask 255.255.255.0 {
        interface ens192;
        pool {
                range 192.168.111.100 192.168.111.150;
                  # this is PXE specific
                filename «pxelinux.0»;
                next-server 192.168.111.10;
        }
}

Конфигурация dns

Для нашего кластера создана зона ocp45.demo.local и созданы A и PTR записи для диапазона DHCP. Создаем требуемые OpenShift записи для API и Ingress:

Кусок из BIND zone ocp45.demo.local:

api             IN      A       192.168.111.190
*.apps          IN      A       192.168.111.191


После этого загружаем сертификаты с нашего vCenter и устанавливаем их как доверенные на наш сервер.

Устанавливаем сертификаты vCenter:

Масштабирование и удаление кластера openshift

Плюсы нового способа не только в том, что установка теперь проще и требует меньше усилий на подготовку. Кластер OpenShift, установленный в vSphere через IPI, воспринимает vShpere как полноценную Cloud Platform и может пользоваться ее преимуществами — «эластичностью».

Теперь у кластера на платформе vSphere (как у больших облачных платформ типа Amazon AWS или Google GCP) есть machineset, автоматически создаваемый программой установки:

OpenShift machineset 
[ocp@shift-is01 ~]$ ./bin/oc get machinesets -n openshift-machine-api
NAME                 DESIRED   CURRENT   READY   AVAILABLE   AGE
ocp45-64clc-worker   3         3         3       3           50m

Это позволяет свести масштабирование кластера к запуску одной команды. OpenShift самостоятельно создаст узел и введет его в кластер или удалит его.

Подготовка окружающей инфраструктуры

Совсем без подготовки инфраструктуры при установке OpenShift не обойтись, но список задач стал скромнее:

  1. Нужен DHCP сервер (для выдачи адресов узлам OpenShift);
  2. Потребуются две записи в DNS (VIP для кластерного API и VIP для Ingress трафика);
  3. Понадобится учетная запись в vSphere c набором привилегий, описанных в документации по установке OpenShift.

В нашем случае для установки OpenShift и запуска всех требуемых сервисов использовался сервер shift-is01 под управление CentOS 7.

Получаем программу установки и ключи


Загружаем программу инсталляции и PullSecret c RedHat, эта процедура описана в

. В нашем примере все необходимые для работы бинарные файлы расположены в директории bin домашней директории пользователя ocp.

[ocp@shift-is01 bin]$ ll
total 499036
-rwxr-xr-x 1 ocp ocp  78599208 Jul 16 11:53 kubectl
-rwxr-xr-x 1 ocp ocp  78599208 Jul 16 11:53 oc
-rwxr-xr-x 1 ocp ocp 353804288 Jul 16 11:53 openshift-install
-rw-r--r-- 1 ocp ocp       954 Jul 16 11:53 README.md

Проблемы с загрузкой rhcos

Если соединение с Internet небыстрое, то установка может не пройти: инсталлятор не дождется загрузки RHCOS image. Вы можете заранее загрузить RHCOS image по ссылке, которую показывает инсталлятор. Полученный файл надо положить в директорию ~/.cache/openshift-installer/image_cache c именем 5dad1f50634794b0e1ff8a830cad4b98 и перезапустить инсталляцию. На этот раз openshift-install возьмет его с файловой системы:

INFO The file was found in cache: /home/ocp/.cache/openshift-installer/image_cache/5dad1f50634794b0e1ff8a830cad4b98. Reusing…

Всё, кластер готов:

[ocp@shift-is01 ~]$ export KUBECONFIG=/home/ocp/ocp45/auth/kubeconfig
[ocp@shift-is01 ~]$ ./bin/oc get nodes

NAME                       STATUS   ROLES    AGE   VERSION
ocp45-64clc-master-0       Ready    master   33m   v1.18.3 6025c28
ocp45-64clc-master-1       Ready    master   33m   v1.18.3 6025c28
ocp45-64clc-master-2       Ready    master   33m   v1.18.3 6025c28
ocp45-64clc-worker-f7bw2   Ready    worker   15m   v1.18.3 6025c28
ocp45-64clc-worker-m277w   Ready    worker   15m   v1.18.3 6025c28
ocp45-64clc-worker-wcjj7   Ready    worker   15m   v1.18.3 6025c28

Сборка на кук-е

Итак, поехали.

Удаление узла из кластера

[ocp@shift-is01 ~]$ ./bin/oc scale --replicas=3 machineset ocp45-64clc-worker -n openshift-machine-api
machineset.machine.openshift.io/ocp45-64clc-worker scaled

[ocp@shift-is01 ~]$ ./bin/oc get nodes

NAME                       STATUS   ROLES    AGE   VERSION
ocp45-64clc-master-0       Ready    master   97m   v1.18.3 6025c28
ocp45-64clc-master-1       Ready    master   98m   v1.18.3 6025c28
ocp45-64clc-master-2       Ready    master   98m   v1.18.3 6025c28
ocp45-64clc-worker-hvjmn   Ready    worker   32m   v1.18.3 6025c28
ocp45-64clc-worker-m277w   Ready    worker   79m   v1.18.3 6025c28
ocp45-64clc-worker-wcjj7   Ready    worker   79m   v1.18.3 6025c28

Способность кластера самостоятельно создавать и удалять узлы можно использовать для настройки

В общем с vSphere IPI Installation все управление платформой оркестрации контейнерами OpenShift переходит на сторону kubernetes:

  1. созданием и удалением ресурсов для кластера управляет администратор OpenShift через machineset;
  2. конфигурацией настроек ОС на узлах кластера также управляет администратор OpenShift через macheneconfig.

Устанавливаем кластер

Сама процедура установки кластера принципиально не изменилась. После запуска программы инсталляции:

Процесс установки кластера.

Запускаем установку кластера и ждем. Обычно процесс установки занимает 30-40 минут:

Установка кластера openshift


Сама процедура установки теперь максимально упрощена:

  1. получаем программу установки и ключи (Pull Secret) с сайта Red Hat;
  2. готовим yaml файл с install-config.yaml с планируемой конфигурацией кластера;
  3. устанавливаем кластер.

Шаг 1 – запускаем свой кластер openshift

Мы используем Code Ready Containers от Red Hat, который по сути есть тот же Minikube, но только с полноценным одноузловым кластером Openshift.

crc start

Шаг 1 – собираем наш контейнерный образ

Начнем я с того, что развернем наш «Hello World» на minikube. Для этого потребуется:

Шаг 2 – выполняем сборку и развертывание приложения в кластере openshift


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

OpenShift всегда строился как платформа для создания и запуска контейнерных приложений. Сборка контейнеров всегда была неотъемлемой частью этой платформы, поэтому здесь есть куча дополнительных Kubernetes-ресурсов для соответствующих задач.

Мы будем использовать OpenShift’овский процесс Source 2 Image (S2I), у которого есть несколько различных способов для того, чтобы взять наш исходник (код или двоичные файлы) и превратить его в контейнерный образ, запускаемый в кластере OpenShift.

Про сертификаты:  СП 12.13130.2009 Определение категорий помещений, зданий и наружных установок по взрывопожарной и пожарной опасности (с Изменением N 1) от 25 марта 2009 -

Для этого нам понадобятся две вещи:

Существует множество таких образов, сопровождаемых как силами Red Hat, так и на уровне сообщества, и мы воспользуемся образом OpenJDK, ну поскольку я же собираю Java-приложение.

Запустить S2I-сборку можно, как и из графической консоли OpenShift Developer, так и из командной строки. Мы воспользуемся командой new-app, указав ей, где брать builder-образ и наш исходный код.

Шаг 2 – отправляем наш контейнер в репозиторий контейнерных образов

Пока что созданный нами образ хранится локально, в нашем локальном контейнерном хранилище. Если мы хотим использовать этот образ в своей среде КУК, то его надо положить в какой-то другой репозиторий. В Kubernetes нет таких функций, поэтому мы будем использовать dockerhub. Потому что, во-первых, он бесплатный, а во-вторых, (почти) все так делают.

Это тоже очень просто, и нужен здесь только аккаунт на dockerhub.

Итак, ставим dockerhub и отправляем туда наш образ.

Шаг 3 – делаем expose сервиса для доступа извне

Как и в случае КУК, на платформе OpenShift нашему «Hello World» тоже нужен роутер, чтобы направлять внешний трафик на сервис внутри кластера. В OpenShift это делает очень просто. Во-первых, в кластере по умолчанию установлен компонент маршрутизации HAProxy (его можно поменять на тот же NGINX).

Во-вторых, здесь есть специальные и допускающие широкие возможности настройки ресурсы, которые называются Routes и напоминают Ingress-объекты в старом добром Kubernetes (на самом деле OpenShift’овкие Routes сильно повлияли на дизайн Ingress-объектов, которые теперь можно использовать и в OpenShift), но для нашего «Hello World», да и почти во всех остальных случаях, нам хватит стандартного Route без дополнительной настройки.

Чтобы создать для «Hello World» маршрутизируемый FQDN (да, в OpenShiift есть свой DNS для маршрутизации по именам сервисов), мы просто выполним expose для нашего сервиса:

oc expose service quarkus-hello-world

Если посмотреть только что созданный Route, то там можно найти FQDN и другие сведения по маршрутизации:

oc get route

И наконец, обращаемся к нашему сервису из браузера:

Шаг 3 – запускаем kubernetes

Есть много способов собрать конфигурацию kubernetes для запуска нашего «Hello World», но мы будем использовать наипростейший из них, уж такие мы люди…

Для начала запускаем кластер minikube:

minikube start

Шаг 4 – развертываем наш контейнерный образ

Теперь надо преобразовать наш код и контейнерный образ в конфигурации kubernetes. Иначе говоря, нам нужен pod и deployment definition с указанием на наш контейнерный образ на dockerhub. Один из самых простых способов это сделать – запустить команду create deployment, указав на наш образ:

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

Этой командной мы сказали нашей КУК создать deployment configuration, которая должна содержать спецификацию pod’а для нашего контейнерного образа. Эта команда также применит эту конфигурацию к нашему кластеру minikube, и создаст deployment, который скачает наш контейнерный образ и запустит pod в кластере.

Шаг 5 – открываем доступ к нашему сервису


Теперь, когда у нас есть развернутый контейнерный образ, пора подумать, как сконфигурировать внешний доступ к этому Restful-сервису, который, собственно, и запрограммирован в нашем коде.

Тут есть много способов. Например, можно использовать команду expose, чтобы автоматически создавать соответствующие Kubernetes-компоненты, такие как services и endpoints. Собственно, так мы и сделаем, выполнив команду expose для нашего deployment-объекта:

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

Давайте на минутку остановимся на опции « — type» команды expose.

Когда мы делаем expose и создаем компоненты, необходимые для запуска нашего сервиса, нам, среди прочего, надо, чтобы снаружи можно было подключиться к службе hello-quarkus, которая сидит внутри нашей программно-определяемой сети. И параметр type позволяет нам создать и подключить такие вещи, как балансировщики нагрузки, чтобы маршрутизировать трафик в эту сеть.

Например, прописав type=LoadBalancer, мы автоматически инициализируем балансировщик нагрузки в публичном облаке, чтобы подключаться к нашему кластеру Kubernetes. Это, конечно, замечательно, но надо понимать, что такая конфигурация будет жестко привязана к конкретному публичному облаку и ее будет сложнее переносить между Kubernetes-инстансам в разных средах.

В нашем примере type=NodePort, то есть обращение к нашему сервису идет по IP-адресу узла и номеру порта. Такой вариант позволяет не использовать никакие публичные облака, но требует ряд дополнительных шагов. Во-первых, нужен свой балансировщик нагрузки, поэтому мы развернем в своем кластере балансирощик нагрузки NGINX.

Шаг 6 – ставим балансировщик нагрузки

У minikube есть ряд платформенных функций, облегчающих создание необходимых для доступа извне компонентов, вроде ingress-контроллеров. Minikube идет в комплекте с ingress-контроллером Nginx, и нам остается только включить его и настроить.

minikube addons enable ingress

Теперь мы всего одной командой создам ingress-контроллер Nginx, который будет работать внутри нашего кластера minikube:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

Шаг 7 – настраиваем ingress


Теперь нам надо настроить ingress-контроллер Nginx, чтобы он воспринимал запросы hello-quarkus.

И, наконец, нам надо применить эту конфигурацию.

kubectl apply -f ingress.yml

Заключение

Установка OpenShift на платформе VMware vSphere — это самый распространенный вариант инсталляции. И умение OpenShift работать с vSphere как с облачной платформой, появившееся в релизе 4.5.1, значительно упрощает его администрирование, предоставляя готовое решение по автоматизации процессов жизненного цикла от создания платформы, ее масштабирования и удаления.

Теперь подход Infrastructure as Code для обслуживания on-premise решений на базе Red Hat OpenShift и VMware vSphere становится гораздо более доступным для воплощения в жизнь.

Оцените статью
Мой сертификат
Добавить комментарий