Kubernetes: Minikube, та LoadBalancer в статусі “Pending”

Автор |  04/10/2022
0 коментарів
 

Після запуску Pritunl в Minikube неможливо підключитися до ВПН:

…
2022-10-03 13:50:32 TCP/UDP: Preserving recently used remote address: [AF_INET]194.168.3.100:1194
2022-10-03 13:50:32 UDP link local: (not bound)
2022-10-03 13:50:32 UDP link remote: [AF_INET]194.168.3.100:1194
…

Перевіряємо його Kubernetes Service:

[simterm]

$ kubectl -n pritunl-local get svc
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
pritunl           LoadBalancer   10.102.129.25   <pending>     1194:30166/TCP   47m
...

[/simterm]

Тип – LoadBalancer, але його EXTERNAL-IP – в статусі Pending, так як у Minikube немає сервісу з типом LoadBalancer, бо вони мають створюватися на рівні інфрастуктури – AWS, GCE, Azure, і потім вже від них Kubernetes отримує IP або URL, на який роутить запити до цього лоад-балансеру.

Рішення LoadBalancer <pending>

Для Мінікуба є декілька рішень:

  • затосувати minikube tunnel – зробить тунель між хостом та Сервісом в Кубернетесі
  • або minikube service – отримуємо прямий URL для підключення
  • або вказати externalIPs для Kubenetes LoadBalancer Service  – налаштувати його вручну

Спробуємо всі.

Minikube tunnel

Перевіряємо роути на хост-машині:

[simterm]

$ route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.1     0.0.0.0         UG    100    0        0 enp38s0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-9c291321e71a
192.168.3.0     0.0.0.0         255.255.255.0   U     100    0        0 enp38s0
192.168.59.0    0.0.0.0         255.255.255.0   U     0      0        0 vboxnet0

[/simterm]

Бачимо тут маршрут до нашого VirtualBox – 192.168.59.0 0.0.0.0 255.255.255.0 U 0 0 0 vboxnet0.

Запускаємо tunnel:

[simterm]

$ minikube tunnel
[sudo] password for setevoy: 
Status:
        machine: minikube
        pid: 333552
        route: 10.96.0.0/12 -> 192.168.59.107
        minikube: Running
        services: [pritunl]
    errors: 
                minikube: no errors
                router: no errors
                loadbalancer emulator: no errors
...

[/simterm]

Перевіряємо роути зараз – з’явився новий маршрут в мережу 10.96.0.0 (Kubernetes CIDR)  через 192.168.59.107 – це віртуалка з VirtualBox, на якій запущено сам Minikube:

[simterm]

$ route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.1     0.0.0.0         UG    100    0        0 enp38s0
10.96.0.0       192.168.59.107  255.240.0.0     UG    0      0        0 vboxnet0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-9c291321e71a
192.168.3.0     0.0.0.0         255.255.255.0   U     100    0        0 enp38s0
192.168.59.0    0.0.0.0         255.255.255.0   U     0      0        0 vboxnet0

[/simterm]

Перевіряємо Kubernetes LoadBalancer тепер:

[simterm]

$ kubectl -n pritunl-local get svc pritunl
NAME      TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
pritunl   LoadBalancer   10.102.129.25   10.102.129.25   1194:30166/TCP   54m

[/simterm]

“It works!” (c)

Minikube service

Запускаємо minikube service, вказуємо неймспейс та им’я Сервісу – Мінікуб поверне нам URL для подключення:

[simterm]

$ minikube service -n pritunl-local pritunl
|---------------|---------|--------------|-----------------------------|
|   NAMESPACE   |  NAME   | TARGET PORT  |             URL             |
|---------------|---------|--------------|-----------------------------|
| pritunl-local | pritunl | openvpn/1194 | http://192.168.59.108:32350 |
|---------------|---------|--------------|-----------------------------|
🎉  Opening service pritunl-local/pritunl in default browser...

[/simterm]

Тут 192.168.59.108 – адрес нашого серверу VirtualBox, а 32350 – NodePort на ньому, на якому працює Pritunl Server.

Також, можно вивести всі Kubernetes Service за допомогою list:

[simterm]

$ minikube service -n pritunl-local list
|---------------|-----------------|--------------|-----------------------------|
|   NAMESPACE   |      NAME       | TARGET PORT  |             URL             |
|---------------|-----------------|--------------|-----------------------------|
| pritunl-local | pritunl         | openvpn/1194 | http://192.168.59.108:32350 |
| pritunl-local | pritunl-mongodb | No node port |
| pritunl-local | pritunl-web     | No node port |
|---------------|-----------------|--------------|-----------------------------|

[/simterm]

Або отримати URL однією строкою замість таблиці:

[simterm]

$ kubectl -n priminikube service -n pritunl-local pritunl --url
http://192.168.59.108:32350

[/simterm]

Пробуємо підключитися:

[simterm]

$ telnet 192.168.59.108 32350
Trying 192.168.59.108...
Connected to 192.168.59.108.
Escape character is '^]'.

[/simterm]

Логи Pritunl:

“It works!” (c)

LoadBalancer externalIPs

Отримаємо IP машинки VirtualBox:

[simterm]

$ minikube ip
192.168.59.108

[/simterm]

Редагуємо LoadBalancer:

[simterm]

$ kubectl -n pritunl-local edit svc pritunl

[/simterm]

Вказуємо externalIPs:

...
  externalIPs:
  - 192.168.59.108
...

Збергіаємо, перевіряємо сам Service:

[simterm]

$ kubectl -n pritunl-local get svc pritunl
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
pritunl   LoadBalancer   10.104.33.93   192.168.59.108   1194:32350/TCP   81m

[/simterm]

Та підключення до нього:

[simterm]

$ telnet 192.168.59.108 1194
Trying 192.168.59.108...
Connected to 192.168.59.108.
Escape character is '^]'.

[/simterm]

“It works!” (c)

Готово.