威力增强版-OpenShift4的SDN :让我们重新认识OpenShift系列3

引入OpenShift软件定义的网络

OpenShift实施软件定义的网络（SDN）来管理集群和用户应用程序的网络基础结构。软件定义的网络是一种网络模型，允许您通过抽象几个网络层来管理网络服务。它使处理流量的软件（称为控制平面）与路由流量的基础机制（称为数据平面）分离。在SDN的众多功能中，开放标准使供应商能够提出其解决方案，集中式管理，动态路由和租户隔离。

在OpenShift容器平台中，SDN解决了以下五个要求：

以编程方式管理网络流量和网络资源，以便组织团队可以决定如何公开其应用程序。
管理在同一项目中运行的容器之间的通信。
管理Pod之间的通信，无论它们属于同一个项目还是在单独的项目中运行。
管理从Pod到服务的网络通信。
管理从外部网络到服务或从容器到外部网络的网络通信。
SDN实现创建了一个向后兼容的模型，该模型的Pod在端口分配，IP地址租赁和预留方面类似于虚拟机。

讨论OpenShift网络模型

OpenShift SDN使用Linux名称空间对物理主机和虚拟主机上资源和进程的使用进行分区。此实现允许Pod内的容器共享网络资源，例如设备，IP堆栈，防火墙规则以及路由表。OpenShift SDN为每个Pod分配唯一的可路由IP，以便您可以从同一网络中的任何其他服务访问Pod。

迁移旧版应用程序

SDN设计使您可以轻松地将旧版应用程序进行容器化，因为您无需更改应用程序组件之间相互通信的方式。如果您的应用程序由许多通过TCP / UDP堆栈进行通信的服务组成，则此方法仍然可以使用，因为Pod中的容器共享同一网络堆栈。尽管推荐使用OpenShift服务，但是在考虑迁移OpenShift中的所有服务之前，您可以无缝迁移这些服务。

下图显示了所有Pod如何连接到共享网络。

使用服务访问Pod

Kubernetes提供了服务的概念，这是任何OpenShift应用程序中必不可少的资源。服务允许在公共访问路由下对Pod进行逻辑分组。服务充当一个或多个Pod前面的负载平衡器，从而使应用程序规范（例如，运行副本的数量）与对所述应用程序的访问脱钩。它在成员Pod之间平衡客户端请求的负载，并提供一个稳定的接口，使与Pod的通信无需跟踪单个Pod IP地址即可。

大多数现实世界中的应用程序都不是作为单个Pod运行的。他们需要水平扩展，因此应用程序可以在许多Pod上运行，以满足不断增长的用户需求。在OpenShift集群中，会在集群中的各个节点之间不断创建和销毁Pod，例如在部署新应用程序版本期间或在耗尽节点进行维护时。每次创建Pod时，都会为其分配一个不同的IP地址；因此，吊舱不容易寻址。您可以使用服务来提供其他单一Pod唯一的唯一IP地址，而与Pod的运行位置无关，而不必让Pod查找另一个Pod的IP地址。

服务依赖于选择器（标签），这些选择器指示哪些吊舱通过服务接收流量。与这些选择器匹配的每个Pod将作为端点添加到服务资源。创建和终止Pod后，该服务会自动更新端点。

使用选择器为设计应用程序的体系结构和路由提供了灵活性。例如，您可以将应用程序划分为多个层，并决定为每个层创建服务。选择器使设计具有灵活性和高弹性。

OpenShift使用两个子网：一个用于Pod的子网，一个用于服务的子网。流量以透明方式转发到Pod；代理（取决于您使用的网络模式）管理路由规则，以将流量路由到与选择器匹配的Pod。

下图显示了三个API容器如何在单独的节点上运行。service1服务能够平衡这三个Pod之间的负载。

以下YAML定义显示了如何创建服务。这定义了应用程序前端服务，该服务创建了一个虚拟IP，该虚拟IP暴露了TCP端口443。前端应用程序侦听非特权端口8843。

kind: Service

apiVersion: v1

metadata:

name: application-frontend 1

labels:

app: frontend-svc 2

spec:

ports: 3

- name: HTTP

protocol: TCP

port: 443 4

targetPort: 8443 5

selector: 6

app: shopping-cart

name: frontend

定义服务类型

OpenShift支持许多服务类型以适应各种用例。以下列表列出了可用的服务类型。

群集IP（ClusterIP）：此服务类型使用群集内部的IP公开服务。因此，无法从外部网络访问此IP。定义服务时，这是默认值。作为管理员，您可以在安装时为这些IP配置CIDR。

节点端口（NodePort）：此服务类型指示OpenShift控制平面映射到群集中的节点使用的IP地址。这是一种旧类型，Red Hat建议改用路由，该路由将服务公开为主机名。下一节将讨论路线。

使用此服务类型时，每个节点在服务的每个节点上代理相同的端口号。

默认情况下，节点端口的范围是30000-32767，这意味着节点端口不太可能与服务的预期端口匹配。

负载平衡器（LoadBalancer）：此服务类型通过云提供程序负载平衡器公开服务。您访问提供商的负载平衡器的虚拟IP，OpenShift控制平面会自动创建节点端口或群集IP来路由传入的数据包。

外部名称（ExternalName）：此服务类型在DNS区域中创建一个与外部主机名匹配的CNAME。通常，您可以使用此服务类型为群集外部的应用程序创建不同的访问点。该服务返回其值与外部名称匹配的CNAME记录。

各种服务类型使您可以控制如何访问服务。某些服务类型可能更适合您的环境，例如在Amazon Web Services（AWS），Microsoft Azure或Google Compute Engine（GCE）中部署时的LoadBalancer类型。使用这种服务类型，OpenShift将流量从外部负载平衡器重定向到后端Pod，但是，提供程序确定负载平衡机制和策略。这可能会增加与群集相关的管理开销，因为您还必须管理开发人员创建或删除其服务的权限。

TheNodePorttype是一种较旧的基于Kubernetes的方法，其中，控制计划通过绑定到节点主机上的可用端口，将服务公开给外部客户端。然后，该节点代理与服务IP地址的连接。然后，您通过节点主机和端口值访问应用程序。使用此服务类型时，必须手动维护用于避免端口冲突的端口列表。此外，您必须使用有效的端口号，即，该端口在范围内并且已针对NodePortservice类型配置。

TheExternalName服务类型是最近添加的。使用此服务类型的服务不会映射到选择器。而是使用DNS名称来确定如何访问与主机名匹配的应用程序。控制平面创建一个CNAME记录，其值对应于外部名称。这是将旧版应用程序迁移到集群的便捷解决方案，因为您可以在集群外部运行应用程序的某些部分，直到迁移完成为止。

讨论DNS Operator

DNSOperator部署并运行由CoreDNS管理的DNS服务器，CoreDNS是用GoLang编写的轻量级DNS服务器。DNS operator提供Pod之间的DNS名称解析，这使服务能够发现其端点。

每次创建新应用程序时，OpenShift都会配置Pod，以便它们联系CoreDNS服务IP进行DNS解析。

运行以下命令以检查DNS Operator的配置。

[user@demo ~]$oc describe dns.operator/default
Name:         default
...output omitted...
API Version:  operator.openshift.io/v1
Kind:         DNS
...output omitted...
Spec:
Status:
  Cluster Domain:  cluster.local
Cluster IP:      172.30.0.10...output omitted...

DNS operator负责以下工作：

创建默认的群集DNS名称（cluster.local）。
为名称空间分配DNS名称（例如，backend.cluster.local）。
为您定义的服务分配DNS名称（例如，db.backend.cluster.local）。
将DNS名称分配给名称空间中的Pod（例如db001.backend.cluster.local）。

为Services管理DNS记录

此DNS实现使Pod可以无缝解析项目或群集中资源的DNS名称。Pod可以使用可预测的命名方案来访问服务。例如，从容器查询db.backend.cluster.local将返回服务的IP地址。在这种情况下，db是服务的名称，backend是项目名称，cluster.local是群集DNS名称。

CoreDNS为服务创建两种记录：解析为服务的一个记录和与以下格式匹配的SRV记录：

_port-name._port-protocol.svc.namespace.svc.cluster.local

例如，如果您使用通过HTTPS服务公开TCP端口443的服务，则如下创建SRV记录：

_443._tcp.https.frontend.svc.cluster.local

当服务没有Cluster P时，DNS operator会为它们分配一个DNS record，该DNS record会解析为服务背后的Pod的IP地址。

同样，创建的SRV记录解析为服务后面的所有Pod。

Cluster Network Operator

OpenShift容器平台使用群集网络operator来管理SDN。这包括要使用的网络CIDR，网络模式，网络提供程序和IP地址池。

以管理用户身份运行followingoc get命令以查询SDN配置，该配置由Network.config.openshift.io自定义资源定义管理。

oc get Network.config.openshift.io cluster -oyaml

apiVersion: config.openshift.io/v1

kind: Network

...output omitted...

spec:

clusterNetwork:

- cidr: 10.128.0.0/14 1

hostPrefix: 23 2

externalIP:

policy: {}

networkType: OpenshiftSDN 3

serviceNetwork:

- 172.30.0.0/16

...output omitted...

1：为群集中的所有Pod定义CIDR。在此示例中，SDN的网络掩码为255.252.0.0，可以分配262144个IP地址。

2：定义主机前缀。值23表示网络掩码为255.255.254.0，可转换为512个可分配IP。

3：显示当前的SDN提供程序。您可以在OpenShiftSDN，OVNKubernetes和Kuryr之间进行选择。红帽仅支持OpenShiftSDN网络提供商。

引入OpenShift网络模式

OpenShift软件定义的网络（SDN）提供了群集中的Pod用于通信的网络层。为了建立该网络层，OpenShift SDN使用一个插件模型，该模型允许您为用例选择适当的技术。

在OpenShift容器平台4中，OpenShif SDN API资源定义和管理SDN模式。配置要在install-config.yaml安装文件的defaultNetwork部分中使用的模式。

OpenShift支持三种模式：多租户，子网和网络策略；默认模式是NetworkPolicy。

以下摘录显示了SDN模式配置：

defaultNetwork:
  type: OpenShiftSDN
  openshiftSDNConfig:
    mode: NetworkPolicy
    mtu: 1450
    vxlanPort: 4789

该配置指示安装程序使用NetworkPolicy模式，并定义MTU覆盖和VXLAN UDP端口的值以创建隧道。调整MTU值以防止数据包分片，这通常是在将以太网帧封装到另一个帧中时发生的，例如用于覆盖网络。

比较和对比网络模式

子网模式允许您创建一个扁平网络，其中所有Pod可以在项目和租户之间相互通信。

Mutitenant模式在项目级别实现隔离，这为Pod和服务提供了额外的隔离层。使用此模式时，每个项目都会收到一个唯一的VLAN ID，该ID标识来自属于该项目的Pod的流量。Pod只能访问其网络数据包标签使用相同VNID的Pod。Pod无法与其他项目中的Pod和服务进行通信。

VNID为0的项目可以与所有其他Pod通信，反之亦然。这对于您在默认项目中创建的所有Pod都是正确的，默认项目将VNID分配给Pod。

NetworkPolicy模式允许您定义Pod的网络策略，从而提供了额外的灵活性。默认情况下，在没有定义任何网络策略资源的情况下，项目中的容器可以访问任何其他容器。

要隔离项目中的一个或多个Pod，请在该项目中定义一个NetworkPolicy资源，以指示允许的入口和出口连接。

以下摘录显示了如何允许外部用户访问带有标签matchapp的应用程序：product-catalog通过端口8080上的TCP连接。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: external-access
spec:
  podSelector:
    matchLabels:
      app: product-catalog
  ingress:
  - ports:
    - protocol: TCP
      port: 8080

使用网络策略的一个好处是管理项目（租户）之间的安全，而VLAN等第二层技术则无法做到这一点。网络策略允许您在项目之间创建量身定制的策略，以确保应用程序和用户只能访问他们应有的权限。

引入Multus容器网络接口（CNI）

随着容器采用率的提高，管理应用程序之间流量的需求也随之增加。这意味着要有基于策略，性能和安全性来隔离流量的方法。

隔离和管理此业务流的一种方法是使用网络功能虚拟化软件（NFV）。NFV允许您控制和管理数据平面和控制平面上的流量。出于性能和安全原因，使用NFVS可让您使用各种协议。

Multus是一个开源项目，支持Kubernetes中的多个网卡。解决的挑战之一是将NFV和网络功能虚拟化迁移到容器。Multus是一个容器网络接口（CNI），充当其他CNI插件的代理和仲裁器，用于管理容器中补充网络设备的实现和生命周期。Multus支持SR-IOV，vHost CNI，Flannel和Calico等插件。

下图显示了如何设计两个单独的工作负载：基于内核的工作负载（SR-IOV）和基于DPDK的工作负载。有了这些工作负载，控制平面网络（OpenShift）即可管理Pod，每个Pod通过第二个网络设备连接到额外的数据平面。

功能的这种分离提高了基于DPDK的工作负载的性能，因为它不再依赖SR-IOV性能。

更多相关文章

随机推荐