Metallb с входным контроллером nginx на minkube продолжает сбрасывать внешний IP для входа
Пример MCVE находится здесь: https://github.com/chrissound/k8s-metallb-nginx-ingress-minikube(просто запустите ./init.sh а также minikube addons enable ingress).
IP-адрес, присвоенный входу, продолжает сбрасываться, я не знаю, что его вызывает? Нужна ли мне дополнительная настройка?
kubectl get ingress --all-namespaces
NAMESPACE NAME HOSTS ADDRESS PORTS AGE
chris-example app-ingress example.com 192.168.122.253 80, 443 61m
И через минуту:
NAMESPACE NAME HOSTS ADDRESS PORTS AGE
chris-example app-ingress example.com 80, 443 60m
С точки зрения конфигурации я только что применил:
# metallb
kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
# nginx
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/mandatory.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/service-nodeport.yaml
входной контроллер регистрирует журналы:
I0714 22:00:38.056148 7 event.go:258] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"chris-example", Name:"app-ingress", UID:"cbf3b5bf-a67a-11e9-be9a-a4cafa3aa171", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"8681", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress chris-example/app-ingress
I0714 22:01:19.153298 7 event.go:258] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"chris-example", Name:"app-ingress", UID:"cbf3b5bf-a67a-11e9-be9a-a4cafa3aa171", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"8743", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress chris-example/app-ingress
I0714 22:01:38.051694 7 status.go:296] updating Ingress chris-example/app-ingress status from [{192.168.122.253 }] to []
I0714 22:01:38.060044 7 event.go:258] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"chris-example", Name:"app-ingress", UID:"cbf3b5bf-a67a-11e9-be9a-a4cafa3aa171", APIVersion:"networking.k8s.io/v1beta1", ResourceVersion:"8773", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress chris-example/app-ingress
И контроллер metalb записывает:
{"caller":"main.go:72","event":"noChange","msg":"service converged, no change","service":"kube-system/kube-dns","ts":"2019-07-14T21:58:39.656725017Z"}
{"caller":"main.go:73","event":"endUpdate","msg":"end of service update","service":"kube-system/kube-dns","ts":"2019-07-14T21:58:39.656741267Z"}
{"caller":"main.go:49","event":"startUpdate","msg":"start of service update","service":"chris-example/app-lb","ts":"2019-07-14T21:58:39.6567588Z"}
{"caller":"main.go:72","event":"noChange","msg":"service converged, no change","service":"chris-example/app-lb","ts":"2019-07-14T21:58:39.656842026Z"}
{"caller":"main.go:73","event":"endUpdate","msg":"end of service update","service":"chris-example/app-lb","ts":"2019-07-14T21:58:39.656873586Z"}
В качестве теста я удалил развертывание + демон, относящийся к metallb:
kubectl delete deployment -n metallb-system controller
kubectl delete daemonset -n metallb-system speaker
И после того, как внешний IP установлен, он снова будет сброшен...
1 ответ
Мне было любопытно, и я воссоздал ваш случай. Мне удалось правильно выставить сервис.
Прежде всего: вам не нужно использовать аддон minikube ingress при развертывании собственного NGINX. Если вы это сделаете, у вас есть 2 входных контроллера в кластере, и это приведет к путанице позже. Пробег:minikube addons disable ingress
Примечание: вы можете увидеть эту путаницу в IP-адресе, назначенном вашему входу: 192.168.122.253 который не входит в диапазон CIDR 192.168.39.160/28 вы определили в configmap-metallb.yaml.
Вам необходимо изменить тип услуги ingress-nginx к LoadBalancer. вы можете сделать это, запустив:
kubectl edit -n ingress-nginx service ingress-nginx
Дополнительно вы можете изменить app-lb служение NodePort, поскольку его не нужно открывать за пределами кластера - об этом позаботится контроллер входящего трафика.
Объяснение
Легче думать о Ingress объект по состоянию на ConfigMap, скорее, чем Service.
MetalLB принимает конфигурацию, которую вы предоставили в ConfigMapи ожидает вызова API IP-запроса. Когда он его получает, он предоставляет IP из указанного вами диапазона CIDR.
Аналогичным образом входной контроллер (NGINX в вашем случае) принимает конфигурацию, описанную в Ingress объект и использует его для маршрутизации трафика в желаемое место в кластере.
потом ingress-nginx сервис предоставляется за пределами кластера с назначенным IP.
Входящий трафик направляется Ingress-контроллером (NGINX) в соответствии с правилами, описанными в Ingress возражать против службы шрифтом вашего приложения.
Диаграмма
Inbound
traffic
++ +---------+
|| |ConfigMap|
|| +--+------+
|| |
|| | CIDR range to provision
|| v
|| +--+----------+
|| |MetalLB | +-------+
|| |Load balancer| |Ingress|
|| +-+-----------+ +---+---+
|| | |
|| | External IP assigned |Rules described in spec
|| | to service |
|| v v
|| +--+--------------------+ +---+------------------+
|| | | | Ingress Controller |
|---->+ ingress-nginx service +----->+ (NGINX pod) |
+---->| +----->+ |
+-----------------------+ +----------------------+
||
VV
+-----------------+
| Backend service |
| (app-lb) |
| |
+-----------------+
||
VV
+--------------------+
| Backend pod |
| (httpbin) |
| |
+--------------------+