Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。伴随着云原生技术的迅速崛起，如今Kubernetes 事实上已经成为应用容器化平台的标准，越来越受到企业的青睐，在生产中也应用的也越来越广泛。
我们的容器平台建设从2016年开始，大致经历了探索预研、体系建设和平台落地这样三个阶段。
下面就从Kubernetes的网络、存储、集群管理和监控与运维几个方面来分享下我们容器云平台建设走过的历程，希望给大家一些思考和启发。
一、 kubernetes网络
容器网络发展到现在，已经是双雄会的格局。双雄会其实指的就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点，CNM和CNI并不是网络实现，他们是网络规范和网络体系，从研发的角度他们就是一堆接口，你底层是用Flannel也好、用Calico也好，他们并不关心，CNM和CNI关心的是网络管理的问题。
网络需求调研发现，业务部门主要关注以下几点：1、容器网络与物理网络打通2、速度越快越好3、改动越少越好4、尽可能少的风险点。
容器的网络方案大体可分为协议栈层级、穿越形态、隔离方式这三种形式
协议栈层级：二层比较好理解，在以前传统的机房或虚拟化场景中比较常见，就是基于桥接的 ARP+MAC 学习，它最大的缺陷是广播。因为二层的广播，会限制节点的量级；三层（纯路由转发），协议栈三层一般基于 BGP，自主学习整个机房的路由状态。它最大的优点是它的 IP 穿透性，也就是说只要是基于这个 IP 的网络，那此网络就可以去穿越。显而易见，它的规模是非常有优势，且具有良好的量级扩展性。但在实际部署过程中，因为企业的网络大多受控。比如，有的企业网络的 BGP 是基于安全考虑不给开发者用或者说企业网络本身不是 BGP，那这种情况下你就受限了；协议栈二层加三层，它的优点是能够解决纯二层的规模性扩展问题，又能解决纯三层的各种限制问题，特别是在云化 VPC 场景下，可以利用 VPC 的跨节点三层转发能力。
穿越形态：
这个与实际部署环境十分相关。穿越形态分为两种：Underlay、Overlay。
Underlay：在一个较好的可控的网络场景下，我们一般利用 Underlay。可以这样通俗的理解，无论下面是裸机还是虚拟机，只要整个网络可控，容器的网络便可直接穿过去 ，这就是 Underlay。
Overlay：Overlay 在云化场景比较常见。Overlay 下面是受控的 VPC 网络，当出现不属于 VPC 管辖范围中的 IP 或者 MAC，VPC 将不允许此 IP/MAC 穿越。出现这种情况时，我们可利用 Overlay 方式来做。
Overlay网络使物理网络虚拟化、资源池化，是实现云网融合的关键。把Overlay网络和SDN技术结合使用，把SDN控制器作为Overlay网络控制平面的控制器，这种方式更容易使网络与计算组件整合，是网络向云平台服务转变的理想选择。
隔离方式：
隔离方式通常分为VLAN和VXLAN 两种：
VLAN：VLAN 机房中使用偏多，但实际上存在一个问题。就是它总的租户数量受限。众所周知，VLAN 具有数量限制。
VXLAN：VXLAN 是现今较为主流的一种隔离方式。因为它的规模性较好较大，且它基于 IP 穿越方式较好。
我们从协议层级、穿越形态和隔离方式对kubernetes几个常见的网络组件（calico、contiv、flannel、Openshift SDN、自定义路由）在传统机房网络以及云化VPC网络应用场景下做一个分析，用连线图来表述它们之前的关系。
首先无论是传统机房网络还是云化 VPC 网络，我们可以看到 Overlay 方案是通用的，它在云化场景里可能用的更多一些，因为它有很好的穿越性。
在上图中，红线实线指向传统机房网络，这里重点说明下。Underlay + 三层的方案，是传统机房网络非常流行的方案，同时它的性能非常可观，场景应用比较偏多。
绿色虚线指向云化VPC网络， Underlay+三层网络在云化 VPC 场景下，也是可以受限使用。受限使用顾名思义，可以使用但不是每个供应商都让你用，因为每一个云厂商对他自己网络保护的定义不一样。比如像 Calico 方案，它的 BGP 在 AWS 中就容易做，但在 Azure 中就不允许，因为 Azure 的 VPC 本身是不允许不受它管控范围的 IP 通过。
