第 18 章 AWS Local Zone 任务

在 Amazon Web Services (AWS)上安装 OpenShift Container Platform 后，您可以进一步配置 AWS Local Zones 和边缘计算池，以便您可以扩展并自定义集群来满足您的需要。

18.1. 将现有集群扩展为使用 AWS Local Zones

作为安装后任务，您可以扩展 Amazon Web Services (AWS)上的现有 OpenShift Container Platform 集群，以使用 AWS Local Zones。

将节点扩展到 Local Zone 位置包括以下步骤：

调整 cluster-network 最大传输单元(MTU)
在 Local Zone 组中选择 AWS Local Zones
在现有 VPC 中为 Local Zone 位置创建子网
创建机器集清单，然后在每个 Local Zone 位置创建节点

重要

在扩展 AWS 上的现有 OpenShift Container Platform 集群前，请检查现有的 VPC 是否包含可用的 Classless Inter-Domain Routing (CIDR) 块。创建子网需要这些块。

其他资源

如需有关 AWS Local Zones、支持的实例类型和服务的更多信息，请参阅 AWS 文档中的 AWS Local Zones 功能。

18.1.1. Edge 计算池和 AWS 本地区域

边缘 worker 节点是在 AWS Local Zones 位置中运行的污点 worker 节点。

在部署使用 Local Zones 的集群时，请考虑以下点：

本地区域中的 Amazon EC2 实例比可用区中的 Amazon EC2 实例的成本更高。
应用程序和最终用户之间的延迟较低在本地区域中，延迟可能会因位置而异。例如，在 Local Zones 和 Availability Zones 混合了入口流量时，一些工作负载会有一个延迟影响。

重要

通常，本地区中的 Amazon EC2 实例和 Region 中的 Amazon EC2 实例之间的最大传输单元 (MTU) 为 1300。如需更多信息，请参阅 AWS 文档中的 Local Zones 如何工作。对于开销，集群网络 MTU 必须总是小于 EC2 MTU。具体开销由您的网络插件决定，例如：

OVN-Kubernetes: 100 字节
OpenShift SDN: 50 字节

网络插件可以提供额外的功能，如 IPsec，它们还必须减少 MTU。如需更多信息，请参阅文档。

OpenShift Container Platform 4.12 引入了一个新的计算池 edge，用于在远程区中使用。边缘计算池配置在 AWS Local Zones 位置之间很常见。由于 Local Zone 资源上的 EC2 和 EBS 等资源的类型和大小限制，默认的实例类型可能与传统的 worker 池不同。

Local Zone 位置的默认 Elastic Block Store (EBS) 是 gp2，它与常规 worker 池不同。根据区上的实例产品，边缘计算池中的每个 Local Zone 使用的实例类型可能与 worker 池不同。

边缘计算池创建新的标签，供开发人员用来将应用程序部署到 AWS Local Zones 节点上。新标签包括：

node-role.kubernetes.io/edge=''
machine.openshift.io/zone-type=local-zone
machine.openshift.io/zone-group=$ZONE_GROUP_NAME

默认情况下，边缘计算池的机器集定义 NoSchedule 污点，以防止常规工作负载分散到 Local Zone 实例中。只有用户在 pod 规格中定义容限时，用户才能运行用户工作负载。

18.1.2. 更改集群网络 MTU 以支持 AWS 本地区域子网

您可能需要更改集群网络的最大传输单元(MTU)值，以便集群基础架构可以支持 Local Zone 子网。

18.1.2.1. 关于集群 MTU

在安装集群网络的最大传输单元(MTU)期间，会根据集群中节点的主网络接口的 MTU 自动检测到。您通常不需要覆盖检测到的 MTU。

您可能希望因为以下原因更改集群网络的 MTU：

集群安装过程中检测到的 MTU 不正确。
集群基础架构现在需要不同的 MTU，如添加需要不同 MTU 的节点来获得最佳性能

您只能为 OVN-Kubernetes 和 OpenShift SDN 集群网络插件更改集群 MTU。

18.1.2.1.1. 服务中断注意事项

当您为集群启动 MTU 更改时，以下效果可能会影响服务可用性：

至少需要两个滚动重启才能完成迁移到新的 MTU。在此过程中，一些节点在重启时不可用。
部署到集群的特定应用程序带有较短的超时间隔，超过绝对 TCP 超时间隔可能会在 MTU 更改过程中造成中断。

18.1.2.1.2. MTU 值选择

在规划 MTU 迁移时，需要考虑两个相关但不同的 MTU 值。

Hardware MTU ：此 MTU 值根据您的网络基础架构的具体设置。
Cluster network MTU ：此 MTU 值始终小于您的硬件 MTU，以考虑集群网络覆盖开销。具体开销由您的网络插件决定：
- OVN-Kubernetes:100 字节
- OpenShift SDN: 50 字节

如果您的集群为不同的节点需要不同的 MTU 值，则必须从集群中任何节点使用的最低 MTU 值中减去网络插件的开销值。例如，如果集群中的某些节点的 MTU 为 9001，而某些节点的 MTU 为 1500，则必须将此值设置为 1400。

重要

为了避免选择节点无法接受的 MTU 值，请使用 ip -d link 命令验证网络接口接受的最大 MTU 值 (maxmtu)。

18.1.2.1.3. 迁移过程如何工作

下表对迁移过程进行了概述，它分为操作中的用户发起的步骤，以及在响应过程中迁移过程要执行的操作。

表 18.1. 集群 MTU 的实时迁移
用户发起的步骤	OpenShift Container Platform 活动
在 Cluster Network Operator 配置中设置以下值： `spec.migration.mtu.machine.to` `spec.migration.mtu.network.from` `spec.migration.mtu.network.to`	Cluster Network Operator(CNO) ：确认每个字段都设置为有效的值。如果硬件的 MTU 没有改变，则 `mtu.machine.to` 必须设置为新硬件 MTU 或当前的硬件 MTU。这个值是临时的，被用作迁移过程的一部分。如果您指定了与现有硬件 MTU 值不同的硬件 MTU，您必须手动将 MTU 配置为持久，如机器配置、DHCP 设置或 Linux 内核命令行。 `mtu.network.from` 字段必须等于 `network.status.clusterNetworkMTU` 字段，这是集群网络的当前 MTU。 `mtu.network.to` 字段必须设置为目标集群网络 MTU，且必须小于硬件 MTU，以允许网络插件的覆盖开销。对于 OVN-Kubernetes，开销为 `100` 字节，OpenShift SDN 的开销为 `50` 字节。如果提供的值有效，CNO 会生成一个新的临时配置，它将集群网络集的 MTU 设置为 `mtu.network.to` 字段的值。 Machine Config Operator(MCO) ：执行集群中每个节点的滚动重启。
重新配置集群中节点的主网络接口 MTU。您可以使用各种方法完成此操作，包括：使用 MTU 更改部署新的 NetworkManager 连接配置集通过 DHCP 服务器设置更改 MTU 通过引导参数更改 MTU	N/A
在网络插件的 CNO 配置中设置 `mtu` 值，并将 `spec.migration` 设置为 `null`。	Machine Config Operator(MCO) ：使用新的 MTU 配置执行集群中每个节点的滚动重启。

18.1.2.2. 更改集群 MTU

作为集群管理员，您可以更改集群的最大传输单元(MTU)。当 MTU 更新推出时，集群中的迁移具有破坏性且节点可能会临时不可用。

先决条件

已安装 OpenShift CLI（oc）。
使用具有 cluster-admin 权限的用户登陆到集群。
已为集群识别目标 MTU。正确的 MTU 因集群使用的网络插件而异：
- OVN-Kubernetes: 集群 MTU 必须设置为比集群中的最低硬件 MTU 值小 100。
- OpenShift SDN ：集群 MTU 必须设置为比集群中的最低硬件 MTU 值小 50。

流程

要增加或减少集群网络的 MTU，请完成以下步骤。

要获得集群网络的当前 MTU，请输入以下命令：

$ oc describe network.config cluster

输出示例

...
Status:
  Cluster Network:
    Cidr:               10.217.0.0/22
    Host Prefix:        23
  Cluster Network MTU:  1400
  Network Type:         OpenShiftSDN
  Service Network:
    10.217.4.0/23
...

要开始 MTU 迁移，请输入以下命令指定迁移配置。Machine Config Operator 在集群中执行节点的滚动重启，以准备 MTU 更改。
```
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": <overlay_from>, "to": <overlay_to> } , "machine": { "to" : <machine_to> } } } } }'
```
其中：
<overlay_from>
指定当前的集群网络 MTU 值。
<overlay_to>
指定集群网络的目标 MTU。这个值相对于 <machine_to>，对于 OVN-Kubernetes，值必须小 100，OpenShift SDN 必须小 50。
<machine_to>
指定底层主机网络上的主网络接口的 MTU。
增加集群 MTU 的示例
```
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
  '{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 9000 } , "machine": { "to" : 9100} } } } }'
```
当 MCO 更新每个机器配置池中的机器时，它会逐一重启每个节点。您必须等到所有节点都已更新。输入以下命令检查机器配置池状态：
```
$ oc get mcp
```
成功更新的节点具有以下状态： UPDATED=true、UPDATING=false、DEGRADED=false。
注意
默认情况下，MCO 会一次在一个池中更新一个机器，从而导致迁移总时间随着集群大小的增加而增加。
确认主机上新机器配置的状态：
1. 要列出机器配置状态和应用的机器配置名称，请输入以下命令：
```
$ oc describe node | egrep "hostname|machineconfig"
```
  输出示例
```
kubernetes.io/hostname=master-0
machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
machineconfiguration.openshift.io/reason:
machineconfiguration.openshift.io/state: Done
```
  验证以下语句是否正确：
  - machineconfiguration.openshift.io/state 字段的值为 Done。
  - machineconfiguration.openshift.io/currentConfig 字段的值等于 machineconfiguration.openshift.io/desiredConfig 字段的值。
2. 要确认机器配置正确，请输入以下命令：
```
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
```
  这里的 <config_name> 是 machineconfiguration.openshift.io/currentConfig 字段中机器配置的名称。
  机器配置必须包括以下对 systemd 配置的更新：
```
ExecStart=/usr/local/bin/mtu-migration.sh
```