我正在努力使用MetalLB,Kubernetes,Istio在裸机实例上进行配置的最后一步,那就是通过Istio VirtualService路由将服务从服务返回到外部世界 . 我刚刚将实例更新为
-
MetalLB(版本0.7.3)
-
Kubernetes(版本1.12.2)
-
Istio(版本1.0.3)
我将从什么工作开始 .
所有补充服务已经部署,大多数都在运作:
-
Kubernetes Dashboard on http://localhost:8001
-
http://localhost:10010上的普罗米修斯仪表板(我在9009上还有别的东西)
-
Grafana(Istio Dashboard)于http://localhost:3000
-
Jaeger on http://localhost:16686
我说的最多,因为自从升级到Istio 1.0.3后,我在Jaeger仪表板上失去了istio-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 . 您将在网关中看到我正在使用保留字网格,但我已经尝试了这两个并命名特定网关 . 我还尝试了特定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仪表板进入入口网关的shell
并做两个
nslookup enrich-service.default
和
curl -f http://enrich-service.default/
并且两者都成功运行,所以我知道ingress-gateway pod可以看到这些 . sidecars设置为默认命名空间和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地址 .
任何建议,我已经尝试过几天从多个角度来看这个,我觉得我只是缺少一些简单的东西 . 建议的日志或许可以看一下?
1 回答
只是为了解决我的实例中的问题的解决方案 . 配置错误始于Kubernetes集群初始化 . 我申请了:
pod-network-cidr使用与部署Kubernetes安装的本地LAN相同的地址范围,即Ubuntu主机的桌面使用与我指定的容器网络相同的IP子网 .
在大多数情况下,如上所述,一切运行正常,直到Istio代理尝试将数据包从外部负载均衡器IP地址路由到恰好位于同一子网的内部IP地址 . Calico与Kubernetes的项目似乎能够应对它,因为这是有效的第3/4层政策,但Istio有一个L7的问题(即使它坐在Calico下面) .
解决方案是拆除我的整个Kubernetes部署 . 我是偏执狂,甚至卸载Kubernetes再次部署并重新部署172范围内的pod网络,这与我的本地局域网没有任何关系 . 我还在Project Calico配置文件中进行了相同的更改以匹配pod网络 . 在那次改变之后,一切都按预期工作 .
我怀疑在更公开的配置中,您的群集直接连接到BGP路由器,而不是使用具有L2配置的MetalLB作为LAN的子集也不会出现此问题 . 我在这篇文章中记录了更多:
Microservices: .Net, Linux, Kubernetes and Istio make a powerful combination