配置Istio、Kubernetes和MetalLB以使用Istio LoadBalancer

Question

我正在挣扎于使用MetalLB、Kubernetes、Istio进行配置的最后一步，即通过Istio VirtualService路由从服务返回到外部世界的web页面。我刚刚将实例更新为

• MetalLB (0.7.3版)
• Kubernetes (1.12.2版)
• Istio (1.0.3版)

我先从什么能起作用开始。

所有补充服务都已部署，大多数服务正在发挥作用：

1. 基于http://localhost:8001的Kubernetes仪表板
2. http://localhost:10010上的Prometheus仪表板(我在9009上有别的东西)
3. http://localhost:15000特使行政管理
4. http://localhost:3000上的Grafana (Istio仪表板)
5. http://localhost:16686上的Jaeger

我之所以这么说，是因为自从升级到Istio 1.0.3之后，我在Jaeger仪表板上丢失了ingressgateway的遥测数据，我不知道如何把它带回来。我掉下了吊舱，重新创造出来，但没有用。

除此之外，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命名空间中，侧标记都被设置为自动注入。

入口网关的日志显示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地址。

任何建议，我已经尝试从多个角度打了几天，我觉得我只是错过了一些简单的东西。建议的日志也许可以看？

Answer 1

在我的例子中，为了解决这个问题，我要结束这个问题。配置上的错误从Kubernetes集群初始化开始就开始了。我申请过：

kubeadm init --pod-network-cidr=n.n.n.n/n --apiserver-advertise-address 0.0.0.0

使用与部署Kubernetes安装的本地LAN相同的地址范围的pod，即Ubuntu主机的桌面使用与我分配的容器网络相同的IP子网。

在大多数情况下，所有操作都很好，就像上面详细描述的那样，直到Istio代理尝试将包从外部负载均衡器IP地址路由到恰好位于同一子网上的内部IP地址。带有Kubernetes的Calico项目似乎能够处理它，因为这是有效的3/4层策略，但是Istio有一个问题，它是一个L7 (尽管它坐在下面的Calico上)。

解决办法是拆除我的全部库伯奈特部署。我疑神疑鬼，甚至卸载Kubernetes，重新部署，并重新部署在172范围内的吊舱网络，这与我的本地局域网没有任何关系。我还在Project配置文件中做了相同的更改，以匹配pod网络。在这一变化之后，一切都如期而至。

我怀疑，在更公开的配置中，集群直接连接到BGP路由器，而不是使用MetalLB将L2配置作为局域网的子集，也不会出现这个问题。我在这篇文章中有更多的记载：

微服务：.Net、Linux、Kubernetes和Istio是一个强大的组合。