随着技术发展，运维实现部署，实现应用编排，经历了许多变化
早期，我们可以使用ansible，saltstack等批量工具进行安装，编排
后来出现了docker，应用程序容器化，编排工具也发生了变化
这里我用通俗一些的话简单介绍下早期的docker三剑客，也就是docker compose、docker swarm和docker machine的应用场景 。
docker compose
它更加适用于单机编排，换句话说，docker compose适用于一个docker host来进行编排操作
docker swarm
我们可以理解为它可以将多个docker host整合为同一平台下管理机制的一个集群工具，通俗讲就是docker swarm可以将多个docker host提供的计算资源整合成一个资源池，随后docker compose再去编排时，只需要面向这一资源池进行编排即可，无论底层到底有什么样的docker host或是几个dockerhost。
docker machine
docker swarm可以将多个docker host整合，那么什么样的docker host能被它整合，满足加入docker swarm中的一个成员呢？这就需要另一个工具，那就是docker machine，它可以将一个 docker host初始化成一个可以满足加入docker swarm集群的docker主机，我们也可以称它为一个预处理工具。
再后来出现了我们要讲的主角--kubernetes（k8s）
kubernetes环境架构、概念、术语
集群主机
可以说他就是一个集群，组合多台主机的资源，整合成一个大的资源池，并统一对外提供计算、存储等能力的集群，说白了就是找很多台主机，每一台主机上都安装上 kubernetes的应用程序，并通过这些应用程序协同工作，把多个主机当成一个主机来使用，让 所有主机来完成通信 ，从而完成彼此间的协调。
在k8s中，主机是分角色的，属于有中心节点架构的集群系统， 称为master/nodes结构模型
一组节点用来扮演master主节点，不需太多，能够做冗余，一般三个，是整个集群的唯一入口。
nodes在做相关的工作，可以理解为master是蜂王，用来指挥，node则为工蜂，是干活的。每一个node节点，都是来贡献一部分计算能力，存储能力等相关资源的节点，说白了就是运行容器的节点。
一个容器的启动
用户把创建启动容器的请求先发给master，master当中有一个调度器去分析各node现有的可用资源状态，然后找一个最适配的node节点利用本地的docker或者容器引擎把这个容器启动起来。
要启动这个容器需要镜像，接受这个请求的node节点先会在本地是否有镜像，若没有，这个node节点则从外部的dockerhub或私有redis，亦或者是K8S内自己的redis上把镜像拖下来，来启动所被请求的容器。
Node组件
kubelet、kube-proxy
kubelet
在每个节点（node）上都要运行一个 worker 对容器进行生命周期的管理，这个 worker 程序就是 kubelet。简单地说，kubelet 的主要功能就是定时从某个地方获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。
kubelet的主要作用可概括为节点管理、pod管理、容器健康检查、容器监控
节点管理
Kubelet在创建之初就会向API Server做自注册，然后会定时报告节点的信息给API Server写入到Etcd中。默认为10秒。
pod管理
Kubelet会监听API Server，如果发现对Pod有什么操作，它就会作出相应的动作。例如发现有Pod与本Node进行了绑定。那么Kubelet就会创建相应的Pod且调用Docker Client下载image并运行container。
容器健康检查
有三种方式对容器做健康检查：
1.在容器内部运行一个命令，如果该命令的退出状态码为0，则表明容器健康。
2.TCP检查。
3.HTTP检查。
容器监控
Kubelet通过cAdvisor对该节点的各类资源进行监控。如果集群需要这些监控到的资源信息，可以安装一个组件Heapster。
Heapster会进行集群级别的监控，它会通过Kubelet获取到所有节点的各种资源信息，然后通过带着关联标签的Pod分组这些信息。
如果再配合InfluxDB与Grafana，那么就成为一个完整的集群监控系统了。
kube-proxy
每个pod上都会运行一个kube-proxy，负责接收并转发请求。Kube-proxy的核心功能是将到Service的访问请求转发到后台的某个具体的Pod。(service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP)具体来说，就是实现了内部从pod到service和外部的从node port向service的访问。
举个例子，现在有podA，podB，podC和serviceAB。serviceAB是podA，podB的服务抽象(service)。那么kube-proxy的作用就是可以将pod(不管是podA，podB或者podC)向serviceAB的请求，进行转发到service所代表的一个具体pod(podA或者podB)上。请求的分配方法一般分配是采用轮询方法进行分配。
另外，kubernetes还提供了一种在node节点上暴露一个端口，从而提供从外部访问service的方式。
无论是通过ClusterIP+Port的方式还是NodeIP+NodePort的方式访问Service，最终都会被节点的Iptables规则重定向到Kube-proxy监听服务代理端口，当Kube-proxy监听到Service的访问请求后，它会找到最适合的Endpoints，然后将请求转发过去。具体的路由选择依据Round Robin算法及Service的Session会话保持这两个特性。
Master包含三个组件。
controller-manager，scheduler，apiserver，他们的状态和信息都保存在etcd中，所以etcd也要做冗余
API server
kubernetes把master之上的一个组件称为API server，负责接收请求，解析请求，处理请求，它提供了HTTP Rest接口的关键服务进程，是kubernetes里所有资源的增删改查等操作的唯一入口，也是集群的入口进程。
调度器-scheduler
如果客户端请求创建一个容器，这个容器不应该是创建在master之上的，而应该是node之上，但是哪一个node更合适？此时就引出另一个概念，那就是调度器，叫做scheduler，负责去观测每一个可用的node之上总共可用的计算资源和存储资源，并根据用户所请求创建的容器所需要的最低需求量、资源量去评估，哪一个节点更合适，因此kubernetes设计了一个两级调度的方式来完成调度，第一步，先做预选，即先初步评估一下到底有多少个适合启动请求容器需求的节点，第二步，从筛选出的node中挑选出最佳适配，取决于你的调度算法中的优选算法来决定
控制器管理器-controller-manager
kubernetes还拥有自愈能力。当其中一台node节点上的容器故障了，它会在其他合适的节点上创建一台相同的容器来，确保这个容器始终是健康的。那么我们如何知道他是否故障呢？---持续监控它，所以kubernetes还实现了一大堆的叫控制器的组件，它会在本地不停的loop循环，持续性的负责去监控他所管理的容器是否是健康的，一旦发现问题，控制器就会向master APIserver发请求说我的容器挂了一个，你在帮我调度一个适配的node把容器启动起来。
但是，当我们之前说的去负责持续监控的scheduler控制器出现问题了，又该如何解决呢？这就引出了master之上的另一重要组件，控制器管理器-controller-manager，他是kubernetes里所有资源对象的自动化管理中心，可以理解为资源对象的“大总管”，它负责去监控着每一个控制器是健康的。
node节点可动态增加到kubernetes集群中，前提是这个节点已经正确安装、配置和启动了上述的关键进程，默认情况下，kubelet会向master注册自己，这也是kubernetes推荐的node管理方式，一旦node被纳入集群管理范围，kubelet会定时向master汇报自身的情况，以及之前有哪些pod在运行等，这样master可以获知每个node的资源使用情况，并实现高效均衡的资源调度策略。如果node没有按时上报信息，则会被master判断为失恋，node状态会被标记为not ready，随后master会触发工作负载转移流程。
Pod
是kubernetes最重要也是最基本的概念，每个Pod都会包含一个‘根容器’，还会包含一个或者多个紧密相连的业务容器，pod是kubernetes中最基本的管理单位，而不是 container。
flannel
kubernetes为每个Pod都分配了唯一的IP地址，称之为PodIP，一个Pod里的多个容器共享PodIP地址，要求底层网络支持集群内任意两个Pod之间的直接通信，通常采用虚拟二层网络技术来实现（Flannel）
Label
是一个key=value的键值对，其中key与value由用户自己指定。可以附加到各种资源对象上，一个资源对象可以定义任意数量的Label。可以通过LabelSelector（标签选择器）查询和筛选资源对象
Etcd
Etcd一种k-v存储仓库，可用于服务发现程序。在Kubernetes中就是用Etcd来存储各种k-v对象的。
Etcd是Kubernetes的一个重要组件。当我们无论是创建Deployment也好，还是创建Service也好，各种资源对象信息都是写在Etcd中了。
各个组件是通过API Server进行交流的，然而数据的来源是Etcd。所以维持Etcd的高可用是至关重要的。如果Etcd坏了，任何程序也无法正常运行了。
总结
Kubernetes的这些组件各自分别有着重要的功能。它们之间协同工作，共同保证了Kubernetes对于容器化应用的自动管理。
API Server起着桥梁的作用，各个组件都要通过它进行交互。Controller Manager像是集群的大管家，管理着许多事务。Scheduler就像是一个调度亭，负责Pod的调度工作。
Kubelet则在每个节点上都有，像是一个执行者，真正创建、修改、销毁Pod的工作都是由它来具体执行。
Kube-proxy像是负载均衡器，在外界需要对Pod进行访问时它作为代理进行路由工作，将具体的访问分给某一具体的Pod实例。
Etcd则是Kubernetes的数据中心，用来存储Kubernetes创建的各类资源对象信息。
这些组件缺一不可，无论少了哪一个Kubernetes都不能进行正常的工作。这里大概讲了下各组件的功能，感兴趣的可以分析Kubernetes的源码，github中就有。