在本地和公共云上使用相同的编排允许高度的灵活性和易操作性。您可以跨裸机和公共云使用相同的 API 。 Kubernetes 是一个开源的容器编排系统，用于自动化容器化应用程序的部署、扩展和管理。它最初是由谷歌设计的，现在由云本地计算基金会维护。
Kubernetes 正在迅速成为在混合云中部署和管理容器的新标准。作为一个网络工程师，你为什么要关心开发人员对 Kubernetes 做了什么？它不只是另一个消耗网络资源的应用程序吗？ Kubernetes 提供了一个灵活可靠的平台，使开发人员能够专注于开发和扩展他们的应用程序。
在本文中，我将讨论 Kubernetes 的基本构建块和一些网络挑战。
Kubernetes 积木
Kubernetes 是一个工具，它使您能够管理云基础设施以及管理虚拟机或网络的复杂性。
节点
节点是 Kubernetes 中计算元素的最小单位。它是集群中单个机器的表示。在大多数生产系统中，节点通常是物理服务器或托管在本地或云上的虚拟机。
集群
Kubernetes 集群是一组用于运行容器化应用程序的节点机。当您在集群上部署应用程序时，集群将智能地处理将工作分发到各个节点的工作。如果添加或删除了任何节点，集群会根据需要转移工作负载。对于应用程序或开发人员来说，哪个节点实际运行代码并不重要。
持久卷
由于不能保证在集群上运行的应用程序在特定节点上运行，因此无法将数据保存到文件系统中的任意位置。如果应用程序试图保存数据以供以后使用，但随后又重新定位到新节点上，则数据将不再位于应用程序所期望的位置。因此，与每个节点相关联的传统本地存储被视为一个临时缓存来保存应用程序，但本地保存的任何数据都不能持久。
为了永久存储数据， Kubernetes 使用持久卷。虽然所有节点的 CPU 和 RAM 资源都由集群有效地汇集和管理，但持久性文件存储不是必需的。相反，本地或云存储可以作为持久卷附加到集群。
容器和微型服务
运行在 Kubernetes 上的应用程序被打包为 Linux 容器。容器是一个被广泛接受的标准，因此已经有许多预构建的映像可以部署在 Kubernetes 上。
容器化允许创建自包含的 Linux 执行环境。任何应用程序及其所有依赖项都可以捆绑到单个文件中。容器允许形成强大的连续集成（ CI ）和连续部署（ CD ）管道，因为每个容器可以容纳应用程序的特定部分。容器是微服务的基础设施。
微服务是一种软件开发技术，一种将应用程序构造为松散耦合服务集合的体系结构风格。将应用程序分解为不同的较小服务的好处是它改进了模块化。这使得应用程序更易于理解、开发、测试和部署。
Pods
Kubernetes 不直接运行容器。相反，它将一个或多个容器包装成一个更高层次的结构，称为 Pod 。同一 Pod 中的任何容器共享同一节点和本地网络。容器可以轻松地与同一个 Pod 中的其他容器进行通信，就像它们在同一台机器上一样，同时保持与其他容器的一定程度的隔离。
豆荚是库伯内特斯的复制单位。如果您的应用程序变得太重，单个 Pod 实例无法承载负载，那么可以配置 Kubernetes ，以便根据需要将 Pod 的新副本部署到集群。即使不是在重载下，在生产系统中随时运行一个 Pod 的多个副本也是标准的，以允许负载平衡和抗故障。
部署
虽然 pod 是 Kubernetes 的基本计算单元，但它们通常不会直接在集群上启动。相反， pod 通常由另一个抽象层来管理： deployment 。部署的目的是声明一次应该运行多少个 Pod 副本。当部署被添加到集群中时，它会自动增加请求的 pod 数量，然后监视它们。如果吊舱死亡，部署会自动重新创建它。
对于部署，您不必手动处理 pod 。您只需声明所需的系统状态，系统就会自动为您进行管理。
服务和服务网格
Kubernetes 服务是一种抽象，它定义了一组逻辑 pod 和访问它们的策略。服务支持依赖吊舱之间的松散耦合。
术语 服务网 用于描述组成此类应用程序的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性的增长，它可能变得更难理解和管理。它的需求可以包括发现、负载平衡、故障恢复、度量和监视。服务 mesh 通常还有更复杂的操作需求，如 A / B 测试、 canary 发布、速率限制、访问控制和端到端身份验证。
控制服务网格最流行的插件之一是 Istio ，这是一个开源的独立服务，它提供了成功运行分布式微服务体系结构所需的基础。 Istio 提供了对整个服务网格的行为洞察力和操作控制，提供了一个完整的解决方案来满足微服务应用程序的各种需求。使用 Istio ，应用程序的所有实例都有自己的 sidecar 容器。此侧车充当所有传出和传入网络流量的服务代理。
网络
Kubernetes 网络的核心是一个重要的基本设计理念：每个 Pod 都有一个唯一的 IP 地址。
Pod 的 IP 地址由内部的所有容器共享，并且可以从其他 Pod 路由。这种 IP-per-Pod 模型的一个巨大好处是没有与底层主机的 IP 地址或端口冲突。不必担心应用程序使用什么端口。
有了这一点， Kubernetes 唯一的要求就是 Pod IP 地址是可路由的，并且可以从所有其他 Pod 访问，而不管它们的节点是什么。
为了降低复杂性并使应用程序移植无缝进行，在 Kubernetes 网络模型中，一些规则作为基本要求被强制执行：
- 容器可以在没有网络地址转换（ NAT ）的情况下与所有其他容器通信。
- 节点可以在没有 NAT 的情况下与所有容器通信，反之亦然。
- 容器将自己视为的 IP 地址与其他容器看到的 IP 地址相同。
Kubernetes 有许多网络实现。法兰绒和印花布可能是最流行的用作容器网络接口（ CNI ）的网络插件。 CNI 可以看作是容器运行时和网络实现之间最简单的接口，其目标是为容器创建一个通用的基于插件的网络解决方案。
Flannel 可以使用多个封装后端运行，建议使用 VXLAN 。在 VXLAN 中使用 Flannel 时， Kubernetes 节点之间需要 L2 连接。由于这一要求，结构 MIG 的大小将受到限制，如果部署了纯 L2 网络，则连接的机架数将限制为脊椎交换机上的端口数。
为了克服这个问题，可以在叶级部署一个具有 VXLAN 和 EVPN 的 L3 结构。 L2 连接提供给 BGP 路由结构上的节点，该结构可以轻松扩展。来自节点的 VXLAN 数据包被封装到叶交换机之间运行的 VXLAN 隧道中。
NVIDIA Spectrum ASIC 在 VXLAN 吞吐量、延迟和规模方面提供了巨大的价值。大多数交换机最多可支持 128 个远程 VTEP ，这意味着单个结构中最多可支持 128 个机架。 NVIDIA Spectrum ASIC 支持多达 750 个远程 vtep ，在单个结构中允许多达 750 个机架。
NVIDIA Spectrum EVPN VXLAN 微分器
观看以下视频，了解为什么 NVIDIA Spectrum 以太网交换机是构建可扩展、高效和高性能 EVPN VXLAN 结构的最佳平台。
印花布作为设计选项
在印花布网络中，每个端点都是一条路由。硬件网络平台受到他们可以学习的路由数量的限制。这通常在 10000 或 100000 条路线的范围内。路由聚合可以有所帮助，但这通常取决于编排软件（例如 OpenStack ）使用的调度器的功能。
为 Kubernetes 部署选择交换机时，请确保它的路由表大小不会限制 Kubernetes 的计算规模。 NVIDIA Spectrum ASIC 提供了完全灵活的表大小， Spectrum 1 支持多达 176000 个 IP 路由条目， Spectrum 2 支持多达 512000 个 IP 路由条目，支持全球最大企业运行的最大 Kubernetes 集群。
跨物理网络和 Kubernetes 的路由栈持久性
在交换层上使用 Cumulus Linux 操作系统时，我们建议使用 FRR 作为节点上的路由栈，利用 BGP 未编号 。如果你正在寻找一个纯开源的解决方案，考虑一下 NVIDIA Linux 交换机 ，它支持 FRR 和 BEAR 作为路由栈。
Kubernetes 的网络可见性挑战
容器会根据需要在群集中的任何服务器上自动启动和销毁。因为容器位于主机内部，所以网络工程师可能看不到它们。你永远不知道它们在哪里，也不知道它们何时被创造和毁灭。
众所周知，运营现代敏捷数据中心非常困难，因为网络可见性有限，流量模式不断变化。
通过在运行 Cumulus 操作系统的 NVIDIA Spectrum 交换机上使用 Cumulus NetQ ，您可以广泛了解 Kubernetes 部署，并在这些快速变化的动态环境中运行。
