给istio部署插件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
提示:istio插件的部署清单在istio/samples/addons/目录下,该目录下有grafana、jaeger、kiali、prometheus的部署清单;其中jaeger是负责链路追踪,kiali是istio的一个web客户端工具,我们可以在web页面来管控istio,prometheus是负责指标数据采集,grafana负责指标数据的展示工具;应用该目录下的所有部署清单后,对应istio-system名称空间下会跑相应的pod和相应的svc资源;
验证:在istio-system名称空间下,查看对应pod是否正常跑起来了?对应svc资源是否创建?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
提示:可以看到对应pod都在正常runing并处于ready状态;对应svc资源也都正常创建;我们要想访问对应服务,可以在集群内部访问对应的clusterIP来访问;也可以修改svc对应资源类型为nodeport或者loadbalancer类型;当然除了上述修改svc资源类型的方式实现集群外部访问之外,我们也可以通过istio的入口网关来访问;不过这种方式需要我们先通过配置文件告诉给istiod,让其把对应的服务通过ingressgate的外部IP地址暴露出来;
这里说一下通过ingressgateway暴露服务的原理;我们在安装istio以后,对应会在k8s上创建一些crd资源,这些crd资源就是用来定义如何管控流量的;即我们通过定义这些crd类型的资源来告诉istiod,对应服务该如何暴露;只要我们在k8s集群上创建这些crd类型的资源以后,对应istiod就会将其收集起来,把对应资源转换为envoy的配置文件格式,再统一下发给通过istio注入的sidecar,以实现配置envoy的目的(envoy就是istio注入到应用pod中的sidecar);
查看crd
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
|
提示:可以看到在networking.istio.io这个群组里面有很多crd资源类型;其中gateway就是来定义如何接入外部流量的;virtualservice就是来定义虚拟主机的(类似apache中的虚拟主机),destinationrules用于定义外部流量通过gateway进来以后,结合virtualservice路由,对应目标该如何承接对应流量的;我们在k8s集群上创建这些类型的crd资源以后,都会被istiod收集并由它负责将其转换为envoy识别的格式配置统一下发给整个网格内所有的envoy sidecar或istio-system名称空间下所有envoy pod;
通过istio ingressgateway暴露kiali服务
定义 kiali-gateway资源实现流量匹配
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
提示:该资源定义了通过istio-ingresstateway进来的流量,匹配主机头为kiali.ik8s.cc,协议为http,端口为80的流量;
定义virtualservice资源实现路由
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
提示:该资源定义了gateway进来的流量匹配主机头为kiali.ik8s.cc,uri匹配“/”;就把对应流量路由至对应服务名为kiali的服务的20001端口进行响应;
定义destinationrule实现如何承接对应流量
1 2 3 4 5 6 7 8 9 10 11 |
|
提示:该资源定义了对应承接非tls的流量;即关闭kiali服务的tls功能;
应用上述配置清单
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
通过集群外部客户端的hosts文件将kiali.ik8s.cc解析至istio-ingressgateway外部地址
提示:我这里是一台win11的客户端,修改C:\Windows\System32\drivers\etc\hosts文件来实现解析;
测试,用浏览器访问kiali.ik8s.cc看看对应是否能够访问到kiali服务呢?
提示:可以看到我们现在就把集群内部kiali服务通过gateway、virtualservice、destinationrule这三种资源的创建将其暴露给ingresgateway的外部地址上;对于其他服务我们也可以采用类似的逻辑将其暴露出来;这里建议kiali不要直接暴露给集群外部客户端访问,因为kiali没有认证,但它又具有管理istio的功能;
部署bookinfo
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
提示:我们安装istio以后,bookinfo的部署清单就在istio/samples/bookinfo/platform/kube/目录下;该部署清单会在default名称空间将bookinfo需要的pod运行起来,并创建相应的svc资源;
验证:查看default名称空间下的pod和svc资源,看看对应pod和svc是否正常创建?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
提示:可以看到default名称空间下跑了几个pod,每个pod内部都有两个容器,其中一个是bookinfo程序的主容器,一个是istio注入的sidecar;bookinfo的访问入口是productpage;
验证:查看istiod是否将配置下发给我们刚才部署的bookinfo中注入的sidecar配置?
1 2 3 4 5 6 7 8 9 10 11 |
|
提示:这里我们只需要关心cds、lds、eds、rds即可;显示synced表示对应配置已经下发;配置下发完成以后,对应服务就可以在集群内部访问了;
验证:在集群内部部署一个客户端pod,访问productpage:9080看看对应bookinfo是否被访问到?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
进入sleep pod,访问productpage:9080看看是否能访问?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
|