k8s入坑之路(11)kubernetes服务发现
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 列表。
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。
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。
最新文章
- KMP模板
- javaSE基础06
- loadrunner ---模拟多IP登录
- 【BZOJ 2118】墨墨的等式
- UICollectionView布局功能
- create和grant配合使用,对Mysql进行创建用户和对用户授权
- Ubuntu 14.04 LTS Server 无法挂载光盘 启动initramfs等问题
- oracle.jbo.JboException: JBO-29000: JBO-29000: Bad version number in .class file
- 源码安装Memcached服务器及其2种PHP客户端
- LeetCode24 Swap Nodes in Pairs
- HTML5 服务器发送事件
- 【17】以独立语句将newed对象置入智能指针
- delete删除多表
- Swing系列之控件一
- Redis的安装与使用(单节点)
- SVG轨迹回放实践
- jmeter+ant+jenkins的自动化接口测试
- bzoj 5289: [Hnoi2018]排列
- ssh 连接不上报Connection closed by remote host
- February 8th, 2018 Week 6th Thursday