UDP-трафик внутри хоста отсутствует после повторного создания модуля назначения - PullRequest
Новая
       11

UDP-трафик внутри хоста отсутствует после повторного создания модуля назначения

1 голос
/ 25 сентября 2019

Я отправляю UDP-пакеты (statsd) от модулей на хосте на <hostIP>:8125.С другой стороны, сборщик (агент данных, использующий hostPort; по одному на хост через DaemonSet) собирает пакеты и делает свое дело.

Обычно это работает нормально, но если я когда-либо удаляю + повторносоздать сборщик (kubectl delete pod datadog-agent-xxxx; новый модуль запускается на том же IP / порту через несколько секунд), трафик от существующих клиентских сокетов перестает поступать на сборщик (UDP-сокеты, созданные после перенос pod работает нормально).

Перезапуск только агента внутри модуля сборщика (kubectl exec -it datadog-agent-xxxxx agent stop; автозапуск через ~ 30 с) того же старого трафика показывает ,Таким образом, контейнеры так или иначе должны оказывать влияние.

Хотя UDP (предположительно) не имеет состояния, что-то где-то явно сохраняет состояние вокруг !?Любые идеи / указатели?

В каждом модуле "клиент" есть что-то подобное в развертывании / модуле: 

kind: Deployment
...
spec:
  template:
    spec:
      containers:
        - name: webservice
          env:
            # Statsd defaults to localhost:8125, but that's this pod. Use `hostPort` on collector + hostIP here to get around that.
            DD_AGENT_HOST:
              valueFrom:
                fieldRef:
                  fieldPath: 'status.hostIP'

На сборщике (следуя документам k8s datadog ): 

kind: DaemonSet
...
spec:
  template:
    spec:
      containers:
        - image: datadog/agent:6.140.0
          ports:
            - containerPort: 8125
              hostPort: 8125
              protocol: UDP
          env:
            - name: DD_DOGSTATSD_NON_LOCAL_TRAFFIC
              value: "true"
            - ...

Это происходит в Kubernetes 1.12 в Google Kubernetes Engine.

1 Ответ

0 голосов
/ 27 сентября 2019

Вероятно, это связано с проблемой в плагине portmap .Текущая рабочая теория заключается в том, что запись conntrack создается, когда клиентский модуль обращается к порту хоста UDP, и эта запись становится устаревшей, когда серверный модуль удален, но не удаляется, поэтому клиенты продолжают нажимать на него, по существу, блокируя трафик..

Вы можете попробовать удалить запись conntrack с чем-то вроде conntrack -D -p udp --dport 8125 на одном из затронутых хостов.Если это решает проблему, то это было основной причиной вашей проблемы.

Этот обходной путь, описанный в проблеме GitHub, должен смягчать проблему до объединения исправлений:

Вы можете добавить initContainer вмодуль сервера для запуска команды conntrack при запуске: 

initContainers: 
        - image: <conntrack-image>
          imagePullPolicy: IfNotPresent 
          name: conntrack 
          securityContext: 
            allowPrivilegeEscalation: true 
            capabilities: 
              add: ["NET_ADMIN"] 
          command: ['sh', '-c', 'conntrack -D -p udp']
...