Типы сервисов, DNS-резолв и управление ресурсами
Этот раздел посвящен тому, как выводить приложения наружу, как работает внутренняя DNS-система и как правильно распределять ресурсы CPU/RAM между подами.
1. Типы сервисов (Service Types)
Мы используем сервисы, чтобы обеспечить стабильный доступ к динамическим подам.
- ClusterIP (Default): Внутренний IP кластера. Сервис доступен только внутри K8s.
- NodePort: Открывает порт на каждой ноде (диапазон
30000-32767). Позволяет достучаться до приложения поIP_любой_ноды:NodePort. Используется в основном для тестов. - LoadBalancer: Создает внешний балансировщик (в облаке типа AWS/GCP или через MetalLB на On-Premise). Выдает внешний IP для доступа из интернета.
- ExternalName: Работает как CNAME в DNS. Перенаправляет запрос на внешний домен (например,
google.com), не используя проксирование трафика.
2. DNS в Kubernetes (CoreDNS)
Kubernetes использует внутреннюю DNS-систему для обнаружения сервисов (Service Discovery).
- FQDN (Полное имя): Структура имени сервиса выглядит так:
<service-name>.<namespace>.svc.cluster.local - Search Domains: Благодаря файлу
/etc/resolv.confвнутри пода, вы можете обращаться к сервису просто по его имени (curl backend), если он находится в том же Namespace. Если в другом — нужно указывать пространство имен (curl backend.dev). - CoreDNS: Основной компонент, который хранит записи о сервисах и их IP-адресах.
3. Управление ресурсами (Requests & Limits)
Для стабильности кластера каждому контейнеру нужно указывать лимиты ресурсов.
- Requests (Запросы): Минимальное количество ресурсов, которое гарантированно получит контейнер. Scheduler использует это значение, чтобы найти подходящую ноду для пода.
- Limits (Лимиты): Максимальный порог ресурсов.
- Если контейнер превысит Memory Limit, он будет убит (OOMKilled).
- Если контейнер превысит CPU Limit, он будет ограничен в производительности (Throttling), но не убит.
Единицы измерения:
- CPU: Измеряется в "миллиядрах" (
1000m= 1 ядро). - Memory: Измеряется в байтах/мегабайтах (
Mi,Gi).
4. Классы качества обслуживания (QoS Classes)
Kubernetes автоматически присваивает поду класс в зависимости от ресурсов, что влияет на приоритет выживания пода при нехватке памяти на ноде:
- Guaranteed: У пода указаны и Requests, и Limits, и они равны. Эти поды убиваются в последнюю очередь.
- Burstable: У пода указаны ресурсы, но они не равны, или указан только Request. Средний приоритет.
- BestEffort: Ресурсы не указаны вообще. Эти поды удаляются первыми при любой нагрузке на систему.
5. Ограничения на уровне Namespace
- ResourceQuota: Ограничивает суммарное потребление ресурсов всем пространством имен (например, "Namespace
devне может потреблять более 10 ядер и 20ГБ RAM"). Также может ограничивать количество подов, сервисов и других объектов. - LimitRange: Позволяет задать значения по умолчанию для Requests/Limits, если разработчик забыл их указать в манифесте пода.
6. Полезные команды (Cheat Sheet)
| Команда | Описание |
kubectl get ep
|
Просмотр Endpoints (на какие IP подов реально идет трафик) |
kubectl top nodes / pods
|
Просмотр реального потребления ресурсов (нужен Metrics Server) |
kubectl get quota
|
Проверка квот в текущем Namespace |
kubectl describe node <name>
|
Просмотр аллокации ресурсов (сколько зарезервировано под поды) |
kubectl port-forward <pod-name> 8080:80
|
Проброс порта с пода на локальную машину для отладки |
💡 Советы DevOps-инженера:
- Всегда ставьте Requests: Без них Scheduler может "перегрузить" ноду, и она упадет.
- QoS "Guaranteed" для критичных баз: Для баз данных или важных API всегда делайте
Requests = Limits, чтобы K8s не убил их в первую очередь. - Проверка DNS: Если один сервис не видит другой, зайдите в под (
kubectl exec) и проверьте файл/etc/resolv.conf— там прописаны правила поиска имен.