Балансировка нагрузки с pacemaker и ipaddr (active/active cluster)

Настройка высокой доступности vCenter

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

После создания сети, щелкните ПКМ по серверу vCenter Server в разделе навигации клиента vSphere Web Client. В меню выберите vCenter HA Settings.

В меню vCenter HA нажмите на кнопку Configure в правом верхнем углу.

Есть два варианта настройка HA.

• Basic – автоматическое клонирование сервера и настройка всех трех узлов
• Advanced – настраиваемый вариант развёртывания, клонирование сервера и настройка узлов кластера выполняется в ручном режиме.

Мы остановился на самом простом — автоматическом варианте Basic.

Укажем IP адрес и подсеть для HA интерфейса на активной ноде. В качестве сети нужно выбрать созданную ранее выделенную сеть HA.

Укажите IP адрес пассивной (Passive) ноды и свидетеля (Witness).

Проверьте предложенный вариант развертывания. Внесите необходимые изменения, выбрав хост, кластер и VMFS хранилище.

Если все ОК, нажмите кнопку Finish для начала развертывания.

Запустите процесс клонирования и автоматической настройки трех узлов. Процесс выполнения развертывания можно отслеживать в разделе Recent Tasks.

После завершения развертывания в иерархии vCenter появятся два новых узла. Как вы видите, для пассивной копии vCenter добавлена постфикс –peer , а для свидетеля –witness.

Программные средства

Операционная система Solaris предоставляет программное обеспечение Solaris Cluster, которое служит для обеспечения высокой доступности и безотказности серверов, работающих под управлением Solaris. Для OpenSolaris существует реализация с открытым кодом под названием OpenSolaris HA Cluster.

Среди пользователей GNU/Linux популярны несколько программ:

• distcc, MPICH и др. — специализированные средства для распараллеливания работы программ. distcc допускает параллельную компиляцию в GNU Compiler Collection.
• Linux Virtual Server, Linux-HA — узловое ПО для распределения запросов между вычислительными серверами.
• MOSIX, openMosix, Kerrighed, OpenSSI — полнофункциональные кластерные среды, встроенные в ядро, автоматически распределяющие задачи между однородными узлами. OpenSSI, openMosix и Kerrighed создают среду единой операционной системы между узлами.

Кластерные механизмы планируется встроить и в ядро DragonFly BSD, ответвившуюся в 2003 году от FreeBSD 4.8. В дальних планах также превращение её в среду единой операционной системы.

Компанией Microsoft выпускается HA-кластер для операционной системы Windows. Существует мнение, что он создан на основе технологии Digital Equipment Corporation, поддерживает до 16 (с 2010 года) узлов в кластере, а также работу в сети SAN (Storage Area Network). Набор API-интерфейсов служит для поддержки распределяемых приложений, есть заготовки для работы с программами, не предусматривающими работы в кластере.

Windows Compute Cluster Server 2003 (CCS), выпущенный в июне 2006 года разработан для высокотехнологичных приложений, которые требуют кластерных вычислений. Издание разработано для развертывания на множестве компьютеров, которые собираются в кластер для достижения мощностей суперкомпьютера. Каждый кластер на Windows Compute Cluster Server состоит из одного или нескольких управляющих машин, распределяющих задания и нескольких подчиненных машин, выполняющих основную работу. В ноябре 2008 года представлен Windows HPC Server 2008, призванный заменить Windows Compute Cluster Server 2003.

Novell Open Enterprise Server (OES) — сетевая операционная система, «» Novell NetWare и SUSE Linux Enterprise Server; кроме прочего способная создавать смешанные кластеры, в которых ресурсы при сбое могут перемещаться с сервера NetWare на сервер Linux и наоборот.

Вступление:

Для кого предназначены данные статьи? В первую очередь, для тех, кто только начинает свой путь в изучении Kubernetes. Также данный цикл будет полезен для инженеров, которые думают переходить от монолита к микросервисам. Все описанное — это мой опыт, в том числе полученный и при переводе нескольких проектов из монолита в Kubernetes. Возможно, что какие-то части публикаций будут интересны и опытным инженерам.

Что я не буду подробно рассматривать в данной серии публикаций:

• подробно объяснять, что такое примитивы kubernetes, такие как: pod, deployment, service, ingress и тд.
• CNI (Container Networking Interface) я рассмотрю очень поверхностно, мы используем callico поэтому другие решения, я только перечислю.
• процесс сборки docker образов.
• процессы CI\CD. (Возможно отдельной публикацией, но после всего цикла)
• helm; про него написано уже достаточно много, я затрону лишь процесс его инсталляции в кластер и настройку клиента.

Что я хочу рассмотреть подробно:

• пошаговый процесс развертывания кластера Kubernetes. Я буду использовать kubeadm. Но при этом я подробно шаг за шагом рассмотрю процесс инсталляции кластера на голое железо, различные виды инсталляции ETCD, составление конфигфайлов для kube admina. Постараюсь разъяснить все варианты балансировки для Ingress контроллера и отличие в разнообразных схемах доступа worknodes до api сервера.
  Я знаю, что сегодня для развертывания kubernetes есть много прекрасных инструментов, например, kubespray или тот же rancher. Возможно, кому-то будет более удобно использовать их. Но, я думаю, найдется немало инженеров которые захотят рассмотреть вопрос более детально.
• терминологию CEPH и пошаговую инсталляцию кластера CEPH, а также пошаговую инструкцию подключение хранилища ceph к созданному Kubernetes кластеру.
• local-storages, подключение к кластеру kubernetes, а также отличия от подключений типа hostpath и тд.
• kubernetes операторы и развертывание Percona XtraDB Cluster с помощью оператора, а также постараюсь рассказать про плюсы и минусы такого решения после полугодового опыта использования в продакшене. А также немного поделюсь планами по доработке оператора от percona.

Архитектура высокой доступности сервера VMWare vCenter 6.5

Архитектура отказоустойчивого VCHA состоит из 3 узлов: активного, пассивного экземпляра vCenter Server Appliance и хоста-свидетеля. Активный экземпляр vCenter Appliance имеет два сетевых интерфейса: стандартный интерфейс управления (eth0) и специальный интерфейс HA (eth1). VCHA реплицирует данные с активной ноды на пассивную по HA сети. База данных активной копии vCenter реплицируется в синхронном режиме, а файловая система – в асинхронном. У пассивной копии также 2 сетевых интерфейса, однако основной его интерфейс eth0 с теми же FQDN, IP и MAC неактивен. Интерфейс активируется в случае сбоя основного экземпляра сервера vCenter. Свидетель является последним элементом архитектуры VCHA. Он используется для предоставления ресурса-кворума, информируя кластер о том, какой из узлов является активным в текущий момент времени. В нормальном режиме работы все три компонента кластера должны быть доступны.

При сбое, на пассивной ноде активируется интерфейса eth0. С помощью механизма Gratuitous ARP выполняется оповещение устройств в широковещательном домене о появлении новой привязки IP и MAC. Если оригинальная нода после сбоя опять появляется в сети, она снова становится активной и репликация восстанавливается. В том случае, если он полностью утрачена, ее можно удалить из конфигурации и пересоздать кластер VCHA.

Что потребуется для организации высокодоступного сервера vCenter

• vCenter Server Appliance версии 6.5
  • Лицензия vCenter Standard
  • Размер развертывания vCSA: Small, Medium или Large (но не tiny)
  • Встроенный или внешний Platform Services Controller (PSC)
• ESXi 5.5 и выше
• Сеть vCenter HA
  • Отдельная HA сеть, отделенная от сети управления
  • Сетевая задержка между двумя узлами не более 10мс
  • Статические IP адреса на нодах

Устанавливаем haproxy на worknodes

Теперь мы имеем рабочий кластер с тремя master нодами и тремя worker нодами.
Проблема в том, что сейчас наши worker ноды не имеют HA режима.
Если посмотреть на конфиг файл kubelet, то мы увидим, что наши worker ноды обращаются только к одной master ноде из трех.

После того, как HAproxy, установлен нам нужно создать для него конфиг.
Если на worker нодах нет каталога с конфиг файлами, то клонируем его

И запускаем скрипт конфига с флагом haproxy

Скрипт сконфигурирует и перезапустит haproxy.
Проверим, что haproxy стал слушать порт 6443.

Теперь нам нужно сказать kubelet, чтобы он обращался на localhost вместо master ноды. Для этого нужно отредактировать значение server в файлах /etc/kubernetes/kubelet.conf и /etc/kubernetes/bootstrap-kubelet.conf на всех worker нодах.

Значение server должно принять вот такой вид:

После внесения изменений нужно перезапустить службы kubelet и docker

Проверим, что все ноды работают исправно

Пока что у нас нет приложений в кластере, чтобы проверить работу HA. Но мы можем остановить работу kubelet на первой master ноде и убедится, что наш кластер остался дееспособным.

Проверяем со второй master ноды

Все ноды функционируют нормально, кроме той, на которой мы остановили службы.
Не забываем включить обратно службы kubernetes на первой master ноде

System requirements

If you run HA, only high end server hardware with no single point of failure should be used. This includes redundant disks (Hardware Raid), redundant power supply, UPS systems, network bonding.

• Fencing device(s) — reliable and TESTED! NOTE: this is NEEDED, there isn’t software fencing.
• Fully configured Proxmox_VE_2.0_Cluster (version 2.0 and later), with at least 3 nodes (maximum supported configuration: currently 16 nodes per cluster). Note that, with certain limitations, 2-node configuration is also possible (Two-Node High Availability Cluster).
• Shared storage (SAN or NAS/NFS for Virtual Disk Image Store for HA KVM)
• Reliable, redundant network, suitable configured
• A extra network for Cluster communication, one network for VM traffic and one network for Storage traffic.
• NFS for Containers

Добавляем worker ноды в кластер

На данный момент у нас работает кластер, в котором запущены три master ноды. Но master ноды — это машины, на которых работает api, scheduler и прочие сервисы кластера kubernetes. Для того, чтобы мы могли запускать свои поды, нам нужны так называемые worker ноды.
Если Вы ограничены в ресурсах, то можно запускать поды и на master нодах.Но я лично не советую так делать.

Устанавливаем на worker ноды kubelet, kubeadm, kubectl и докер как на master нодах

Теперь пора время вернуться к той строчке, которую нам сгенерировал kubeadm при установке мастер ноды.
У меня она выглядит так.

Нужно выполнить данную команду на каждой worker ноде.
Если Вы не записали токен, то можно сгенерировать новый

После того, как kubeadm отработает, Ваша новая нода введена в кластер и готова для работы

Теперь посмотрим на результат

IT-кластер в мире и России

В последнее время очень часто встречается такой термин, как IT-кластер. В самом обобщенном смысле под ним понимаются однородные элементы с общими однородными элементами, которые объединены в самостоятельную единицу. Чтобы кластер был успешным, в нем должны сочетаться все те элементы, которые будут способствовать росту и развитию IT-проектов. Если говорить о мировых моделях, то успешным кластером в сфере IT считается Кремниевая долина. Хотя зарождение технопарка было как минимум случайным, так как инициатива о его создании пошла от студентов, инженеров и преподавателей Стэнфорда.

IT-кластер быстро стал популярным среди компаний, которым не важна жесткая привязка к офису. Свободная обстановка и развитая инфраструктура стали привлекающими факторами для компаний, разрабатывающих технологические проекты. И они стали перебираться в технопарки. Условия оценили по достоинству и представители бизнеса, которые стали арендовать в технопарках офисы и лаборатории. Тем самым начала формироваться питательная среда, в которой происходит обмен идей, использование мощностей других компанией, заключаются договоры и прорабатываются бизнес-стратегии.

Несколько иной подход к формированию IT-кластера выбрали в Китае. Кластер Чжунгуаньцунь образовался за счет административных возможностей страны на базе научного городка. Но в Китае сумели эффективно использовать государственные возможности, своевременно реагируя на нужды рынка. Благодаря этому в китайской «кремниевой долине» работают около 8000 компаний, причем половина из них в сфере высоких технологий.

В России тоже появляются собственные кластеры, правда, они прижились в нашей стране под названием «технопарки». Но идея обеих территорий состоит в создании питательной среды, в которой могли бы развиваться высокотехнологичные проекты, а компании – коммерциализировать свои разработки.

История

История создания кластеров неразрывно связана с ранними разработками в области компьютерных сетей. Одной из причин для появления скоростной связи между компьютерами стали надежды на объединение вычислительных ресурсов. В начале 1970-х годов группой разработчиков протокола TCP/IP и лабораторией Xerox PARC были закреплены стандарты сетевого взаимодействия. Появилась и операционная система Hydra для компьютеров PDP-11 производства DEC, созданный на этой основе кластер был назван C.mpp (Питтсбург, штат Пенсильвания, США, 1971 год). Тем не менее, только около 1983 года были созданы механизмы, позволяющие с лёгкостью пользоваться распределением задач и файлов через сеть, по большей части это были разработки в SunOS (операционной системе на основе BSD от компании Sun Microsystems).

Первым коммерческим проектом кластера стал ARCNet, созданный компанией Datapoint в 1977 году. Прибыльным он не стал, и поэтому строительство кластеров не развивалось до 1984 года, когда DEC построила свой VAXcluster на основе операционной системы VAX/VMS. ARCNet и VAXcluster были рассчитаны не только на совместные вычисления, но и совместное использование файловой системы и периферии с учётом сохранения целостности и однозначности данных. VAXCluster (называемый теперь VMSCluster) — является неотъемлемой компонентой операционной системы HP OpenVMS, использующих процессоры DEC Alpha и Itanium.

Два других ранних кластерных продукта, получивших признание, включают Tandem Hymalaya (1994, класс HA) и IBM S/390 Parallel Sysplex (1994).

История создания кластеров из обыкновенных персональных компьютеров во многом обязана проекту Parallel Virtual Machine. В 1989 году это программное обеспечение для объединения компьютеров в виртуальный суперкомпьютер открыло возможность мгновенного создания кластеров. В результате суммарная производительность всех созданных тогда дешёвых кластеров обогнала по производительности сумму мощностей «серьёзных» коммерческих систем.

Создание кластеров на основе дешёвых персональных компьютеров, объединённых сетью передачи данных, продолжилось в 1993 году силами Американского аэрокосмического агентства NASA, затем в 1995 году получили развитие кластеры Beowulf, специально разработанные на основе этого принципа. Успехи таких систем подтолкнули развитие grid-сетей, которые существовали ещё с момента создания UNIX.

Схема HA кластера kubernetes

Примерная схема HA кластера. Художник из меня так себе, если честно, но постараюсь объяснить в двух словах и достаточно упрощенно, особо не углубляясь в теорию.
Итак, наш кластер будет состоять из трех master нод и трех worker нод. На каждой master ноде kubernetes у нас будет работать etcd (на схеме зеленые стрелочки) и служебные части kubernetes; назовем их обобщенно — kubeapi.
Через кластер etcd master ноды обмениваются состоянием кластера kubernetes. Эти же адреса я укажу как точки входа ingress контроллера для внешнего трафика (на схеме красные стрелочки)
На worker нодах у нас работает kubelet, который связывается с api сервером kubernetes через haproxy установленным локально на каждой worker ноде. В качестве адреса api сервера для kubelet я буду использовать локалхост 127.0.0.1:6443, а haproxy по roundrobin будет раскидывать запросы по трем master нодам, также он будет проверять доступность master нод. Данная схема позволит нам создать HA, и в случае выхода из строя одной из master нод, worker ноды будут спокойно посылать запросы на две оставшихся в живых master ноды.

Установка ETCD

Вариант №1
Установка локально, запуск через systemd

На всех мастерах: (на рабочих нодах кластера этот шаг выполнять не нужно)
Шаг №1
Скачиваем и распаковываем архив с etcd:

Шаг №2
Создаем конфиг файл для ETCD

Скрипт принимает на вход значение etcd, и формирует конфиг файл в каталоге etcd. После работы скрипта готовый конфиг файл будет находится в каталоге etcd.
Для всех других конфигов, скрипт работает по тому же принципу. Принимает на вход какое-то значение и создает конфиг в определенном каталоге.

Шаг №3
Запускаем etcd кластер и проверяем его работоспособность

Проверяем работоспособность демона

И работоспособность самого кластера:

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

Данный цикл будет состоять минимум из четырех статей:

1. В первой из них я расскажу, как на голое железо установить отказоустойчивый кластер kubernetes, как установить стандартный дашборд и настроить доступ к нему, как установить ingress контроллер.
2. Во второй статье я расскажу, как развернуть отказоустойчивый кластер Ceph и как начать использовать RBD тома в нашем кластере Kubernetes. Также немного затрону остальные виды стораджей (storages) и более подробно рассмотрю local-storage. Дополнительно расскажу, как на базе созданного кластера CEPH организовать отказоустойчивое хранилище S3
3. В третьей статье я расскажу, как в нашем кластере Kubernetes развернуть отказоустойчивый кластер MySql, а именно — Percona XtraDB Cluster on Kubernetes. И также опишу все проблемы с которыми мы столкнулись, когда решили перенести БД в kubernetes.
4. В четвертой статье я постараюсь собрать все вместе и рассказать, как задеплоить и запустить приложение, которое будет использовать БД и тома ceph. Расскажу, как настроить ingress контроллер для доступа к нашему приложению извне и сервис автоматического заказа сертификатов от Let’s Encrypt. Еще — как автоматически поддерживать данные сертификаты в актуальном состоянии. Также немного затронем тему RBAC в контексте доступа до панели управления. Расскажу в двух словах про Helm и его установку.
   Если Вам интересна информация данных публикаций, то — добро пожаловать !

Конструктор

Параметры:

Примеры:

1.

2.

HA Configuration

Adding and managing VM´s and containers for HA should be done via GUI. The configuration of fence devices is CLI only.

Fencing

Fencing is an essential part for Proxmox VE HA (version 2.0 and later), without fencing, HA will not work. REMEMBER: you NEED at least a fencing device for every node.
Detailed steps to configure and test fencing can be found here.

Configure VM or Containers for HA

Review again if you have everything you need and if all systems are running reliable. It makes no sense to configure HA cluster setup on unreliable hardware.

See High_Availability_Cluster#System_requirements

Enable a KVM VM or a Container for HA

Note: Make sure that the VMs or CTs are not running when you add them to HA.

HA Cluster maintenance (node reboots)

If you need to reboot a node, e.g. because of a kernel update you need to stop rgmanager. By doing this, all resources are stopped and moved to other nodes. All KVM guests will get a ACPI shutdown request (if this does not work due to VM internal setting just a ‘stop’).

You can stop the rgmanager service via GUI or just run:

/etc/init.d/rgmanager stop

The command will take a while, monitor the «tasks» and the VM´s and CT´s on the GUI. as soon as the rgmanager is stopped, you can reboot your node. as soon as the node is up again, continue with the next node and so on.

Алгоритмы восстановления при отказах

Системы, которые обрабатывают ошибки в распределенных компьютерных системах, используют разные стратегии устранения последствий сбоя. Например, Apache Cassandra API Hector (API) предусматривает три варианта обработки ошибок:

• Fail Fast, в скрипте — «FAIL_FAST», просто возвращает клиенту ошибку при недоступности узла.
• On Fail, Try One — Next Available, в скрипте — «ON_FAIL_TRY_ONE_NEXT_AVAILABLE», означает, что система при сбое узла пробует перевести запрос на другой узел, наиболее свободный, и после первой неудачной попытки возвращает ошибку.
• On Fail, Try All, в скрипте — «ON_FAIL_TRY_ALL_AVAILABLE», означает, что система после первой неудачной попытки последовательно пробует все имеющиеся узлы, и только потом возвращает ошибку.

Для контроля работоспособности узлов в кластере обычно используется передача непрерывного периодического сигнала («пульса», англ. heartbeat) во внутренней сети кластера от каждого из узлов, по наличию которого управляющее ПО судит о нормальной работе соседних узлов. С этим связана неочевидная, но серьёзная проблема «разделённого мозга» (англ. split-brain_(computing)) — в случае одновременного разрыва множества соединений во внутренней сети кластера по причине сбоя питания, неисправности сетевого оборудования и т.п., узел, не способный корректно обработать данную ситуацию, начинает вести себя так, как будто все остальные узлы кластера вышли из строя, запуская дубликаты уже работающих в кластере сервисов, что может привести к повреждению данных в общем хранилище.

В технопарке рождаются стартапы

Если говорить о коммерциализации научных разработок, то в европейских странах этот показатель составляет около 65%. В нашей стране пока можно только стремиться к таким результатам. Однако технологические кластеры – прекрасная среда, созданная для того, чтобы здесь появлялись инновационные продукты и разрабатывались подходы в самых разных областях.

Уровень коммерциализации российских технопарков составляет всего 5%. Однако при этом здесь занимаются созданием навигационных приборов, лазерных гироскопов, лазеров разного типа, которые поставляются в Индию, Китай, Израиль, Австралию. Резиденты IT-технопарков создают продукты для интеллектуальной обработки информации и лингвистики.

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

1. В технопарке можно найти компании аналогичной сферы, сделав тем самым разработку какой-то идеи более продуктивным процессом.
2. Здесь легко найти единомышленников или узких специалистов, без которых не обойтись.
3. Кластеры открывают дорогу к венчурным инвесторам, которые ориентируются в специфике конкретного проекта.
4. Для стартапов открыты бизнес-инкубаторы.
5. Можно воспользоваться льготными условиями, которые предоставляются для инновационных команд. Это касается и льготной аренды, и сниженного налога, и набора необходимых услуг.

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

Самые производительные кластеры

Дважды в год организацией TOP500 публикуется список пятисот самых производительных вычислительных систем в мире, среди которых в последнее время часто преобладают кластеры. Самым быстрым кластером является IBM Roadrunner (Лос-Аламосская национальная лаборатория, США, созданный в 2008 году), его максимальная производительность (на июль 2008) составляет 1,026 Петафлопс. Самая быстрая система в Европе (на июль ) — суперкомпьютер, BlueGene/P находится в Германии, в исследовательском центре города Юлих, земля Северный Рейн-Вестфалия, максимально достигнутая производительность 167,3 Терафлопс.

Кластерные системы занимают достойное место в списке самых быстрых, при этом значительно выигрывая у суперкомпьютеров в цене. На июль 2008 года на 7 месте рейтинга TOP500 находится кластер SGI Altix ICE 8200 (Chippewa Falls, Висконсин, США).

Сравнительно дешёвую альтернативу суперкомпьютерам представляют кластеры, основанные на концепции Beowulf, которые строятся из обыкновенных недорогих компьютеров на основе бесплатного программного обеспечения. Один из практических примеров такой системы — Stone Soupercomputer в Национальной лаборатории Ок-Ридж (Теннесси, США, 1997).

Крупнейший кластер, принадлежащий частному лицу (из 1000 процессоров), был построен Джоном Козой (John Koza).

Надежность отдельного узла

HA-кластеры, кроме описанных схем межузлового резервирования, используют и все методы, обычно применяемые в отдельных (некластерных) системах и сетевой инфраструктуре для максимального повышения надёжности. К ним относятся:

• Резервирование и репликация дисков: отказ части внутренних дисков не приводит к сбоям системы. DRBD является одним из примеров.
• Резервирование внешних сетевых соединений: повреждения кабеля, отказ коммутатора или сетевого интерфейса не приводят к полному отключению от сети.
• Резервирование внутренних соединений cети хранения данных (SAN): повреждения кабеля, сбой коммутатора или сетевого интерфейса не приведут к потере соединения серверов с хранилищем (это нарушило бы неразделяемую архитектуру).
• Избыточные схемы электропитания различного оборудования, как правило, защищённого источниками бесперебойного питания, и резервируемые блоки питания: отказ единичного ввода, кабеля, UPS или БП не приводит к критическому отказу питания системы.

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

Установка Web UI (Dashboard)

После того, как мы установили панель в наш кластер, панель стала доступна по адресу

Но для того, чтобы на нее попасть, нам нужно с локальной машины пробросить порты с помощью kubectl proxy. Для меня эта схема очень не удобная. Поэтому я изменю service панели управления, для того чтобы dashboard стал доступен на адресе любой ноды кластера на порту 30443. Есть еще другие способы получить доступ до дашборда, например, через ingress. Возможно, я рассмотрю этот способ в следующих публикациях.
Для изменения сервиса запустим деплой измененного сервиса

Осталось создать admin пользователя и token для доступа к кластеру через дашборд