Установка кластера OKD 4.X на виртуальные сервера (baremetall)

В данной статье рассматривается вариант установки OKD (The Community Distribution of Kubernetes) версии 4.5 на выделенные виртуальные сервера (BareMetall User Provided Infrastructure). Данная статья составлена на основе сторонних источников в сети Интернет, документации OKD, информации из чата OpenShift в телеграм и личного опыта. Гипервизор виртуальных машин - Hyper V.

Подготовка к установке кластера OKD

Минимальные требования к серверам

В данном варианте установки рассмотрим инфраструктуру 3 master и 3 worker ноды. Чтобы установить данные сервера потребуется ещё балансер и bootstrap нода. После того, как установка кластера будет завершена, ресурсы bootstrap ноды можно освободить. В версии OKD 4.8 bootstrap нода переиспользуется как master нода.

Есть мнение, что выделенный сервер для балансера в данном варианте установке не нужен, так как возможно обойтись без него с использованием DNS Round-robin балансировки. Я пробовал такой вариант установки, но DNS не находил нужной ноды в момент установки, поэтому принял решение использовать балансировщик на основе HAProxy на выделенном сервере, к тому же данный сервер в дальнейшем использован как NFS сервер.

Общая ресурсная конфигурация серверов может выглядеть следующим образом:

Машина Количество Операционная система vCPU RAM, GB Диск, GB
Master 3 Fedora CoreOS 32 4 16 120
Worker 3 Fedora CoreOS 32 4 16 120
Bootstrap 1 Fedora CoreOS 32 4 8 80
Балансер 1 Fedora Server 32 2 4 60

Документация OKD рекомендует устанавливать альтернативные ресурсы для master, worker и boostrap нод. В моём варианте установки boostrap нода будет удалена после полной установки кластера, общая нагрузка приложений будет размещаться только на worker нодах, а на master нодах будут размещаться системные OKD сервисы, в том числе мониторинг, поэтому worker нодам выдано больше ресурсов, bootstrap ноде меньше. Балансер будет выполнять только роль проксирования запросов к API Kubernetes и к роутерам OpenShift.

Для каждой виртуальной машины должен быть назначен статический IP адрес. Также возможно использовать DHCP.

Требования к записям DNS

Установка OKD кластера требует наличия определенных DNS записей, но данные DNS записи расходятся с тем, что указано в документации на github. Я устанавливал DNS записи, которые указаны на github. Перед установкой кластера должны быть определены базовый домен <base_domain> и имя кластера <cluster_name>. Например: okd4.example.ru - где example.ru - базовый домен, okd4 - имя кластера. Данные параметры будут необходимы в дальнейшем при генерации манифестов для кластера.

DNS записи должны быть следующими:

Компонент DNS запись Описание
Kubernetes API api.<cluster_name>.<base_domain>. A/AAAA или CNAME запись должна указывать на IP адрес балансировщика.
Kubernetes API api-int.<cluster_name>.<base_domain>. A/AAAA или CNAME запись должна указывать на IP адрес балансировщика.
Routes *.apps.<cluster_name>.<base_domain>. A/AAAA или CNAME запись должна указывать на IP адрес балансировщика.
Master <etcd>-<n>.<cluster_name>.<base_domain>. A/AAAA или CNAME запись должна указывать на IP адрес master ноды.

Каждая master и worker нода должна резолвится по своему доменному имени.

Компонент DNS запись Описание
master1 master1.<cluster_name>.<base_domain>. A/AAAA или CNAME запись должна указывать на IP master1 ноды.
master2 master2.<cluster_name>.<base_domain>. A/AAAA или CNAME запись должна указывать на IP master2 ноды.
master3 master3.<cluster_name>.<base_domain>. A/AAAA или CNAME запись должна указывать на IP master3 ноды.

Также для каждой записи etcd необходимо установить SRV запись.

# _service._proto.name.                            TTL   class SRV priority weight port target.
_etcd-server-ssl._tcp.<cluster_name>.<base_domain>   86400 IN    SRV 0        10     2380 etcd-0.<cluster_name>.<base_domain>.
_etcd-server-ssl._tcp.<cluster_name>.<base_domain>   86400 IN    SRV 0        10     2380 etcd-1.<cluster_name>.<base_domain>.
_etcd-server-ssl._tcp.<cluster_name>.<base_domain>   86400 IN    SRV 0        10     2380 etcd-2.<cluster_name>.<base_domain>.

DNS записи должны резолвится с нод кластера. Имя хоста master, worker, bootstrap нод при установке системы необходимо указать в соответствии с DNS записью для ноды.

Сетевые требования к кластеру

  1. Ноды должны видеть друг друга по доменному имени.
  2. На балансировщике должен быть открыт порт 6443 для обращения к API Kubernetes.
  3. На балансировщике должен быть открыт порт 22623 (Machine Config Server).
  4. На балансировщике должны быть открыты порты 80 и 443 для проксирования на роутеры OpenShift.

В данном примере для нод виртуальных машин выданы следующие IP адреса:

DNS имя и hostname IP / Маска
balancer.okd4.example.ru 192.168.0.2 / 24
bootstrap.okd4.example.ru 192.168.0.6 / 24
master1.okd4.example.ru 192.168.0.3 / 24
master2.okd4.example.ru 192.168.0.4 / 24
master3.okd4.example.ru 192.168.0.5 / 24
worker1.okd4.example.ru 192.168.0.7 / 24
worker2.okd4.example.ru 192.168.0.8 / 24
worker3.okd4.example.ru 192.168.0.9 / 24

Общая схема кластера после установки должна выглядеть примерно следующим образом: okd4-install

1. Установка и настройка балансировщика

  1. После установки на ноду балансировщика Fedora Server 32, устанавливаем haproxy.
dnf install -y haproxy
  1. Необходимо скопировать конфигурационный файл haproxy.cfg в /etc/haproxy/haproxy.cfg.
haproxy.cfg 
# Global settings
#---------------------------------------------------------------------
global
    maxconn     20000
    log         /dev/log local0 info
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    user        haproxy
    group       haproxy
    daemon

    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------
#Common defaults that all the 'listen' and 'backend' sections will
#Use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          300s
    timeout server          300s
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 20000

listen stats
    bind :9000
    mode http
    stats enable
    stats uri /

frontend okd4_k8s_api_fe
    bind :6443
    default_backend okd4_k8s_api_be
    mode tcp
    option tcplog

backend okd4_k8s_api_be
    balance source
    mode tcp
    server      master1 192.168.0.3:6443 check
    server      master2 192.168.0.4:6443 check
    server      master3 192.168.0.5:6443 check
    server      bootstrap 192.168.0.6:6443 check

frontend okd4_machine_config_server_fe
    bind :22623
    default_backend okd4_machine_config_server_be
    mode tcp
    option tcplog

backend okd4_machine_config_server_be
    balance source
    mode tcp
    server      master1 192.168.0.3:6443 check
    server      master2 192.168.0.4:6443 check
    server      master3 192.168.0.5:6443 check
    server      bootstrap 192.168.0.6:6443 check

frontend okd4_http_ingress_traffic_fe
    bind :80
    default_backend okd4_http_ingress_traffic_be
    mode tcp
    option tcplog

backend okd4_http_ingress_traffic_be
    balance source
    mode tcp
    server      master1 192.168.0.3:6443 check
    server      master2 192.168.0.4:6443 check
    server      master3 192.168.0.5:6443 check

frontend okd4_https_ingress_traffic_fe
    bind *:443
    default_backend okd4_https_ingress_traffic_be
    mode tcp
    option tcplog

backend okd4_https_ingress_traffic_be
    balance source
    mode tcp
    server      master1 192.168.0.3:6443 check
    server      master2 192.168.0.4:6443 check
    server      master3 192.168.0.5:6443 check

В данной конфигурации предполагается, что ингресс контроллеры / роутеры будут находиться на master нодах.

  1. Установим контекст selinux, запустим haproxy и добавим в автозагрузку.
setsebool -P haproxy_connect_any 1
systemctl enable --now haproxy
  1. Добавим правила сетевого фильтра.
firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --add-port=22623/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

2. Установка и настройка Apache сервера для публикации ignite-файлов для кластера

  1. Установим сервер Apache.
dnf install -y httpd
  1. Так как 80 порт занят haproxy, заменим 80 порт веб-сервера Apache на 8080.
sed -i 's/Listen 80/Listen 8080/' /etc/httpd/conf/httpd.conf
  1. Добавим правила selinux и firewalld.
setsebool -P httpd_read_user_content 1
systemctl enable --now httpd
firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --reload

Проверим, что веб-сервер работает:

curl localhost:8080

Ответом должен быть текст стандартной html страницы Apache.

  1. Скачиваем утилиты для генерации ignition конфигурационных файлов и клиент-утилиты для работы с OpenShift.
wget https://github.com/openshift/okd/releases/download/4.5.0-0.okd-2020-07-29-070316/openshift-client-linux-4.5.0-0.okd-2020-07-29-070316.tar.gz

wget https://github.com/openshift/okd/releases/download/4.5.0-0.okd-2020-07-29-070316/openshift-install-linux-4.5.0-0.okd-2020-07-29-070316.tar.gz

В данной статьей рассматривается вариант установки версий 4.5. На текущий момент на github уже есть версия 4.7.

  1. Извлекаем архивы.
tar -zxvf openshift-client-linux-4.5.0-0.okd-2020-07-29-070316.tar.gz

tar -zxvf openshift-install-linux-4.5.0-0.okd-2020-07-29-070316.tar.gz
  1. Перемещаем извлеченные бинарные файлы в /usr/local/bin/
mv kubectl oc openshift-install /usr/local/bin/

  1. Командой ssh-keygen генерируем связку приватного и публичного ключей.

  2. Создаем любую директорию, например /opt/okd4, и перемещаем в неё файл install-config.yaml.

install-config.yaml 
apiVersion: v1
baseDomain: <base_domain>
metadata:
  name: <cluster_name>

compute:
- hyperthreading: Enabled
  name: worker
  replicas: 3

controlPlane:
  hyperthreading: Enabled
  name: master
  replicas: 3

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23 
  networkType: OVNKubernetes
  serviceNetwork: 
  - 172.30.0.0/16

platform:
  none: {}

fips: false

pullSecret: '{"auths":{"fake":{"auth": "bar"}}}' 
sshKey: 'ssh-rsa ...'

В данном файле необходимо установить необходимые значения для .baseDomain, .metadata.name, установить нужное количество реплик для master и worker нод и вставить в sshKey значение публичного ключа, который был сгенерирован на предыдущем шаге.

Про все параметры данного файла можно прочитать в документации OKD.

  1. Генерируем манифесты из данного файла.
openshift-install create manifests --dir=/opt/okd4
  1. Генерируем ignition-файлы.
openshift-install create ignition-configs --dir=/opt/okd4
  1. Создаем директорию для работы веб-сервера и копируем туда полученные файлы.
mkdir /var/www/html/okd4
cp -R /opt/okd4/* /var/www/html/okd4/
  1. Переходим в директорию /var/www/html/okd4/ и скачиваем в нее образы .raw.xz Fedora CoreOS в версии установки для baremetall.
cd /var/www/html/okd4/
wget https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20200715.3.0/x86_64/fedora-coreos-32.20200715.3.0-metal.x86_64.raw.xz
wget https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/32.20200715.3.0/x86_64/fedora-coreos-32.20200715.3.0-metal.x86_64.raw.xz.sig
mv fedora-coreos-32.20200715.3.0-metal.x86_64.raw.xz fcos.raw.xz
mv fedora-coreos-32.20200715.3.0-metal.x86_64.raw.xz.sig fcos.raw.xz.sig

В данном примере используются образы Fedora CoreOS 32. На момент написания статьи уже есть Fedora CoreOS 33.

  1. Устанавливаем владельца и права на директорию работы веб-сервера.
chown -R apache: /var/www/html/
chmod -R 755 /var/www/html/

3. Запуск установки bootstrap ноды

Запускаем машину и загружаемся с iso образа Fedora CoreOS для baremetall. Когда появится меню загрузки ядра нажимаем Ctrl+X и вводим следующие параметры в строку, начинающуюся с linux:

ip=192.168.0.6::192.168.0.1:24:bootstrap.okd4.example.ru::none nameserver=192.168.1.11 coreos.inst.install_dev=/dev/sda coreos.inst.image_url=http://192.168.0.2:8080/okd4/fcos.raw.xz coreos.inst.ignition_url=http://192.168.0.2:8080/okd4/bootstrap.ign

В данной строке:

  • 192.168.0.6 - IP адрес ноды,
  • 192.168.0.1 - Шлюз,
  • 24 - префикс сети, возможно указывать в полном формате 255.255.255.0,
  • bootstrap.okd4.example.ru - hostname,
  • 192.168.1.11 - адрес DNS сервера,
  • /dev/sda - блочное устройство, куда будет ставится система,
  • http://192.168.0.2:8080/okd4/fcos.raw.xz - URL, с которого будет скачан образ Fedora CoreOS при установки, в данном случае это web адрес Apache сервера на балансировщике,
  • http://192.168.0.2:8080/okd4/bootstrap.ign - URL, с которого будет скачан ignition-файл.

Нажимаем Enter и ждём установки bootstrap ноды.

Проверить установку boostrap ноды возможно выполнив следующую команду на сервере балансировщика.

openshift-install --dir=/opt/okd4 wait-for bootstrap-complete --log-level=info

4. Запуск установки master ноды

Аналогичным образом устанавливаются master ноды.

ip=192.168.0.3::192.168.0.1:24:master1.okd4.example.ru.magenta::none nameserver=192.168.1.11 coreos.inst.install_dev=/dev/sda coreos.inst.image_url=http://192.168.0.2:8080/okd4/fcos.raw.xz coreos.inst.ignition_url=http://192.168.0.2:8080/okd4/master.ign

При установке остальных master нод указать соответсвующие IP адреса и хостнейм.

5. Запуск установки worker ноды

Для запуска установки worker нод дождаться, когда будет установлена хотя бы одна master нода.

Аналогичным образом устанавливаются worker ноды.

ip=192.168.0.7::192.168.0.1:24:worker1.okd4.example.ru::none nameserver=192.168.1.11 coreos.inst=yes coreos.inst.install_dev=/dev/sda coreos.inst.image_url=http://192.168.0.2:8080/okd4/fcos.raw.xz coreos.inst.ignition_url=http://192.168.0.2:8080/okd4/worker.ign

При установке остальных worker нод указать соответсвующие IP адреса и хостнейм.

Подтверждение CSR worker нод

После установки worker нод при просмотре статуса нод (oc get nodes) можно заметить, что worker ноды в состоянии NotReady, CSR worker нод находятся в состоянии Pending (oc get csr). Чтобы решить данную проблему необходимо выполнить подтверждение CSR.

oc adm certificate approve <CSR_name>

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

oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

6. Проверка готовности кластера

Чтобы проверить, что кластер был установлен выполним команду

openshift-install --dir=/opt/okd4 wait-for install-complete

Также проверим, что все операторы кластера установились.

oc get clusteroperators

У всех операторов должно быть значение True в колонке Available и False в колонке Degraded.

7. Доступ к кластеру

После установки веб-консоль будет доступна по адресу https://console-openshift-console.apps.$cluster_name.$base_domain/

Логин для входа kubeadmin, пароль находится в /opt/okd4/auth/kubeadmin-password

kubeadmin - пользователь с ролью кластер админа, который был создан автоматически при создании кластера.

Создадим файл users.htpasswd с данными нового пользователя для доступа с использованием провайдера htpasswd.

htpasswd -c -B -b users.htpasswd <имя_пользователя> <пароль_пользователя>

Создадим секрет на основе файле users.htpasswd.

oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd -n openshift-config

Создадим файл htpasswd_provider.yaml с провайдером аутентификации с использованием созданного секрета htpass-secret:

htpasswd_provider.yaml 
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: htpasswd_provider 
    mappingMethod: claim 
    type: HTPasswd
    htpasswd:
      fileData:
        name: htpass-secret

Применим манифест.

oc apply -f htpasswd_provider.yaml

Добавим новому пользователю права администратора кластера.

oc adm policy add-cluster-role-to-user cluster-admin <имя_пользователя>

После этого можем подключиться к кластеру через web консоль и oc клиент с использованием созданного пользователя.

Неочевидные вещи после установки кластера OKD

Далее описаны некоторые проблемы, с которыми я столкнулся на свежеустановленном OKD кластере.

  1. После установки 3 master и 3 worker нод, деплое приложения и установки роутов для приложений, приложение оказалось недоступным по URL указанным в роутере. Причиной являлось то, что все роутеры опеншифта после установки разместились на worker нодах, в то время как на haproxy балансировщике установлено проксирование на master ноды. Чтобы это устранить можно воспользоваться инструкцией из официальной документации.
  • Смотрим список нод.
oc get nodes
  • Смотрим список лейблов на master ноде.
oc describe node <имя_master_ноды>

В списке лейблов должен быть node-role.kubernetes.io/master

  • Выполняем команду oc edit ingresscontroller default -n openshift-ingress-operator и добавляем следующую информацию в spec.
  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/master: ""
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/master
      operator: Exists
  replicas: 3

Сразу укажем tolerations, чтобы разрешить размещать поды на master нодах и количество реплик, т.к. балансер проксирует на 3 ноды мастера.

  • Далее остается проверить, что поды роутера переместились на master ноды.
oc get pod -n openshift-ingress -o wide
  1. Все сервисы мониторинга тоже оказались разбросаны по worker нодам. Чтобы переместить их на master ноды, необходимо воспользоваться инструкцией из документации OKD.
  • Создаем файл cluster-monitoring-configmap.yaml и добавляем в него следующую информацию.
cluster-monitoring-configmap.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |+
    alertmanagerMain:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    prometheusK8s:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    grafana:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    k8sPrometheusAdapter:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
        operator: Exists
  • Создаем ConfigMap из созданного манифеста:
oc create -f cluster-monitoring-configmap.yaml
  • Проверяем, что поды начали перемещение на master ноды.
oc get pod -n openshift-monitoring -o wide

Источники:

  1. Install: BareMetal User Provided Infrastructure
  2. Installing a cluster on bare metal
  3. Creating infrastructure machine sets
  4. Guide: OKD 4.5 Single Node Cluster
Сведения о статье:
Дата публикации: 13/04/2021 11:15AM
Последнее обновление: 13/04/2021 11:17AM (rmntrvn)
Поделиться статьей: 
Автор: rmntrvn
Постоянная ссылка: http://kb.rmntrvn.ru/kb/install-okd4-baremetall
okd4 | openshift | router | monitoring | kubernetes |