Регистрация Войти
Рейтинг:2
avatar Server

kube-proxy не работает для IP-адресов сервисного кластера

флаг es
derabbink

Я установил кластер k8s 1.23.3 на четыре raspberry pi под управлением raspberrypi OS 11 (яблочко) рука64; в основном следуя это руководство.
Суть в том, что плоскость управления была создана с помощью этой команды

kubeadm init --token={some_token} --kubernetes-version=v1.23.3 --pod-network-cidr=10.1.0.0/16 --service-cidr=10.11.0.0/16 --control-plane-endpoint= 10.0.4.16 --имя-узла=rpi-1-1

Затем я создал свой собственный kube-проверить пространство имен, поместите развертывание эхо-сервер в него и создал для него службу.

Однако, Я не могу получить доступ к IP-адресу кластера службы ни с одного из узлов. Почему? Запросы просто истекают, в то время как запросы к IP-адресу кластера модуля работают нормально.
я подозреваю, что мой kube-прокси не работает как надо. Ниже то, что я исследовал до сих пор.

$ kubectl получить услуги -n kube-verify -o=wide

НАЗВАНИЕ ТИП КЛАСТЕР-IP ВНЕШНИЙ-IP ПОРТ(Ы) ВЫБОР ВОЗРАСТА
echo-server ClusterIP 10.11.213.180 <нет> 8080/TCP 24h app=echo-server

$ kubectl get pods -n kube-system -o=wide

НАЗВАНИЕ ГОТОВНОСТЬ СТАТУС ПЕРЕЗАПУСКИ ВОЗРАСТ IP УЗЛА НАЗНАЧЕННЫЙ УЗЕЛ ГОТОВНОСТЬ ВОРОТА
coredns-64897985d-47gpr 1/1 Запуск 1 (69 м назад) 41 час 10.1.0.5 rpi-1-1 <none> <none>
coredns-64897985d-nf55w 1/1 Запуск 1 (69 м назад) 41h 10.1.0.4 rpi-1-1 <none> <none>
etcd-rpi-1-1 1/1 Запуск 2 (69 м назад) 41 час 10.0.4.16 rpi-1-1 <none> <none>
kube-apiserver-rpi-1-1 1/1 Запуск 2 (69 м назад) 41h 10.0.4.16 rpi-1-1 <none> <none>
kube-controller-manager-rpi-1-1 1/1 Запуск 2 (69 м назад) 41h 10.0.4.16 rpi-1-1 <none> <none>
kube-flannel-ds-5467m 1/1 Бег 1 (69 м назад) 28h 10.0.4.17 rpi-1-2 <none> <none>
kube-flannel-ds-7wpvz 1/1 Бег 1 (69м назад) 28h 10.0.4.18 rpi-1-3 <none> <none>
kube-flannel-ds-9chxk 1/1 Бег 1 (69 м назад) 28 ч 10.0.4.19 rpi-1-4 <none> <none>
kube-flannel-ds-x5rvx 1/1 Бег 1 (69 м назад) 29h 10.0.4.16 rpi-1-1 <none> <none>
kube-proxy-8bbjn 1/1 Запуск 1 (69 м назад) 28 ч 10.0.4.17 rpi-1-2 <none> <none>
kube-proxy-dw45d 1/1 Выполняется 1 (69 м назад) 28 ч 10.0.4.18 rpi-1-3 <none> <none>
kube-proxy-gkkxq 1/1 Запуск 2 (69 м назад) 41 ч 10.0.4.16 rpi-1-1 <none> <none>
kube-proxy-ntl5w 1/1 Запуск 1 (69 м назад) 28 ч 10.0.4.19 rpi-1-4 <none> <none>
kube-scheduler-rpi-1-1 1/1 Запуск 2 (69 м назад) 41h 10.0.4.16 rpi-1-1 <none> <none>

$ kubectl регистрирует kube-proxy-gkkxq -n kube-system

I0220 13:52:02.281289 1 node.go:163] Успешно получен IP-адрес узла: 10.0.4.16
I0220 13:52:02.281535 1 server_others.go:138] «IP-адрес обнаруженного узла» = «10.0.4.16»
I0220 13:52:02.281610 1 server_others.go:561] «Неизвестный режим прокси, предполагается прокси-сервер iptables» proxyMode=""
I0220 13:52:02.604880 1 server_others.go:206] «Использование прокси-сервера iptables»
I0220 13:52:02.604966 1 server_others.go:213] «kube-proxy работает в режиме двойного стека» ipFamily=IPv4
I0220 13:52:02.605026 1 server_others.go:214] «Создание dualStackProxier для iptables»
I0220 13:52:02.605151 1 server_others.go:491] «Режим Detect-local-mode установлен на ClusterCIDR, но CIDR кластера IPv6 не определен, по умолчанию для IPv6 установлено значение no-op detect-local»
I0220 13:52:02.606905 1 server.go:656] «Информация о версии» version="v1.23.3"
W0220 13:52:02.614777 1 sysinfo.go:203] Топология узлов недоступна, указана топология ЦП
I0220 13:52:02.619535 1 conntrack.go:52] «Настройка nf_conntrack_max» nf_conntrack_max=131072
I0220 13:52:02.620869 1 conntrack.go:100] «Установить sysctl» entry="net/netfilter/nf_conntrack_tcp_timeout_close_wait" value=3600
I0220 13:52:02.660947 1 config.go:317] «Запуск контроллера конфигурации службы»
I0220 13:52:02.661015 1 shared_informer.go:240] Ожидание синхронизации кешей для конфигурации службы
I0220 13:52:02.662669 1 config.go:226] «Запуск контроллера конфигурации сегмента конечной точки»
I0220 13:52:02.662726 1 shared_informer.go:240] Ожидание синхронизации кешей для конфигурации фрагмента конечной точки
I0220 13:52:02.762734 1 shared_informer.go:247] Кэши синхронизируются для конфигурации службы 
I0220 13:52:02.762834 1 shared_informer.go:247] Кэши синхронизируются для конфигурации фрагмента конечной точки

Что я замечаю здесь, так это то, что Топология узлов недоступна, поэтому я еще немного покопался в конфиге kube-proxy, но ничего не выделяется.
Если действительно есть проблема с топологией узлов в моем кластере, пожалуйста, направьте меня к некоторым ресурсам о том, как устранить эту проблему, поскольку я не смог найти ничего значимого на основе этого сообщения об ошибке.

$ kubectl описать configmap kube-proxy -n kube-system

Имя: kube-прокси
Пространство имен: kube-system
Ярлыки: app=kube-proxy
Аннотации: kubeadm.kubernetes.io/component-config.hash: sha256:edce433d45f2ed3a58ee400690184ad033594e8275fdbf52e9c8c852caa7124d

Данные
====
конфиг.конф:
----
apiVersion: kubeproxy.config.k8s.io/v1alpha1
адрес привязки: 0.0.0.0
bindAddressHardFail: ложь
клиентское соединение:
  принятьContentTypes: ""
  взрыв: 0
  Тип содержимого: ""
  kubeconfig: /var/lib/kube-proxy/kubeconfig.conf
  запросов в секунду: 0
кластерCIDR: 10.1.0.0/16
configSyncPeriod: 0 с
связь:
  максперкоре: ноль
  мин: ноль
  tcpCloseWaitTimeout: ноль
  tcpEstablishedTimeout: ноль
обнаружитьлокалмоде: ""
включить профилирование: ложь
HealthzBindAddress: ""
hostnameOverride: ""
IP-таблицы:
  маскарадВсе: ложь
  masqueradeBit: ноль
  минсинкпериод: 0 с
  период синхронизации: 0 с
IPvs:
  excludeCIDRs: ноль
  минсинкпериод: 0 с
  планировщик: ""
  строгийARP: ложь
  период синхронизации: 0 с
  tcpFinTimeout: 0 с
  tcpTimeout: 0 с
  udpTimeout: 0 с
вид: KubeProxyConfiguration
метриксбиндадрес: ""
Режим: ""
Адреса узловых портов: ноль
oomScoreAdj: ноль
диапазон портов: ""
showHiddenMetricsForVersion: ""
удпидлетаймаут: 0 с
винкернел:
  включитьDSR: ложь
  имя сети: ""
  ИсточникВип: ""
kubeconfig.conf:
----
апиВерсия: v1
вид: Конфигурация
кластеры:
- кластер:
    центр сертификации: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    сервер: https://10.0.4.16:6443
  имя: по умолчанию
контексты:
- контекст:
    кластер: по умолчанию
    пространство имен: по умолчанию
    пользователь: по умолчанию
  имя: по умолчанию
текущий контекст: по умолчанию
пользователи:
- имя: по умолчанию
  пользователь:
    tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

Двоичные данные
====

События: <нет>

$ kubectl -n kube-system exec kube-proxy-gkkxq cat /var/lib/kube-proxy/kubeconfig.conf

kubectl exec [POD] [COMMAND] УСТАРЕЛ и будет удален в будущей версии. Вместо этого используйте kubectl exec [POD] -- [COMMAND].
апиВерсия: v1
вид: Конфигурация
кластеры:
- кластер:
    центр сертификации: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    сервер: https://10.0.4.16:6443
  имя: по умолчанию
контексты:
- контекст:
    кластер: по умолчанию
    пространство имен: по умолчанию
    пользователь: по умолчанию
  имя: по умолчанию
текущий контекст: по умолчанию
пользователи:
- имя: по умолчанию
  пользователь:
    tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token

Режим по умолчанию iptables, как подтверждают логи выше.
У меня также включена IP-переадресация на всех узлах.

$ судо sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
455
0 + 0
moonkotte avatar
флаг in
moonkotte
Кажется, есть проблема с подсетями: сетевой cidr модуля — «10.1.0.0/16», а конечная точка плоскости управления фактически находится в сетевом cidr модуля (поскольку это «10.1.0.4»). Также вы меняли `pod network cidr`, когда устанавливали `flannel`? По умолчанию используется другой cidr.
0
Ответить
флаг es
derabbink
Я установил фланель следующим образом: `kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.16.3/Documentation/kube-flannel.yml`. В моей команде `kubeadm init` были установлены флаги `--pod-network-cidr=10.1.0.0/16` и `--control-plane-endpoint=10.0.4.16`
0
Ответить
moonkotte avatar
флаг in
moonkotte
Вы можете проверить, что находится внутри, в конфигурации yaml фланели. Вы увидите, что «Сеть»: «10.244.0.0/16» настроена на другую подсеть, чем вы инициализировали кластер с параметром «--pod-network-cidr=10.1.0.0/16». У вас есть 2 варианта исправить это: вы можете изменить подсеть в yaml of flannel на такую ​​же, как `--pod-network-cidr=10.1.0.0/16`, или вы можете уничтожить свой кластер и начать с той же подсети, что и в yaml фланель `"Сеть": "10.244.0.0/16"`
0
Ответить
флаг es
derabbink
Спасибо. Это помогло. Если хотите, вы можете создать ответ, и я обязательно приму его. И я мог бы впоследствии предложить редактирование, которое добавляет скрипт для автоматической перезаписи этого файла YAML с использованием `yq` и `jq`
0
Ответить
moonkotte avatar
флаг in
moonkotte
Конечно, спасибо. Мой друг @radekw опубликует ответ для меня, так как ему нужна репутация + он дал мне это предложение. Не стесняйтесь принять это и предложить редактирование.
0
Ответить
Рейтинг:1
RadekW avatar Server
флаг cn
RadekW

Фланель можно установить, применив манифест из репозитория.

Flannel можно добавить в любой существующий кластер Kubernetes, хотя проще всего добавить фланель до того, как будут запущены какие-либо модули, использующие сеть модулей. Для Kubernetes v1.17+ kubectl применить -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Как вы можете видеть в этом батат файл по умолчанию подсеть сети установлена ​​​​на 10.244.0.0/16

  сеть-conf.json: |
    {
      «Сеть»: «10.244.0.0/16»,
      "Бэкенд": {
        "Тип": "vxlan"
      }

инициализация кубеадм это команда для запуска кластера, для которого требуется указать подсеть для сети кластера, и она должна совпадать с подсетью в вашем CNI. Вы можете проверить больше параметры.

--pod-network-cidr строка Укажите диапазон IP-адресов для сети модулей. Если установлено, плоскость управления будет автоматически выделять CIDR для каждого узла.

Вы инициировали кластер с --pod-network-cidr=10.1.0.0/16 и подсеть вашего кластера была установлена ​​​​отличной от подсети в файле yaml фланелевого манифеста "10.244.0.0/16" и именно поэтому это не сработало.

Есть два варианта исправить это:
Первое - изменить подсеть в yaml конфигурации фланеля на ту, которая применялась при инициализации кластера, в данном случае это --pod-network-cidr=10.1.0.0/16 (см. скрипт ниже)
ИЛИ ЖЕ
Во-вторых, если кластер предназначен для тестирования и был только что инициализирован, то уничтожьте кластер и начните с той же подсети, что и yaml конфигурации фланеля. «Сеть»: «10.244.0.0/16»

Для автоматического изменения кубе-фланель.yml, следующий скрипт на основе yq и jq можно использовать команды:

#!/бин/баш

ввод=$1
вывод=$2

echo "Преобразование $input в $output"

netconf=$( yq '. | select(.kind == "ConfigMap") | select(.metadata.name == "kube-flannel-cfg") | .data."net-conf.json"' "$input " | jq 'fromjson | .Network="10.1.0.0/16"' | yq -R '.' )
kube_flannel_cfg=$( yq --yaml-output '. | select(.kind == "ConfigMap") | select(.metadata.name == "kube-flannel-cfg") | .data."net-conf.json "='"$netconf" "$input" )
Everything_else=$( yq --yaml-output '. | select(.kind != "ConfigMap") | select(.metadata.name != "kube-flannel-cfg")' "$input" )
эхо "$kube_flannel_cfg" >> "$ вывод"
эхо '---' >> "$ output"
эхо "$everything_else" >> "$ output"
0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.