Files
huncode 48049ee0ca
Build and deploy / deploy (push) Successful in 16s
revise June 2024 container orchestration articles
2026-07-31 16:01:21 +03:00

12 KiB
Raw Permalink Blame History

P76 · 2024-06 · Управление контейнерной нагрузкой — три самостоятельных прохода ревью

Рамка sidecar-пакета

  • Archive slugs: editorial-2024-06-practice-container-orchestration, editorial-2024-06-mechanism-container-orchestration, editorial-2024-06-field-container-orchestration.
  • Голос: M7, июнь 2024. Три материала начинают с конкретной ситуации и её цены, затем проходят «симптом → причина → проверка → действие». Каждый текст сопоставляет declaration, профиль управляемой нагрузки и смысл наблюдаемого поведения Pod, а не объявляет один YAML field универсальным ответом.
  • Созданы ровно пять sidecar-файлов: этот review, import-safe script и три локальные SVG. Overlay, README, очередь, articles.json, Git и чужие файлы не менялись; commit и push не выполнялись.
  • Fixture содержит только versioned fixed synthetic JS-объекты в памяти. Она не читает files, manifest, cluster, CI, network, HTTP, trace, telemetry или production и не изменяет их. Поле syntheticObservedPodBehavior явно помечено как embedded-fixed-js-object-not-telemetry; оно не является и не имитирует kubectl, CI output, metrics или production observation.

Проход 1 — источники, техника и модель

  • Историческая граница проверена 31.07.2026 по первичным Kubernetes материалам, доступным до июня 2024. Kubernetes v1.30: Uwubernetes, 17.04.2024 фиксирует публичный выпуск v1.30 до нужного месяца, но не подменяет версию или настройки чужой среды.
  • Resource Management for Pods and Containers, snapshot 07.03.2024 использован узко: scheduler опирается на request при размещении, kubelet и runtime применяют limit, а limit без request может стать request. Статьи не выдают limit за гарантированный throughput или фиксированное capacity number.
  • Horizontal Pod Autoscaling, snapshot 26.03.2024 подтверждает, что CPU utilization считается относительно request; если relevant request отсутствует, HPA не действует по этой метрике. В P76 это оформлено отдельной отрицательной веткой fixed-warmup-request-missing-v1, а не утверждением о поведении реального controller.
  • Pod Lifecycle and readiness gates, snapshot 24.05.2024 задаёт границу ContainersReady, Ready и custom readiness gate: для Ready нужны ready containers и все declared gates True. P76 не придумывает producer condition, feature gate, owner или recovery path для внешней системы.
  • Configure Liveness, Readiness and Startup Probes, snapshot 13.04.2024 использован для traffic semantics readiness и отделения startup от liveness/readiness. Текст не превращает readiness в root-cause diagnosis, telemetry, latency probe или dependency SLO.
  • Модель имеет один version marker synthetic-container-load-profile-v1, закрытый input contract и ровно три named fixed cases. Каждый case хранит declaredManifest, managedLoad и syntheticObservedPodBehavior как frozen literals. Plan повторно строит canonical report и сравнивает весь object; подмена verdict, observation или добавление внешнего поля отвергаются.
  • Самостоятельный model review проверяет отрицательные ветки для manifest file, cluster, CI, network, HTTP, trace и production fields; их нельзя передать как скрытый input. Rollback принимает только canonical synthetic review draft и возвращает явное отсутствие операций над manifest, cluster, CI, сетью, trace, telemetry и production.

Проход 2 — стиль, объём и голос

  • Основной текст без раздела источников по audit:draft: practice — 11 931 знак, mechanism — 11 997, field — 11 608. Все три значения находятся в целевом коридоре 9–12 тыс. и обязательном диапазоне 5 000–15 000 знаков.
  • Первые два абзаца practice разбирают цену copied request/limit/HPA values; mechanism — цену путаницы HPA signal и traffic eligibility и процент без denominator; field — цену трактовки Unready или CPU как немедленного scale action. Это конкретные учебные ситуации, не истории о реальном кластере.
  • Во всех статьях есть содержательная figure с alt и caption, рабочая table, исполнимый JS example, ordered route, ограничения, rollback и следующий проверяемый шаг. Код не содержит YAML, kubectl, HTTP request, CI command или telemetry fixture: только import-safe functions и fixed in-memory object literals.
  • M7 выдержан: короткие технические утверждения привязаны к request, limit, readiness, gate, metric, owner или evidence boundary. Нет обещаний, что HPA устраняет очередь, что readiness доказывает capacity, что limit даёт throughput, или что fixture подтверждает behaviour реальной среды.
  • После сокращения финальных редакторских проходов capacity curve не используется как прогноз: она прямо подписана fixed synthetic teaching data. Полевой материал называет blocker там, где отсутствует request или смысл readiness, вместо предложения «масштабировать на всякий случай».

Проход 3 — mobile visual, SVG safety и проверки

  • Три SVG отвечают на разные вопросы: pod-lifecycle отделяет profile, declaration и traffic eligibility; capacity-curve различает request-relative HPA target и CPU limit; readiness-gate отделяет Ready от отдельного CPU metric. Во всех подписях сказано, что это teaching model, а не cluster, CI или telemetry data.
  • xmllint --noout принял все три SVG. Safety scan не нашёл script, foreignObject, href/src, event-handler attributes, external URL, data: или javascript:. Изображения статичны, не принимают input и не загружают external resource.
  • Sharp реально отрендерил SVG на ширине 375 px: pod lifecycle — 375×552, capacity curve — 375×547, readiness gate — 375×547. Все три render просмотрены: заголовки, cards, arrows, labels и footer читаются; в capacity curve длинная mobile callout была разбита на две строки до финальной проверки.
  • Фактические финальные результаты: node --check web/scripts/upgrade-2024-06.mjs — PASS; node web/scripts/upgrade-2024-06.mjs --verify-fixture — PASS fixture: 32/32 assertions; cd web && npm run audit:draft -- scripts/upgrade-2024-06.mjs — PASS для трёх slug и import-safe CLI/export comparison.
  • npm run audit:draft вывела три non-fatal предупреждения существующей user npm config: store-dir, cache-dir и public-hoist-pattern. Команда завершилась с code 0; эти предупреждения не относятся к P76 и не менялись.
  • Sidecar намеренно не интегрирован в overlay или archive: P76 не выполняет deploy, cluster analysis, CI, HTTP, trace collection или production change. Реальная проверка требует отдельного разрешения, изолированной scope, owner-а, evidence source, stop condition и rollback plan.

Выпуск после трёх независимых проходов

  1. Факты и техника. Редактор повторно проверил неизменяемые первичные snapshots через raw GitHub: resource request используется scheduler при выборе Node, limit применяется kubelet/runtime, а limit без request копируется как request; HPA определяет CPU utilization относительно request и не действует по этой метрике без relevant request; readiness/readiness gates и startup probe имеют описанные в статье границы. Публичный релиз Kubernetes v1.30 от 17.04.2024 дополнительно подтвердил историческую границу. Проверены node --check, fixture — PASS 32/32.
  2. Редактура и голос. Повторный проход удалил из публичной прозы служебное имя партии P76: теперь читатель видит «учебную модель» и «учебный набор», а не внутреннюю маркировку. Цепочка «симптом → причина → проверка → действие», стоимость ошибки и ограничения сохранены. После правки audit:draft подтвердил объёмы: practice — 11 953, mechanism — 12 023, field — 11 662 знака.
  3. Визуал и выпуск. Все три SVG прошли XML и safety scan, затем были заново отрендерены Sharp на ширине 375 px и просмотрены: подписи, стрелки, таблицы и контраст читаемы. После подключения overlay audit:articles подтвердил для каждого slug один figure, одну table и один code example; registry содержит 223 уникальные ревизии. npm run build завершился успешно: 374 статические страницы.

В выпуск включены только пять файлов июня, обновления registry/production README и редакционный стандарт. Изменения пользователя, черновики других месяцев и исходный articles.json в этот пакет не входят.