Модуль 9 / 19

Requests, Limits і Probes

KUBERNETES

Зміст

1. Цілі модуля

Ви навчитеся задавати requests/limits, пояснювати QoS та OOM, обирати startup/readiness/liveness probes, використовувати Metrics API й діагностувати stalled rollout через readiness.

Scheduler використовує requests для розміщення Pod. CPU limit зазвичай реалізує throttling, а перевищення memory limit може спричинити OOM kill. Limit не резервує ресурс і не гарантує продуктивність.

QoS Guaranteed потребує рівних requests і limits CPU/memory для кожного контейнера; Burstable має неповний або нерівний набір, BestEffort не задає їх. QoS впливає на eviction.

3. Теорія: probes

startupProbe захищає повільний запуск і до успіху вимикає liveness/readiness. readiness виключає Pod із Service endpoints без restart. liveness перезапускає контейнер і має знаходити лише стан, який restart здатен виправити.

Надто агресивна livenessProbe посилює збій restart storm. Probe має бути дешевою і не перевіряти весь ланцюжок зовнішніх залежностей.

4. Теорія: Metrics Server

kubectl top читає Metrics API, тому потребує Metrics Server. Ці показники оптимізовані для autoscaling та оперативного огляду, а не замінюють Prometheus і довготривалий моніторинг.

5. Методичні вказівки

Починайте requests з вимірювань
Перевіряйте allocatable Node і сумарні requests
Розділяйте startup, traffic readiness і deadlock detection
Не використовуйте одну зовнішню dependency в усіх probes
Зіставляйте Ready, restartCount, lastState та Events
--kubelet-insecure-tls допустимий лише в kind-лабораторії

6. Лабораторна робота: ресурси та probes

Збережіть маніфест як resource-lab.yaml.

apiVersion: v1
kind: Namespace
metadata: {name: lab-resources}
---
apiVersion: apps/v1
kind: Deployment
metadata: {name: app, namespace: lab-resources}
spec:
  replicas: 3
  progressDeadlineSeconds: 30
  selector:
    matchLabels: {app: resource-demo}
  template:
    metadata:
      labels: {app: resource-demo}
    spec:
      containers:
        - name: web
          image: busybox:1.37.0
          command: ["sh", "-c", "mkdir -p /www; echo ok > /www/ready; exec httpd -f -p 8080 -h /www"]
          ports: [{name: http, containerPort: 8080}]
          resources:
            requests: {cpu: 50m, memory: 32Mi}
            limits: {cpu: 200m, memory: 64Mi}
          startupProbe:
            tcpSocket: {port: http}
            periodSeconds: 2
            failureThreshold: 15
          readinessProbe:
            httpGet: {path: /ready, port: http}
            periodSeconds: 3
          livenessProbe:
            tcpSocket: {port: http}
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata: {name: app, namespace: lab-resources}
spec:
  selector: {app: resource-demo}
  ports: [{name: http, port: 80, targetPort: http}]

kubectl apply -f resource-lab.yaml
kubectl rollout status deployment/app -n lab-resources --timeout=120s
kubectl get pods -n lab-resources
kubectl describe pod -n lab-resources -l app=resource-demo
kubectl get pods -n lab-resources -o jsonpath='{range .items[*]}{.metadata.name}{" qos="}{.status.qosClass}{" ready="}{.status.containerStatuses[0].ready}{" restarts="}{.status.containerStatuses[0].restartCount}{"\n"}{end}'
kubectl get endpointslices -n lab-resources -l kubernetes.io/service-name=app

Критерій: три Ready Pod, QoS=Burstable, restartCount=0 і три ready endpoint.

7. Лабораторна робота: Metrics API

Встановіть Metrics Server v0.8.1. Patch вимикає перевірку kubelet certificate лише для kind; у production налаштуйте довірений TLS.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.8.1/components.yaml
kubectl patch deployment metrics-server -n kube-system --type=json -p='[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'
kubectl rollout status deployment/metrics-server -n kube-system --timeout=120s
kubectl get apiservice v1beta1.metrics.k8s.io
kubectl top nodes
kubectl top pods -n lab-resources --containers

Критерій: APIService Available=True, top nodes і top pods повертають CPU/memory.

8. Діагностика: помилкова readinessProbe

Неправильний path залишає нові Pods Running, але NotReady. Вони не входять до ready endpoints, rollout зупиняється, а liveness не має їх перезапускати.

kubectl patch deployment app -n lab-resources --type=json -p='[{"op":"replace","path":"/spec/template/spec/containers/0/readinessProbe/httpGet/path","value":"/missing"}]'
kubectl rollout status deployment/app -n lab-resources --timeout=40s
kubectl get deployment,replicaset,pod,endpointslice -n lab-resources
kubectl get pods -n lab-resources -o jsonpath='{range .items[*]}{.metadata.name}{" ready="}{.status.containerStatuses[0].ready}{" restarts="}{.status.containerStatuses[0].restartCount}{"\n"}{end}'
kubectl describe pods -n lab-resources -l app=resource-demo
kubectl events -n lab-resources --types=Warning
kubectl rollout undo deployment/app -n lab-resources
kubectl rollout status deployment/app -n lab-resources --timeout=120s
kubectl delete namespace lab-resources

Ланцюжок: Deployment Conditions → Pod Ready → probe Warning Events → ручна перевірка endpoint → EndpointSlice → rollback.

9. Контроль і шпаргалка

Що scheduler робить з requests?
Чим CPU limit відрізняється від memory limit?
Чому readiness не перезапускає контейнер?
Коли потрібна startupProbe?
Чому top не замінює моніторинг?

Модуль засвоєно, якщо ви пояснюєте QoS, не змішуєте призначення probes і доводите, чому Running Pod виключено із Service.

PDF для роботи офлайн

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

Завантажити PDFPDF