kubernetes
ansible # 应用程序编排
docker提供的编排工具3剑客：
docker-componse # 适用单机编排，面向1个docker host
docker swarm # 面向docker host集群编排，docker host要加入到docker swarm池中
dcoker machine # 能将1个docker host初始化加入到docker swarm集群中的主机
ASF下的：
mesos + marathon
kubernetes # 舵手|飞行员，受Borg的影响，用go按Borg的思想重写，Borg是google内部运行了十几年的稳定的容器编排工具
DevOps # 本身不是技术，而是文化，一种运动，一种趋势，使得devlop和operation结合；容器的出现，使得devops在落地上完成了实现的可能，不用关注各平台
MicroServices # 单体应用（众多功能）-->一个microservice只运行1个功能，微服务部署在容器上
BlockChain
瀑布式开发-->敏捷开发-->精益开发
ops-->devops
CI # 持续集成
CD # delivery持续交付
CD # deployment持续部署，部署模型（蓝绿部署|灰度|金丝雀）
github.com/kubernetes
12年，amazon的aws，ms的azure，阿里云，云计算平台宣布支持容器化k8s；
docker企业版中支持自身的swarm，还有k8s；
rkt（CoreOS是gg大力扶持的，redhat收购了CoreOS并花大价钱在容器上，k8s成为redhat的openshift的PaaS，可理解为openshift是k8s的发行版，k8s很底层）的容器编排工具fleet，直接放弃fleet直接使用k8s；
特性：
自动装箱；
自我修复；
水平扩展；
服务发现和负载均衡；
自动发布和回滚；
密钥和配置管理； # 模拟了配置中心的作用
存储编排；
任务批量处理执行；
架构：
是一集群，组成集群的主机有角色（p2p无中心节点，另有中心节点）；
master/nodes
nodes即worker，运行容器的节点
注：
可将registry托管在k8s上；
mysql提供的3306，可理解为该端口为api server；
master一般3个，node不限量；
master上组件：
api server，用https通信；
scheduler，负责哪个node适合运行某个容器（筛选-->优选）
controller，周期性探测管理的容器是否健康，一旦不符合用户定义的状态，使之成为健康状态；
controler manager，监控controler的健康状态，master是多节点的，cm也要做冗余；k8s支持众多的控制器，控制容器健康的只是一种；
master是集群大脑，api server负责接收并处理请求，scheduler负责调度容器创建的请求，controler负责容器处于健康状态，cm确保已创建的容器处于健康状态；
各master上有一共享存储，etcd，etcd是一kv数据库系统，还有协调功能实现leader选举，更像zk,etcd也是restful(用https通信，同es，1个port用于内部通信（点对点证书），1个port用于对外提供服务)，一般3个节点，etcd的客户端是api server（https，与etcd通信不要和etcd内部通信使用同一个ca颁发的证书，与client通信需要另一套ca及证书，另与kubelet通信，与kube-proxy通信）；
手动部署k8s，至少要建5套CA；
node上组件：
kubelet组件，与api server交互，（集群代理）接收master调度来的任务，用来执行启动pod|挂载卷等；
容器引擎docker，用于执行容器；
kube-proxy，node上的守护进程，用于管理service，随时与api server通信（pod发生改变），api server会生成一通知事件，kube-proxy会在本地把对应的改变生成为iptables规则
pod：
k8s上，最小运行单位(原子单元)是pod，可理解为对容器作了层封装（外壳），1个pod中有多个容器，共享底层的net|UTS|IPC，而另3个是隔离的，pod是模拟传统的vm，使得可以精细的控制容器间通信，同一个pod中的容器共享同一个存储卷；
一般1个pod内放1个容器，除非几个容器间有紧密关联，如果1个Pod内有多个容器，其中有1个主容器，其它的称为side car边车是辅助的用来补充主的功能，如nignx和filebeat；
node内运行pod，node可以是任何OS平台；
label selector，对pod打标签（kv），用来身份识别和过滤，分类管理；
k8s是restful风格的api，所有对象都可以用label selector，pod只是用的其中1种；
pod有生命周期；
pod控制器分类：
1、自主式pod，自己管理的,不能动态的增减pod，如果pod异常挂掉不能主动增加；
2、控制器管理的pod：
ReplicationController，1）保持某pod始终有配置的几个副本；2）支持滚动更新（如用户要求有2个pod，在使用新镜像时（nginx版本升级），在更新过程中允许临时超出1个pod，依次把旧版本运行的容器替换掉），支持回滚操作（先例操作，即滚动更新的逆反）；
ReplicSet，副本集控制器；
Deployment，更新时用的，用的最多，只能管理无状态应用，支持HPA（horizontalPodAutoscale水平pod自动伸缩控制器，如2个Pod不足以支持当前的访问量，会自动加pod）；
StatefulSet，管理有状态应用；
DaemonSet，1个node上运行1个副本，而不是随意运行；
Job，运行作业；
CronJob，周期性的作业；
注：每1种控制器实现特定的任务管理，用于确保不同类型的pod资源来符合用户期望的运行方式；
service
client程序和pod间有一中间层service，实现代理转发，用于在pod更新时动态地加入组中，service关联后端的pod通过label selector选定新加的pod；
service不是一程序，而是iptables的DNAT规则，在1.11ver上已改为ipvs（LVS）；
service是基础架构级（支撑其它服务运行的组件）的pod，称为addon附件，k8s自身要用到，安装k8s时要先安装它；
k8s上有一专用的DNS（也是pod），也是基础架构级组件，用于动态创建动态删除对应的service地址；
用户访问到N，要经3次转发，先经外部的调度器，再经物理节点的网卡，再经service转；
每个服务都要有1个service组件和1个controller，service要手动创建，service和controller通过label和label selector实现自己治下的资源；
dns也需要service和controller；
另负责监控pod的grafana|prometheus也是附件之一；
k8s网络：
节点网络；
集群网络，service网络；
pod网络；
k8s自身不提供这3种网络，依赖于第三方插件（也可作为附件），网络服务商至少要解决pod网络和service网络，节点网络由运维人员构建k8s集群前提供；
k8s通过CNI（container network interface）接入外部的网络服务解决方案，只要遵循CNI就可作为k8s网络的解决方案，这些网络可作为附件运行在pod容器上为其它pod提供网络（也可作为守护进程运行在node上），这个网络解决方案pod虽运行在集群之上但要共享节点的网络名称空间，这样就实现了以容器方式运行进而进行系统管理；
flannel，常见的CNI，coreos提供，简单，仅网络配置，overlay网络；
calico，配置复杂，网络配置和网络策略，3层隧道网络，也可使用bgp协议的路由直通模型；
canel，网络配置，网络策略；
通常需要2个维度的网络，1给pod和service提供地址，2k8s要求提供network policy网络策略功能（隔离不同的pod间通信，pod间本身是可以直接通信的，只不过为解决pod异常停止|动态加pod才加了中间service）；
k8s通信：
同一pod内的多个容器间通信，本地通信lo；
各pod间通信，overlay network叠加网络（隧道）；
pod与service通信，service地址仅是宿主机上的iptables规则，pod上的容器将其网关指向docker0，docker0访问service时通过iptables规则检查就知道了；
