一、POD网络结构

1.1、POD网络结构

概念： 
1、pod是k8s最小的操作单元
2、pod也是一个容器，独立的沙箱环境，有自己的ip地址，有自己的hostname
3、pod是容器的容器，内部用来封装docker容器

Pod本身就是运行在操作系统中一个进程，相当于是一台独立机器；（虚拟化概念），pod内部可以封装一个容器，也可以封装多个容器；在物理机节点上，pod和pod之间是相互独立；

当创建一个pod的资源对象的时候，先创建一个pause容器，此容器会帮助pod创建共享网卡，共享存储卷；网卡，数据卷都是pod内部容器共享的资源；
共享网络栈（网卡）：
1、会分配一个独立，唯一的ip地址
2、此ip地址被pod内部容器共享，另外pod的IP地址也是此ip地址；（pod,pod内部容器共享同一块网卡，因此他们都是使用的同一个ip地址）

注意： pod内部容器共享同一个网卡，ip地址是相同的，端口不能冲突；

1.2、POD内部容器访问

由于pod内部的容器共享同一个网卡，因此pod内容容器的访问，就相当于访问本地服务一样，使用localhost访问即可；

1.3 POD外网访问

POD,Service 都是运行在操作系统内部一个进程，独立一个沙箱环境，有自己的IP地址，有自己的端口；就是一个虚拟的机器；因此外网不能直接访问物理节点内部的沙箱环境； 必须通过物理的网卡的转发；

1.4、POD外部访问

由于POD网络采用特殊设计模式： POD 和 POD内部容器共享同一个ip地址的；因此访问pod内部容器的时候的，直接通过ip:容器端口即可访问到此容器服务；

1.5、同一个机器，跨pod访问

在同一个节点内部pod之间相互访问，需要借助于网桥完成ip寻址（ip路由），然后由网桥把请求转发给相应的pod服务；
1.6、不同机器，pod访问

不同节点pod要实现通信，必须借助于route table，实现在不同节点中ip寻址；

1.7、网卡ip冲突

Docker容器来说，是一个单机版的，当docker在一个node节点创建一个容器的时候，生成docker网桥(网段)，此节点中所有的容器都在此网桥下，都是同一个网段；

此时此刻导致podIP地址发生冲突，如何解决此问题？？？（在同一个k8s集群中）---- 在kubernetes集群中，podIP具有唯一性
答案： 开源网络组件flanel

Flanel网络插件确保POD IP地址在整个kubernetes集群中具有唯一性的IP地址； 只需要确保网桥的网段不一致就行了，在网桥下的pod IP自然不会发生冲突；

二、基于应用网络

2.1、DNS+ClusterIP

在服务部署中，网关对外提供服务的，订单服务属于局域网内部的服务，不需要直接对外提供服务，只需要通过网关来访问订单服务即可，在微服务架构模式下，服务之间访问通过服务名称解析出服务的ip地址的方式模式，因此在kuberntes部署模式下，借助了dns服务ip解析模式，实现服务发现；

2.2、集群内网访问外部服务

第一种访问模式： 直接访问外部的数据库即可（把数据库所在的ip,端口直接访问到服务内部）

缺点： 把数据库连接地址直接封装到服务镜像中，耦合度太高，一旦数据库地址发生变化，那么将要进行重新打包，从新部署；

第二种模式： service 对外做一个转发

访问外部服务的时候，通过service，endpoints转发，即可实现外部服务访问； endpoints 就是一个 ip地址数组
Endpoints : [mysqlIP]

2.3、外网访问内网服务

外部服务要访问内部服务，必须在物理机开辟一个端口，先访问物理机，然后通过物理机端口和service端口映射，把请求转发给service服务，实现从外到内的一个访问的一个流程；

问题答疑：
1、内网访问外网的dns是怎么来设置的？
答案： 创建service，kubernetes自动把service名称，ip的映射存储在dns; 因此dns服务是kubernetes来自动实现维护；

2、一定要用service吗？用配置中心管理mysql连接地址呢？
答案： 使用配置中心也是ok，把数据注入到pod内部；

三、Service VIP (虚拟IP)

3.1、POD服务集群负载均衡的问题？

针对podIP动态变化的问题，nginx/openresty无法感知到的问题，如何解决这一问题呢？？？
答案：服务发现（及时发现PODIP发生变化，及时更新转发规则），kubernetes提供了4层负载均衡的转发的模式，就是Service 资源对象；

3.2、什么是Service?

Service 资源对象 其实就是kubernetes抽象出一个虚拟的对象（运行在node节点一个进程，服务），有自己有的IP地址（虚拟IP）,有自己的服务端口；
Service就相当于是一个网关，对应的一组业务的请求都必须经过service资源对象（被Service拦截），然后对请求转发某种规则的转发；

思考： kubernetes设计Service原因是什么？？？
Service要实现服务发现（自动进行），屏蔽掉底层pod异常，宕机发生的IP地址，hostname变化而造成的一系列的影响；使得用户就不需要关心底层POD到底发生了何种变化；

3.3、Service几个问题？

问题1： Service 如何知道为那几个pod服务（几十万个pod服务）提供服务的呢？？

Service 资源对象通过标签选择器 确定哪些pod服务为当前的Service对象的服务对象；

问题2： Service 服务组态如何划分的？（同一个service资源对象可以同时给订单服务，支付服务提供服务吗）?

在服务部署的时候： 一个service对应一个业务组，一个service只能对应一个业务组；

问题3： Service VIP 是否会发生变化？？？？（IP地址发生变化，对服务是否有影响）
答案： Service VIP 一般不会发生变化，除非对象Service 资源对象进行重建； 即使Service IP地址发生了变化，对服务没有任何影响，
第一： 服务名称没有变化（service服务名称没有变化，DNS可以根据服务名称解析到对应ip）,
第二： 标签选择器没有发生变化，新的Service对象可以根据标签选择器找到你对应服务；

问题4： Service VIP 是否存在单点故障？？？
答案： 不存在，Service VIP 资源对象存储在etcd中，高可用由etcd来保障的； 及时node节点宕机，service进程宕了，还可以从etcd中对服务进行恢复；

问题5：Service 是否可以通过外网直接访问呢？？
答案： service 是一个虚拟的对象，运行在操作系统内部进程，外网服务无法直接访问service，如果需要访问service，必须先访问物理节点，然后由物理节点转发请求；

问题6： Service对象是否可以无限制的创建?(10000个service)??
答案： 根据极限压力测试：（华为容器云提供方案）
1、Service(iptables) > 500 个， 性能急剧下降 5000 （11min） 20000 (5 hours)
2、Service (ipvs) 么有限制 5000 (50us) 20000(70us)

3.4、如何实现负载均衡？

Service 实现负载均衡的原理是利用netfilter（防火墙）iptables 实现请求的转发（轮询，随机）

Service iptables是如何实现请求分发的？？

注意： Service本身并不具备请求分发能力，kubernetes实现pod服务负载均衡是借助iptables能力的实现的；

3.5、如何实现服务发现？

问题描述： PODIP,hostname 发生了变化，iptables中 ServiceIP ，PODIP映射关系也要发生响应的变化，此变化有谁来维护的？？

POD IP发生变化，endpoints controller控制器通过watch（kubernetes API接口）监控POD服务变化，及时更新servcie ,pod映射关系，从而实现服务发现；

3.6、路由规则的改写

Kube-proxy核心组件监控etcd中Service，pod映射关系，发现pod ip发生变化后，更新iptables的路由规则，从而实现访问服务的时候，可以及时发现新的pod服务；

3.7、Service VIP 如何产生的？

选择：
1、由kubernetes自动创建的
2、部署服务的时候手动创建的 （√）
服务上线部署的时候：
1、Deployment部署对象
2、Service对象

四、Service 负载均衡的方案

Service VIP 负载均衡的实现方案：
1、userspace
2、iptables — k8s默认负载均衡方案
3、ipvs

4.1 Userspace

Userspace负载均衡的方案就是利用 kube-proxy组件实现负载均衡，也就是说请求转发由kube-proxy来实现；

4.2 Iptables

1）随机策略

2）轮询策略：

4.3、IPVS

IPVS和IPTABLES都基于netfilter。 IPVS模式和IPTABLES模式之间的差异如下：

• IPVS为大型集群提供了更好的可扩展性和性能。
• IPVS支持比iptables更复杂的负载平衡算法（最小负载，最少连接，位置，加权等）。
• IPVS支持服务器健康检查和连接重试等。

IPVS支持的负载均衡算法有这么几种：
• rr: 轮询
• lc: 最小连接数
• dh: 目的地址hash
• sh: 源地址hash
• sed: 最短期望延迟
• nq: 无须队列等待

4.4 、Service,Depolyment部署实践

1）Deployment对象
通过yaml文件实现服务部署的；

2）Service

3）查看帮助文档，查询资源清单
Kubectl explain 资源对象 — 查看此资源对象资源清单