应用部署方式演变

传统部署---->虚拟化部署---->容器化部署

容器化部署出现的问题

1、一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器

2、当并发访问量变大的时候，怎么样做到横向扩展容器数量

容器管理的问题统称为容器编排问题

解决方式：

产生了容器编排的软件（市场占有率最高的是Kubernetes：Google开源的的容器编排工具）

k8s的主要功能

1、自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器（比如图中挂了一个nginx，那么1s左右就会有一个ngnix启动，总数5个不变）

2、弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整（比如图中5个ngnix上限支持1000个并发，当并发量突然增大到1200，那么k8s集群会自动地增加一个ngnix去分担流量，当并发量高峰过去以后，会自动地把新启动的ngnix删掉。）

3、服务发现：服务可以通过自动发现的形式找到它所依赖的服务（比如ngnix需要redis和mysql的帮助，那么它会在k8s内部以自动发现的形式去寻找这两个服务【左上的nginx会自动地去找到右上地mysql和右下地redis）

4、负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡（比如图中集群中有5个ngnix，比如有1000个并发请求，那么它会自动地分担到5个ngnix上去）

5、版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本。

6、存储编排：可以根据容器自身的需求自动创建存储卷（比如mysql创数据需要存储，那么它就要去中间的那个紫色的写着存储的地方要存储卷，那么它直接告诉k8s它需要多少存储。待日后学完再补充细节。）

k8s组件

一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件。

master：集群的控制平面，负责集群的决策 ( 管理 )

ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制

Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上【如果我要用这个集群，那么就要发起请求，请求进入master后就进入到ApiServer中，然而右边上下有两个node，所以要决策一下给哪个node干活，Scheduler就担任决策的工作。】

ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等【Scheduler决策完毕让node1干活，需要有人安排，ControllerManager就把这个活安排给node1告诉它怎么去做。】

Etcd ：负责存储集群中各种资源对象的信息【记录这个服务在哪里，体现的是一个数据库功能（k8s默认用这个，如果想用mysql就自己配）】

node：集群的数据平面，负责为容器提供运行环境 ( 干活 )

Kubelet : 负责维护容器的生命周期，即通过控制docker，来创建、更新、销毁容器（接收master传达的信息，接收完了它再把活安排下去，它要控制docker将服务跑起来，也就是说要启动一个该服务的pod，pod是kubernetes的最小操作单元，容器必须跑在pod中）

KubeProxy : 负责提供集群内部的服务发现和负载均衡（服务跑在了docker上了，但是要提供对外访问，就通过KubeProxyy来对pod产生访问的代理。和ApiServer入口访问的区别：KubeProxy只是访问这个布在docker上的服务，而不是控制程序。）

Docker : 负责节点上容器的各种操作

kubernetes概念

Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控

Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的docker负责容器的运行

Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器

Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等

Service：pod对外服务的统一入口，下面可以维护者同一类的多个pod

Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签（图中service把流量打到3个tomcat上是因为这三个tomcat的标签相同）

NameSpace：命名空间，用来隔离pod的运行环境（本来图中四个pod是可以相互访问的，如果不想让他们相互访问了，就设个namespace，同一个namespace里面的pod才能相互访问。）