八、基于OpenStack了解云平台
当有了虚拟机，并且虚拟机能够上网了之后，接下来就是搭建云平台的时候了。
云是基于计算，网络，存储虚拟化技术的，云和虚拟化的主要区别在于，管理员的管理模式不同，用户的使用模式也不同。
虚拟化平台没有多层次的丰富的租户管理，没有灵活quota配额的限制，没有灵活的QoS的限制，多采用虚拟网络和物理网络打平的桥接模式，虚拟机直接使用机房网络，没有虚拟子网VPC的概念，虚拟网络的管理和隔离不能和租户隔离完全映射起来。对于存储也是，公司采购了统一的存储，也不能和租户的隔离完全映射起来。
使用虚拟化平台的特点是，对于这个平台的操作完全由运维部门统一管理，而不能将权限下放给业务部门自己进行操作。因为一旦允许不同的部门自己操作，大家都用机房网络，在没有统一管控的情况下，很容易网段冲突了。如果业务部门向申请虚拟机，需要通过工单向运维部门统一的申请。当然这个运维部门很适应这种方式，因为原来物理机就是这样管理的。
但是公有云，例如aws就没办法这样，租户千千万万，只能他们自己操作。在私有云里面，随着服务化甚至微服务化的进行，服务数目越来越多，迭代速度越来越快，业务部门需要更加频繁的创建和消耗虚拟机，如果还是由运维部统一审批，统一操作，会使得运维部门压力非常大，而且极大限制了迭代速度，因而要引入 租户管理，运维部灵活配置每个租户的配额quota和QoS，在这个配额里面，业务部门随时可以按照自己的需要，创建和删除虚拟机，无需知会运维部门。每个部门都可以创建自己的虚拟网络VPC，不同租户的VPC之前完全隔离，所以网段可以冲突，每个业务部门自己规划自己的网络架构，只有少数的机器需要被外网或者机房访问的时候，需要少数的机房IP，这个也是和租户映射起来的，可以分配给业务部门机房网IP的个数范围内，自由的使用。这样每个部门自主操作，迭代速度就能够加快了。
云平台中的开源软件的代表是OpenStack，建议大家研究OpenStack的设计机制，是在云里面通用的，了解了OpenStack，对于公有云，容器云，都能发现相似的概念和机制。
沿着OpenStack创建虚拟机的过程，我总结了100个知识点，写下了下面的文章。
用OpenStack界面轻松创建虚拟机的你，看得懂虚拟机启动的这24个参数么？
觉得OpenStack的网络复杂？其实你家里就有同样一个网络
当发现你的OpenStack虚拟机网络有问题，不妨先试一下这16个步骤
手动用KVM模拟OpenStack Cinder挂载iSCSI卷
不仅Docker会使用Control Group，KVM也会使用Cgroup来控制资源分配
通过我们研究OpenStack，我们会发现很多非常好的云平台设计模式。
第一：基于PKI Token的认证模式
如果我们要实现一个Restful API，希望有个统一的认证中心的话，Keystone的三角形工作模式是常用的。
当我们要访问一个资源，通过用户名密码或者AK/SK登录之后，如果认证通过，接下来对于资源的访问，不应该总带着用户名密码，而是登录的时候形成一个Token，然后访问资源的时候带着Token，服务端通过Token去认证中心进行验证即可。
如果每次验证都去认证中心，效率比较差，后来就有了PKI Token，也即Token解密出来是一个有详细租户信息的字符串，这样本地就可以进行认证和鉴权。
第二：基于Role Based Access Control的鉴权模式
对于权限控制，我们学会比较通用的Role Based Access Control的权限控制模式，形成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系，可以非常灵活的控制权限。
第三：基于Quota的配额管理
可以通过设置计算，网络，存储的quota，设置某个租户自己可以自主操作的资源量。
第四：基于预选和优选两阶段的Scheduler机制
当需要从一个资源池里面，选择一个节点，使用这个节点上的资源的时候，一个通用的Scheduler机制是：
- 首先进行预选，也即通过Filter，将不满足条件的过滤掉。
- 然后进行优选，也即对于过滤后，满足条件的候选人，通过计算权重，选择其中最优的。
第五：基于独立虚拟子网的网络模式
为了每个租户可以独立操作，因而虚拟网络应该是独立于物理网络的，这样不同的租户可以进行独立的网络规划而互不影响，也不影响物理网络，当需要跨租户访问，或者要访问物理网络的时候，需要通过路由器。
第六：基于Copy on Write的镜像机制
有时候我们在虚拟机里面做了一些操作以后，希望能够把这个时候的镜像保存下来，好随时恢复到这个时间点，一个最最简单的方法就是完全复制一份，但是由于镜像太大了，这样效率很差。因而采取Copy on write的机制，当打镜像的时刻，并没有新的存储消耗，而是当写入新的东西的时候，将原来的数据找一个地方复制保存下来，这就是Copy on Write。
对于Openstack，有一种镜像qcow2就是采取的这样的机制。
这样镜像就像分层一样，一层一层的罗上去。
第七：基于namespace和cgroup的隔离和Qos机制
在OpenStack里面，网络节点的路由器是由network namespace来隔离的。
KVM的占用的CPU和内存，使用Cgroup来隔离的。
网络的QoS使用TC来隔离的。
第八：基于iptables的安全机制
有时候，我们希望网络中的节点之间不能相互访问，作为最简单的防火墙，iptables起到了很重要的作用，以后实现ACL机制的，都可以考虑使用iptables。
九、基于Mesos和Kubernetes了解容器平台
搭建完毕虚拟化层和云平台层，接下来就是容器层了。
Docker有几个核心技术，一个是镜像，一个是运行时，运行时又分看起来隔离的namespace和用起来隔离的cgroup。
Docker的镜像也是一种Copy on Write的镜像格式，下面的层级是只读的，所有的写入都在最上层。
对于运行时，Docker使用的namespace除了network namespace外，还有很多，如下表格所示。
Docker对于cgroup的使用是在运行Docker的时候，在路径/sys/fs/cgroup/cpu/docker/下面控制容器运行使用的资源。
可见容器并没有使用更新的技术，而是一种新型的交付方式，也即应用的交付应该是一容器镜像的方式交付，容器一旦启动起来，就不应该进入容器做各种修改，这就是不可改变基础设施。
由于容器的镜像不包含操作系统内核，因而小的多，可以进行跨环境的迁移和弹性伸缩。
我写下了下面的文章，总结了几点容器的正确使用姿势。
有了容器之后，接下来就是容器平台的选型，其实swarm, mesos, kubernetes各有优势，也可以在不同的阶段，选择使用不同的容器平台。
Docker, Kubernetes, DCOS 不谈信仰谈技术
容器平台选型的十大模式：Docker、DC/OS、K8S谁与当先？
基于Mesos的DCOS更像是一个数据中心管理平台，而非仅仅容器管理平台，他可以兼容Kubernetes的编排，同时也能跑各种大数据应用。
在容器领域，基于Kubernetes的容器编排已经成为事实标准。
当我们深入分析Kubernetes管理容器模式的时候，我们也能看到熟悉的面孔。
在Kubernetes里面，租户之间靠namespace进行隔离，这个不是Docker的namespace，而是Kubernetes的概念。
API Server的鉴权，也是基于Role Based Access Control模式。
Kubernetes对于namespace，也有Quota配置，使用ResourceQuota。
当Kubernetes想选择一个节点运行pod的时候，选择的过程也是通过预选和优选两个阶段。
- 预选(Filtering)
- PodFitsResources满足资源
- PodSelectorMatches符合标签
- PodFitsHost符合节点名称
- 优选(Weighting)
- LeastRequestedPriority资源消耗最小
- BalancedResourceAllocation资源使用最均衡
Kubernetes规定了以下的网络模型定义。
- 所有的容器都可以在不使用NAT的情况下同别的容器通信
- 所有的节点都可以在不使用NAT的情况下同所有的容器通信
- 容器的地址和别人看到的地址一样
也即容器平台应该有自己的私有子网，常用的有Flannel, Calico, Openvswitch都是可以的。
既可以使用Overlay的方式，如图flannel.
也可以使用BGP的方式，如图Calico
