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

时间:2018-11-01 04:22:48

标签: kubernetes istio envoyproxy cloud-bare-metal

我正努力在裸机实例上使用MetalLB,Kubernetes和Istio进行配置的最后一步,那就是要通过Istio VirtualService路由将网页从服务返回到外界。我刚刚将实例更新为

  • 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. Grafana(Istio信息中心)在http://localhost:3000
  5. Jaeger在http://localhost:16686

我之所以这么说是因为自从升级到Istio 1.0.3以来,我已经失去了Jaeger仪表板中istio-ingressgateway的遥测功能,而且我不确定如何将其恢复。我放下了吊舱,然后重新创建它。

除此之外,MetalLB和K8S似乎运行良好,并且负载平衡器已正确配置(使用ARP)。

ObjectDisposedException

我可以使用以下方式公开部署:

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

一切正常,我可以从外部负载平衡IP地址访问网页(此后我删除了公开的服务)。

kubectl expose deployment enrich-dev --type=LoadBalancer --name=enrich-expose

如果我在默认名称空间中创建了K8S服务(我已经尝试了多次)

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

接着是网关和路由(VirtualService),我得到的唯一响应是网格外部的404。您会在网关中看到我正在使用保留字mesh,但我已经尝试过并命名了特定网关。我还为特定的URI和端口尝试了不同的匹配前缀,如下所示。

网关

apiVersion: v1
kind: Service
metadata:
  name: enrich-service
  labels:
    run: enrich-service
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
  selector:
    app: enrich

VirtualService

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:
        - "*"

我已经仔细检查了这不是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

同时做一个

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

nslookup enrich-service.default

都可以正常工作,所以我知道入口网关窗格可以看到这些。边车设置为在默认名称空间和istio-system名称空间中自动注入。

入口网关的日志显示404:

curl -f http://enrich-service.default/

192.168.224.168:80是网关的IP地址。 192.168.1.90:53960是我的外部客户端的IP地址。

任何建议,我已经尝试从多个角度尝试了几天,而我觉得我只是缺少一些简单的东西。建议查看日志?

1 个答案:

答案 0 :(得分:0)

只需将这个问题排除在外即可解决我的问题。配置错误始于Kubernetes集群初始化。我申请了:

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

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

在大多数情况下,一切都按上述详细操作,直到Istio代理尝试将数据包从外部负载平衡器IP地址路由到恰好在同一子网中的内部IP地址。带有Kubernetes的Calico项目似乎能够应付,因为它实际上是3/4层策略,但是Istio的L7出现了问题(即使它位于下面的Calico上也是如此)。

解决方案是拆除整个Kubernetes部署。我很偏执,甚至卸载了Kubernetes,然后再次部署并重新部署172范围内的Pod网络,这与我的本地局域网无关。我还对Project Calico配置文件进行了相同的更改,以匹配Pod网络。更改之后,一切都按预期进行。

我怀疑在更公开的配置中,您的群集直接连接到BGP路由器,而不是将MetalLB和L2配置用作LAN的子集,也不会出现此问题。我在这篇文章中对此进行了更多记录:

Microservices: .Net, Linux, Kubernetes and Istio make a powerful combination