06 Contarner Orchestration

容器编排

Docker Swarm

Kubernetes

Mesos

Nomad by Hashicorp

Amazon ECS

Google Container Engine

Azure Container Service

本人最喜欢的是Kubernetes，简单讲解下。

架构，简单一看很简单，一个master，两个node，当然也可以n个master，n个node，里面还是很复杂的，这里先不深挖了。

组件;

1. Cluster 群集：群集是一组系统（物理的或虚拟的）和其他基础架构资源被Kubernetes用来运行容器化的应用。说白了，就是整套Kubernetes这个东西，有两种节点组成。

2. Node 节点：节点是一个pods在上面被调度和运行的系统。节点运行着一个守护进程叫kubelet，它允许节点与master节点通信。就是图中的Minion，图中有两个Minion，Minion是一种老叫法，还有什么salve node、worker node其实都是节点node，主要功能就是在上面运行容器化的应用。

3. Master主人，master是一个系统负责pod调度决策和管理复制和管理节点。

通俗理解就是一个Kubernetes群集当中有两种节点，一种是master负责管理的，一种是worker（这个好像是最新的叫法）负责运行容器的。

4. pod是一组共置的容器带有共享卷。它是最小的部署单元在Kubernetes中。一个pod能够被独立地创建，但是推荐使用复制控制器，即使仅仅一个单独的pod被部署。

pod就是运行在worker节点上的一组容器，在worker节点上运行的一组容器叫pod。哪怕是部署一个容器，Kubernetes的部署也是部署一个pod，然后这个容器在这个pod里面运行，所以它是被部署的最小的单元。

5. Replication Controller复制控制器，复制控制器管理pod的生命周期。它确保期望数量的pods运行在任何已知点在任何时候。

实际上就是控制pod的副本，其实也就是控制容器的副本。

6. Replica Sets复制集还是复制设置？是下一代复制控制器，那就先不说了。

7.Deployments部署，部署是一个抽象的概念，是一种操作对象。一个部署提供给Pods和Replica Sets。你仅仅需要描述期望的状态在一个部署对象中，部署控制器会改变实际的状态到期望的状态在一个被控制的速率为你。你可以定义部署来创建新的资源或重置已存在被新的。

一个典型的使用场景是，

创建一个部署来启用一个Replica Set和Pods。

检查一个部署的状态来看是否成功还是没有。

之后，更新部署来重创建pods，例如，使用新的镜像。

滚回到一个早前的部署版本如果当前的部署不稳定

暂停和恢复一个部署。

简单来说就是，部署是用来定义pods和replica set状态的。一个抽象的概念，你要部署一组容器，就创建一个部署（名字）来部署（动词）一组容器。

那这个跟Replication Controller有什么区别呢？老实说，我也没搞清楚，对比下面的代码，我简单理解是Deployment是一种更大更重的东西，就是如果要创建一组容器，那就用创建一个部署来定义这组容器，包括这组容器会用到的一些资源，而副本控制器是用来控制副本伸缩的，随时定义容器需要几个副本。

apiVersion: v1kind: ReplicationControllermetadata:  name: frontendspec:  replicas: 2  template:    metadata:      labels:        app: dockchat        tier: frontend    spec:      containers:      - name: chat        image: nkhare/dockchat:v1        env:        - name: GET_HOSTS_FROM          value: dns        ports:        - containerPort: 5000

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
    template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 8

8. Service服务，一个抽象的概念。服务就是一组pods，用一个单一的静态IP地址和DNS名字来引用这些pods。

说白了就是一组pod组成一个Service，然后这组pod拥有同一个IP地址和同一个DNS名字。

apiVersion: v1kind: Servicemetadata:  name: frontend  labels:    app: dockchat    tier: frontendspec:  type: LoadBalancer  ports:  - port: 5000  selector:    app: dockchat
    tier: frontend

9. Label标签，又是一个抽象的概念，就是给pod或者副本控制器贴标签，作用就是好识别，让人容易识别。上面列子app:dockchat、tier:frontend就是给前端贴的标签。

10. Selector，抽象的概念，就是一组贴了标签的资源。上面例子，所有贴有app:ddockchat和tier: frontend标签的资源都会挂载到负载均衡后面。

11. Volume卷，就是挂载到pod的存储，这个好理解，挂载给容器的存储，其实这个并不是Kubernetes的概念。

12. NameSpace命名空间，放在资源名字之前的一个前缀。

就是一个最大的名字，在一个Kuber区分项目、团队所属的资源，这里的资源其实就是pods、Replication Controller、Deployment等等这些东西。

Kubernetes由于还在快速发展，所以很多架构概念也在快速变化，很容易混淆和头晕。

通过我自己的安装可以看出来，以master结尾的，master是我自己命名的CentOS的主机名

etcd-master

kube-apiserver-master

kube-controller-manager-master

kube-scheduler-master

其中，etcd是一种数据库，是CoreOS生态圈当中的一员，Kubernetes群集依赖这个数据库，

所以master节点当中能称得上架构的，大概就是apiserver、controller-manager、scheduler

那worker节点当中运行着什么呢，其实就只有kubelet，这个作用是与master节点通信的。

其次就是worker节点还运行着docker，并不是Kubernetes组件。

docker运行着容器，一组容器就是一个pod，是Kubernetes的最小运行单元，

然后pod会标上很多标签，用以识别。

kube-proxy好理解，就是网络反向代理的。

所以Kubernetes的组件就5个

master上面3个，kube-apiserver，kube-controller-manager，kube-scheduler

worker上面2个，kkubelet，kube-proxy

下面是我能找到的与现在比较接近的Kubernetes的架构图

下面就是一个非常重要的东西，可创建的对象，那么多概念，那到底用文件定义的对象有哪些？

就是那些kind，太多了，我觉得应该会有一个yaml文件编辑器