vlambda博客
学习文章列表

从个人的角度来说，我能看到的云平台，无外乎面向Iaas私有云的kvm/openstack，以及面向容器或者Paas的 kubernetes/docker。

为什么我喜欢基于linux的云平台呢？首先linux就如万金油一般的存在，linux上的应用，基本都开源。

当然云计算是个很广的概念。首先 “云”和“计算”都能被劈来聊上一下午。然后，云计算还可以从统一管理，自动运维，和技术创新等方面进行思考和阐述。

而作为草根出身喜欢自下而上看方案的人，我更喜欢从操作系统的角度来看云平台究竟是怎么实现的。

许多厂商将数据中心发展，划分成了:基于物理设备，基于虚拟化，基于云计算平台三个阶段以及往后等等。redhat也不外如是。

在redhat的map图里，云产品架构涵盖了物理机上的RHEL/centos，KVM/RHVM，openstack，openshift。以及贯穿三阶段的，批量配置管理工具。

虚拟化，将物理机的CPU内存，网络，存储等资源进行了粒度化。实现了云计算资源即需即供的基础。

实现虚拟化后，IT资源的使用更加灵活弹性，但IT资源使用者和系统管理员却没有解耦：

使用者的资源需求还是要落到系统管理员那里——或者说，系统管理员需要 对使用者的需求进行需求分析，生成资源配置，以及资源生命周期管理，然后系统管理员通过虚拟化管理软件实现并最终交付给使用者。

而云平台，则试图解耦：

对外，将使用者与IT管理员解耦，将使用者和使用者进行解耦；

对内，将逻辑实现和物理层解耦；

——再对比上面虚拟化，也就是说，云平台给了使用者一个统一接口、云平台本身实现了使用者的需求分析，资源配置，资源生命周期管理，以及最终的资源交付；系统管理员更专注云平台建设、扩容和维护。所以 使用者和IT管理员 实现了解耦。

这种解耦，其实是有代价的。——例如我们为了实现 租户的虚机可以自由跨物理机分布以及大量用户/租户之间的隔离，采用了overlay网络方案，而这必然影响到了网络性能。但当用户数量/设备数量庞大时，这个用于管理的代价又是我们不得不接受的。

就如一个公司，创业初寥寥几人，每个人都是兼职几乎不需要专门的管理团队，高效，员工成本几乎就等于他的工资。而到了一定规模，几人之上就要设立一个经理；等到了规模更大的时候，还必须要有专门的管理部门，再计算员工个人成本时，必须要额外考虑管理成本。

如果从底层技术人员的角度看过去，有时候真在解耦和性能之间纠结——就如同 kubernetes中的flannel 和 calico，解耦和性能，究竟该选哪个？

还有另外一个代价就是，这种庞大的平台系统，涉及到了方方面面，主机，数据库，网络，分布式存储，消息队列。正常运转时还好，但若出现了问题，对维护人员真是挑战。

云计算确实增强了使用者的体验，但是确实也带来了额外的问题。所以，有些资料里又提出了这样的设问：你真的需要云计算吗？——这里还没有展开有状态服务和无状态服务的概念。

无论如何，云计算是当前的大势所趋。

其实云平台实现了（技术+自动化批量流程）的包装。若将linux分成 内核（微观）和应用（宏观）两方面，那么云平台也可以看作操作系统的应用的更高一层的封装。所以，当我们跨过了云平台安装、平台命令的操作、想深入看看组件内部是什么的时候，自上而下的，我们又不得不回头深入去看linux基础内容。

例如，很多资料里都说，网络部分往往是云平台中最复杂的部分。

当我们真的要去看清楚openstack Neutron那几层ovs/br网络架构，我们又不得不去回头逐条去看OVS的 opendataflow。——而当年我们学linux操作系统时，玩个ovs的命令配置：配个端口/tag，连接个tap设备就觉得会NFV了；

当我们真的要深入理解kubernetes的网络架构时，我们几乎必然的要回头去看iptables nat表的一条条规则组成的SNAT/DNAT逻辑。——而当年我们学linux操作系统时，能独立的在filter中写个防火墙禁入规则，就觉得很了不起了。

当我们真的要深入理解k8s的kube-proxy如何实现外部网络访问时，或者要深入理解openstack的router时，我们几乎必然要回头去看linux的 namespace————而当年我们学linux操作系统时，能创建个最简单namespace来模拟个虚机网络通信，就觉得学的很深了。

后面要并行开始虚拟化和云计算方面的内容了。我不想写网上泛泛的内容，真的是想写在我眼中的云计算到底是个啥.

先说虚拟化吧，kvm。