Kubernetes和OpenStack到底是什么关系？先搞清楚，再系列学习

   Kubernetes 面向应用层，变革的是业务架构，而 OpenStack 面向资源层，改变的是资源供给模式。使用容器且集群规模不大，直接用 Kubenetes 就可以；集群规模大，不管应用是否只是跑在容器中，都是 OpenStack + Kubernetes 更好。

OpenStack + Kubernetes 是各取所长，并不只是因为惯性，而是对于多租户需求来说，Container（容器）的隔离性还需要加强，需要加一层 VM（虚拟机） 来弥补，而 OpenStack 是很好的方案。不过，VM + Container 的模式，必然有性能的损耗，所以 OpenStack 基金会也推出一个项目叫 Kata Containers，希望减少虚拟化的开销，兼顾容器的性能和隔离性。

永恒的只有变化，未来的业务都会运行在云上，容器是走向 DevOps、Cloud Native（云原生）的标准工具，已经开始走向平凡，而 Kubernetes 的编排能力，让容器能够落地到业务应用中，所以我们看到 Docker、Mesos、OpenStack 以及很多公有云、私有云服务商，都在支持 Kubernetes，大家都加入了 CNCF（云原生计算基金会）。

总结起来，OpenStack 是兼容传统的架构，而 Kubernetes 是面向未来的架构。

最后，计算开源云这几年发展很快，从这个问题提出到现在，社区又有了很多变化。所以要修正一个观点：Kubernetes 支持的容器运行时不仅仅是 Docker，也包括 Rkt，当然 Docker 更加流行。

  

简单的说，kubernetes是管理container的工具，openstack是管理VM的工具。

container可以运行在物理机上，也可以运行在VM上。所以kubernetes不是需要openstack的支持。但对于云计算来说，很多IasS都通过openstack来管理虚拟机。然后用户可以在这些虚拟机上运行docker，可以通过kubernetes进行管理。

不过kubernetes虽然是开源的，但它毕竟是为GCE服务的，Google其实并没有多少动力去支持其他平台的。

   

Kubernetes这个单词来自于希腊语，含义是舵手或领航员。K8S是它的缩写，用“8”字替代了“ubernete”这8个字符。

和Docker不同，K8S的创造者，是众人皆知的行业巨头——Google。

然而，K8S并不是一件全新的发明。它的前身，是Google自己捣鼓了十多年的Borg系统。

K8S是2014年6月由Google公司正式公布出来并宣布开源的。

同年7月，微软、Red Hat、IBM、Docker、CoreOS、Mesosphere和Saltstack等公司，相继加入K8S。

之后的一年内，VMware、HP、Intel等公司，也陆续加入。

2015年7月，Google正式加入OpenStack基金会。与此同时，Kuberentes v1.0正式发布。

目前，kubernetes的版本已经发展到V1.13。

K8S的架构，略微有一点复杂，我们简单来看一下。

一个K8S系统，通常称为一个K8S集群（Cluster）。

这个集群主要包括两个部分：

• 一个Master节点（主节点）
• 一群Node节点（计算节点）

一看就明白：Master节点主要还是负责管理和控制。Node节点是工作负载节点，里面是具体的容器。

深入来看这两种节点。

首先是Master节点。

Master节点包括API Server、Scheduler、Controller manager、etcd。

API Server是整个系统的对外接口，供客户端和其它组件调用，相当于“营业厅”。

Scheduler负责对集群内部的资源进行调度，相当于“调度室”。

Controller manager负责管理控制器，相当于“大总管”。

然后是Node节点。

Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。

Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。除了Pod之外，K8S还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口。这段不太好理解，跳过吧。

Docker，不用说了，创建容器的。

Kubelet，主要负责监视指派到它所在Node上的Pod，包括创建、修改、监控、删除等。

Kube-proxy，主要负责为Pod对象提供代理。

Fluentd，主要负责日志收集、存储与查询。

是不是有点懵？唉，三言两语真的很难讲清楚，继续跳过吧。

Docker和K8S都介绍完了，然而文章并没有结束。

接下来的部分，是写给核心网工程师甚至所有通信工程师看的。

从几十年前的1G，到现在的4G，再到将来的5G，移动通信发生了翻天覆地的变化，核心网亦是如此。

但是，如果你仔细洞察这些变化，会发现，所谓的核心网，其实本质上并没有发生改变，无非就是很多的服务器而已。不同的核心网网元，就是不同的服务器，不同的计算节点。

变化的，是这些“服务器”的形态和接口：形态，从机柜单板，变成机柜刀片，从机柜刀片，变成X86通用刀片服务器；接口，从中继线缆，变成网线，从网线，变成光纤。

就算变来变去，还是服务器，是计算节点，是CPU。

既然是服务器，那么就势必会和IT云计算一样，走上虚拟化的道路。毕竟，虚拟化有太多的优势，例如前文所说的低成本、高利用率、充分灵活、动态调度，等等。

前几年，大家以为虚拟机是核心网的终极形态。目前看来，更有可能是容器化。这几年经常说的NFV（网元功能虚拟化），也有可能改口为NFC（网元功能容器化）。

以VoLTE为例，如果按以前2G/3G的方式，那需要大量的专用设备，分别充当EPC和IMS的不同网元。

VoLTE相关的网元

而采用容器之后，很可能只需要一台服务器，创建十几个容器，用不同的容器，来分别运行不同网元的服务程序。

这些容器，随时可以创建，也可以随时销毁。还能够在不停机的情况下，随意变大，随意变小，随意变强，随意变弱，在性能和功耗之间动态平衡。

简直完美！

5G时代，核心网采用微服务架构，也是和容器完美搭配——单体式架构（Monolithic）变成微服务架构（Microservices），相当于一个全能型变成N个专能型。每个专能型，分配给一个隔离的容器，赋予了最大程度的灵活。