Здравствуйте, Vetal_ca, Вы писали:
V_>- kubectl port forward
Нет, порт-форвард не подходит. Нужны нормальные полноценные IP-адреса, а не localhost:23523.
V_>- Что-то нативное Minicube
Чтобы использовать нативное Minicube, нужно запускать Minikube на локалхосте. А это — не работает в Win:
— в докере нетворк роутинг просто убит насмерть, там какое-то адское смешение всего со всем, которое невозможно починить
— в hyperV роутинг работает, но изнутри контейнеров во внешнюю сеть связи почти что нет — не всегда резолвятся имена, tcp льёт по 2-3 килобайта в секунду
V_>- Load balancer Service, Metallb.
Эммм, этот сервис вроде для baremetal minikube. А у меня — minikube внутри Ubuntu, которая внутри HyperV.
V_>- VPN воткнуть прямо в кластер и к нему соединяться. Тот же Zerotier или Tailscale. В VPN нужно добавить всю подсеть сервисов а то и подов. Тогда можно "ходить как у себя дома" по всему хозяйству
Выглядит правдоподобно. Но
1. Нужна бы пошаговая инструкция, т.к. тут слишком много движущихся частей, чтобы подбирать работоспособное сочетание методом тыка
2. А это будет дружить с офисной VPN, включённой параллельно?

Здравствуйте, Sinclair, Вы писали:

S>Нагуглить я не смог по этому поводу ничего — не могу подобрать такое сочетание ключевых слов, чтобы находилось что-то полезное.
S>Кто может что посоветовать по данному вопросу? Где и какие настройки подкрутить? Куда вообще смотреть?

Не работал с minikube, но с контейнерами помогает portproxy

netsh interface portproxy add v4tov4 listenport=443 connectaddress=127.0.0.1 connectport=21443

А так бы почитал про настройку сети в wsl2, кажется там я про portproxy и вычитал.

Здравствуйте, Sinclair, Вы писали:


S>Выглядит правдоподобно. Но
S>1. Нужна бы пошаговая инструкция, т.к. тут слишком много движущихся частей, чтобы подбирать работоспособное сочетание методом тыка

У тебя 2 клиента:

1. На хосте (Windows Zerotier)
2. Pod в Minicube

S>2. А это будет дружить с офисной VPN, включённой параллельно?

Да, это простая подсеть

Например,

172.25.12.0/24 — это подсеть Zerotier

172.25.12.1 — Zerotier Windows
172.25.12.2 — Zerotier Pod

Скажем,
10.16.0.0/16 — сервисы в миникуб
10.17.0.0/16 — pods



Я настраивал через Terraform, сейчас глянул код, в терминах resource "zerotier_network" "occams_router", https://github.com/zerotier/terraform-provider-zerotier

Через UI Zerotier, если потыкать, будут соответствующие поля:

`
...
route {
via = "172.25.12.2"
route = "10.16.0.0/16"
}
route {
via = "172.25.12.2"
route = "10.17.0.0/16"
}
...
`

Или объединенная route, `10.16.0.0/15`, == (10.16.0.0/16 + 10.17.0.0/16)

Настройки выше (терраформ), это настройки самих клиентов в terraform или Zerotier UI на сайте. После этого, если запустить клиент в Windows, то добавится route 10.16.0.0/15 (netstat -rn)

Сам Pod настраивается согласно https://hub.docker.com/r/zerotier/zerotier#!

Скопировал свой код в Терраформ, для кубернетес:

```
locals {
zt_net_id = var.zerotier.network_ids[var.zerotier.network]
zt_key_pair = var.zerotier.host_keys[var.zerotier.network][var.instance.name]
zt_secret = "zerotier"
zt_selector = {
app = "zerotier"
}

zt_mounts = {
secrets_path = "/data"
share_path = "/var/lib/zerotier-one"
share_mount = "share"
secrets_mount = "secrets"
}
zt_container_uid = 999
}

resource "kubernetes_secret" "zt" {
metadata {
name = local.zt_secret
namespace = local.ns
}
data = {
devicemap = "${local.zt_net_id}=${var.zerotier.interface}"
("identity.public") = local.zt_key_pair.public
("identity.secret") = local.zt_key_pair.private
}
}

resource "kubernetes_deployment" "zt" {
metadata {
name = "zerotier"
namespace = local.ns
}
spec {
replicas = 1

strategy {
// For the host network, the interface is busy, so Zerotier cannot start a new one since the old pod keeps the interface up
type = var.host_network ? "Recreate" : "RollingUpdate"
}
selector {
match_labels = local.zt_selector
}
template {
metadata {
labels = local.zt_selector
}
spec {
host_network = var.host_network
init_container {
name = "data-prep"
image = var.images.busy_box
command = [
"sh",
"-c",
# Copy and chown secrets
"cp -v ${local.zt_mounts.secrets_path}/* ${local.zt_mounts.share_path} && chown -R ${local.zt_container_uid}:${local.zt_container_uid} ${local.zt_mounts.share_path}"
]
volume_mount {
mount_path = local.zt_mounts.secrets_path
name = local.zt_mounts.secrets_mount
read_only = true
}
volume_mount {
mount_path = local.zt_mounts.share_path
name = local.zt_mounts.share_mount
}
}
container {
name = "zerotier"
image = var.images.zerotier
image_pull_policy = "IfNotPresent"
args = [local.zt_net_id]
security_context {
privileged = true
}
volume_mount {
mount_path = local.zt_mounts.share_path
name = local.zt_mounts.share_mount
}
}
volume {
name = local.zt_mounts.share_mount
empty_dir {}
}
volume {
name = local.zt_mounts.secrets_mount
secret {
secret_name = kubernetes_secret.zt.metadata[0].name
}
}
}
}
}
}
```

По коду, внутрь добавил mounts с ключами Zerotier. Если поиграть с контейнером по ссылке с докур хаб, то будет понятно о чем речь.

Код (персональный) с 2022-08-05, деталей не очень помню. Но, думаю, поможет

Здравствуйте, amironov79, Вы писали:
A>Не работал с minikube, но с контейнерами помогает portproxy
A>

netsh interface portproxy add v4tov4 listenport=443 connectaddress=127.0.0.1 connectport=21443

Эмм, это конечно здорово, но как мне это поможет получить роутинг на IP-адрес вида 192.168.58.2?
Порт-форвардинг — это костыль, который помогает поотлаживать узкопрофильные сервисы, у которых наружу торчит один ендпоинт и больше им ничего не нужно.
А для полноценной работы с веб-приложениями, у которых на одном адресе поднято несколько ендпоинтов, различающихся по Host header, это непригодно.

A>А так бы почитал про настройку сети в wsl2, кажется там я про portproxy и вычитал.
Сеть в wsl2 и сама по себе работает из рук вон плохо. См. напр. https://github.com/microsoft/WSL/issues/11011

Здравствуйте, Vetal_ca, Вы писали:
V_>У тебя 2 клиента:
Спасибо, попробую разобраться.
Там ещё Pod-ы поднимаю не я, а Eclipse Che. Нужно будет выяснить, как там ему запихать этого клиента в Workspace pod.

Здравствуйте, Sinclair, Вы писали


S>Там ещё Pod-ы поднимаю не я, а Eclipse Che. Нужно будет выяснить, как там ему запихать этого клиента в Workspace pod.

Запихивать не нужно — просто самодостаточный Deployment/Pod в кластере, не зависящий от остального. Обеспечивающий доступ извне

Здравствуйте, Sinclair, Вы писали:

S>Эмм, это конечно здорово, но как мне это поможет получить роутинг на IP-адрес вида 192.168.58.2?
S>Порт-форвардинг — это костыль, который помогает поотлаживать узкопрофильные сервисы, у которых наружу торчит один ендпоинт и больше им ничего не нужно.

Мне помогло выставить сервисы наружу. Если это не твой случай, то извини

S>А для полноценной работы с веб-приложениями, у которых на одном адресе поднято несколько ендпоинтов, различающихся по Host header, это непригодно.

Это вообще здесь причем? Настройка сети и настройка reverse proxy -- разные задачи.

Здравствуйте, Sinclair, Вы писали:

S>Эмм, это конечно здорово, но как мне это поможет получить роутинг на IP-адрес вида 192.168.58.2?
S>Порт-форвардинг — это костыль, который помогает поотлаживать узкопрофильные сервисы, у которых наружу торчит один ендпоинт и больше им ничего не нужно.
S>А для полноценной работы с веб-приложениями, у которых на одном адресе поднято несколько ендпоинтов, различающихся по Host header, это непригодно.

Порт форвардинг просто локальный порт пробрасывает внутрь minikube.
С разными доменными адресами — это вопрос к DNS.
Либо в файле hosts нужные адреса заворачивать на 127.0.0.1,
либо с аддоном ingress-dns разбираться

Здравствуйте, karbofos42, Вы писали:

K>Порт форвардинг просто локальный порт пробрасывает внутрь minikube.
Отож.
K>С разными доменными адресами — это вопрос к DNS.
Вопрос не в доменных адресах, а в IP адресах.
K>Либо в файле hosts нужные адреса заворачивать на 127.0.0.1,
Да, я это пробовал. В итоге лучшее, что удалось получить — internal error 500. Где-то видать какой-то из компонентов не может дойти до другого по этому подменённому адресу.
Так что нет, роутинг в докер десктоп сломан надёжно.