Я борюсь с последним этапом настройки с использованием MetalLB, Kubernetes, Istio на голом железном экземпляре, а именно для возврата веб-страницы из сервиса во внешний мир по маршруту Istio VirtualService. Я только что обновил экземпляр до
- MetalLB (версия 0.7.3)
- Kubernetes (версия 1.12.2)
- Istio (версия 1.0.3)
Начну с того, что работает.
Все дополнительные услуги развернуты, и большинство из них работают:
- Панель управления Kubernetes на http://localhost:8001
- Prometheus Dashboard на http://localhost:10010 (у меня было что-то еще на 9009)
- Envoy Admin on http://localhost:15000
- Графана (панель инструментов Istio) на http://localhost:3000
- Джегер на 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
http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/shell/istio-system/istio-ingressgateway-6bbdd58f8c-glzvx/?namespace=istio-system
и сделайте оба
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-адрес моего внешнего клиента.
Любые предложения, я пытался ударить это с разных точек зрения уже пару дней, и мне кажется, что я просто упускаю что-то простое. Предлагаемые журналы посмотреть на что ли?