Kubernetes如何为应用程序提供网络和存储？

网络组件支持pod到pod、节点到pod、pod到服务以及外部客户端到服务的通信。 Kubernetes遵循用于实现网络服务的插件模式。Kubenet是默认的网络插件，配置简单。它通常与为节点之间或单节点环境中的通信设置路由规则的云提供商一起使用。

Kubernetes可以支持基于容器网络接口(CNI)规范的许多插件，该规范定义了容器的网络连接，并在容器删除时处理网络资源。CNI有许多实现版本，包括Calico、Cilium、Contiv和Weave Net等。CNI规范还支持公共云中可用的虚拟网络，因而可以将网络拓扑和子网扩展到Kubernetes集群。

一些与CNI兼容的网络插件(比如Calico)通过隔离pod来实施策略，从而执行严格的路由策略。它们将类似防火墙的规则引入到Kubernetes集群的pod和命名空间。

Kubernetes存储

持久存储通过持久卷暴露给Kubernetes。pod通过持久卷声明来使用卷。存储管理员配置存储资源的方式是，从现有的网络连接存储(NAS)、存储区域网络(SAN)、直连存储(DAS)、固态驱动器(SSD)、非易失性内存标准(NVMe)或闪存磁盘阵列来创建持久卷。开发人员和DevOps团队通过与pod关联的持久卷声明获得大量的持久卷。

Kubernetes随带存储基元(primitive)，可以从现有节点来暴露存储。使底层存储可以被pod访问的卷类型就是这样一种基元。卷类型的例子包括emptyDir和hostPath。它们用于特定的使用场合：emptyDir用于暂存空间，hostPath使本地卷可供pod使用。但是由于与节点紧密耦合，它们没有很高的可用性和容错性。覆盖存储层将来自块设备、NAS和SAN的存储卷聚合起来，将外部存储暴露给Kubernetes对象。

为了提供高可用性和容器原生存储功能，Kubernetes推出了插件，以便存储供应商将其平台暴露给容器化工作负载。来自公共云提供商的块存储、基于NFS和GlusterFS的分布式文件系统以及几个商业存储平台在Kubernetes的上游开源发行版中含有插件。存储管理员根据性能和速度为每种类型的存储引擎创建存储类。可以从这些存储类别为不同类型的工作负载创建持久卷和声明。比如说，关系数据库管理系统(RDBMS)可以与每秒输入/输出操作(IOPS)较高的存储类别关联起来，而内容管理系统(CMS)可以通过不同的存储类别针对分布式存储引擎。

图1. Kubernetes的覆盖存储：将存储暴露给pod和容器。

与CNI相似，Kubernetes社区已通过容器存储接口(CSI)定义了存储规范，该规范鼓励采用一种标准的便携式方法来实现和使用存储服务。

为扩展而生的轻量级网络堆栈

Kubernetes源自Borg，为超大规模工作负载而设计。其现代化架构可确保基础架构资源的最佳利用。几乎无需更改配置，即可轻松将另外的worker节点添加到现有集群中。工作负载就能够立即利用新节点的CPU、内存和存储资源。

将一组相关的容器组合起来作为一个pod，并将其当作部署和扩展单元，这个想法带来更好的性能。比如说，将Web服务器和缓存容器放在同一个pod中可缩短延迟、提高性能。 pod中的容器有着同样的执行上下文，从而使它们能够使用进程间通信，这减少了开销。

属于同一ReplicaSet和部署的pod可迅速扩展。只需几秒钟即可将部署扩展到数百个pod的规模。可以根据资源能力和所需的配置状态，调度节点上的pod。如果配置Horizontal Pod Autoscaler(HPA)，Kubernetes可以自动扩展部署的规模。

在弹性基础架构环境中运行时，Kubernetes可以使用Cluster Autoscaler向集群添加节点和从集群删除节点。与HPA结合使用，该技术可以有效地管理工作负载和基础架构的动态自动扩展。

Kubernetes的轻量级网络堆栈和服务发现是为规模环境设计的。它们可以处理服务暴露的供内外使用的数万个端点。