kubernetes学习三

service：

pod 重启后ip地址会发生变化，service通过Label Selector跟提供服务的pod绑定，其它对象就可以使用Label Selector来选择还有指定Label的对象。

Label以key/value键值对的形式附加到各种对象上，如Pod、Node等，Label定义了这些对象的可识别属性，用来对它们进行管理和选择。

Service的工作方式有三种:

1.Userspace方式

2.iptables模型

3.ipvs模型

以上不论哪种，kube-proxy都通过watch的方式监控着kube-APIServer写入etcd中关于Pod的最新状态信息,它一旦检查到一个Pod资源被删除了或新建，它将立即将这些变化，反应再iptables或ipvs规则中，以便iptables和ipvs在调度Clinet Pod请求到Server Pod时，不会出现Server Pod不存在的情况。

每个service都会由kube-proxy在node节点上起一个随机的代理端口，iptables会捕捉clusterIP上的端口(port)流量重定向代理端口，访问代理端口的任何连接都会被代理到service后端的某一个pod，默认情况下对后端pod的选择是轮询

每个service都会由kube-proxy（监控 kube-control）生成一组iptables规则，iptables（nat 表）会捕捉clusterIP上的端口(targetPort)流量重定向后端某一个pod，默认对pod的选择是随机的

Flannel：

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

1.数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端。

2.Flannel通过Etcd服务维护了一张节点间的路由表，该张表里保存了各个节点主机的子网网段信息。

3.源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel0虚拟网卡，然后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通信一样的由docker0路由到达目标容器。

 

在 kubernetes 1.3 版本之后，kubernetes 改变了 DNS 的部署方式，变成了 kubeDNS + dnsmasq

正常的 service 域名会被解析成 service vip，而 headless service 域名会被直接解析成背后的 pods ip

kubeDNS：提供了原来 kube2sky + etcd + skyDNS 的功能，可以单独对外提供 DNS 查询服务

dnsmasq： 一个轻量级的 DNS 服务软件，可以提供 DNS 缓存功能。kubeDNS 模式下，dnsmasq 在内存中预留一块大小（默认是 1G）的地方，保存当前最常用的 DNS 查询记录，如果缓存中没有要查找的记录，它会到 kubeDNS 中查询，并把结果缓存起来

1、kubeDNS通过apiserver监听service和endpoint的变化，并将结果记录在本地内存中；

2、pod向dnsmasq进行nslookup查询svc；

3、dnsmasq向kubedns查询后缓存在本地内存中，后续可直接使用。