Сталкивались ли вы с проблемами DNS в кластере Kubernetes и как их решали?

Да, проблемы с DNS — одна из частых причин сбоев в Kubernetes. Вот с какими основными проблемами я сталкивался и методы их решения:

1. Сбои разрешения имен (DNS lookup failures):

• Причина: Поды не могут разрешить имена сервисов (my-svc.my-namespace.svc.cluster.local) или внешние домены.
• Диагностика: Запуск отладочного пода с утилитами nslookup или dig:

  kubectl run dns-debug --image=busybox:1.28 --rm -it --restart=Never -- nslookup kubernetes.default

• Решение: Проверка состояния пода coredns (или kube-dns) в пространстве имен kube-system. Часто помогает перезапуск этих подов или увеличение их лимитов ресурсов (CPU/memory).

2. Медленное разрешение имен (Slow DNS resolution):

• Причина: Параметр ndots в файле /etc/resolv.conf пода. По умолчанию он равен 5, что означает: для имени myapp система сделает 5 бесполезных запросов (добавляя суффиксы поиска), прежде чем выполнить запрос как есть.
• Решение: Уменьшение ndots в спецификации пода или на уровне dnsConfig для конкретных приложений:

  dnsConfig:
    options:
      - name: ndots
        value: "2"

3. Проблемы с кешированием на стороне приложения:

• Причина: Некоторые приложения (например, на JVM) кешируют DNS-записи на очень долгое время, что ломает service discovery при обновлении сервисов.
• Решение: Настройка TTL кеша в приложении (например, флаг -Dsun.net.inetaddr.ttl=30 для Java) или использование sidecar-контейнеров, таких как dnsmasq, для локального кеширования с контролируемым TTL.

4. Ограничения и отказы CoreDNS при высокой нагрузке:

• Решение: Мониторинг метрик CoreDNS (запросов в секунду, latency). Масштабирование Deployment CoreDNS, увеличение количества реплик. Настройка автозапуска (HPA) на основе метрик CPU или количества запросов.

Общий подход: Все изменения DNS-конфигурации (например, через Corefile ConfigMap) сначала тестируются в не-production среде, так как ошибка может "положить" весь кластер.