Блог

Я установил кластер kubernetes Azure с помощью kubespray 2.13.2 . Но после того, как я установил некоторые модули компонентов моей платформы данных, я заметил, что модули, работающие на одном узле, не могут получить доступ друг к другу через сервис.

Например, мой координатор presto должен получить доступ к метастору улья. Давайте посмотрим службы в моем пространстве имен:

 kubectl get svc -n ai-developer
NAME                                              TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                      AGE
metastore                                 ClusterIP      10.233.12.66    <none>           9083/TCP                     4h53m
  

Вызывается служба метастора улья metastore , через которую мой координатор presto должен получить доступ к модулю метастора улья.
Давайте посмотрим на следующие модули в моем пространстве имен:

 kubectl get po -n ai-developer -o wide
NAME                                          READY   STATUS      RESTARTS   AGE     IP             NODE       NOMINATED NODE   READINESS GATES
metastore-5544f95b6b-cqmkx                    1/1     Running     0          9h      10.233.69.20   minion-3   <none>           <none>
presto-coordinator-796c4c7bcd-7lngs           1/1     Running     0          5h32m   10.233.69.29   minion-3   <none>           <none>
presto-worker-0                               1/1     Running     0          5h32m   10.233.67.52   minion-1   <none>           <none>
presto-worker-1                               1/1     Running     0          5h32m   10.233.70.24   minion-4   <none>           <none>
presto-worker-2                               1/1     Running     0          5h31m   10.233.68.24   minion-2   <none>           <none>
presto-worker-3                               1/1     Running     0          5h31m   10.233.71.27   minion-0   <none>           <none>
  

Взгляните на модуль хранилища метафор улья metastore-5544f95b6b-cqmkx , который запущен на узле minion-3 , на котором также запущен модуль координатора presto presto-coordinator-796c4c7bcd-7lngs .

Я настроил URL thrift://metastore:9083 -адрес метахрана улья для свойств улья для каталога ульев в координаторе presto. Когда модули presto запущены на том же узле, где запущен модуль хранилища метастазов улья, они не могут получить доступ к моему хранилищу метастазов улья, но модуль, работающий на другом узле, где хранилище метастазов улья не запущено, может получить доступ к service хранилищу метастазов улья очень хорошо.

Я упомянул только один пример, но на данный момент я столкнулся с несколькими другими случаями, подобными этому примеру.

kubenet устанавливается как сетевой плагин в моем кластере kubernetes, установленном с включенным kubespray azure :

 /usr/local/bin/kubelet --logtostderr=true --v=2 --node-ip=10.240.0.4 --hostname-override=minion-3 --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --config=/etc/kubernetes/kubelet-config.yaml --kubeconfig=/etc/kubernetes/kubelet.conf --pod-infra-container-image=k8s.gcr.io/pause:3.1 --runtime-cgroups=/systemd/system.slice --hairpin-mode=promiscuous-bridge --network-plugin=kubenet --cloud-provider=azure --cloud-config=/etc/kubernetes/cloud_config
  

Есть идеи?

Пожалуйста, проверьте, является ли политика переадресации цепочки iptables по умолчанию ПРИНЯТОЙ. В моем случае, установите политику прямой цепочки по умолчанию с drop на accept, связь между узлами работает хорошо.

возможно, вы сможете преодолеть эту проблему, используя полное имя, которое k8s предоставляет вам для разрешения служебных IP-адресов, как описано в документах k8s введите описание ссылки здесь.

В вашем случае это, вероятно, будет означать изменение вашего thrift://metastore:9083 свойства на thrift://metastore.ai-developer.svc.cluster.local (при условии, конечно, что ваш домен кластера настроен на cluster.local )

После того, как я сменил ipvs режим прокси-сервера kube на iptables , он работает нормально!