kubernetes访问场景

  • 1.集群内部访问
  • 2.集群内部访问外部
  • 3.集群外部访问内部

1.集群内部访问

1.pod之间直接ip通讯（利用calico通过路由表经过三层将ip流量转发）由于容器之间ip并不固定不推荐使用ip直连

2.pod通过service-ip访问后端pod（service为虚拟ip，kube-proxy将请求分发给ipvs，负载到某个后端pod，calico通过路由转发将请求转发过去）

3.（dns+ClusterIp）pod通过service-name访问后端pod（pod通过dns解析service名字的ip到kube-proxy，kube-proxy将请求分发给ipvs，负载到某个后端pod，calico通过路由转发将请求转发过去）

4.（headlessService）service创建时将 Service 的 spec.ClusterIP 设为 None，得到的就是一个 Headless Service，该service对应的不是一个虚拟ip，service name 只提供 SRV 记录的 DNS 解析，返回一个 Pods 的 ip/dns 列表。

k8s入坑之路（11）kubernetes服务发现_edn

 

2.集群外部访问集群内部

1.（IP或域名）写死ip直接访问，ip通过eth网卡直连，域名的话通过宿主机resvle直接访问，（coredns查询本地缓存，查询corednspod当前namespace下域名，查询全部namespace下域名无的话直接访问宿主机dns，外部链接的话最后以.结尾绝对域名去访问提高解析记录）

2. （outservice）service绑定Endpoint endpoint绑定的外部具体地址，pod通过dns访问到service，kube-proxy将service绑定的endpoint地址返回给pod。（有点当外部地址变化只需要修改endpoint即可）通过watch/list监测kube-proxy更新iptables。

k8s入坑之路（11）kubernetes服务发现_nginx_02

 

 

3.集群外部访问集群内部

1.（NodePort）service-nodeport类型除生成clusterip外会在每个节点都开放一个相同的端口，访问集群内任何一个节点的对应端口都会重新转发到service上，kube-proxy通过ipvs将请求转发到一个具体pod上。（缺点：端口混乱，转发次数增多。）

2.（HostPort）service生成cluster-ip后，在指定相对应的pod所在节点开启对应端口。

3.（域名访问通过ingress-nginx/ingress-controller）将指定域名绑定到后端service上。ingress-controller负责解析与转发通过watch监听service-api，同步修改后端ingress-nginx。

k8s入坑之路（11）kubernetes服务发现_请求转发_03