k8s的系统组件构成
k8s的前身borg
BorgMaster类似于是中心调度的大脑，Borglet是一些真正运行服务的节点，其中包含某些节点的副本，一般来说节点的数量都是奇数的为了防止投票的时候出现平手的现象一般都是用奇数个节点。
scheduler调度器
scheduler将数据写入Paxos数据库当中之后再发给Borglet去消费这些数据。
K8s的架构
master服务器分为三部分
- scheduler ： 调度器
- replication controller ：配置控制器，负责控制副本数量得，伸展和收缩容器的数量
- api server：所有数据访问和请求的接口
外部组件
kubectl： 命令行管理工具也会与api server进行交互
webUI：也是与api server进行交互
etcd：api server接收到操作的请求之后访问etcd，起到了持久化的作用
etcd介绍
etcd一个可信赖分布式键值存储服务，他本身就支持分布式存储，不需要其他的中间件的存在。用于为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。
在k8s集群中使用EtcdV3，v2版本已经在v1.11弃用。V2版本是没有做备份操作的，需要单独做备份，v3是有做持久化的。
- httpserver提供所有的服务的接口
- raft存储着所有的信息
- wal生成日志，将每条数据的都备份到Entry记录当中，并且会定时的对数据进行快照完整备份。因为不可能随时进行完整备份，也不能一直用临时备份，可能会导致增量数据太多后面再进行完整备份的时候太麻烦，所以隔一段时间就进行一下快照。同事也会将数据存储到本地磁盘当中进行持久化设置。
底层的节点的作用
kubelet
可以选择使用的容器类型，常见的是docker，kubelet管理docker
kube proxy
pod与pod之间的访问和负载均衡需要依靠kube proxy来实现。默认是通过操作防火墙来实现pod的映射，新版本支持IPVS。
其他插件
coreDNS：可以为及群众的SVC创建一个域名IP的对应关系解析
dashboard：给k8s集群的bs访问体系
Ingress Controller可以进行七层代理
federation：提供一个可以跨集群中心多k8s统一管理的功能
prometheus：提供k8s集群的监控能力
ELK： 提供K8s集群日志的统一分析接入平台
Pod的概念
一个pod里面可以管理多个docker容器，每一个pod里面都具备一个pause容器，这个容器是创建pod的时候就会生成的一个容器，主要的作用就是为所有的进程隔离的容器提供一个统一的网络协议栈，这样两个容器看起来就像是运行在一个系统的网络环境下面的两个process。所以需要注意的是不能使用同样的ip和端口。如果pause和外界的html资源有联系的话，pause上面的资源也会被pod内所有其他的容器节点所共享。
Pod控制器
ReplicationController && ReplicaSet && deployment
ReplicationController
用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来代替，而如果异常多出来的容器也会自动回收。
ReplicatSet
与ReplicationController本质上没有任何区别，只是名字布一样而已，而且replicaSet支持集合式的selector
Deployment
自动管理ReplicaSet，无需担心跟其他的机制不兼容的问题发生。（ReplicaSet不支持rolling-update但是deployment支持）
滚动更新的概念：一个deloyment会设置一个Rs去管理pod，如果需要升级这些Pod的版本就会再生成一个RS从旧的Rs中拿一个pod重启之后再放入新的Rs中，如果中间的升级有问题的话还可以undo回滚，因为之前的旧的RS处于暂停的状态，并不会被删除，只有整个全部更新完毕才会删掉之前的RS。
HPV：平滑扩展根据利用率
v1中根据pod的cpu利用率来进行平滑扩展。HPV也是一个对象，当Cpu大于80的时候就需要被扩展，新建一个或多个pod，如果创建一个pod还没有低于八十，那就继续创建。最大数量pod是10，在利用率比较低的时候就会删除多余的pod。未来可以支持内存和用户自定义metrics扩容。
StatefulSet
docker比较支持的是无状态服务，但是如果希望让有状态的服务也能搭建到集群上面，就可以使用stateful来进行数据的持久化。
主要提供三个功能
- 稳定的持久化存储：pod重新调度后还是能访问到相同的持久化数据，基于PVC实现的
- 稳定的网络标识：Pod重新调度之后其podName和HostName不变，基于Headless Service来实现
- 有序部署，有序扩展，Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行，只有当前一个的pod处于running或者是Ready状态下才可以启动新的pod。
DaemonSet
确保全部（或者一些）Node上运行一个Pod的副本，当有Node加入集群当中时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
如果被打上污点的pod就不会被参与调度。
使用demonSet的一些典型的用法：
- 运行集群存储demon，在每个Node上运行的glusterd、ceph
- 在每个Node上面运行日志收集deamon
- 在每个Node上运行监控daemon
cron Job
负责批处理服务，仅执行一次的任务，保证批处理任务的一个或多个pod成功结束
cron job管理基于时间的job，即
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
服务发现
应用场景：客户端想要去访问一组pod的时候，这几个pod有一些共同点（同一标签 or 同一deploy管理）
service去主动收集这些pod的服务，service是通过标签去收集这些pod的。
service有IP和端口，client可以通过这些端口和IP去间接访问pod服务（轮询）