1、kubernetes集群架构图
master节点：
kubectl ：
客户端命令行工具,将接受的命令格式化后发送给kube-apiserver,作为整个系统的操作入口;
kube-apiserver：
集群的统一入口，各组件协调者，HTTP API提供接口服务，所有对象资源的增删改查和监听都交给apiserver处理后再交给etcd存储；
kube-cotraller-manager：
处理集群中常规后台任务，一个资源对应一个控制器，而controllermanager就是负责管理这些控制器的；
kubernetes scheduler：
将待调度的pod按照特定的算法和调度策略绑定到集群中某个合适的node上,并将绑定信息写入到etcd中；
node节点：
#####
kubelet：
每个node节点都会安装一个kubelet进程, 用于处理master下发到本节点的任务， 管理本机运行容器的生命周期，比如创建容器，Pod挂载数据卷，下载secret，获取容器和节点状态等工作。
#####
kube-proxy与service：
kube-proxy运行在每个Node节点上，它是实现Kubernetes Service的通信与负载均衡机制的重要组件；负责Pod网络代理, 它会定时从etcd服务获取到service信息
来做相应的策略，维护网络规则和四层负载均衡工作；
在k8s中，提供相同服务的一组pod可以抽象成一个service，通过service提供的统一入口对外提供服务，每个service都有一个虚拟IP地址（VIP）和端口号供客户端访问。
kube-proxy存在于各个node节点上，主要用于Service功能的实现，具体来说，就是实现集群内的客户端pod访问service，或者是集群外的主机通过NodePort等方式访问service。
kubernetes1.2版本开始,将iptables作为kube-proxy的默认模式, 通过各个node节点上的iptables规则来实现service的负载均衡，但是随着service数量的增大，
iptables模式由于线性查找匹配、全量更新等特点，其性能会显著下降；
从k8s的1.8版本开始，kube-proxy引入了IPVS模式，IPVS模式与iptables同样基于Netfilter，但是采用的hash表，因此当service数量达到一定规模时，
hash查表的速度优势就会显现出来，从而提高service的服务性能。
Pods是短暂的，那么重启时IP地址可能会改变，Service是定义一系列Pod以及访问这些Pod的策略的一层抽象。Service通过Label找到Pod组；
Label是附加到Pod的一对键/值对，比如，你可能创建了一个"tier"和“app”标签，通过Label（tier=frontend, app=myapp）来标记前端Pod容器，
使用Label（tier=backend, app=myapp）标记后台Pod。然后可以使用Selectors选择带有特定Label的Pod，并且将Service或者Replication Controller应用到上面。
kube-proxy管理sevice的端点，该service对外暴露一个Virtual IP，也成为Cluster IP, 集群内通过访问这个Cluster IP:Port就能访问到集群内对应的serivce下的Pod。
service是基于标签关联pod的不是基于IP，所以把一个pod删了，会自动创建出来并关联上；
Service与其后端Pod副本集群之间则是通过Label Selector来实现"无缝对接"。而RC的作用实际上是保证Service 的服务能力和服务质量处于预期的标准。
#####
pod：
Pod是可以创建和管理Kubernetes计算的最小可部署单元。为什么pod是最小调度单元？
*可以统一调度一组容器到指定的node上；
*共享资源：Pod的容器可以使用localhost进行通信，使用volume进行文件共享、使用socket文件；
*进行本地通信，减少频繁的远程网络请求网络；
Pod就像是豌豆荚一样，它由一个或者多个容器组成（例如Docker容器），它们共享容器存储、网络和容器运行配置项。Pod中的容器总是被同时调度，有共同的运行环境。
你可以把单个Pod想象成是运行独立应用的“逻辑主机”-—其中运行着一个或者多个紧密耦合的应用容器——在有容器之前，这些应用都是运行在几个相同的物理机或者虚拟机上。
#####
docker：
容器引擎，运行容器
2、dns
DNS 是 Kubernetes 的核心功能之一，通过 kube-dns 或 CoreDNS 作为集群的必备扩展来提供命名服务。
集群中可以通过配置Kube-dns来实现服务发现的功能。Kube-dns实现了服务名到cluster IP的映射关系。
Kube-dns通常会为service赋予一个名为“service名称.namespace.svc.cluster.local”的A记录，用来解析service的cluster IP。
如果访问default namespace下的服务，可以通过“service名称”直接访问；如果访问其他namespace下的服务，可以过“service名称.namespace”访问。
k8s会为每个容器提供默认的/etc/resolv.conf配置，内容为：
search default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.0.0.10
options ndots:5
集群通过查询/etc/resolv.conf文件的nameserver字段来确定dns服务器，该文件是在kubelet服务启动配置中指定—cluster-dns，并在服务启动后自动生成的。
当用“service名称”访问服务时，最终会使用default.svc.cluster.local这条search记录拼接完整的服务名称；当使用“service名称.namespace”时，最终会使用svc.cluster.local这条search记录。
在Kubernetes 1.11中，CoreDNS已经实现了基于DNS的服务发现的GA(General Availability,正式发布的版本)，可作为kube-dns插件的替代品。
coredns在kubernetes中被归为addon，作为附加组件，支持容器化部署;