Я изо всех сил пытаюсь понять, как правильно настроить 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}
}
]
}
Edit:
Только что наткнулся на это с 2016 года:
По состоянию на несколько недель назад (я забыл релиз, но это был 1.2.x где х
! = 0) (# 24429) мы исправили маршрутизацию так, чтобы любой трафик приходил
на узле, предназначенном для службы IP, будет обрабатываться так, как если бы он пришел к
порт узла. Это означает, что вы должны иметь возможность устанавливать статические маршруты для
диапазон IP-адресов вашего кластера услуг до одного или нескольких узлов, и узлы будут
действовать как мосты. Это та же самая уловка, которую большинство людей делают с фланелевой
мост оверлея.
Это несовершенно, но работает. В будущем нужно будет получить больше
Точный с маршрутизацией, если вы хотите оптимального поведения (то есть не теряя
IP-адрес клиента), или мы увидим больше реализаций не-Kube-прокси
услуги.
Это все еще актуально? Нужно ли устанавливать статический маршрут для службы 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
Edit:
После просмотра шагов отладки 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?