Як провести приймальне тестування кластера Kubernetes перед production

Щойно встановлений кластер OpenShift або OKD зустрічає вас консоллю, повною зеленого. Кожен operator звітує available, кожен вузол ready, і спокусливо назвати це готовим. Зелене каже вам, що компоненти запустилися. Воно не каже, що том можна відновити, що трафік переживе втрату вузла або що один орендар не може прочитати secrets іншого. Це ви маєте протестувати, навмисно, до того, як там запрацює щось, що вам дороге.

Статус не є поведінкою

Перевірки здоров’я кластера створені, щоб звітувати, чи компонент працює. Production залежить від того, як платформа поводиться, коли щось іде не так: вузол помирає, диск наповнюється, rolling update спорожнює вузол, що несе базу даних. Єдиний спосіб дізнатися: спричинити ці умови контрольовано і спостерігати. План тестів нижче покриває рівні, які мають найбільше значення. Адаптуйте його, але запишіть свій, виконайте кожен крок вручну першого разу і збережіть докази.

Сховище: створити, записати, збільшити, snapshot, відновити, порівняти

Stateful-навантаження стоять або падають на сховищі. Для кожного storage class, який ви маєте намір пропонувати:

oc apply -f test-pvc.yaml
oc rsh <test-pod> sh -c 'dd if=/dev/urandom of=/data/blob bs=1M count=256 && sha256sum /data/blob'
oc patch pvc test-pvc -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'
oc apply -f test-snapshot.yaml
oc apply -f restore-pvc-from-snapshot.yaml
oc rsh <restore-pod> sha256sum /data/blob

Контрольні суми мають збігатися. Підтвердьте, що розширення видно всередині pod через df, а не лише в claim. Для спільного сховища read-write-many змонтуйте той самий claim з pods на двох різних вузлах і підтвердьте, що обидва бачать записи одне одного. Потім перевірте, що станеться при видаленні claim: production-дані мають лежати на storage class, чия reclaim policy зберігає том, щоб помилкове видалення його не знищило.

Відмова: убийте вузол і заміряйте відновлення

Оберіть вузол, що несе живий ingress-трафік, і вимкніть його живлення з його контролера керування, а не ввічливим shutdown. З-поза кластера запустіть цикл, який ставить мітку часу на кожен запит:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code}\n' --max-time 2 https://test-app.example.com/
  sleep 0.2
done

Вивід показує точно, як довго сервіс був недоступний, а це число, яке відчули б ваші користувачі. Потім спостерігайте, що робить оркестратор: скільки часу до того, як вузол позначено not ready, чи перепризначаються pods, чи повертаються stateful pods зі своїми даними. Увімкніть вузол знову і підтвердьте, що він чисто приєднується. Тут має значення те, як мережа дізнається про відмову. Якщо адреса сервісу анонсується з кожного вузла через BGP, а мережева сторона використовує швидке виявлення відмов, таке як BFD, трафік може піти від мертвого вузла за секунди, задовго до того, як сам Kubernetes вирішить, що вузла немає.

Обслуговування: доведіть, що disruption budgets тримають кворум

Планове обслуговування вузлів і оновлення платформи спорожнюють вузли один за одним. Кластерна база даних потребує більшості учасників у роботі в будь-який момент, і PodDisruptionBudget є способом сказати це платформі:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: galera-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: galera

Потім протестуйте. З кластером із трьох учасників і одним уже вимкненим (його вузол спорожнений, тож працюють лише два учасники) спробуйте спорожнити вузол другого учасника:

oc adm cordon <node-a>
oc adm drain <node-b> --ignore-daemonsets --delete-emptydir-data
oc get pdb

Drain має чекати, а не виселяти, бо виселення зламало б кворум. Якщо він виселяє, budget неправильний або відсутній, і ви щойно дізналися про це в тесті, а не під час оновлення. Розподіліть учасників між вузлами через topology spread constraints або anti-affinity, щоб одна відмова вузла ніколи не могла забрати двох учасників.

Збірки і registry

Підтвердьте, що кластер може збирати і запускати власні образи, бо внутрішній registry, який не може прийняти push, виявиться лише в день деплою:

oc new-build --name=smoke --binary --strategy=docker
oc start-build smoke --from-dir=. --follow
oc new-app smoke

Доступ: протестуйте, чого орендар не може

Оренда визначається тим, у чому користувачу відмовлено. Створіть тестового користувача з обмеженими правами на орендаря і явно перевірте межі:

oc auth can-i get secrets -n tenant-b --as=tenant-a-user
oc auth can-i create pods -n tenant-a --as=tenant-a-user
oc auth can-i list nodes --as=tenant-a-user

Перша й третя мають сказати ні, друга так. Перевірте, що квоти не дають одному орендарю поглинути кластер, що ingress кожного орендаря обслуговує лише його власні домени з дійсним сертифікатом, і що трафік, який виходить із кластера до ваших інших систем, іде від egress identity, якої очікує ваш firewall.

Збережіть докази

Записуйте кожен тест з його командою, виводом і результатом. Коли щось зміниться пізніше, оновлення платформи або новий storage class, повторіть відповідний розділ і порівняйте. Кластер, який пройшов тести один раз і більше ніколи не тестувався, повільно стає непротестованим кластером.

Як це робимо ми

Ми будуємо OpenShift і OKD на виділених серверах HPE, з постійним блоковим і спільним сховищем усередині кластера, публічними адресами сервісів, які анонсуються з вузлів через BGP, і ingress та сертифікатами на орендаря. Перш ніж кластер понесе навантаження клієнта, він проходить понад тридцять практичних перевірок такого роду, від побайтових відновлень сховища до примусових відмов і меж доступу. В одному приймальному тесті ми вимкнули живлення вузла, що ніс живий трафік, і мережа перемаршрутизувала трафік приблизно за три секунди, задовго до того, як оркестратор оголосив вузол зниклим. Кластерні бази даних на платформі будуються за наведеним вище стандартом: disruption budgets, що тримають кворум, сховище, що зберігається, учасники, розподілені між вузлами.

Якщо ви збираєтеся покласти production на новий кластер і бачили його лише зеленим, ми радо допоможемо спершу протестувати його як слід.

Поговоріть з інженером

Related

Пов’язане: Приватний Kubernetes на bare metal, OpenShift і OKD · Bare metal сервери на HPE і Dell · Private cloud на KVM з OLVM