Модуль 3.4: Моніторинг застосунків

Складність: [ШВИДКИЙ] — базові команди, концептуальне розуміння

Час на проходження: 25–30 хвилин

Передумови: Модуль 3.1 (проби), розуміння запитів і лімітів ресурсів

Результати навчання

Після завершення цього модуля ви зможете:

Діагностувати тиск на ресурси Подів і Нод за допомогою kubectl top pods, kubectl top nodes, відсортованого виводу та метрик на рівні контейнерів.
Порівнювати поточне споживання CPU й пам’яті із запитами та лімітами ресурсів, щоб вирішити, чи має робоче навантаження здоровий запас.
Перевіряти доступність Metrics Server і пояснювати, які дані він може й не може надати для кластерів Kubernetes 1.35.
Оцінювати на основі спостережених метрик, чи потребує запущений застосунок налаштування запитів, налаштування лімітів, зміни кількості реплік чи глибшого дослідження самого застосунку.

Чому цей модуль важливий

Гіпотетичний сценарій: ви розгортаєте невеликий API, який у середовищі розробки виглядав справно, але під час пробного іспиту Под починає відповідати повільно після сплеску трафіку. Логи не показують винятку, проба готовності (readiness) усе ще проходить, а kubectl get pods показує робоче навантаження зі статусом Running. У цей момент початківець часто продовжує читати логи, бо логи здаються конкретними, але справжнє питання полягає в тому, чи вичерпує контейнер процесорний час, чи наближається до знищення через пам’ять, чи просто чекає на зовнішню залежність, яку метрики ресурсів не пояснять.

Моніторинг дає вам швидкий оглядовий зріз, що заповнює прогалину між «Под існує» та «застосунок здоровий». Логи пояснюють події вже після того, як застосунок їх записав, проби пояснюють, чи має Kubernetes спрямовувати трафік або перезапускати контейнер, а метрики пояснюють, скільки саме CPU й пам’яті робоче навантаження споживає просто зараз. На іспиті CKAD від вас не очікують, що ви спроєктуєте повноцінну інфраструктуру Prometheus, але очікують, що ви скористаєтеся kubectl top, правильно витлумачите числа, не плутаючи їх із запитами чи лімітами, та вирішите, що саме перевіряти наступним кроком.

Аналогія з панеллю приладів корисна, бо вона тримає масштаб чесним. Панель приладів автомобіля може повідомити, що рівень пального низький або температура двигуна висока, але вона не розповість про хімічний склад пального чи повну історію обслуговування. Моніторинг ресурсів Kubernetes схожий: kubectl top швидкий, сфокусований і навмисно поверхневий. Він підкаже, чи заслуговує на увагу споживання ресурсів Ноди, Пода або контейнера, а потім ви поєднуєте цей сигнал з описами Подів, подіями, пробами, налаштуваннями ресурсів і знанням про застосунок.

Цей модуль формує операційну звичку, що стоїть за цією іспитовою навичкою. Ви перевірите, чи доступний Metrics Server, прочитаєте метрики Нод і Подів, зануритеся в контейнери всередині Пода, порівняєте поточне споживання з оголошеними ресурсами та оберете наступну дію, коли числа виглядають незатишно. Мета не в тому, щоб запам’ятати одну команду; мета — побудувати надійну першу реакцію на той момент, коли застосунок виглядає живим, але почувається нездоровим.

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

Metrics Server: джерело даних за `kubectl top`

Сам по собі Kubernetes не зберігає в основному API зручної історії споживання CPU й пам’яті, до якої можна було б робити запити. Kubelet на кожній Ноді може показувати поточне споживання ресурсів, але kubectl top потребує API метрик ресурсів, щоб агрегувати й подавати ці дані. Metrics Server — поширений легкий додаток, який опитує kubelet’и (виконує скрейпінг), тримає недавні семпли в пам’яті та подає поточні метрики CPU й пам’яті через metrics.k8s.io.

Для кандидата CKAD важлива ментальна модель така: Metrics Server — це інфраструктура кластера, а не контейнер застосунку, яким ви зазвичай керуєте під час іспитового завдання. Якщо API метрик ресурсів відсутній, kubectl top не може вигадати дані з нічого, а рішення HPA на основі CPU чи пам’яті також втрачають своє звичне джерело метрик. У керованому кластері чи в іспитовому середовищі його часто встановлено заздалегідь; у локальному ж кластері вам, цілком імовірно, доведеться встановити або увімкнути його самостійно, перш ніж моніторинг ресурсів узагалі запрацює.

# Check for metrics-server deployment
kubectl get deployment -n kube-system metrics-server

# Or check if `top` works
kubectl top nodes

Коли kubectl top nodes виконується успішно, ви підтвердили більше, ніж просто доступність команди. Ви підтвердили, що шар агрегації API здатен подавати метрики, що Metrics Server має достатньо свіжі дані про Ноди й що ваш поточний користувач має право читати ендпоінт метрик ресурсів. Коли ж команда зазнає невдачі з повідомленням на кшталт Metrics API not available, не вважайте, що робоче навантаження лишилося без моніторингу через несправність застосунку; спершу перевірте сам додаток кластера та свої дозволи.

Metrics Server надає поточне споживання CPU й пам’яті на кожну Ноду, поточне споживання CPU й пам’яті на кожен Под та стандартні дані CPU чи пам’яті, які використовує Horizontal Pod Autoscaler. Він не надає історичних графіків, лічильників рівня застосунку, перцентилів затримки, частоти запитів, запитів PromQL чи власних бізнес-метрик. Ця межа має значення, бо kubectl top може показати, що пам’ять зросла, але не може сказати, який ендпоінт, черга, орендар чи ключ кешу спричинили це зростання.

Зробіть паузу й передбачте: якщо kubectl top nodes зазнає невдачі, а kubectl get pods працює, що це говорить про API-сервер Kubernetes порівняно з API метрик? API-сервер може бути доступним, тоді як агрегований API на кшталт metrics.k8s.io недоступний, тож правильною реакцією буде відокремити «доступ до об’єктів кластера працює» від «метрики ресурсів подаються».

Metrics Server бере семпли достатньо часто для швидкого тріажу, але це не криміналістична база даних. Оскільки він тримає недавні показники в пам’яті, перезапуск втрачає локальний історичний контекст, а короткий сплеск може зникнути ще до того, як ви на нього подивитеся. Це прийнятно для робочого процесу CKAD, бо іспитова навичка — це діагностика в теперішньому часі: знайти гарячий Под, порівняти його поточне споживання з оголошеними ресурсами та зробити практичне коригування чи скласти план дослідження.

Є також корисна деталь щодо таймінгу, яку варто пам’ятати, коли ви створюєте Под і одразу запитуєте метрики. Под може стати Ready ще до того, як Metrics Server опитає kubelet і опублікує для нього семпл, тож свіжий Под може якийсь час бути відсутнім у kubectl top або показувати беззмістовне значення. Очікування короткого інтервалу — це не забобон; воно відображає цикл скрейпінгу й утримує вас від того, щоб діагностувати щойно створений Под як зламаний, коли конвеєр метрик просто ще не наздогнав.

Якщо Деплоймент Metrics Server існує, але kubectl top усе одно зазнає невдачі, шлях відмови належить конвеєру метрик, а не вашому застосунку. У реальному кластері адміністратор міг би оглянути APIService metrics.k8s.io, логи Metrics Server, зв’язність із kubelet і налаштування сертифікатів. В іспитовому завданні CKAD важливіший хід — точно сформулювати залежність і не вигадувати висновки про ресурси з відсутніх даних.

Читання метрик Нод, Подів і контейнерів

Починайте моніторинг із найширшого рівня, який може відповісти на ваше нагальне питання. Метрики Нод допомагають вирішити, чи є в кластера широкий тиск на потужність, тоді як метрики Подів допомагають визначити робоче навантаження, що споживає ресурси в просторі імен. Метрики контейнерів — це наступний шар, коли Под має більше одного контейнера, бо запити та ліміти ресурсів задаються на контейнерах, навіть якщо kubectl top pods спершу подає агрегований вигляд Пода. Kubernetes 1.35 також підтримує необов’язкові ресурси на рівні Пода через spec.resources, коли увімкнено feature gate PodLevelResources, але в типовому випадку CKAD kubectl top pods --containers досліджує саме налаштування на рівні контейнера.

# All nodes
kubectl top nodes

# Output:
# NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
# node-1     250m         12%    1024Mi          25%
# node-2     500m         25%    2048Mi          50%

Вивід по Нодах корисний, коли ви підозрюєте проблему з плануванням або зі спільною потужністю. Нода з високим споживанням пам’яті може не мати достатньо місця для нових Подів, а Нода з високим споживанням CPU може запускати чутливі до затримок навантаження, які конкурують за час. Відсотки у виводі по Нодах за замовчуванням базуються на allocatable Ноди, тож вони відповідають на інше питання, ніж споживання Пода: «Наскільки завантажена ця машина?», а не «Наскільки близько цей контейнер до свого налаштованого ліміту?». Передайте --show-capacity, щоб порівнювати з повною потужністю Ноди.

# All pods in current namespace
kubectl top pods

# All pods in all namespaces
kubectl top pods -A

# Pods in specific namespace
kubectl top pods -n kube-system

# Sort by CPU
kubectl top pods --sort-by=cpu

# Sort by memory
kubectl top pods --sort-by=memory

# Specific pod
kubectl top pod my-pod

Вивід по Подах — це робоча конячка іспиту, бо більшість завдань CKAD є завданнями застосунків у межах простору імен. Сортування за CPU швидко виводить на поверхню завантажену репліку, а сортування за пам’яттю — навантаження, що наближаються до свого обсягу пам’яті. Прапорець -A корисний у реальній експлуатації, але в іспитових завданнях вам слід пам’ятати про контекст простору імен, бо вам може бути непотрібно — або недозволено — перевіряти кожен простір імен.

Зробіть паузу й передбачте: kubectl top pods показує Под, що використовує 450m CPU з лімітом 500m, та інший Под, що використовує 240Mi пам’яті з лімітом 256Mi. Який із них у більш безпосередній небезпеці й чому? Под, обтяжений CPU, може зазнавати тротлінгу й бути повільним, але Под, обтяжений пам’яттю, ближчий до жорсткого знищення, бо перевищення пам’яті не згладжується так, як це можливо з процесорним часом.

# Show metrics per container
kubectl top pods --containers

# Output:
# POD          NAME      CPU(cores)   MEMORY(bytes)
# my-pod       app       100m         128Mi
# my-pod       sidecar   10m          32Mi

Вивід на рівні контейнера запобігає поширеній діагностичній помилці в багатоконтейнерних Подах. Якщо контейнер застосунку та sidecar спільно використовують Под, агрегований показник Пода може приховати, який саме контейнер насправді споживає ресурси. Ця відмінність має значення, бо запити ресурсів, ліміти, поведінка перезапуску та виправлення на рівні образу — це рішення, специфічні для контейнера, а не загальні здогади на рівні Пода.

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

Селектори також роблять ваші нотатки й іспитові команди легшими для обґрунтування. Команда на кшталт kubectl top pods -l app=myapp прямо описує межу робочого навантаження, тоді як візуальне сканування довгого списку Подів залежить від імен, пам’яті та уваги під тиском часу. Ця різниця має значення під час усунення несправностей, бо першу команду може повторити інший інженер, і вона має повертати той самий набір цілей, доки мітки правильні.

# Node status
kubectl top nodes

# Pod status sorted by resource usage
kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

Ця швидка перевірка стану навмисно коротка, бо моніторинг має зменшувати невизначеність, а не створювати новий ритуал дослідження щоразу. Спершу спитайте, чи є Ноди під широким тиском, потім спитайте, які Поди споживають найбільше CPU чи пам’яті. Якщо відповідь вказує на один Под, занурюйтеся глибше; якщо кожен Под малий, але кожна Нода заповнена, ви маєте справу з розподілом потужності, а не з одним зламаним застосунком.

# Top CPU consumers
kubectl top pods -A --sort-by=cpu --no-headers | head -10

# Top memory consumers
kubectl top pods -A --sort-by=memory --no-headers | head -10

Фільтр head — практичний спосіб перетворити галасливий вивід кластера на короткий список. У реальному інциденті ви поєднали б це з перевірками власника й простору імен перед тим, як щось змінювати, бо найбільший споживач може бути очікуваною пакетною роботою, а не несправним сервісом. У вправі CKAD це допомагає швидко знайти Под, на який завдання намагається звернути вашу увагу.

Відсортований вивід найкорисніший, коли ви вже знаєте, який вимір ресурсу відповідає симптому. Якщо симптом — це затримка під навантаженням, сортування за CPU є природним першим проходом, бо тротлінг і нестача CPU можуть розтягувати обробку запитів. Якщо симптом — це цикли перезапусків, то сортування за пам’яттю та описи Подів заслуговують на пріоритет, бо контейнер може раптово загинути після перетину ліміту пам’яті.

# See which container in pod uses most resources
kubectl top pods --containers -l app=myapp

Перш ніж запускати це, який вивід ви очікуєте, якщо основний контейнер здоровий, але sidecar для логування зациклюється? Слід очікувати, що показник на рівні Пода виглядатиме високим, а вивід на рівні контейнера зосередить більшість цього споживання в sidecar. Це передбачення дає вам гіпотезу, яку можна перевірити, перш ніж ви почнете змінювати ресурси Деплойменту.

Тлумачення CPU, пам’яті та одиниць виміру

Числа у kubectl top компактні, тож перша навичка — перекладати одиниці виміру без зайвих роздумів. Значення CPU в Kubernetes вимірюються в ядрах і міліядрах, де 1000m означає одне повне ядро CPU, а 100m означає одну десяту ядра. Значення пам’яті зазвичай відображаються в двійкових одиницях, як-от Mi та Gi, хоча в маніфестах можуть також траплятися десяткові одиниці, як-от M.

Значення	Що означає
`1`	1 повне ядро CPU
`1000m`	1000 міліядер = 1 ядро
`500m`	0,5 ядра (половина ядра)
`100m`	0,1 ядра (10% ядра)

Споживання CPU слід читати як попит на процесорний час, а не як купу пам’яті, що поступово заповнюється. Контейнер, що використовує 450m CPU, у цей момент намагається спожити майже половину ядра, і якщо його ліміт становить 500m, він може бути близько до тротлінгу — тобто примусового обмеження частоти процесорного часу. Тротлінг CPU зазвичай спричиняє затримку, повільнішу роботу чи пропущені дедлайни, але сам контейнер не знищується лише тому, що захотів більше CPU, ніж дозволяв ліміт; йому просто видають менше часу.

Значення	Що означає
`128Mi`	128 мебібайтів
`1Gi`	1 гібібайт (1024 Mi)
`256M`	256 мегабайтів

Споживання пам’яті поводиться інакше, бо це обсяг, який утримує процес у конкретний момент. Якщо контейнер перевищує свій ліміт пам’яті, ядро може завершити його через знищення з браку пам’яті (out-of-memory), і Kubernetes повідомить про попередній стан, коли ви описуватимете Под командою describe. Саме тому Под на рівні 94 відсотків свого ліміту пам’яті почувається небезпечнішим, ніж Под на рівні тих самих 94 відсотків свого ліміту CPU, навіть якщо обидва числа однаково заслуговують на увагу.

NAME        CPU(cores)   CPU%     MEMORY(bytes)   MEMORY%
my-pod      100m         10%      256Mi           12%

У цьому виводі 100m означає, що Под використовує 100 міліядер, або приблизно 10 відсотків одного ядра CPU. 256Mi означає, що він наразі використовує 256 мебібайтів пам’яті. Відсотки у виводі по Нодах за замовчуванням стосуються allocatable Ноди (--show-capacity використовує повну потужність), тоді як вивід по Подах найкорисніший, коли ви порівнюєте абсолютні значення із запитами та лімітами навантаження.

Ключова звичка — уникати ставлення до кожного високого числа як до однакового різновиду надзвичайної ситуації. Високе CPU може пояснити повільність, накопичення черги чи тротлінг, але також може бути очікуваним під час короткого пакетного завдання. Висока пам’ять біля ліміту може пояснити перезапуски, події OOMKilled і раптову загибель процесу, і вона часто потребує або більшого запасу, або механізмів керування пам’яттю на рівні застосунку.

Відсотки CPU можуть бути особливо оманливими, якщо ви забудете, відносно чого вони. Відсотки по Нодах відносні до allocatable Ноди за замовчуванням (або до повної потужності з --show-capacity), тоді як значення CPU по Подах корисніші у вигляді міліядер, які ви порівнюєте із запитом і лімітом контейнера. Коли є сумніви, спершу довіряйте абсолютній одиниці, а потім використовуйте відсотки лише як швидкий сигнал потужності для вигляду по Нодах.

resources:
  requests:
    cpu: "100m"      # Guaranteed minimum
    memory: "128Mi"
  limits:
    cpu: "500m"      # Maximum allowed
    memory: "256Mi"

Запити та ліміти відповідають на інші питання, ніж поточне споживання. Запит повідомляє планувальнику, скільки потужності зарезервувати для розміщення та рішень про якість обслуговування. Ліміт повідомляє середовищу виконання максимум, який контейнеру дозволено спожити, причому CPU й пам’ять застосовують цей максимум по-різному.

Ця відмінність також впливає на те, як Kubernetes класифікує Поди для якості обслуговування. Под без запитів і без лімітів обробляється інакше, ніж Под, контейнери якого мають однакові запити й ліміти, і ці класифікації впливають на вибір витіснення під тиском на Ноду. Вам не потрібно перераховувати кожен клас для цього модуля, але слід усвідомлювати, чому чесні запити мають значення, навіть коли навантаження не біля ліміту.

# Actual usage from metrics
kubectl top pod my-pod
# CPU: 50m, Memory: 100Mi

# Interpretation:
# - Using 50m CPU (within 100m request, well under 500m limit)
# - Using 100Mi RAM (within 128Mi request, under 256Mi limit)

Цей Под наразі використовує менше CPU, ніж запитано, і менше пам’яті, ніж запитано, тож він має комфортний запас. Це не доводить, що він завжди буде здоровим, бо kubectl top — це дані поточного стану, а не історичні докази. Проте це говорить вам, що безпосередній ліміт ресурсу, ймовірно, не є причиною поточного симптому в той момент, коли ви робили вимір.

Зупиніться й подумайте: Под має запити ресурсів cpu: 100m, memory: 128Mi, але kubectl top показує фактичне споживання cpu: 50m, memory: 300Mi, і Под не зазнав OOMKilled. Як це можливо? Запит — це не стеля, тож пам’ять може зрости вище запиту; лише ліміт пам’яті створює жорсткий максимум, а Под може не мати ліміту пам’яті або мати ліміт вище 300Mi.

# Check if pods are near their limits
kubectl top pods

# Compare with defined limits
kubectl get pod my-pod -o jsonpath='{.spec.containers[*].resources}'

Це порівняння — найменший корисний цикл дослідження ресурсів. Спершу спостерігайте поточне споживання, потім перевірте оголошену політику ресурсів, а тоді вирішіть, чи проблема в замалій запитаній потужності, у затісному ліміті, у застосунку, що споживає несподівані ресурси, чи в навантаженні, якому потрібно більше реплік. Числа самі по собі не є рішенням; вони є доказами, які ви використовуєте, щоб обрати наступну команду.

Порівняння споживання із запитами та лімітами

Найпоширеніша помилка моніторингу — порівнювати не те, що треба. Под, що використовує більше за свій запит, не є автоматично нездоровим, бо запити — це обіцянки планування, а не стелі часу виконання, які не можна перетнути. Однак Под біля свого ліміту пам’яті може бути буквально за одну алокацію від завершення, а Под біля свого ліміту CPU може зазнавати тротлінгу настільки сильного, що не вкладається в очікування щодо часу відповіді.

Уявіть запити як бронювання столика, а ліміти — як час закриття ресторану. Бронювання означає, що ресторан запланував для вас місце, але це аж ніяк не означає, що ви не можете замовити більше їжі, якщо на кухні ще є потужність. Час закриття — зовсім інша річ: щойно він настає, обслуговування припиняється незалежно від того, чи хотіли ви замовити ще одну страву.

Для CPU низькі запити можуть спричинити тиск на планування та поведінку «галасливого сусіда», бо планувальник розмістив забагато ненажерливих навантажень на одній Ноді. Затісні ліміти CPU можуть спричинити тротлінг, коли застосунку потрібні короткі сплески. Для пам’яті низькі запити можуть зробити розміщення оптимістичним, тоді як затісні ліміти створюють раптові збої, коли процес перетинає межу.

Споживання ресурсів нижче запиту зазвичай означає, що контейнер має достатньо зарезервованої потужності для своєї поточної поведінки. Споживання вище запиту, але нижче ліміту означає, що контейнер позичає доступну потужність Ноди і все ще може бути прийнятним, якщо навантаження сплескове. Споживання біля ліміту означає, що вам слід дослідити симптоми, події та поведінку застосунку, перш ніж вирішувати, чи піднімати ліміт, налаштовувати застосунок чи змінювати розподіл трафіку.

Фраза «позичає доступну потужність» важлива, бо вона пояснює і гнучкість, і ризик. Kubernetes дозволяє контейнеру використовувати більше за свій запит, коли Нода має місце, що робить сплески ефективними. Ризик полягає в тому, що багато контейнерів можна запланувати на основі запитів, нижчих за їхнє реальне стале споживання, через що Нода стає переповненою, коли кілька навантажень одночасно стають активними.

Використовуйте kubectl describe pod, коли метрики вказують на проблему з пам’яттю, бо опис може показати кількість перезапусків, причину останнього завершення та події. Поточне значення пам’яті 220Mi проти ліміту 256Mi незатишне, але попередній стан OOMKilled змінює діагноз із «ризику» на «вже сталося». Моніторинг знаходить тиск; стан Пода підтверджує, чи Kubernetes уже діяв.

Сценарій вправи: Деплоймент із трьома репліками має один Под, що використовує 400m CPU, тоді як два інші використовують 50m. Якщо ліміту CPU немає, гарячий Под може робити сплески настільки, наскільки дозволяє Нода, і безпосередній ризик — конкуренція за ресурси з іншими навантаженнями. Якщо є ліміт 500m, гарячий Под близький до тротлінгу, і вам слід дослідити баланс трафіку, прив’язку сесій, тривалі запити чи нерівномірний прогрів кешу.

Оцінюючи, чи змінювати запити чи ліміти, уникайте використання єдиного семпла як єдиного доказу, якщо тільки іспитове завдання навмисно не просте. Один показник kubectl top повідомляє вам точку в часі, тоді як безпечна політика ресурсів навантаження має відображати очікувану сталу поведінку та сплески. У завданнях CKAD ви все одно можете зробити цілеспрямовану зміну, коли вправа дає чіткий симптом, але професійна звичка — відрізняти теперішній тріаж від довгострокового планування потужності.

Для налаштування запитів спитайте, чи мав планувальник чесну картину навантаження. Якщо Под зазвичай працює на рівні 300Mi, але запитує 64Mi, кластер може перепаковувати Ноди, навіть якщо Под виживає в тихі періоди. Підвищення запиту не змусить застосунок споживати менше пам’яті, але зробить розміщення правдивішим і може зменшити несподіванки, коли кілька Подів стають активними разом.

Для налаштування лімітів спитайте, чи захищає межа кластер, чи карає нормальну поведінку. Ліміт пам’яті нижче звичайного робочого набору створює ризик перезапуску, тоді як ліміт CPU нижче нормального сплеску створює ризик затримки. Цілковите вилучення лімітів не є автоматично кращим, бо один некерований контейнер може тоді агресивно конкурувати з іншими навантаженнями на тій самій Ноді.

Той самий принцип стосується пам’яті. Якщо сервіс на Java з кешем використовує 240Mi з ліміту 256Mi, підвищення ліміту може зупинити безпосередні перезапуски, але може не виправити необмежений кеш. Правильна рекомендація часто має два шари: створити достатній запас для стабільності, а потім дослідити чи налаштувати застосунок так, щоб зростання пам’яті було навмисним, а не випадковим.

Розібраний робочий процес моніторингу

Надійний робочий процес моніторингу починається з вузького питання, а не зі звички запускати команду. Якщо користувачі повідомляють про повільність, спитайте, чи обмежене навантаження по CPU, обмежене по пам’яті, нерівномірно завантажене, чи заблоковане чимось, чого метрики не бачать. Це формулювання допомагає вирішити, що перевіряти далі — Ноди, Поди, контейнери, специфікації ресурсів, події чи логи.

Почніть із перевірки тиску на Ноди, бо насичена Нода може змусити здорові Поди виглядати погано. Якщо одна Нода має набагато вище споживання CPU чи пам’яті, ніж її сусіди, проблема може бути в розміщенні, локальному гарячому навантаженні чи браку запасної потужності кластера. Якщо Ноди виглядають справно, перейдіть до виводу на рівні Подів і сортуйте за ресурсом, що відповідає симптому.

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

Далі порівняйте гарячий Под із його оголошеними ресурсами. Под, що використовує 80m CPU з лімітом 500m, навряд чи зазнає тротлінгу CPU, навіть якщо він є найбільшим споживачем CPU в тихому просторі імен. Под, що використовує 480m CPU з лімітом 500m, — це інша історія, особливо якщо затримка зростає або під навантаженням з’являються збої готовності.

Для багатоконтейнерних Подів переходьте від загальних показників Пода до розбивки по контейнерах, перш ніж змінювати Деплоймент. Sidecar’и, проксі, відправники логів і контейнери service mesh можуть споживати більше за очікуване, а шлях їхнього налаштування відрізняється від основного застосунку. Якщо sidecar гарячий, підвищення ліміту основного контейнера не вирішить причину.

Нарешті, вирішіть, чи достатньо метрик для завдання. Метрики ресурсів можуть обґрунтувати зміну запитів, лімітів чи реплік, але вони не можуть пояснити кожен симптом застосунку. Якщо CPU й пам’ять виглядають здорово, переходьте до логів, подій, проб, ендпоінтів, мережевої політики, маршрутизації сервісів чи метрик рівня застосунку, замість того щоб намагатися змусити kubectl top відповісти на питання поза межами його сфери.

Саме тут судження старшого інженера лишається практичним, а не філософським. Сильна реакція моніторингу не означає запуску кожної відомої вам команди підряд; вона означає зупинку, щойно докази вказують геть від тиску на ресурси, та свідомий, обдуманий вибір наступного інструмента. На іспиті ця дисципліна заощаджує час, бо ви уникаєте редагування маніфестів, які не мають жодного стосунку до спостереженого збою.

Наступна візуалізація тримає зв’язок «запит–ліміт» на видноті, поки ви ухвалюєте ці рішення. Вона навмисно проста: нижче запиту — комфортно, вище запиту — позичена потужність, біля ліміту — попередження, а понад лімітом пам’яті стає шляхом до знищення. CPU відрізняється в застосуванні, але та сама візуальна звичка допомагає порівнювати поточне споживання з оголошеними межами.

┌─────────────────────────────────────────────────────────────┐
│                  Resource Usage Levels                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Memory Usage Example:                                      │
│                                                             │
│  |                                                          │
│  |  ▓▓▓▓▓▓▓▓▓▓ Limit: 256Mi (max before OOMKill)           │
│  |                                                          │
│  |  ████████ Request: 128Mi (guaranteed)                   │
│  |                                                          │
│  |  ████ Current: 64Mi (from kubectl top)                  │
│  |                                                          │
│  └──────────────────────────────────────────────           │
│                                                             │
│  Status: Healthy (usage < request)                         │
│                                                             │
│  ─────────────────────────────────────────────             │
│                                                             │
│  |                                                          │
│  |  ▓▓▓▓▓▓▓▓▓▓ Limit: 256Mi                                │
│  |                                                          │
│  |  ████████████████ Current: 200Mi (from kubectl top)     │
│  |                                                          │
│  |  ████████ Request: 128Mi                                │
│  |                                                          │
│  └──────────────────────────────────────────────           │
│                                                             │
│  Status: Warning (usage > request, approaching limit)       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Розібраний результат навмисно скромний, бо й більшість перемог моніторингу скромні. Вам не потрібно будувати цілий дашборд, щоб знати, що Под, який використовує 200Mi з ліміту пам’яті 256Mi, заслуговує на увагу. Вам потрібно лише помітити цей зв’язок, підтвердити, чи вже сталися перезапуски або відповідні події, та обрати, чи коригувати ресурси, чи спершу дослідити поведінку самого застосунку.

Сфера CKAD та операційні межі

Сфера моніторингу CKAD практична й орієнтована на командний рядок. Вам слід знати, як користуватися kubectl top, визначати, чи доступний Metrics Server, читати одиниці CPU й пам’яті, сортувати Поди за споживанням ресурсів і занурюватися в контейнери. Вам також слід розуміти, що моніторинг — це один сигнал спостережуваності серед логів, проб, подій і описів, а не їхня заміна.

Чого вам не потрібно для цього модуля, то це повного налаштування Prometheus, проєктування дашбордів Grafana, написання запитів PromQL, конфігурації адаптера власних метрик чи архітектури довгострокового зберігання. Ці теми мають значення у промислі, але вони лежать поза швидким робочим процесом моніторингу ресурсів, на якому наголошує CKAD. Дотримання чіткості цієї межі допомагає витрачати іспитовий час на команди, що насправді вирішують завдання.

У Kubernetes 1.35 та сусідніх поточних версіях робочий процес метрик ресурсів лишається зосередженим навколо API метрик і kubectl top. Вивід команди може трохи відрізнятися залежно від кластера, а локальні середовища іноді потребують додаткових прапорців Metrics Server для TLS kubelet чи переваг адреси. Звичка тлумачення лишається стабільною: спершу поточне споживання, потім оголошена політика ресурсів, на третьому місці — специфічне для симптому продовження.

Вам також слід знати, коли kubectl top недостатньо. Якщо Под повільний при низькому CPU та низькій пам’яті, вузьким місцем можуть бути введення-виведення, DNS, зовнішній сервіс, блокування в застосунку, збирання сміття чи погано спроєктована проба готовності. Метрики ресурсів повідомляють вам, чи правдоподібний тиск на CPU чи пам’ять; вони не доводять відсутності кожної іншої проблеми.

Ще одна межа — відмінність між інфраструктурними метриками та метриками застосунку. CPU й пам’ять можуть повідомити вам, що процес важко працює, але не можуть повідомити, скільки запитів оплати завершилися невдачею, як довго чекала черга чи чи обвалився коефіцієнт влучань кешу. Для CKAD вам потрібен лише інфраструктурний шар, але усвідомлення цієї межі вберігає вас від перебільшення того, що доводять дані.

Коли завдання просить вас «моніторити» чи «перевірити споживання ресурсів», не переходьте одразу до редагування маніфестів. Зберіть метрику, порівняйте її із запитами та лімітами, і лише тоді вирішуйте, чи виправдана зміна ресурсів. Ця послідовність захищає вас від ставлення до кожного симптому як до проблеми потужності та від того, щоб зробити навантаження менш ефективним, підвищивши ліміти без доказів.

Патерни та антипатерни

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

Ще один сильний патерн — це моніторинг на основі селекторів для Деплойментів. Замість сканувати всі Поди й візуально фільтрувати імена, використовуйте мітки, щоб запитати Поди, які належать одному навантаженню. Це тримає вивід команди малим, робить відсортовані результати змістовними та уникає плутанини схоже названого системного Пода із застосунком, за який ви відповідаєте.

Третій патерн — це розбивка по контейнерах перед редагуванням ресурсів у багатоконтейнерних Подах. Коли Под має sidecar’и, агрегований показник Пода — лише відправна точка. Метрики на рівні контейнера допомагають змінити запит чи ліміт правильного контейнера й допомагають уникнути звинувачення основного застосунку у споживанні ресурсів, спричиненому проксі, логером чи допоміжним процесом.

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

Другий антипатерн — це очікування, що kubectl top пояснить історію. Команда показує поточне споживання ресурсів, а не вчорашній сплеск чи лінію тренду через реліз. Якщо вам потрібен історичний аналіз, використовуйте стек моніторингу, що зберігає часові ряди; якщо ви розв’язуєте завдання CKAD, використовуйте kubectl top для швидких доказів теперішнього часу й рухайтеся далі.

Третій антипатерн — це зміна лімітів без перевірки подій. Под біля ліміту пам’яті викликає занепокоєння, але фактична подія OOMKilled дає вам сильніший доказ і може змінити терміновість. Поєднуйте метрику з виводом опису Пода, коли симптом передбачає перезапуски, бо стан Kubernetes повідомляє вам, чи ризик уже перетворився на збій.

Фреймворк ухвалення рішень

Використовуйте kubectl top nodes, коли питання стосується потужності кластера, нерівномірного тиску на Ноди чи того, чи несе одна Нода незвичне навантаження. Використовуйте kubectl top pods, коли питання стосується того, яке навантаження гаряче в просторі імен. Використовуйте kubectl top pods --containers, коли Под має більше одного контейнера або коли агрегований показник Пода не визначає фактичного споживача.

Якщо CPU високе, а пам’ять комфортна, шукайте ризик тротлінгу, нерівномірний трафік, дорогі запити чи замало реплік. Підвищення ліміту CPU може зменшити тротлінг, але також може дозволити одному навантаженню забирати більше CPU Ноди, тож порівняйте зміну з потужністю Ноди та очікуваною поведінкою навантаження. У швидкому іспитовому завданні маніфест може робити заплановане коригування очевидним; у промислі ви перевірили б його довшими вимірами.

Якщо пам’ять висока й близька до ліміту, дослідіть перезапуски та попередній стан, перш ніж припускати, що застосунок просто зайнятий роботою. Ліміти пам’яті — це жорсткі межі, і навіть мала чергова алокація може перетворити попередження на повноцінне OOM-знищення. Наступною дією може бути збільшення запасу, зменшення розміру кешу, виправлення витоку пам’яті чи зниження навантаження на окремий Под через масштабування кількості реплік.

Якщо одна репліка гаряча, а її сусіди тихі, опирайтеся спокусі однаково налаштувати кожну репліку, перш ніж зрозумієте асиметрію. Деплоймент може бути здоровим у сукупності, тоді як один Под обробляє «липкі» сесії, тривалий запит, прогрітий кеш чи фонове завдання, якого інші репліки не поділяють. Тому фреймворк ухвалення рішень розглядає нерівномірність як підказку: спершу поясніть, чому Под відрізняється, а потім вирішуйте, чи має змінитися політика ресурсів, розподіл трафіку чи поведінка застосунку.

Якщо й CPU, і пам’ять виглядають низькими, припиніть намагатися розв’язати симптом самими лише ручками ресурсів. Натомість перевірте логи, події, проби готовності та живучості, ендпоінти сервісів, DNS, мережеву політику, стан залежностей чи метрики самого застосунку. Спокійний вивід kubectl top корисний, бо звужує простір пошуку, але сам по собі він ще не оголошує застосунок здоровим.

Якщо Metrics Server недоступний, відокремте іспитову реакцію від реакції адміністратора кластера. На іспиті зазначте, що kubectl top залежить від Metrics Server, і використовуйте інші доступні докази, якщо встановлення лежить поза завданням. У реальному кластері перевірте Деплоймент, APIService, доступ до kubelet і логи Metrics Server, перш ніж робити висновки з відсутніх метрик.

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

Чи знали ви?

Metrics Server за замовчуванням скрейпить kubelet’и кожні 15 секунд. Дані достатньо свіжі для швидкого тріажу, але це не потік у реальному часі й не довговічна історія.
kubectl top показує поточне споживання, а не історичні тренди. Для порівняння релізів, хронологій інцидентів і прогнозів потужності вам потрібна система моніторингу часових рядів.
Horizontal Pod Autoscaler використовує метрики ресурсів для стандартних рішень масштабування за CPU й пам’яттю. Якщо метрики ресурсів недоступні, HPA не може ухвалювати звичайні рішення за CPU чи пам’яттю.
Metrics Server тримає свої робочі дані в пам’яті. Перезапуск видаляє локальний історичний контекст, і це одна з причин, чому його не слід вважати базою даних моніторингу.

Типові помилки

Помилка	Чому це трапляється	Як це виправити
Запуск `kubectl top` перед перевіркою Metrics Server	Основний API працює, тож відсутній API метрик виглядає як проблема застосунку	Перевірте `kubectl top nodes` і Деплоймент `metrics-server`, перш ніж тлумачити відсутні метрики
Плутання запитів із фактичним споживанням	Запити й ліміти стоять разом у YAML, тож вони здаються однаковим різновидом порога	Ставтеся до запитів як до резервувань планування й окремо порівнюйте поточне споживання з лімітами
Ігнорування Подів із високою пам’яттю	Тротлінг CPU видно як повільність, тоді як ризик пам’яті може лишатися тихим аж до знищення	Сортуйте за пам’яттю, порівнюйте з лімітами й перевіряйте попередній стан Пода на `OOMKilled`
Неперевірка метрик на рівні контейнера	Загальні показники Пода легше читати, ніж вивід по контейнерах	Використовуйте `kubectl top pods --containers` перед зміною ресурсів у багатоконтейнерних Подах
Очікування історичних даних від `kubectl top`	Команда здається інструментом моніторингу, тож учні очікують графіки й тренди	Використовуйте `kubectl top` для поточного тріажу, а стек часових рядів — для історії
Зміна лімітів без перевірки подій	Високе число створює терміновість, тож маніфест редагують першим	Поєднуйте метрики з `kubectl describe pod`, щоб підтвердити перезапуски, ознаки тротлінгу чи історію OOM
Сортування всіх просторів імен без звуження власності	Загальнокластерний вивід виглядає авторитетним, але може змішувати непов’язані навантаження	Використовуйте простори імен і селектори міток, коли завдання стосується одного застосунку

Тест

Ваш Деплоймент має три репліки. Один Под використовує 400m CPU, тоді як два інші використовують по 50m кожен, а користувачі повідомляють про нерівномірну затримку. Що вам слід перевірити, перш ніж піднімати ліміти CPU?

Спершу порівняйте споживання гарячого Пода з його запитом і лімітом CPU, щоб побачити, чи він насправді близький до тротлінгу. Потім перевірте, чи нерівномірний трафік, чи один Под обробляє тривалу роботу, та чи використовує Деплоймент «липкі» сесії або патерн кешу, що створює гарячу репліку. Підвищення ліміту CPU може зменшити тротлінг, але не виправить незбалансоване навантаження. Метрики на рівні контейнера також корисні, якщо Под має sidecar, який може споживати CPU.

Под на Java з `limits.memory: 256Mi` показує 240Mi у `kubectl top pods`, але ще не перезапускався. Як вам слід оцінити ризик?

Под близький до жорсткої межі пам’яті, тож ризик високий навіть без поточного перезапуску. Пам’ять понад ліміт може призвести до OOM-знищення, на відміну від тиску CPU, що зазвичай з’являється як тротлінг. Вам слід оглянути kubectl describe pod на попередні OOM-знищення й перевірити, чи має кеш або купа (heap) налаштований максимум. Розумне виправлення може включати більший запас плюс налаштування пам’яті на рівні застосунку.

Ви запускаєте `kubectl top nodes` й отримуєте `Metrics API not available`, тоді як `kubectl get pods` усе ще працює. Про що це вам говорить?

Основний API Kubernetes доступний, але API метрик ресурсів не подає дані на ваш запит. Відсутній компонент — це зазвичай Metrics Server, нездоровий Деплоймент Metrics Server, проблема з APIService чи проблема з дозволами. Це не доводить, що Поди застосунку нездорові. Це говорить вам, що kubectl top наразі бракує його джерела даних, тож ви мусите перевірити конвеєр метрик, перш ніж використовувати метрики ресурсів.

Багатоконтейнерний Под має контейнер застосунку та sidecar для логування. Метрики на рівні Пода показують загалом 200m CPU. Як ви визначите справжнього споживача й чому це має значення?

Запустіть kubectl top pods POD_NAME --containers або використайте ту саму команду із селектором, щоб побачити CPU й пам’ять по контейнерах. Ця відмінність має значення, бо ресурси зазвичай налаштовуються на кожен контейнер, а не як одна спільна ручка Пода в маніфесті — хоча Kubernetes 1.35 також підтримує необов’язкові ресурси на рівні Пода через spec.resources, коли увімкнено feature gate PodLevelResources. Якщо sidecar використовує 180m, підвищення запиту контейнера застосунку промине причину. Правильним виправленням може бути конфігурація sidecar, поведінка образу чи специфічний для sidecar ліміт.

Под використовує 300Mi пам'яті, його запит — 128Mi, а ліміту пам'яті немає. Він не зазнав OOMKilled. Чи це суперечливо?

Ні, це узгоджено, бо запит пам’яті не є максимумом. Запит допоміг планувальнику розмістити Под і впливає на якість обслуговування, але він не зупиняє процес на 128Mi. Без ліміту пам’яті контейнер може споживати більше пам’яті, доки Нода може її надати. Операційне питання стає таким: чи замалий запит для чесного планування й чи слід навмисно встановити ліміт.

Після перевірки `kubectl top pods` і CPU, і пам'ять виглядають низькими, але збої готовності тривають. Що вам слід робити далі?

Низькі CPU й пам’ять роблять тиск на ресурси менш імовірною основною причиною, тож вам слід розширити дослідження. Перевірте події Пода, конфігурацію проби готовності, логи застосунку, ендпоінти сервісів, DNS, мережеву політику та здоров’я залежностей. Моніторинг усе одно допоміг, бо прибрав один клас пояснень. Помилкою було б підвищувати ресурси просто тому, що застосунок нездоровий.

Ви сортуєте Поди за пам'яттю й знаходите вгорі Под із системного простору імен, але ваше завдання стосується одного Деплойменту застосунку. Як вам тримати дослідження сфокусованим?

Використовуйте цільовий простір імен і селектори міток, щоб оглянути Поди Деплойменту напряму. Загальнокластерне сортування корисне для усвідомлення потужності, але може відволікати вас навантаженнями, не пов’язаними із завданням. Для дослідження застосунку kubectl top pods -l app=... дає чистіше порівняння реплік. Якщо тиск на Ноди лишається підозрілим, то поверніться до метрик Нод і ширшого виводу по простору імен.

Практична вправа

Сценарій вправи: ви створите невеликий Деплоймент із запитами та лімітами, зачекаєте, поки Metrics Server опублікує показники, порівняєте поточне споживання з оголошеними ресурсами, а потім повторите той самий патерн моніторингу через сфокусовані вправи. Якщо у вашому локальному кластері немає встановленого Metrics Server, команди налаштування все одно можуть успішно створити Поди, але kubectl top зазнаватиме невдачі, доки API метрик не стане доступним. Ставтеся до цієї невдачі як до правильного діагностичного висновку, а не як до причини пропустити кроки тлумачення.

Завдання — моніторити споживання ресурсів запущених застосунків, порівняти числа з політикою ресурсів і пояснити наступну дію, яку ви зробили б на основі доказів.

Налаштування

# Create a deployment with known resource usage
cat << 'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: monitor-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: monitor-demo
  template:
    metadata:
      labels:
        app: monitor-demo
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          requests:
            cpu: 50m
            memory: 64Mi
          limits:
            cpu: 100m
            memory: 128Mi
EOF

# Wait for pods to be ready and metrics to populate
kubectl rollout status deployment/monitor-demo
sleep 30

Використовуйте це налаштування, щоб попрактикувати реалістичний порядок дій. Ви не намагаєтеся змусити nginx споживати велику кількість CPU; ви практикуєте, як знайти метрики, прочитати одиниці, порівняти поточні значення з маніфестом і помітити, коли метрики недоступні. sleep 30 дає Metrics Server час опублікувати семпл у типових локальних кластерах.

Частина 1: базовий моніторинг

# Check if metrics server is running
kubectl top nodes

# View pod metrics
kubectl top pods -l app=monitor-demo

# Sort by CPU
kubectl top pods --sort-by=cpu

Підказка до розв'язання Частини 1

Якщо kubectl top nodes повертає метрики Нод, продовжуйте до метрик Подів і порівняйте три репліки. Якщо повертається помилка API метрик, перевірте Metrics Server, перш ніж звинувачувати Деплоймент. Для тихого Деплойменту nginx CPU й пам’ять зазвичай мають бути малими, тож головний критерій успіху — це читання й тлумачення виводу, а не пошук драматичного сплеску.

Частина 2: порівняння із запитами

# Get resource requests
kubectl get pods -l app=monitor-demo -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].resources}{"\n"}{end}'

# Compare with actual usage
kubectl top pods -l app=monitor-demo

Підказка до розв'язання Частини 2

Команда JSONPath показує запити та ліміти, оголошені на контейнері, тоді як kubectl top показує поточне споживання. Здорові Поди nginx, що простоюють, зазвичай мають бути нижче свого ліміту пам’яті й використовувати мало CPU. Якщо поточне значення вище запиту, але нижче ліміту, назвіть це позиченою потужністю, а не автоматичним збоєм.

Очищення

kubectl delete deploy monitor-demo

Тренувальні вправи

Ці вправи зберігають ті самі рухи моніторингу в менших повтореннях у стилі іспиту. Запускайте їх лише в одноразовому тренувальному просторі імен чи локальному кластері та видаляйте ресурси, коли закінчите. Цілі навмисно короткі, бо завдання моніторингу CKAD винагороджують швидке розпізнавання й точне тлумачення.

Вправа 1: метрики Нод (ціль: 1 хвилина)

# Check node resource usage
kubectl top nodes

# Identify which node has highest CPU
kubectl top nodes --sort-by=cpu

Розв'язання Вправи 1

Нода з найвищим CPU з’являється вгорі відсортованого виводу. Якщо команда зазнає невдачі, занотуйте, що Metrics Server недоступний, і не робіть жодних висновків про навантаження Ноди з відсутності даних. Якщо вона успішна, порівняйте відсотки CPU й пам’яті, бо найзавантаженіша за CPU Нода не завжди є найзавантаженішою за пам’яттю.

Вправа 2: метрики Подів (ціль: 2 хвилини)

# Create test pods
kubectl run drill2a --image=nginx
kubectl run drill2b --image=nginx

# Wait for metrics to populate
kubectl wait --for=condition=ready pod/drill2a pod/drill2b
sleep 30

# Check their metrics
kubectl top pods

# Cleanup
kubectl delete pod drill2a drill2b

Розв'язання Вправи 2

Обидва Поди мають з’явитися у kubectl top pods після того, як Metrics Server отримає семпл. Якщо один Под відсутній одразу після готовності, зачекайте трохи, бо збір метрик не миттєвий. Очікуване тлумачення таке: прості Поди nginx використовують мало CPU, доки не отримають значущого трафіку.

Вправа 3: метрики контейнерів (ціль: 2 хвилини)

# Create multi-container pod
cat << 'EOF' | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: drill3
spec:
  containers:
  - name: nginx
    image: nginx
  - name: sidecar
    image: busybox
    command: ['sleep', '3600']
EOF

# Wait for pod and metrics to populate
kubectl wait --for=condition=ready pod/drill3
sleep 30

# View per-container metrics
kubectl top pods drill3 --containers

# Cleanup
kubectl delete pod drill3

Розв'язання Вправи 3

Вивід має показати окремі рядки для контейнерів nginx і sidecar. Sidecar busybox лише спить, тож його CPU зазвичай має бути дуже низьким. Важлива навичка — переконатися, що ви можете відокремити споживання контейнерів, замість того щоб покладатися на агрегований показник Пода.

Вправа 4: відсортований вивід (ціль: 2 хвилини)

# Get pods sorted by memory usage
kubectl top pods -A --sort-by=memory

# Get pods sorted by CPU usage
kubectl top pods -A --sort-by=cpu

Розв'язання Вправи 4

Перша команда ставить Поди, обтяжені пам’яттю, ближче до верху, а друга робить те саме для Подів, обтяжених CPU. Якщо системний Под очолює список, не припускайте, що він є частиною проблеми вашого застосунку. Використовуйте відсортований вивід як короткий список, а потім звужуйте за простором імен чи міткою.

Вправа 5: системні Поди (ціль: 2 хвилини)

# Check kube-system pod resource usage
kubectl top pods -n kube-system

# Sort by CPU to find most active
kubectl top pods -n kube-system --sort-by=cpu

Розв'язання Вправи 5

Метрики системного простору імен допомагають відрізнити тиск застосунку від активності площини управління чи додатків кластера. У багатьох локальних кластерах системні Поди мають бути скромними, але точні значення залежать від середовища. Навичка — читати метрики в межах простору імен, не змішуючи їх із вашим Деплойментом застосунку.

Вправа 6: повний робочий процес моніторингу (ціль: 4 хвилини)

Сценарій цієї фінальної вправи — це дослідження підозрюваного високого споживання ресурсів у Деплойменті з кількома репліками.

# Create deployment with multiple replicas
kubectl create deploy drill6 --image=nginx --replicas=5

# Wait for pods and metrics to populate
kubectl rollout status deployment/drill6
sleep 30

# Check overall deployment resource usage
kubectl top pods -l app=drill6

# Find highest consumer
kubectl top pods -l app=drill6 --sort-by=cpu

# Check container level
kubectl top pods -l app=drill6 --containers

# Compare to node capacity
kubectl top nodes

# Cleanup
kubectl delete deploy drill6

Розв'язання Вправи 6

Очікуваний робочий процес: спершу селектор, на другому місці відсортований селектор, на третьому — розбивка по контейнерах, а останнім — порівняння з Нодами. Для тихого Деплойменту nginx ви можете не знайти значущого високого споживання, але послідовність команд усе одно є суттю. Якщо одна репліка набагато вища за інші, дослідіть, чи вона отримує трафік чи виконує роботу, якої не роблять інші репліки.

Критерії успіху

Ви перевірили, чи Metrics Server подає метрики ресурсів, запустивши команду kubectl top.
Ви порівняли споживання CPU й пам’яті Подом з оголошеними запитами та лімітами Деплойменту.
Ви використали відсортований вивід Подів, щоб визначити найбільшого споживача CPU чи пам’яті.
Ви використали --containers, щоб відокремити метрики на рівні контейнера в багатоконтейнерному Поді.
Ви пояснили, чи високе значення пам’яті біля ліміту нагальніше, ніж високе значення CPU біля ліміту.
Ви прибрали всі тренувальні Поди й Деплойменти, створені під час вправи.

Перевірка засвоєного

Відсотки у виводі по Нодах за замовчуванням базуються на allocatable Ноди, тож вони відповідають на інше питання, ніж споживання Пода: «Наскільки завантажена ця машина?», а не «Наскільки близько цей контейнер до свого налаштованого ліміту?». Передайте --show-capacity, щоб порівнювати з повною потужністю Ноди.

Перш ніж рухатися далі, поясніть, чому CPU% і memory% по Нодах можуть відрізнятися від того, що ви обчислили б відносно повної потужності Ноди, та коли ви передавали б --show-capacity.

Джерела

Наступний модуль

Модуль 3.5: застарівання API — далі ви будете опрацьовувати зміни версій API та застарівання, щоб маніфести лишалися сумісними з поточними релізами Kubernetes.