Настройка Istio, Kubernetes и MetalLB для использования Istio LoadBalancer
Я борюсь с последним этапом конфигурирования с использованием MetalLB, Kubernetes, Istio на голом железном экземпляре, а именно для возврата веб-страницы из сервиса во внешний мир по маршруту Istio VirtualService. Я только что обновил экземпляр
- MetalLB (версия 0.7.3)
- Кубернетес (версия 1.12.2)
- Istio (версия 1.0.3)
Начну с того, что работает.
Все дополнительные услуги были развернуты, и большинство из них работают:
- Панель управления Kubernetes на http://localhost:8001/
- Панель инструментов Prometheus на http://localhost:10010/ (у меня было что-то еще на 9009)
- Администратор посланника на http://localhost:15000/
- Графана (Istio Dashboard) на http://localhost:3000/
- Jaeger на http://localhost:16686/
Я говорю больше всего, потому что после обновления до Istio 1.0.3 я потерял телеметрию с istio-ingressgateway в панели управления Jaeger, и я не уверен, как вернуть его. Я бросил стручок и воссоздал безрезультатно.
Помимо этого, кажется, что MetalLB и K8S работают нормально, а балансировщик нагрузки настроен правильно (с использованием ARP).
kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
grafana ClusterIP 10.109.247.149 <none> 3000/TCP 9d
istio-citadel ClusterIP 10.110.129.92 <none> 8060/TCP,9093/TCP 28d
istio-egressgateway ClusterIP 10.99.39.29 <none> 80/TCP,443/TCP 28d
istio-galley ClusterIP 10.98.219.217 <none> 443/TCP,9093/TCP 28d
istio-ingressgateway LoadBalancer 10.108.175.231 192.168.1.191 80:31380/TCP,443:31390/TCP,31400:31400/TCP,15011:30805/TCP,8060:32514/TCP,853:30601/TCP,15030:31159/TCP,15031:31838/TCP 28d
istio-pilot ClusterIP 10.97.248.195 <none> 15010/TCP,15011/TCP,8080/TCP,9093/TCP 28d
istio-policy ClusterIP 10.98.133.209 <none> 9091/TCP,15004/TCP,9093/TCP 28d
istio-sidecar-injector ClusterIP 10.102.158.147 <none> 443/TCP 28d
istio-telemetry ClusterIP 10.103.141.244 <none> 9091/TCP,15004/TCP,9093/TCP,42422/TCP 28d
jaeger-agent ClusterIP None <none> 5775/UDP,6831/UDP,6832/UDP,5778/TCP 27h
jaeger-collector ClusterIP 10.104.66.65 <none> 14267/TCP,14268/TCP,9411/TCP 27h
jaeger-query LoadBalancer 10.97.70.76 192.168.1.193 80:30516/TCP 27h
prometheus ClusterIP 10.105.176.245 <none> 9090/TCP 28d
zipkin ClusterIP None <none> 9411/TCP 27h
Я могу выставить мое развертывание, используя:
kubectl expose deployment enrich-dev --type=LoadBalancer --name=enrich-expose
все работает отлично, и я могу попасть на веб-страницу с внешнего IP-адреса с балансировкой нагрузки (после этого я удалил уязвимую службу).
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
enrich-expose LoadBalancer 10.108.43.157 192.168.1.192 31380:30170/TCP 73s
enrich-service ClusterIP 10.98.163.217 <none> 80/TCP 57m
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 36d
Если я создаю службу K8S в пространстве имен по умолчанию (я пробовал несколько)
apiVersion: v1
kind: Service
metadata:
name: enrich-service
labels:
run: enrich-service
spec:
ports:
- name: http
port: 80
protocol: TCP
selector:
app: enrich
затем шлюз и маршрут (VirtualService), единственный ответ, который я получаю, это 404 вне меша. В шлюзе вы увидите, что я использую зарезервированное слово mesh, но я попробовал и это, и назвал конкретный шлюз. Я также пробовал разные префиксы соответствия для определенного URI и порта, который вы можете увидеть ниже.
шлюз
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: enrich-dev-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
VirtualService
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: enrich-virtualservice
spec:
hosts:
- "enrich-service.default"
gateways:
- mesh
http:
- match:
- port: 80
route:
- destination:
host: enrich-service.default
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: enrich-destination
spec:
host: enrich-service.default
trafficPolicy:
loadBalancer:
simple: LEAST_CONN
subsets:
- name: v1
labels:
app: enrich
Я дважды проверил, что DNS не воспроизводится, потому что я могу войти в оболочку входного шлюза либо через busybox, либо с помощью панели мониторинга K8S.
и сделать как
nslookup enrich-service.default
а также
curl -f http://enrich-service.default/
и оба работают успешно, так что я знаю, что модуль входного шлюза может их видеть. Боковые коляски установлены для автоматического внедрения как в пространстве имен по умолчанию, так и в пространстве имен istio-system.
Журналы для входного шлюза показывают 404:
[2018-11-01T03:07:54.351Z] "GET /metadataHTTP/1.1" 404 - 0 0 1 - "192.168.1.90" "curl/7.58.0" "6c1796be-0791-4a07-ac0a-5fb07bc3818c" "enrich-service.default" "-" - - 192.168.224.168:80 192.168.1.90:43500
[2018-11-01T03:26:39.339Z] "GET /HTTP/1.1" 404 - 0 0 1 - "192.168.1.90" "curl/7.58.0" "ed956af4-77b0-46e6-bd26-c153e29837d7" "enrich-service.default" "-" - - 192.168.224.168:80 192.168.1.90:53960
192.168.224.168:80 - это IP-адрес шлюза. 192.168.1.90:53960 - это IP-адрес моего внешнего клиента.
Любые предложения, я пытался ударить это с разных точек зрения в течение нескольких дней, и я чувствую, что просто упускаю что-то простое. Предлагаемые журналы на что посмотреть возможно?
0 ответов
Просто чтобы закрыть этот вопрос для решения проблемы в моем случае. Ошибка в конфигурации началась еще во время инициализации кластера Kubernetes. Я подал заявку:
kubeadm init --pod-network-cidr=n.n.n.n/n --apiserver-advertise-address 0.0.0.0
pod-network-cidr, использующий тот же диапазон адресов, что и локальная локальная сеть, в которой была развернута установка Kubernetes, т.е. рабочий стол для хоста Ubuntu использовал ту же IP-подсеть, что и та, которую я назначил для контейнерной сети.
По большей части все работало нормально, как описано выше, пока прокси-сервер Istio не пытался перенаправить пакеты с внешнего IP-адреса балансировщика нагрузки на внутренний IP-адрес, который оказался в той же подсети. Проект Calico с Kubernetes, казалось, был в состоянии справиться с этим, так как это эффективно на уровне 3/4, но у Istio была проблема с L7 (хотя он находился на Calico внизу).
Решение состояло в том, чтобы сорвать все мое развертывание в Kubernetes. Я был параноиком и зашел так далеко, что удалил Kubernetes, развернул снова и развернул сеть pod в диапазоне 172, что не имело ничего общего с моей локальной сетью. Я также сделал те же изменения в файле конфигурации Project Calico, чтобы они соответствовали сетям модулей. После этого изменения все заработало как положено.
Я подозреваю, что в более общедоступной конфигурации, где ваш кластер был напрямую подключен к маршрутизатору BGP, в отличие от использования MetalLB с конфигурацией L2 в качестве подмножества вашей локальной сети, эта проблема также не возникнет. Я задокументировал это больше в этом посте:
Микросервисы: .Net, Linux, Kubernetes и Istio составляют мощную комбинацию