一、组件说明
谷歌borg架构图：
主要由两部分组成：BorgMaster和Borglet。BorgMaster负责请求和分发，我们可以理解为大脑，真正做处理和工作的是Borglet。为了防止BorgMaster由於单节点故障，从图中我们可以看到有五个副本（这个数目是有讲究的，集群节点数目最好是3、5、7、9等等；如果节点数目为4，通过投票机制选择主节点时，会出现投票结果为2：2，这个时候可能无法选出主节点）。
scheduler将请求如borgcfg、command-line tools、web browsers写入Paxos（谷歌的一个键值对数据库），接着Borglet会实时地监听Paxos，当发现有自己要处理的数据时，就会去进行处理。
k8s架构图：
从此架构图中可以看出，这里的scheduler负责介绍任务，选择合适的节点进行分配任务，将任务交给api server，api server再将请求写入etcd；replication controller负责容器管理，维护副本的数目在期望值，如我想让这个容器运行几个副本就是由它控制的，当运行的容器副本数不符合期望值了，它就会创建对应的Pod或添加Pod；api server是主服务器中除scheduler和replication controller后的最后一个组件了，它是一切服务的访问入口，为了减轻api server的压力，scheduler和replication controller可以在本地生成一定的缓存，不用每次都去访问api server。
api server在接收到请求后，就会去操作etcd（类似borg架构图中的Paxos）。etcd的官方将它定位成一个可信赖（天生支持集群化，像mysql则需要借助中间件）的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转，存储k8s集群所有重要信息。推荐在k8s中使用Etcd v3，v2版本已在k8s v1.11中弃用。v2会将所有的数据都写入内存中；v3版本会引入本地卷的持久化场所，也就意味着关机后不会造成数据的损坏，可以从本地磁盘恢复。
以上是对k8s架构图上半部分master节点的介绍，接下来认识下半部分的node节点。node节点有kubelet、kube proxy、container（如docker或者其他容器）。
kubelet会跟docker进行交互，操作docker去创建对应的容器，也就是kubelet会维持Pod的生命周期；kube proxy负责写入规则至IPTABLES、IPVS，实现服务映射访问，即实现Pod与Pod之间的访问、包括负载均衡，默认kube proxy去操作firewall实现Pod的映射。
二、基本概念
1、Pod概念
ReplicationController&ReplicatSet&Deployment
ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器一场退出，会自动创建Pod来代替；而如果异常多出来的容器也会自动回收。在新版本的Kubernetes中建议使用ReplicatSet来取代ReplicationController。
ReplicatSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicatSet支持集合式的selector。
虽然ReplicatSet可以独立使用，但一般还是建议使用Deployment来自动管理ReplicatSet，这样就无需担心跟其他机制的不兼容问题（比如ReplicatSet不支持rolling-update但Deployment支持）。
StatefulSet
StatefulSet是为了解决有状态服务的问题（对应Deployment和ReplicatSet是为无状态服务而设计），其应用场景包括：
（1）稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现；
（2）稳定的网络标志，即Pod重新调度后PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现；
（3）有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现；
（4）有序收缩，有序删除（即从0到N-1）。
DaemonSet
DaemonSet确保全部（或者一些）Node上运行一个Pod副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除所有它创建的Pod。
使用DaemonSet的一些典型用法：
（1）运行集群存储daemon，例如在每个Node上运行glusterd、ceph；
（2）在每个Node上运行日志收集daemon，例如fluentd、logstash；
（3）在每个Node上运行监控daemon，例如Prometheus Node Exported。
Job&Cron Job
Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。
Cron Job管理基于时间的Job，即：
（1）在给定时间点只执行一次；（2）周期性地在给定时间点运行。
2、网络通讯模式
不同情况下网络通信方式
同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈。
Pod1至Pod2
>Pod1与Pod2不在同一台主机，Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。
Pod1与Pod2在同一台机器，由Docker0网桥直接转发请求至Pod2，不需要经过Flannel。
Pod至Service的网络：目前基于性能考虑，全部为iptables维护和转发。
Pod至外网：Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主机网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求。
组件通讯示意图
在k8s中有三层网络：节点网络、Pod网络和Service网络。真实的物理网络只有一个，即节点网络。也就意味着我们在构建服务器的时候只需要一张网卡就可以实现。Pod网络和Service网络都是虚拟网络，我们可以理解为内网。