外部访问pod的流程

https://www.cnblogs.com/ajunyu/articles/11283772.html
1.pod生成的时候会生成pod ip
2.多个pod提供服务时，有多个ip,若pod故障，重新启动一个新的pod，就面临找不到该pod,访问不到该服务
3.基于上面的问题，提出了service
4.service相当于一组pod ,具体是哪些 Pod 则是由 label 来挑选。
5.Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，Kubernetes 则负责建立和维护 Service 与 Pod 的映射关系。
6.无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。
7.到此为止，集群内只需要使用service IP：8080 就可以访问多个后端pod
8.可以使用命令查看service IP 与pod ip 之间的对应关系

eg:kubectl get endpoints -n yxm-dev base-server

9.cluster ip 是存储在什么地方呢？
Service Cluster IP 是一个虚拟 IP，是由 Kubernetes 节点上的 iptables 规则管理的。
10.iptables 将访问 Service 的流量转发到后端 Pod，而且使用类似轮询的负载均衡策略。
11.那外部网络如何访问pod？
使用nodeport方式，客户端访问nodeip:nodeport---->clusterip:8080---->podip:targetpod

eg:nodeip:32300--->clusterip:8080---->podip:34215
　　nodePort 是节点上监听的端口。

　　port 是 ClusterIP 上监听的端口。

　　targetPort 是 Pod 监听的端口。

第一次追加：
ingress的yaml中配置域名，xxx.com
1.访问域名xxx.com就可以访问到对应的service：端口
2.通过标签来找到对应的pod

第二次追加：
dns
ingress的域名添加到了dns中，dns到了k8s的worker节点
此时访问域名/api/health/check,可以直接通过ingress到svc然后访问到pod

第三次追加：
网关ingress
通过网关的域名，域名配置在gateways.networking.istio.io，通过nacos配置文件中的相关配置找到对应的svc，之后找到pod

至此，开发测试环境的流量流经完毕

第四次追加：
关于线上的流量
1.用户访问域名
2.流量首先到达高防IP
3.阿里云SLB
4.istio的网关，此时根据网关中配置的匹配规则找到对应的v1 v2 v3 等，然后访问v1v2v3对应的svc,以及svc对应的pod