集群编排的困难

现代服务大多数都不是单点的，更多的是各种微服务，充斥着各种分布式的分布特点，对应docker的容器的话，一个服务实例就是一个容器，但随着节点一直增多，docker对于这些容器的部署难度也变得棘手了起来。

容器编排工具比较

docker-compose是docker官方提供的对docker多容器进行编排管理，但存在局限性，只能对单机内的多容器进行编排。Docker-Compose 是用来管理你的容器的，有点像一个容器的管家，想象一下当你的Docker中有成百上千的容器需要启动，如果一个一个的启动那得多费时间。有了Docker-Compose你只需要编写一个文件，在这个文件里面声明好要启动的容器，配置一些参数，执行一下这个文件，Docker就会按照你声明的配置去把所有的容器启动起来，只需docker-compose up即可启动所有的容器，但是Docker-Compose只能管理当前主机上的Docker，也就是说不能去启动其他主机上的Docker容器。

Docker Swarm 是一款用来管理多主机上的Docker容器的工具，可以负责帮你启动容器，监控容器状态，如果容器的状态不正常它会帮你重新帮你启动一个新的容器，来提供服务，同时也提供服务之间的负载均衡，而这些东西Docker-Compose 是做不到的

Kubernetes它本身的角色定位是和Docker Swarm 是一样的，也就是说他们负责的工作在容器领域来说是相同的部分，都是一个跨主机的容器管理平台，当然也有自己一些不一样的特点，k8s是谷歌公司根据自身的多年的运维经验研发的一款容器管理平台。而Docker Swarm则是由Docker 公司研发的。

既然这两个东西是一样的，那就面临选择的问题，应该学习哪一个技术呢?实际上这两年Kubernetes已经成为了很多大公司的默认使用的容器管理技术，而Docker Swarm已经在这场与Kubernetes竞争中已经逐渐失势，如今容器管理领域已经开始已经逐渐被Kubernetes一统天下了。所以建议大家学习的时候，应该多考虑一下这门技术在行业里面是不是有很多人在使用。

Kubernetes的职责

1、自动化容器的部署和复制
2、随时扩展或收缩容器规模
3、容器分组Group，并且提供容器间的负载均衡
4、实时监控, 即时故障发现, 自动替换

Kubernetes的基本概念

K8S是一种主从架构的服务架构分布情况，客户端主要通过与K8S Master进行通信，然后由K8S Master分发到指定的Node中执行特定操作。

K8S的基本组成

K8S Master

客户端主要通过与K8S Master进行通信，然后由K8S Master分发到指定的Node中执行特定操作。

Replication Controller

通过它可以指定POD的副本数，并对其目前的实际副本是否达标进行实时监测和修复，当发现某个POD副本超过时间无法响应会自动对其进行剔除，并根据指定副本数自动创建到达标数量，因此，它可以很方便的对服务进行容错处理和对服务的动态伸缩。

Node

Pod

1、POD是存放”容器”的容器,可以包含多个”Container”
2、POD是K8S最小可部署单元,一个POD就是一个进程
3、POD内部容器网络互通,每个POD都有独立虚拟IP
4、POD都是部署完整的应用或模块

Pause容器

每个pod中都有一个pause，它的作用：
1、为pod中的所有容器提供一个共享的挂载数据卷
一般来说数据都不建议存放在容器内部，此时可以将数据剥离到pause中进行共享存储，然后各个容器进行数据卷挂载访问，方便K8S统一集群管理

2、提供一个共享的网络HOSTNAME命名空间

例如一个POD中的多个容器想要互相访问，一般来说需要通过name或者ip进行访问，但通过pause，可以实现它们之间变成一个整体，可直接通过localhost通过端口进行转发： 例如nginx是80端口，ghost是8080端口， nginx想要访问ghost，可直接通过 localhost:8080， 然后pause会进行转发访问到ghost

Label

说明性标签，是作为POD的一个描述性别名，在进行批量化管理时，可以通过指定Label的形式进行方便的管理，且只有给POD起了Label，才能通过K8S Master对这个POD进行操作

Kubelet

作为在宿主机上执行关于K8S的命令的角色。

kube-proxy

因为每个POD都是一个独享的IP，是不能进行跨POD通信的，因此需要通过service进行访问,而实际的技术实现就是通过kube-proxy作为代理，实现跨主机跨POD通信。