kube-dns getsockopt нет маршрута к хосту

Question

Я изо всех сил пытаюсь понять, как правильно настроить kube-dns с фланелью на kubernetes 1.10 и контейнером как CRI.

kube-dns не запускается со следующей ошибкой:

kubectl -n kube-system logs kube-dns-595fdb6c46-9tvn9 -c kubedns
I0424 14:56:34.944476       1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:35.444469       1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
E0424 14:56:35.815863       1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:192: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host
E0424 14:56:35.815863       1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:189: Failed to list *v1.Endpoints: Get https://10.96.0.1:443/api/v1/endpoints?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host
I0424 14:56:35.944444       1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:36.444462       1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
I0424 14:56:36.944507       1 dns.go:219] Waiting for [endpoints services] to be initialized from apiserver...
F0424 14:56:37.444434       1 dns.go:209] Timeout waiting for initialization

kubectl -n kube-system describe pod kube-dns-595fdb6c46-9tvn9
  Type     Reason     Age                 From              Message
  ----     ------     ----                ----              -------
  Warning  Unhealthy  47m (x181 over 3h)  kubelet, worker1  Readiness probe failed: Get http://10.244.0.2:8081/readiness: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
  Warning  BackOff    27m (x519 over 3h)  kubelet, worker1  Back-off restarting failed container
  Normal   Killing    17m (x44 over 3h)   kubelet, worker1  Killing container with id containerd://dnsmasq:Container failed liveness probe.. Container will be killed and recreated.
  Warning  Unhealthy  12m (x178 over 3h)  kubelet, worker1  Liveness probe failed: Get http://10.244.0.2:10054/metrics: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
  Warning  BackOff    2m (x855 over 3h)   kubelet, worker1  Back-off restarting failed container

На самом деле нет никакого маршрута к конечной точке 10.96.0.1:

ip route
default via 10.240.0.254 dev ens160 
10.240.0.0/24 dev ens160  proto kernel  scope link  src 10.240.0.21 
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 
10.244.0.0/16 dev cni0  proto kernel  scope link  src 10.244.0.1 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
10.244.5.0/24 via 10.244.5.0 dev flannel.1 onlink

Что отвечает за настройку диапазона адресов службы кластера и связанных маршрутов? Это среда выполнения контейнера, оверлейная сеть (в данном случае фланелевая) или что-то еще? Где это должно быть настроено?

10-containerd-net.conflist настраивает мост между хостом и моей сетью pod. Можно ли здесь настроить сервисную сеть?

cat /etc/cni/net.d/10-containerd-net.conflist 
{
  "cniVersion": "0.3.1",
  "name": "containerd-net",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipMasq": true,
      "promiscMode": true,
      "ipam": {
        "type": "host-local",
        "subnet": "10.244.0.0/16",
        "routes": [
          { "dst": "0.0.0.0/0" }
        ]
      }
    },
    {
      "type": "portmap",
      "capabilities": {"portMappings": true}
    }
  ]
}

Редактировать:

Просто наткнулся на это с 2016 года:

Несколько недель назад (я забыл релиз, но это был 1.2.x где x!= 0) (#24429), мы исправили маршрутизацию так, что любой трафик, который поступает на узел, предназначенный для IP-адреса службы, будет обрабатываться как если он пришел к порту узла. Это означает, что вы должны иметь возможность устанавливать статические маршруты для диапазона IP-адресов кластера услуг на один или несколько узлов, и узлы будут действовать как мосты. Это та же самая уловка, которую большинство людей делают с фланелью для наложения оверлея.

Это несовершенно, но это работает. В будущем нужно будет уточнить маршрутизацию, если вы хотите оптимального поведения (т.е. не теряете IP-адрес клиента), или мы увидим больше реализаций служб, не относящихся к kube-proxy.

Это все еще актуально? Нужно ли устанавливать статический маршрут для службы CIDR? Или проблема на самом деле с kube-proxy а не фланель или контейнер?

Моя фланелевая конфигурация:

cat /etc/cni/net.d/10-flannel.conflist 
{
  "name": "cbr0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

И кубе-прокси

[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kube-proxy \
  --cluster-cidr=10.244.0.0/16 \
  --feature-gates=SupportIPVSProxyMode=true \
  --ipvs-min-sync-period=5s \
  --ipvs-sync-period=5s \
  --ipvs-scheduler=rr \
  --kubeconfig=/etc/kubernetes/kube-proxy.conf \
  --logtostderr=true \
  --master=https://192.168.160.1:6443 \
  --proxy-mode=ipvs \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Редактировать:

Посмотрев на этапы отладки kube-proxy, выясняется, что kube-proxy не может связаться с мастером. Я подозреваю, что это большая часть проблемы. У меня есть 3 узла контроллера / мастера за балансировщиком нагрузки HAProxy, который связан с 192.168.160.1:6443 и направляет круговой маневр каждому из мастеров на 10.240.0.1[1|2|3]:6443, Это можно увидеть в выводе / конфигах выше.

В kube-proxy.serviceЯ уточнил --master=192.168.160.1:6443, Почему пытаются подключиться к порту 443? Могу ли я изменить это - похоже, нет флага порта? Это должен быть порт 443 по какой-то причине?

Answer 1

В этом ответе есть два компонента, один о запуске kube-proxy и один о том, откуда эти:443 URL приходят.

Во-первых, о kube-proxy: пожалуйста, не беги kube-proxy как системный сервис, как это. Он предназначен для запуска kubelet в кластере, так что адреса SDN ведут себя рационально, так как они фактически являются "поддельными" адресами. Запустив kube-proxy вне контроля kubeletвсе виды странных вещей произойдут, если вы не потратите огромное количество энергии на то, чтобы kubelet настраивает подчиненные Docker-контейнеры.

---

Теперь об этом:443 URL:

E0424 14:56:35.815863 1 reflector.go:201] k8s.io/dns/pkg/dns/dns.go:192: Failed to list *v1.Service: Get https://10.96.0.1:443/api/v1/services?resourceVersion=0: dial tcp 10.96.0.1:443: getsockopt: no route to host

...

Почему пытаются подключиться к порту 443? Могу ли я изменить это - похоже, нет флага порта? Это должен быть порт 443 по какой-то причине?

Это 10.96.0.1 из CIDR службы вашего кластера, который (и должен быть) отделен от CIDR Pod, который должен быть отделен от подсетей узла и т. Д. .1 CIDR службы кластера либо зарезервирован (или традиционно выделен) kubernetes.default.svc.cluster.localServiceсо своим Service.port как 443,

Я не очень уверен, почему --master флаг не заменяет значение в /etc/kubernetes/kube-proxy.conf но так как этот файл очень явно должен использоваться только kube-proxyпочему бы просто не обновить значение в файле, чтобы убрать все сомнения?