Как избежать разрешения сердечных болей в кубернетах - PullRequest
Новая
       98

Как избежать разрешения сердечных болей в кубернетах

3 голосов
/ 22 марта 2020

Я думаю, что название в значительной степени говорит само за себя. Я провел много экспериментов, и печальная правда в том, что coredns добавляет 20 ms накладные расходы ко всем запросам внутри кластера. Сначала мы подумали, может быть, добавив больше репликаций и распределив разрешающие запросы между большим количеством экземпляров, мы могли бы улучшить время отклика, но это совсем не помогло. (мы увеличили с 2 до 4).

Были внесены некоторые улучшения в флуктуациях времени разрешения после масштабирования до 4 экземпляров. Но это было не то, что мы ожидали, и издержки 20 ms все еще были там.

У нас есть несколько веб-сервисов, у которых фактическое время ответа составляет < 30 ms, и с помощью coredns мы удваиваем время отклика, и это не круто!

После того, как мы пришли к выводу по этому вопросу, мы провели эксперимент, чтобы еще раз проверить, что это не накладные расходы на уровне ОС. И результаты не отличались от того, что мы ожидали.

Мы думали, что мы можем реализовать / развернуть решение, основанное на добавлении списка необходимых hostname сопоставлений для каждого модуля внутри /etc/hosts этого модуля. Итак, мои заключительные вопросы следующие:

  • Кто-нибудь еще испытывал нечто подобное с coredns?
  • Не могли бы вы предложить альтернативные решения для coredns, которые работают в среде k8s?

Любые мысли или идеи приветствуются. Заранее спасибо.

1 Ответ

4 голосов
/ 22 марта 2020

Есть несколько вещей, на которые следует обратить внимание при запуске coreDNS в вашем кластере kubernetes

  • Память
  • AutoPath
  • Количество реплик
  • Autoscaler
  • Другие плагины
  • Метрики Prometheus
  • Отдельные блоки сервера

Память

Рекомендуемый объем памяти CoreDNS для реплик равен 

MB required (default settings) = (Pods + Services) / 1000 + 54

enter image description here

Autopath

Autopath - это функция в Coredns, которая помогает увеличить время отклика для внешних запросы

Обычно DNS-запрос проходит через

  1. .. sv c .cluster.local
  2. .sv c .cluster.local
  3. cluster.local
  4. Затем настраивается прямой, обычно путь поиска хоста (/etc/resolv.conf
Trying "example.com.default.svc.cluster.local"
Trying "example.com.svc.cluster.local"
Trying "example.com.cluster.local"
Trying "example.com"
Trying "example.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55265
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        30  IN  A   93.184.216.34

Это требует больше памяти, поэтому расчет теперь становится 

MB required (w/ autopath) = (Number of Pods + Services) / 250 + 56

Количество реплик

По умолчанию 2, но включение Autoscaler должно помочь с проблемами загрузки.

Autoscaler 

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  targetCPUUtilizationPercentage: 50

Локальный кеш узла

Бета-версия в Kubernetes 1.15

NodeLocal DNSCache повышает производительность DNS кластера благодаря запуску агента кэширования DNS на узлах кластера как DaemonSet. В современной архитектуре блоки в режиме DNS ClusterFirst обращаются к IP-сервису kube-dns для запросов DNS. Это транслируется в конечную точку kube-dns / CoreDNS через правила iptables, добавленные kube-proxy. Благодаря этой новой архитектуре Pods будет обращаться к агенту кэширования dns, работающему на том же узле, избегая тем самым правил DNAT iptables и отслеживания соединений. Локальный агент кэширования запросит службу kube-dns на отсутствие кеша имен хостов кластера (суффикс cluster.local по умолчанию).

https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/

Other Плагины

Они также помогут увидеть, что происходит внутри CoreDNS

Ошибка - Любые ошибки, возникшие при обработке запроса, будут выводиться на стандартный вывод.

Trace - включить OpenTracing того, как запрос проходит через CoreDNS

Log - ведение журнала запросов

health - CoreDNS и работает, это возвращает код состояния HTTP 200 OK

ready - При включении готовности конечная точка HTTP на порту 8181 вернет 200 OK, когда все плагины, которые могут сигнализировать о готовности, сделали т.

Ready и Health следует использовать при развертывании 

        livenessProbe:
          httpGet:
            path: /health
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 8181
            scheme: HTTP

Prometheus Metrics

Плагин Prometheus

coredns_health_request_duration_seconds{} - duration to process a HTTP query to the local /health endpoint. As this a local operation, it should be fast. A (large) increase in this duration indicates the CoreDNS process is having trouble keeping up with its query load.

https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md

Отдельные блоки сервера

Последний совет - отделить блок DNS-сервера кластера от внешнего блока 

    CLUSTER_DOMAIN REVERSE_CIDRS {
        errors
        health
        kubernetes
        ready
        prometheus :9153
        loop
        reload
        loadbalance
    }

    . {
        errors
        autopath @kubernetes
        forward . UPSTREAMNAMESERVER
        cache
        loop
    }

Подробнее о плагине k8 и других параметрах здесь https://github.com/coredns/coredns/blob/master/plugin/kubernetes/README.md

...