Kubernetes Check Tests

A Bash-based toolkit for validating Kubernetes cluster behavior under API, scheduler, CPU, memory, DNS, Cilium, fio, and StatefulSet storage workloads.

Quick Start

git clone https://github.com/wasdo129/k8s-check-tests.git
cd k8s-check-tests
kubectl cluster-info
chmod +x run-all-tests.sh
./run-all-tests.sh

Artifacts are saved under:

artifacts/<timestamp>/

Originally created for MKaaS cluster validation, but kept cluster-agnostic where the test scenario allows it.

Requirements

• Kubernetes cluster access via kubectl
• Bash
• jq
• kubectl
• Optional: cilium CLI, required only for Cilium connectivity and network performance tests
• Optional: kube-burner, required only for kube-burner API create/patch/delete tests
• Optional: fio-capable images available in the target cluster
• Metrics Server for kubectl top output in diagnostics

Набор Kubernetes-тестов для проверки кластера по нескольким направлениям:

• нагрузка на Kubernetes API;
• scheduler resource-guarded burst;
• CPU и memory saturation;
• fio IO-intensive;
• Cilium connectivity и network perf;
• CoreDNS / DNS load;
• StatefulSet storage tests.

Главный entrypoint проекта:

run-all-tests.sh

Структура проекта

• 0.init-cluster/ - init baseline диагностика кластера перед нагрузкой.
• 1.1.api-test/ - kube-burner create / patch / delete и api-soak-churn.
• 2.1.sheduler-test/ - scheduler resource-guarded burst тест и standalone runner.
• 3.1.test-cpu/ - CPU saturation тест.
• 3.2.test-mem/ - memory saturation тест.
• 3.3.fio/ - fio IO-intensive тесты и standalone runner по профилям.
• 4.1.cilium/ - Cilium status, connectivity и network perf.
• 4.2.dns/ - DNS / CoreDNS / node-local-dns load runner.
• 5.1.stateful/ - StatefulSet storage тесты и отдельный runner для них.
• run-all-tests.sh - единый orchestration-скрипт для запуска всех этапов по очереди.

Основной runner не содержит реализацию нагрузочных сценариев. Он создает общий RUN_DIR, выполняет preflight/cleanup и вызывает stage-скрипты в соответствующих директориях, передавая им LOG_DIR внутри artifacts/<timestamp>/.

Кратко о тестах

• API test сначала запускает kube-burner create / patch / delete по Deployment и Service. После него всегда запускается api-soak-churn: 5 минут создает и удаляет ConfigMap, Secret, ServiceAccount, Role, RoleBinding, Service и маленькие Deployment, проверяя API /readyz, /livez, /version и признаки деградации API.
• Scheduler test создает много маленьких pause pod'ов пачками и завершает нагрузку при первом FailedScheduling с Insufficient cpu или Insufficient memory, сохраняя events, pod describes и summary.
• CPU test запускает stress-ng pod'ы с маленьким CPU request и постепенно масштабирует Deployment. Insufficient cpu считается штатной точкой остановки capacity-теста; Insufficient memory тоже останавливает stage как resource boundary, чтобы Pending pod'ы не висели без завершения runner.
• Memory test запускает stress-ng --vm pod'ы с маленьким memory request/limit, чтобы тест работал и на небольших кластерах. Insufficient memory, OOMKilled, Evicted и CrashLoopBackOff/Error останавливают memory stage с диагностикой и cleanup.
• fio IO-intensive stage запускает четыре fio-профиля: randread, randwrite, seqread, seqwrite. Каждый профиль создает Job'ы ступенями от FIO_INITIAL_JOBS до FIO_MAX_JOBS, собирает Kubernetes snapshot'ы, fio output и summary. Успех засчитывается только если все созданные Job завершились Complete, без Failed/Error/OOMKilled/Evicted pod'ов и без системных storage/network health failures. Активные Job в финальном snapshot считаются ошибкой или timeout, а не успешным частичным результатом.
• StatefulSet storage stage проверяет PVC/CSI storage classes standard и high-iops: сначала запускает baseline fio Job на одном PVC, затем в режиме full optional longrun Job, после этого масштабирует StatefulSet с отдельным PVC на каждую реплику. Pending fio pod'ы, CrashLoopBackOff/Error, OOMKilled, Evicted, SystemOOM, NotReady node, Cilium not ready или unhealthy CSI pod считаются ошибкой stage.

Cilium network stage

Cilium stage проверяет базовую готовность Cilium, connectivity scenarios и network performance. Stage сохраняет cilium status, Cilium pods, Cilium Envoy pods, deployment/daemonset состояние, Cilium node objects, node PodCIDR/IP mapping, cilium-dbg status --verbose key fields и cilium-dbg endpoint list до и после каждого Cilium-сценария.

cilium status: PASS означает только, что Cilium components на момент проверки были Ready. Это не гарантирует прохождение connectivity suite. Основной индикатор сетевой корректности находится в connectivity-test/summary.txt, connectivity-test/output.log и общем artifacts-cilium/summary.txt.

Runner различает итог сценариев и baseline:

• result=pass|fail - прошли ли Cilium status/connectivity/perf сценарии.
• baseline_status=clean|degraded - были ли Cilium warnings/errors в статусе, events или output.
• perf_validity=valid|degraded|invalid - можно ли использовать perf-результаты как чистый benchmark.
• baseline_status=degraded не останавливает оставшиеся Cilium сценарии, но снижает доверие к perf-цифрам.

Connectivity/perf failure не должен теряться из-за exit_code=0 у Cilium CLI: runner дополнительно парсит output на tests failed, failed actions и явные failure markers. Если найден fail, stage получает result=fail, но остальные Cilium сценарии продолжают выполняться для сбора полной диагностики.

Runner пишет scenario-summary.tsv с итогом каждого сценария и diagnostics-summary.tsv с оценкой diagnostics snapshot'ов. Diagnostics тоже участвуют в baseline_status=degraded: Cilium warnings, Unhealthy, Failed, BackOff, Error, Timeout, forbidden и connection refused в diagnostics не прерывают stage, но фиксируются в summary. Перед каждым следующим Cilium-сценарием runner удаляет cilium-test-* namespace и по умолчанию ждет их удаления, чтобы старые resources не смешивались с новым сценарием.

cilium connectivity test может падать на старых Cilium log errors, потому что сам Cilium CLI проверяет логи компонентов. Поэтому при разборе failure нужно смотреть не только connectivity-test/summary.txt, но и connectivity-test/output.log, diagnostics-summary.tsv, cilium-diagnostics-*.txt и timestamp stage_started_at_utc в общем summary. Старые ошибки не равны ошибке текущей нагрузки, но они все равно снижают доверие к состоянию кластера.

DNS / CoreDNS load stage

DNS stage вынесен отдельно от Cilium и запускается флагом RUN_DNS. Он создает нагрузочный Deployment в namespace dns-test, выполняет nslookup из нескольких pod'ов, собирает per-pod counters, агрегированный success rate, health snapshots node-local-dns, node-local-dns logs и DNS pod logs.

Успешный DNS success rate не означает полностью чистый DNS baseline. Нужно отдельно смотреть node-local-dns-summary.txt: result=warning указывает на restarts или suspicious log lines вроде SERVFAIL, plugin/errors, i/o timeout, connection refused.

fio IO-intensive stage

FIO stage проверяет, что кластер может создать и выполнить IO-нагрузку в namespace load-test, а worker node, container runtime, CNI и ephemeral storage выдерживают короткий профиль чтения/записи без явных отказов. Это не полноценный benchmark всей storage-платформы: текущие manifests используют emptyDir с ephemeral-storage, поэтому результат в первую очередь отражает локальный storage path выбранных worker-нод, а не PVC/CSI latency.

Профили:

• fio-randread-fixed.yaml - random read, block size 4k, iodepth=16, numjobs=2.
• fio-randwrite-fixed.yaml - random write, block size 4k, iodepth=16, numjobs=2.
• fio-seqread-fixed.yaml - sequential read, block size 1M, iodepth=16, numjobs=2.
• fio-seqwrite-fixed.yaml - sequential write, block size 1M, iodepth=16, numjobs=2.

Runner запускает профили последовательно. Внутри одного профиля Job'ы добавляются ступенями, например 1 -> 2 -> 3 -> 4, затем runner ждет завершения всех созданных Job. Если последний Job еще Running после FIO_JOB_COMPLETION_TIMEOUT, профиль завершается с result: fail, потому что fio output неполный и его нельзя честно сравнивать с завершенными прогонами.

Завершение Job фиксируется не только через финальный kubectl wait, но и в completed-jobs.txt. Это защищает тест от ложного fail, если Kubernetes успел удалить уже завершенную Job по ttlSecondsAfterFinished. В summary поэтому нужно смотреть jobs_completed_observed, jobs_completed_by_wait, jobs_deleted_after_completion, jobs_created_total и jobs_current_in_api. Нормальный случай для успешного профиля: jobs_completed_observed == jobs_created_total, jobs_failed: 0, pods_failed_like: 0, pods_evicted: 0.

Смотреть нужно не только summary.txt, но и all-fio-logs.txt / final-fio-logs.txt: там находятся fio IOPS, bandwidth, latency percentiles и disk stats. Runner дополнительно пишет fio-metrics-summary.tsv с pod-level IOPS, bandwidth и latency percentile, чтобы результат можно было быстро сравнить скриптом без ручного парсинга fio output. all-fio-logs.txt объединяет logs со всех scale snapshots и final snapshot, поэтому метрики не теряются, если ранний pod уже исчез из финального состояния.

Если в summary.txt есть jobs_active > 0, jobs_completed_observed < jobs_created_total, jobs_succeeded < jobs_current_in_api, pods_failed_like > 0, pods_evicted > 0 или result: fail, результат профиля невалиден для performance-сравнения. Если baseline_status: degraded или performance_valid: false, профиль мог технически пройти, но performance-цифры нельзя считать чистым baseline.

Для каждого snapshot'а fio runner сохраняет placement pod'ов в *-pod-placement.tsv. Это важно: без node placement нельзя объяснить разброс между pod'ами и нельзя проверить, сработал ли topologySpreadConstraints.

Ограничения, которые важно явно указывать в отчете:

• emptyDir не проверяет PVC/CSI storage class; для этого используется 5.1.stateful.
• topologySpreadConstraints просит scheduler распределять pods по kubernetes.io/hostname, но whenUnsatisfiable: ScheduleAnyway не блокирует запуск, если распределить невозможно.
• Наличие baseline warning'ов в kube-system, Cilium или CSI снижает доверие к performance-цифрам, даже если fio jobs завершились. FIO stage фиксирует Cilium degraded/not ready в snapshots, *-cilium-status.txt, degraded-details.txt и summary.txt, но не прерывает профиль только из-за состояния Cilium.

Основные параметры fio stage:

• FIO_INITIAL_JOBS - сколько Job создать на первом шаге, по умолчанию 1.
• FIO_STEP - шаг увеличения числа Job, по умолчанию 1.
• FIO_MAX_JOBS - верхняя граница Job на профиль, по умолчанию 4.
• FIO_STEP_SLEEP - время наблюдения после каждого scale-step, по умолчанию 90.
• FIO_FINAL_SLEEP - дополнительное ожидание перед финальным kubectl wait, по умолчанию 60.
• FIO_JOB_COMPLETION_TIMEOUT - timeout ожидания завершения каждой Job, по умолчанию 300s.
• FIO_CAPTURE_CILIUM_STATUS - сохранять cilium status в snapshot'ах, по умолчанию наследует CAPTURE_CILIUM_STATUS.
• FIO_STORAGE_TARGET - текстовая метка в summary, сейчас по умолчанию emptyDir.

Job manifests держат ttlSecondsAfterFinished: 3600, чтобы completed Job не удалялись раньше финального сбора логов и summary. Cleanup в конце профиля все равно удаляет Job и namespace load-test.

StatefulSet storage stage

StatefulSet stage проверяет PVC-backed storage, а не emptyDir. Он запускается для одного диска standard или high-iops, либо для обоих через STATEFUL_DISK=all. Все ресурсы создаются в namespace storage-test.

Порядок работы:

• baseline всегда запускает PVC и fio Job для выбранного storage class.
• full дополнительно запускает longrun fio Job перед scale-тестом.
• Scale-тест применяет StatefulSet fio-scale-*, где каждая реплика получает отдельный PVC через volumeClaimTemplates.
• Runner масштабирует StatefulSet по SCALE_STEPS и после каждого шага ждет kubectl rollout status sts/<name> --timeout=$ROLLOUT_TIMEOUT.
• После каждого успешного шага собираются StatefulSet/pod/PVC/events snapshots, kubectl top node, CSI pod placement и logs fio-scale-*.

Успешный baseline Job не означает, что scale прошел. Baseline проверяет один PVC и один fio Job, а scale одновременно нагружает scheduler, CSI provisioning, attach/mount path и ресурсы worker node.

Типовой capacity-stop для scale-теста выглядит так:

• часть pod'ов fio-scale-* остается Pending;
• соответствующие PVC остаются Pending с WaitForPodScheduled;
• describe pod показывает FailedScheduling с Insufficient cpu или Insufficient memory.

В таком случае причина не в том, что CSI не смог создать volume. PVC с WaitForFirstConsumer не начнет provisioning, пока scheduler не выберет node для pod. Поэтому Pending PVC нужно читать вместе с describe pod: если pod не scheduled из-за CPU/memory, это resource boundary кластера, а не storage provisioning failure.

Runner считает stage failed при:

• timeout rollout на любом scale-step;
• Pending, ContainerCreating, CrashLoopBackOff, Error, OOMKilled или Evicted у fio pod'ов;
• NotReady node во время теста;
• SystemOOM в событиях после старта stage;
• Cilium agent not ready;
• unhealthy CSI pod.

Основные артефакты:

• stateful-<disk>-<timestamp>.log - общий лог runner, snapshots, события, причины fail.
• fio-baseline-...log - output baseline fio Job с IOPS/BW/latency.
• fio-longrun-...log - output longrun fio Job, только для STATEFUL_MODE=full.
• stateful-<disk>-scale-pod-logs-<timestamp>.log - logs всех fio-scale-* pod'ов, которые удалось прочитать.

Важные параметры:

• STATEFUL_DISK=standard|high-iops|all - какой storage class тестировать.
• STATEFUL_MODE=baseline|full - baseline запускает baseline + scale, full запускает baseline + longrun + scale.
• SCALE_STEPS="1 2 4 6 8 12 16 20 24 32 40 60 80" - ступени scale-теста.
• ROLLOUT_TIMEOUT=300s - timeout каждого шага StatefulSet rollout.
• CLEANUP_ON_EXIT=true|false - удалять namespace storage-test в конце.

Если нужен чистый storage-only сигнал, подбирай SCALE_STEPS под реальные allocatable CPU/memory кластера. Иначе тест остановится на scheduler resource boundary раньше, чем покажет предел CSI или дисковой подсистемы.

Версии инструментов

Часть API-сценариев проверялась с kube-burner версии:

Version: 2.4.2
Git Commit: f3c72cc9b320f6827b1bc5f32d2e874cada46c6a
Build Date: 2026-03-04T17:12:21Z
Go Version: go1.23.12
OS/Arch: darwin amd64

Проверить локальную версию можно так:

kube-burner version

Быстрая проверка доступа к кластеру:

kubectl config current-context
kubectl get nodes
kubectl auth can-i get pods -A

Для Cilium-сценариев дополнительно проверь:

cilium status

Полный запуск

Из корня проекта:

./run-all-tests.sh

Если нужно, чтобы stateful-этап внутри общего прогона тоже включал longrun, запускай:

./run-all-tests.sh full

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

0. init cluster baseline: версии Kubernetes, node/runtime, kube-system, requests/limits системных workload'ов
1. 1.1 API create / patch / delete и api-soak-churn
2. 2.1 scheduler resource-guarded burst
3. 3.1 CPU until fail
4. 3.2 memory until fail
5. 3.3 fio IO-intensive
6. 4.1 Cilium network
7. 4.2 DNS / CoreDNS load
8. 5.1 StatefulSet storage; по умолчанию запускается baseline + scale для standard

По умолчанию между этапами выполняется cleanup тестовых namespace.

Выборочный запуск

Можно отключать отдельные этапы через переменные окружения.

Примеры:

RUN_FIO=false RUN_STATEFUL=false ./run-all-tests.sh
RUN_API=false RUN_SCHEDULER=false RUN_CPU=false RUN_MEM=true ./run-all-tests.sh
RUN_CILIUM=false RUN_STATEFUL=true ./run-all-tests.sh
RUN_CILIUM=false RUN_DNS=true RUN_STATEFUL=false ./run-all-tests.sh

Пример явного выбора первых этапов:

RUN_INIT=true \
RUN_API=true \
RUN_SCHEDULER=true \
RUN_CPU=false \
RUN_MEM=false \
RUN_FIO=false \
RUN_CILIUM=false \
RUN_DNS=false \
RUN_STATEFUL=false \
./run-all-tests.sh

Доступные флаги этапов:

• RUN_INIT=true|false
• RUN_API=true|false
• RUN_SCHEDULER=true|false
• RUN_CPU=true|false
• RUN_MEM=true|false
• RUN_FIO=true|false
• RUN_CILIUM=true|false
• RUN_DNS=true|false
• RUN_STATEFUL=true|false
• STATEFUL_DISK=all|standard|high-iops
• STATEFUL_MODE=baseline|full baseline = baseline + scale full = baseline + longrun + scale

По умолчанию stateful-этап в общем runner запускает baseline + scale для standard.

Запустить только init-стадию:

RUN_INIT=true \
RUN_API=false \
RUN_SCHEDULER=false \
RUN_CPU=false \
RUN_MEM=false \
RUN_FIO=false \
RUN_CILIUM=false \
RUN_DNS=false \
RUN_STATEFUL=false \
./run-all-tests.sh

Отключить init-стадию в любом выборочном запуске можно через RUN_INIT=false.

Запустить через общий runner только stateful standard (baseline + scale):

RUN_INIT=false \
RUN_API=false \
RUN_SCHEDULER=false \
RUN_CPU=false \
RUN_MEM=false \
RUN_FIO=false \
RUN_CILIUM=false \
RUN_DNS=false \
RUN_STATEFUL=true \
STATEFUL_DISK=standard \
./run-all-tests.sh

Запустить полный stateful-прогон для standard (baseline + longrun + scale):

RUN_API=false \
RUN_SCHEDULER=false \
RUN_CPU=false \
RUN_MEM=false \
RUN_FIO=false \
RUN_CILIUM=false \
RUN_STATEFUL=true \
STATEFUL_DISK=standard \
./run-all-tests.sh full

Запустить полный stateful-прогон для выбранного диска через env:

RUN_STATEFUL=true STATEFUL_DISK=high-iops STATEFUL_MODE=full ./run-all-tests.sh

Очистка ресурсов

Очистить тестовые namespace без запуска нагрузки:

./run-all-tests.sh --cleanup-only

Скрипт удаляет:

• api-load-*
• preload-kube-burner-*
• sched-test
• load-test
• cilium-test-*
• dns-test
• storage-test

Если нужно сохранить ресурсы после теста для ручной диагностики:

CLEANUP_ON_EXIT=false CLEANUP_BETWEEN_STAGES=false ./run-all-tests.sh

Полезные переменные

Наиболее полезные настройки запуска:

• CONTINUE_ON_ERROR=true - продолжать следующие этапы даже если один этап завершился неуспешно.
• K8S_READY_RETRIES=12 - увеличить количество preflight-проверок API.
• K8S_READY_SLEEP=15 - увеличить паузу между retry проверки API.
• KUBE_BURNER_RETRIES=5 - повторять kube-burner init при временных ошибках API/IAM.
• API_RESOURCE_GUARD_INTERVAL_SECONDS=10 - интервал проверки API stage на Pending pod с Insufficient cpu|memory.
• RUN_API_SOAK=true - запускать api-soak-churn после kube-burner API сценария.
• API_SOAK_AFTER_RESOURCE_LIMIT=true - запускать api-soak-churn, даже если kube-burner create уже уперся в resource limit.
• API_SOAK_DURATION_SECONDS=300 - длительность api-soak-churn.
• API_SOAK_ROUND_SLEEP=2 - пауза между round'ами churn-теста.
• API_SOAK_CONFIGMAPS=40, API_SOAK_SECRETS=40, API_SOAK_RBAC_OBJECTS=10, API_SOAK_SERVICES=10, API_SOAK_DEPLOYMENTS=10 - размер одного round'а api-soak-churn.
• SCHED_MAX_PODS=2000 - технический верхний предел количества маленьких pod'ов для scheduler burst.
• SCHED_SOFT_MAX_PODS=500 - безопасный soft-limit: при достижении этого количества runner фиксирует диагностику и останавливает scheduler stage; 0 отключает soft-limit.
• SCHED_BATCH_SIZE=50 - сколько pod'ов создавать за одну пачку.
• SCHED_GUARD_INTERVAL_SECONDS=5 - пауза между пачками и проверками scheduler guard.
• SCHED_STOP_ON_ANY_PENDING=true - останавливать scheduler stage при появлении любых Pending pod, даже если причина еще не стала явным Insufficient cpu|memory.
• SCHED_CPU_REQUEST=5m, SCHED_MEMORY_REQUEST=16Mi - маленькие requests для scheduler pod.
• SCHED_CPU_LIMIT=50m, SCHED_MEMORY_LIMIT=32Mi - маленькие limits для scheduler pod.
• INITIAL_GUARD_TIMEOUT_SECONDS=60 - сколько CPU/MEM runner ждет resource stop condition после initial scale перед продолжением.
• SCHEDULING_GUARD_INTERVAL_SECONDS=5 - интервал polling для CPU/MEM проверки Insufficient cpu|memory и memory pod failures.
• STEP=2, STEP_SLEEP=22 - дефолтный шаг и пауза scale для CPU/MEM saturation stages.
• WAIT_READY_TIMEOUT=180s - timeout rollout в CoreDNS load-тесте.
• MIN_READY_REPLICAS=1 - минимальное число Ready pod для продолжения CoreDNS load-теста после rollout timeout.
• FAIL_ON_DNS_ERRORS=true - считать DNS load-тест неуспешным, если есть fail запросы.
• CILIUM_CONNECTIVITY_ALLOW_FAILURE=false - не игнорировать non-zero exit у cilium connectivity test.
• CILIUM_STATUS_STRICT=false - не валить stage только из-за degraded Cilium baseline; failures самих сценариев все равно дают result=fail.
• CILIUM_WAIT_CLEANUP=true - ждать удаления cilium-test-* namespace между Cilium scenarios.
• CILIUM_CLEANUP_TIMEOUT_SECONDS=180 - timeout ожидания cleanup Cilium test namespaces.
• CILIUM_CLEANUP_POLL_SECONDS=5 - interval polling cleanup Cilium test namespaces.
• FIO_INITIAL_JOBS=1, FIO_STEP=1, FIO_MAX_JOBS=4 - ступени fio Job'ов в каждом профиле.
• FIO_STEP_SLEEP=90, FIO_FINAL_SLEEP=60 - паузы наблюдения между ступенями и перед финальной проверкой fio stage.
• FIO_JOB_COMPLETION_TIMEOUT=300s - timeout ожидания завершения каждого созданного fio Job перед финальным summary.
• FIO_CAPTURE_CILIUM_STATUS=true - сохранять cilium status, cilium pods и warning events в fio artifacts. Состояние Cilium может перевести baseline в degraded, но само по себе не прерывает fio-профиль.
• FIO_CAPTURE_DEGRADED_DESCRIBES=true - при degraded baseline сохранять краткие details по fio pods, cilium pods и warning events.
• ROLLOUT_TIMEOUT=300s - timeout одного шага StatefulSet scale-теста.
• SCALE_STEPS="1 2 4 8 16" - изменить список scale-шагов для storage runner.

Пример более осторожного запуска:

K8S_READY_RETRIES=12 \
K8S_READY_SLEEP=15 \
KUBE_BURNER_RETRIES=5 \
KUBE_BURNER_RETRY_SLEEP=30 \
ROLLOUT_TIMEOUT=300s \
./run-all-tests.sh

Артефакты

Каждый запуск сохраняет результаты в:

artifacts/YYYY-MM-DD-HH:MM:SS/

Output Example

artifacts/2026-05-18-18-00-00/
├── summary.txt
├── artifacts-api/
├── artifacts-scheduler/
├── artifacts-fio/
├── artifacts-cilium/
├── artifacts-dns/
└── artifacts-stateful/

Обезличенный пример общего summary находится в examples/summary.txt.

Основные файлы верхнего уровня:

• summary.txt - общий итог полного запуска: overall status, счетчики stages, статусы pass/fail/skip/interrupted, cleanup status и ссылки на stage artifacts.
• stage-summary.tsv - машинно-читаемый stage-level итог: stage, status, exit_code, cleanup, artifacts.
• run-all-tests.log - общий лог orchestration-скрипта.

Основные поддиректории:

• artifacts-init/ - нулевой этап диагностики кластера: версии Kubernetes/API, verbose /readyz, leases control-plane компонентов, node/runtime versions, kube-system pods, образы control-plane/Cilium/CSI/metrics-server, componentstatuses, последние events, requests/limits системных workload'ов и QoS pod'ов. Отсутствующие requests/limits записываются в kube-system-workload-resources-missing.txt, но не останавливают дальнейшие этапы.
• artifacts-api/ - kube-burner API тесты: workdir/ - рабочие файлы kube-burner, api-after-create.txt, api-after-patch.txt, api-after-delete.txt - snapshots после стадий. Если api-create упирается в Insufficient cpu|memory, runner останавливает kube-burner, пропускает api-patch/api-delete и пишет диагностику: api-create-resource-exhaustion-summary.txt, api-create-pods-wide.txt, api-create-failed-scheduling-events.txt, api-create-pending-pod-describes.txt. api-soak/ - 5-минутный churn-тест API server: round-манифесты и логи kubectl apply/delete, api-soak-summary.txt, api-soak-api-degradation-detected.txt, api-soak-resource-exhaustion-detected.txt, api-soak-events.txt, api-soak-pods-wide.txt.
• artifacts-scheduler/ - scheduler resource-guarded burst тест: scheduler-resource-limit.txt или scheduler-max-pods.txt - общие snapshot'ы кластера, scheduler-resource-limit-namespace.txt или scheduler-max-pods-namespace.txt - namespace-level диагностика, scheduler-resource-limit-summary.txt или scheduler-max-pods-summary.txt - итоговые счетчики pod и события FailedScheduling. При Insufficient cpu|memory дополнительно создаются: scheduler-resource-exhaustion-summary.txt, scheduler-pods-wide.txt, scheduler-failed-scheduling-events.txt, scheduler-pending-pod-describes.txt.
• artifacts-cpu/ - CPU saturation test: snapshots initial.txt, scale-*.txt, final.txt, общий run.log, Pending pod describes при Insufficient cpu|memory.
• artifacts-mem/ - memory saturation test: snapshots initial.txt, scale-*.txt, final.txt, общий run.log, pod describes при Insufficient memory, OOMKilled, Evicted или CrashLoopBackOff/Error.
• artifacts-fio/ - fio тесты по профилям: randread/, randwrite/, seqread/, seqwrite/, run.log - общий лог fio stage, <profile>/summary.txt - итоговый статус профиля и счетчики Job/Pod, <profile>/scale-*.txt и <profile>/final.txt - Kubernetes snapshot'ы, <profile>/scale-*-fio-logs.txt и <profile>/final-fio-logs.txt - fio output с IOPS/BW/latency, <profile>/fio-metrics-summary.tsv - машинно-читаемая pod-level выжимка из fio output, <profile>/*-pod-placement.tsv - распределение fio pod'ов по node, <profile>/*-cilium-status.txt - Cilium status и последние Cilium warning events, <profile>/degraded-details.txt - краткая диагностика при degraded baseline.
• artifacts-cilium/ - Cilium status, connectivity и perf: <scenario>/output.log - raw output Cilium CLI, <scenario>/summary.txt - PASS/FAIL сценария, cilium-diagnostics-*.txt - Cilium pods, Envoy pods, deploy/ds, cilium-dbg status --verbose, endpoint list, nodes PodCIDR/IP и CiliumNode objects, scenario-summary.tsv - машинно-читаемый итог каждого Cilium scenario, diagnostics-summary.tsv - машинно-читаемый итог degraded-проверок diagnostics snapshot'ов, summary.txt - итог result, baseline_status, degraded reasons и failures.
• artifacts-dns/ - DNS / CoreDNS load: run.log, summary.txt, initial.txt, during.txt, final.txt, *-dns-pods.log - логи DNS load pod'ов, *-node-local-dns-health.txt - health snapshot'ы node-local-dns, *-node-local-dns.log - логи node-local-dns, node-local-dns-summary.txt - итоговая оценка Ready/restarts/suspicious log lines.
• artifacts-stateful/ - StatefulSet storage по standard и high-iops. Здесь создаются: stateful-<disk>-<timestamp>.log - общий лог stateful runner, stateful-<disk>-scale-pod-logs-<timestamp>.log - kubectl logs для pod'ов fio-scale-*, fio-baseline-...log и fio-longrun-...log - логи job-сценариев.

Отдельные runner'ы

Если нужно запускать отдельные сценарии напрямую:

./0.init-cluster/run-init-tests.sh
./1.1.api-test/run-api-tests.sh
./1.1.api-test/run-api-soak-test.sh
./2.1.sheduler-test/run-scheduler-tests.sh
./3.1.test-cpu/run-cpu-until-fail.sh
./3.2.test-mem/run-mem-until-fail.sh
./3.3.fio/run-fio-tests.sh
./4.1.cilium/run-cilium-tests.sh
./4.2.dns/run-dns-tests.sh
./5.1.stateful/run-stateful-tests.sh standard
./5.1.stateful/run-stateful-tests.sh high-iops
./5.1.stateful/run-stateful-tests.sh standard full
./5.1.stateful/run-stateful-tests.sh high-iops full

Для низкоуровневой отладки можно запускать внутренние runner'ы напрямую:

./3.3.fio/run-all-fio-tests.sh fio-randread-fixed.yaml
./4.2.dns/run-coredns-load-test.sh
./4.2.dns/run-dns-tests.sh

Все standalone runner'ы принимают LOG_DIR. Если LOG_DIR не задан, они пишут в stage-local директорию вида artifacts-* рядом со своим скриптом.

Для scheduler standalone это означает:

2.1.sheduler-test/artifacts-scheduler/run.log

При запуске через общий runner scheduler-логи пишутся в:

artifacts/<timestamp>/artifacts-scheduler/run.log

Без full stateful-runner запускает baseline + scale. С full запускает baseline + longrun + scale.