Блог

Главная - Вопросы по программированию - EKS Fargate подключается к локальной сети kubelet

EKS Fargate подключается к локальной сети kubelet

#kubernetes #amazon-eks #aws-fargate #kubelet #kubernetes-networking

#kubernetes #amazon-eks #aws-fargate #kubelet #kubernetes-сеть

Вопрос:

Я пытаюсь подключиться к kubelet, работающему на «поддельном узле», из модуля EKS fargate.

Например, у меня есть два модуля nginx с IP 10.0.0.1 -адресами, 10.0.0.2 размещенные на двух поддельных узлах с одинаковыми IP 10.0.0.1 -адресами и 10.0.0.2 .

Из модуля 10.0.0.1 я могу корректно работать с 10.0.0.2 :

 curl -X GET https://10.0.0.2:10250/stats/summary --header "Authorization: Bearer $TOKEN" --insecure

{
 "node": {
  "nodeName": "fargate-ip-10.0.0.2.us-east-2.compute.internal",
  "systemContainers": [
   {
    "name": "pods",
    "startTime": "2021-03-02T11:21:55Z",
   [...]
  • Но если я попытаюсь свернуть тот же хост 10.0.0.1:10250 , я получу отказ в подключении.
  • Выполнение того же самого из второго модуля приводит к противоположному результату, я могу запрашивать 10.0.0.1 и нет 10.0.0.2 .
  • Обратите внимание, что если я закручиваю порт 80, nginx отвечает правильно, поэтому кажется, что при подключении из самого модуля сеть не может понять, что хост может ответить на запрос
  • Более того, я знаю, что могу пройти через прокси ( curl -X GET https://172.20.0.1:443/api/v1/nodes/fargate-ip-10-0-0-1.us-east-2.compute.internal/stats/summary --header "Authorization: Bearer $TOKEN" --insecure ), но из-за некоторых ограничений это невозможно в моем сценарии

Комментарии:

1. Что именно вы хотели бы знать? Почему это не работает? Как заставить это работать? В этом вопросе мне не хватает части «вопрос»: D

Ответ №1:

Итак, в AWS Fargate модули и связанные узлы совместно используют IP-адрес:

 $ kubectl get pods -o=wide
NAME   READY   STATUS    RESTARTS   AGE   IP                NODE                                                       NOMINATED NODE   READINESS GATES
foo    1/1     Running   0          94m   192.168.152.183   fargate-ip-192-168-152-183.eu-central-1.compute.internal   <none>           <none>
$
$ kubectl get nodes -o=wide fargate-ip-192-168-152-183.eu-central-1.compute.internal
NAME                                                       STATUS   ROLES    AGE   VERSION              INTERNAL-IP       EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION                  CONTAINER-RUNTIME
fargate-ip-192-168-152-183.eu-central-1.compute.internal   Ready    <none>   92m   v1.18.9-eks-866667   192.168.152.183   <none>        Amazon Linux 2   4.14.209-160.339.amzn2.x86_64   containerd://1.4.1

Если вы проверите таблицу маршрутизации в модуле, вы обнаружите следующее:

 $ kubectl exec -i -t foo -- ip r get 192.168.152.183
local 192.168.152.183 dev lo src 192.168.152.183 uid 0
    cache <local>
$
$ kubectl exec -i -t foo -- ip r get 192.168.152.20 # Notice different IP address.
192.168.152.20 dev eth0 src 192.168.152.183 uid 0
    cache

Поэтому, если вы попытаетесь связаться со своим собственным IP-адресом из модуля Pod, трафик будет проходить через сетевой стек, локальный для контейнера, где kubelet недоступен.

При доступе извне вы сначала попадаете в базовую ОС хоста, на которой kubelet выполняется. Я предполагаю, что тогда выполняется какая-то магия, которая перенаправляет трафик в контейнер.

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

Я не знаю, есть ли другие способы сделать это непривилегированным способом.