kubernetes

x625802392

　　一、clusterIP、nodeip、loadbalancer、ingress
　　1、clusterIP
　　这种情况下，service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。
　　kube-proxy在转发时主要有两种模式Userspace和Iptables。如下图，左侧是Userspace模式，也是kube-proxy默认的方式，所有的转发都是通过kube-proxy软件实现的；右侧是Iptables模式，所有转发都是通过Iptables内核模块实现，而kube-proxy只负责生成相应的Iptables规则。从效率上看，Iptables会更高一些，但是需要Iptablesversion >=1.4.11，Iptables模式在k8s1.2版本放出，是否开启使用还需要具体斟酌。

　　回到本文的主题，在k8s中暴露Service访问（无论内部还是外部），都要经过kube-proxy，比如下图中我们定义一个Service，便可以通过访问Service的80端口转发到Pod的9376端口上。

　　
　　二、kube-dns
　　1.4版本相对1.2版本有一些改进
　　主要变化
　　1、服务发现机制未变化
　　也就是说kube-dns对外的接口是基本没变的。变化主要在于kube-dns插件的内部组成，由原来的四个容器变为了三个。
　　现在回顾一下上一期所讲的1.2版本kube-dns的组成。
　　Kube2sky通过K8S API监视K8S Service资源的变化，并根据Service的信息生成DNS记录写入到etcd中。Skydns为集群中的Pod提供DNS查询服务，DNS记录从etcd中读取。Exechealthz提供健康检查功能。

　　接下来我们再看一下1.4版本kube-dns的组成。对比两张图，可以很直观的看到kube-dns对外接口没有发生变化。Exechealthz是唯一保留的容器，依然提供健康检查。
　　不同点：
　　1.会检查两个容器的健康状态。
　　2.为集群提供DNS查询服务的容器由skydns变为了dnsmasq。
　　3.Kubedns容器替代了kube2sky来监视Service资源。
　　4.Etcd容器不见了。

　　相信有些人会好奇DNS记录现在保存在哪了呢？那为了回答这个问题以及了解新版kube-dns的工作原理，我们就进入下一章内容来了解其实现原理。见https://segmentfault.com/a/1190000007342180