Kubernetes: Weave выбрал публичный IP-адрес на одном из рабочих узлов

У меня есть 2 мастерских и 2 рабочих кластера Kubernetes. Каждый узел имеет частный IP-адрес в диапазоне 192.168.5.X и общедоступный IP-адрес. После создания демона Weave модуль Weave выбрал правильный внутренний IP-адрес на одном узле, а на другом - общедоступный IP-адрес. Есть ли способ указать модулю Weave на выбор частного IP-адреса на узле?

Я создаю кластер с нуля, делая все вручную на виртуальных машинах, созданных в Virtual Box на локальном ноутбуке. Я ссылаюсь на ссылку ниже

https://github.com/mmumshad/kubernetes-the-hard-way

После развертывания модулей weave на рабочем узле, модуль weave на одном из рабочих узлов использует IP-адрес NAT, как показано ниже.

10.0.2.15 - это IP-адрес NAT, а 192.168.5.12 - это внутренний IP-адрес.

kubectl get pods -n kube-system -o wide
NAME              READY   STATUS    RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
weave-net-p4czj   2/2     Running   2          26h   192.168.5.12   worker1   <none>           <none>
weave-net-pbb86   2/2     Running   8          25h   10.0.2.15      worker2   <none>           <none>
[@master1 ~]$ kubectl describe node
Name:               worker1
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/hostname=worker1
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Tue, 10 Dec 2019 02:07:09 -0500
Taints:             <none>
Unschedulable:      false
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Wed, 11 Dec 2019 04:50:15 -0500   Wed, 11 Dec 2019 04:50:15 -0500   WeaveIsUp                    Weave pod has set this
  MemoryPressure       False   Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 02:09:09 -0500   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 02:09:09 -0500   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 02:09:09 -0500   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 04:16:26 -0500   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:  192.168.5.12
  Hostname:    worker1
Capacity:
 cpu:                1
 ephemeral-storage:  14078Mi
 hugepages-2Mi:      0
 memory:             499552Ki
 pods:               110
Allocatable:
 cpu:                1
 ephemeral-storage:  13285667614
 hugepages-2Mi:      0
 memory:             397152Ki
 pods:               110
System Info:
 Machine ID:                 455146bc2c2f478a859bf39ac2641d79
 System UUID:                D4C6F432-3C7F-4D27-A21B-D78A0D732FB6
 Boot ID:                    25160713-e53e-4a9f-b1f5-eec018996161
 Kernel Version:             4.4.206-1.el7.elrepo.x86_64
 OS Image:                   CentOS Linux 7 (Core)
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://18.6.3
 Kubelet Version:            v1.13.0
 Kube-Proxy Version:         v1.13.0
Non-terminated Pods:         (2 in total)
  Namespace                  Name                   CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                   ------------  ----------  ---------------  -------------  ---
  default                    ng1-6677cd8f9-hws8n    0 (0%)        0 (0%)      0 (0%)           0 (0%)         26h
  kube-system                weave-net-p4czj        20m (2%)      0 (0%)      0 (0%)           0 (0%)         26h
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests  Limits
  --------           --------  ------
  cpu                20m (2%)  0 (0%)
  memory             0 (0%)    0 (0%)
  ephemeral-storage  0 (0%)    0 (0%)
Events:              <none>


Name:               worker2
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/hostname=worker2
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Tue, 10 Dec 2019 03:14:01 -0500
Taints:             <none>
Unschedulable:      false
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Wed, 11 Dec 2019 04:50:32 -0500   Wed, 11 Dec 2019 04:50:32 -0500   WeaveIsUp                    Weave pod has set this
  MemoryPressure       False   Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 03:14:03 -0500   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 03:14:03 -0500   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 03:14:03 -0500   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Wed, 11 Dec 2019 07:13:43 -0500   Tue, 10 Dec 2019 03:56:47 -0500   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:  10.0.2.15
  Hostname:    worker2
Capacity:
 cpu:                1
 ephemeral-storage:  14078Mi
 hugepages-2Mi:      0
 memory:             499552Ki
 pods:               110
Allocatable:
 cpu:                1
 ephemeral-storage:  13285667614
 hugepages-2Mi:      0
 memory:             397152Ki
 pods:               110
System Info:
 Machine ID:                 455146bc2c2f478a859bf39ac2641d79
 System UUID:                68F543D7-EDBF-4AF6-8354-A99D96D994EF
 Boot ID:                    5775abf1-97dc-411f-a5a0-67f51cc8daf3
 Kernel Version:             4.4.206-1.el7.elrepo.x86_64
 OS Image:                   CentOS Linux 7 (Core)
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://18.6.3
 Kubelet Version:            v1.13.0
 Kube-Proxy Version:         v1.13.0
Non-terminated Pods:         (2 in total)
  Namespace                  Name                    CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                    ------------  ----------  ---------------  -------------  ---
  default                    ng2-569d45c6b5-ppkwg    0 (0%)        0 (0%)      0 (0%)           0 (0%)         26h
  kube-system                weave-net-pbb86         20m (2%)      0 (0%)      0 (0%)           0 (0%)         26h
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests  Limits
  --------           --------  ------
  cpu                20m (2%)  0 (0%)
  memory             0 (0%)    0 (0%)
  ephemeral-storage  0 (0%)    0 (0%)
Events:              <none>

person Lijo    schedule 10.12.2019    source источник
comment
Не могли бы вы добавить больше информации к вашему вопросу? Вывод команд, показывающих это поведение, какой облачный провайдер вы используете, если вы следуете инструкциям (поделиться). Чем больше информации вы дадите, тем легче будет выяснить, что происходит.   -  person Mark Watney    schedule 11.12.2019
comment
Обновил вопрос с дополнительной информацией   -  person Lijo    schedule 11.12.2019
comment
Какой результат для $ kubectl describe nodes?   -  person Mark Watney    schedule 11.12.2019
comment
Обновлен вывод выше   -  person Lijo    schedule 11.12.2019
comment
Я вижу, что у вас разные IP-адреса не только в ваших подах, но и в ваших узлах. Как вы можете видеть в выходных данных kubectl describe node InternalIP для worker1 - 192.168.5.12, а для worker2 - 10.0.2.15. Этого не ожидается, поэтому убедитесь, что вы подключили обе виртуальные машины VirtualBox с одним и тем же типом адаптера. Оба должны быть в одной сети, и кажется, что это не так, и это объясняет такое поведение.   -  person Mark Watney    schedule 12.12.2019
comment
Спасибо mWatney за указание на это. Я очень скучал по этому поводу. Первый узел, который я добавил в кластер вручную, а второй узел был добавлен с помощью загрузочной ленты TLS. Что-то пошло не так в этом процессе.   -  person Lijo    schedule 12.12.2019


Ответы (1)


Я вижу, что у вас разные IP-адреса не только в ваших подах, но и в ваших узлах.

Как вы можете видеть в kubectl describe node выводе InternalIP для worker1 это 192.168.5.12, а для worker2 10.0.2.15.

Это не ожидаемое поведение, поэтому важно убедиться, что вы подключили обе виртуальные машины VirtualBox к одному и тому же типу адаптера.

Оба должны быть в одной сети, и в комментариях вы подтвердили, что это так, и это объясняет такое поведение.

Вот пример такой конфигурации:

Настройки адаптера VirtualBox

Как вы упомянули в комментариях, первый узел был добавлен вручную, а второй был добавлен во время начальной загрузки TLS, и он был добавлен даже с «неправильным» IP-адресом.

Лучшее, что вы можете сделать, чтобы решить эту проблему, - это снова запустить кластер с нуля, используя те же настройки адаптера в Virtual Box для всех узлов.

person Mark Watney    schedule 12.12.2019
comment
Все узлы, включая мастер, имеют 2 интерфейса. Один адаптер только для хоста для внутреннего трафика и один адаптер Nat для Интернета. Первый рабочий узел выбрал адаптер только для хоста, а второй узел по какой-то причине выбрал адаптер Nat. - person Lijo; 12.12.2019
comment
Я жестко выполнил все инструкции из учебника Kubernetes, используя VirtualBox, и для меня все работает, как ожидалось. Я бы посоветовал вам снова следовать руководству и запустить новый кластер, чтобы увидеть, возникнет ли такая же проблема. - person Mark Watney; 13.12.2019
comment
Я добавил частный IP-адрес рабочего узла как параметр --node-ip в служебном файле kubelet, и чтение узла в кластер прошло нормально. также пришлось очистить базу данных плетения на 2 рабочих узлах и воссоздать блоки плетения, чтобы сеть работала должным образом. Теперь все хорошо. Большое спасибо за помощь :) - person Lijo; 13.12.2019