OpenShift – mirror-registry disconnected change port

Привет,

По проект, който работя бе необходимо да изградим OpenShift в disconnect env. За целта използвах mirror-registry инструмента от RedHat, който създава Quay с redis и pgsql. Целта е да служи само за наливане на images, които да се използват за самата инсталация на OpenShif. Всичко е шест, но по подразбиране идва с порт 8443. Така го бях и инсталирал, но разговаряйки с разработчиците се установи, че по-добре е да си ходи на 443.

Та стъпка едно бе да подменя начинът на стартиране, говоря за услугата във файл: /etc/systemd/system/quay-pod.service конкретно publish параметър да стане: 443:8443

Вторият файл за редактиране е самият конфигурационен на Quay, намира се в /etc/quay-install/quay-config/ и параметърът е SERVER_HOSTNAME.

След което в самият OpenShift двата image-policy-{0,1} ресурса трябва да бъдат редактирани с правилните данни. Там е обтлязано къде се намира хранилището, което сме създали.

OpenShift – OADP (backup/restore application)

OADP е оператор за backup/restore на приложение в OpenShift. В основата си е пак Velero, но е интегриран в OpenShift.

За целта ще го използвам пак с Minio което имам в лабораторната среда. За демострация ще използвам проект nn-proba01. Както в предишната статия за Velero ще използвам файл с име credentials-velero със съдържание на потребител и парола за достъп до Minio.

Първа стъпка е да се инсталира оператора OADP. От списъкът си избирам този, който е сертифициран от Red Hat. Оставям всичко по-подразбиране. Той ще създаде нов namespace с гръмкото име openshift-adp

Стъпка две, създавам нов secret с име cloud-credentials във въпросният namespace, а съдържанието е гореспоменатият файл за достъп до Minio.

oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

Стъпка три, създаване на custom resource, който да е за DataProtectionApplications. В него се споменава URL до Minio, региона, bucket-a, и какви плъги да може да използва. Подробности в тяхната документация тук.

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero-sample
  namespace: openshift-adp
spec:
  backupLocations:
    - velero:
        config:
          insecureSkipTLSVerify: 'true'
          profile: default
          region: minio-teo
          s3ForcePathStyle: 'true'
          s3Url: 'http://minio.lab.local:9000'
        credential:
          key: cloud
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: nn-proba01
          prefix: velero
        provider: aws
  configuration:
    restic:
      enable: true
    velero:
      defaultPlugins:
        - openshift
        - aws
        - kubevirt
        - csi
  snapshotLocations:
    - velero:
        config:
          profile: default
          region: minio-teo
        provider: aws

oc create -f dataprotection.yaml

След няколко минутки ще се вдигне контейнер с velero, както и контейнер с restic. На кратко restic е инструмент за backup на PV, който е предоставен от storage, който не поддържа volume snapshots(например NFS или emptydir).

Туй то от към конфигурация, сега малко тестове. Както казах ще създам един проект nn-proba01, в него ще създам един контейнер с postgresql, който има PV 10Gi.

За да се сзъдаде backup или през web console или през oc се създава един CR за backup с такова кратко съдържание:

kind: Backup
apiVersion: velero.io/v1
metadata:
  name: backup
  namespace: openshift-adp
spec:
  defaultVolumesToRestic: true
  includedNamespaces:
    - nn-proba01

Изтривам проекта, изчаквам да ми каже че е изтрит и няма никакъв ресурс и през oc му правя възсвановяване. Разбира за теста беше хубаво да се създаде например една таблица в контейнера за да се покаже, че данните са там. Та тук ще напиша как му вкарах малко данни

$ psql
psql (10.15)
Type "help" for help.
postgres=# CREATE DATABASE dbproba01;
CREATE DATABASE
postgres=# \connect dbproba01;
You are now connected to database "restore_me" as user "postgres".
postgres=# CREATE TABLE data (
id INT PRIMARY KEY,
text VARCHAR
);
postgres=# \dt
List of relations
Schema | Name | Type | Owner
--------+------------+-------+----------
public | data | table | postgres
(1 row)
postgres=# INSERT INTO data VALUES (1,'hello there');
INSERT 0 1
postgres=# SELECT * from data;
id | text
----+-------------
1 | hello there
(1 row)

За възстановяване използвам през velero следните параметъра.

velero restore create --from-backup=backup -n openshift-adp \
--include-namespaces nn-proba01 --exclude-resources replicationcontroller,deploymentconfig,templateinstances.template.openshift.io --restore-volumes=true

Като преди това съм се вписал, разбира се. Добавил съм параметрите за exclude на ресурси, защото контейнера е от шаблона на openshift. Другият вариант е с custome resource за restore, който има следният вид.

apiVersion: velero.io/v1
kind: Restore
metadata:
  name: restore
  namespace: openshift-adp
spec:
  backupName: backup
  excludedResources:
    - nodes
    - events
    - events.events.k8s.io
    - backups.velero.io
    - restores.velero.io
    - resticrepositories.velero.io
    - replicationcontroller
    - deploymentconfig
    - templateinstances.template.openshift.io
  includedNamespaces:
    - nn-proba01
  restorePVs: true

Бърза проверка в новопоявилият се контйнер дали базата е там и данните са там. Всичко е наред.

OpenShift – velero backup/restore

Velero е софтуер за backup/restore на приложения в kubernetes. В лабораторната среда с която си играя се оказа, че има инсталиран Minio(разбира се има и nooba, но не ми се иска да цапам въпросният клъстер). Та целта на това занятие е да направя кратко backup/restore на проект в един от openshift клъстерите.

Текущо версията на velero е 1.9. Сваля се въпросният софтуер, след което се разархивира и го местя в /usr/local/bin/.

Втора стъпка, вписвам се с oc в някой от openshift клъстерите.

Трето, в произволна директория създавам файл с гръмкото име credentials-velero, съдържащ в себе си данни за вход във minio конзолата. Изглежда ето така:

[default]
aws_access_key_id = "minioadmin"
aws_secret_access_key = "minioadmin"

За да конфигурирам velero в openshift трябва да се изпълни инсталация, като това е моят пример. Посочвам име на файл с данните за вход, както и името на bucket-a, също и адресът за достъп до самото minio.

velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.2.1 \
--bucket nn-proba \
--secret-file ./credentials-velero \
--use-volume-snapshots=false \
--backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://minio.dev.lablocal:9000

Дават се малко права за да се вдигне velero pod:

oc adm policy add-scc-to-user privileged -z velero -n velero

Използвам namespace proba-ssd в openshift за backup/restore. Разигравам сценарии на backup, унищожение на namespace, възстановяване.

velero backup create proba-bk --include-namespaces proba-ssd

Проверка в minio, както и в самото velero за грешки:

velero backup get

Триеме нещата в openshift и правим възстановяване.

oc delete namespace proba-ssd

Проверка!

velero restore create --from-backup proba01

Проверка! И в този проект се вижда, че имах един mysql с pv.

Полезни параметри за velero:

velero restore get
velero restore describe IME
velero backup delete BACKUP_NAME

OpenShift – ceph warning 15 minutes

Кратка пред история: в лабораторната среда ми предоставиха 3 физически машини за инсталация на OpenShift върху желязо. Желязото ще бъде използвано за ODF + Virtualization.

По време на конфигурацията за мрежовата връзка за Virtulization по погрешка посочих друг мрежови интерфей и нещата замряха. Наложи се физически рестарт на машините за да ги върна отново. След време обаче забелязах, че ODF се е спънал. Та в тази кратка публикация ще споделя опит какво забелязах и как го разреших проблемът.

Забелязах, че ODF е в предупредителен режим, защопто

  1. Намерих контейнера с ceph(rook-ceph-operator)
  2. Посочих списък с променливи от конфигурацията му:
     export CEPH_ARGS='-c /var/lib/rook/openshift-storage/openshift-storage.config'
  3. Прегледах всички събития:
    sh-4.4$ ceph crash ls-new
    ID ENTITY NEW
    2022-07-20T12:44:40.615358Z_3d3593b8-0009-4f88-a340-61c798600250 osd.25 *
  4. Извадих малко повече информация за събитието:
    ceph crash info 2022-07-20T12:44:40.615358Z_3d3593b8-0009-4f88-a340-61c798600250
  5. Попадха на редове гласящи, че е имало отпадане, което беше ясно още в началото. За целта го архивирах въпросното събитие:
    ceph crash archive
  6. Повторен преглед и обеждаване, че в конзолата всичко е наред.

OpenShift – добавяне на worker node

Наложи ми се да добавя нов worker node към съществуваща инсталация на OpenShift с UPI върху VMware. Проблемът, е че съм подменил CA на OCP клъстера. Поради което използването на първичните worker.ing файлове е неуспешно. Чупи се комуникацията до api.domain.name.

Първа стъпка, вземане на текущият сертификат:

oc describe cm root-ca -n kube-system

Трябва ни съдържанието от BEGIN CERT.. до END CERT. За мое улеснение го записвам в ca.crt файл.

Ако разгледаме текущият ignition файл, ще се установи, че съдържанието на въпросният сертификат е в base64.

Втора стъпка, създаване на base64 от записаният файл

cat ca.crt | base64 -w0 > ca.crt.base64

Трета стъпка подмяна на съдържанието. За целта съм си копирал worker.ign файлът на друго място. Отварям го с любимият текстови редактор и извършвам корекция, като съдържанието изглежда нещо такова:

{"ignition":{"config":{"merge":[{"source":"https://api.domain.name:22623/config/worker"}]},"security":{"tls":{"certificateAuthorities":[{"source":"data:text/plain;charset=utf-8;base64, <съдържанието на ca.crt.base64>" }]}},"version":"3.2.0"}}

След запис, тъй като използвам VMware трябва файлът да го направя отново на base64 и съдържанието да го подам на него. С това нещата приключват. Ако инсталацията ни е например за baremetal то готовият ignition файл, трябва да бъде прехвърлен върху достъпен webserver и посочен по време на инсталацията на CoreOS.

OpenShift Container Platform 3.10

От началото на година усилено съм се съсредоточил върху инсталиране/конфигуриране и разучаването на OpenShift. След усилена борба, успях да му надвия.

Ситуацията е следната, написах playbook, който разпъва OpenShift ent(container platform 3.10) върху 1 master, 3 nodes, 3 gluster registry.
Много съм доволен от себе си 🙂

Следваща стъпка, 3 master, 3 nodes, 3 gluster registry, 1 load balancer. 

Същевременно изкарах и сертификат от Red Hat с гръмкото име „Red Hat Delivery Specialist – Platform-as-a-Service (PaaS) Administration“.