$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructures.config.openshift.io cluster
在OpenShift Container Platform 4.14版本中,您可以安装一个在Amazon Web Services (AWS)上的集群,其计算节点在AWS Outposts上运行,作为技术预览版。从OpenShift Container Platform 4.15版本开始,这种安装方法不再受支持。您可以改为将集群安装到AWS现有的VPC中,并在安装后配置任务中在AWS Outposts上配置计算节点。
在将集群安装到Amazon Web Services (AWS)现有的Amazon Virtual Private Cloud (VPC)中之后,您可以创建一个计算机会集,该集合部署AWS Outposts中的计算机会。AWS Outposts是一项AWS边缘计算服务,它允许您在本地环境的延迟降低的情况下使用基于云的AWS部署的许多功能。有关更多信息,请参阅AWS Outposts文档。
如果您将OpenShift Container Platform集群配置为满足以下要求和限制,则可以像管理基于云的AWS集群上的资源一样管理AWS Outpost上的资源。
要将AWS上的OpenShift Container Platform集群扩展到Outpost,您必须已将集群安装到现有的Amazon Virtual Private Cloud (VPC)中。
Outpost的基础设施与AWS区域中的可用区相关联,并使用专用子网。部署到Outpost的边缘计算机会必须使用Outpost子网和Outpost关联的可用区。
当AWS Kubernetes云控制器管理器发现Outpost子网时,它会尝试在Outpost子网中创建服务负载均衡器。AWS Outposts不支持运行服务负载均衡器。为了防止云控制器管理器在Outpost子网中创建不受支持的服务,您必须在Outpost子网配置中包含kubernetes.io/cluster/unmanaged
标签。此要求是OpenShift Container Platform 4.17版本中的一个解决方法。有关更多信息,请参阅OCPBUGS-30041。
AWS上的OpenShift Container Platform集群包括gp3-csi
和gp2-csi
存储类。这些类对应于Amazon Elastic Block Store (EBS) gp3和gp2卷。OpenShift Container Platform集群默认使用gp3-csi
存储类,但AWS Outposts不支持EBS gp3卷。
此实现使用node-role.kubernetes.io/outposts
污点来防止将常规集群工作负载传播到Outpost节点。要在Outpost中调度用户工作负载,您必须在应用程序的Deployment
资源中指定相应的容忍度。为用户工作负载保留AWS Outpost基础设施可以避免额外的配置要求,例如将默认CSI更新为gp2-csi
以使其兼容。
要在Outpost中创建卷,CSI驱动程序需要Outpost Amazon资源名称(ARN)。驱动程序使用存储在CSINode
对象上的拓扑密钥来确定Outpost ARN。为确保驱动程序使用正确的拓扑值,您必须将卷绑定模式设置为WaitForConsumer
,并避免在您创建的任何新的存储类上设置允许的拓扑。
将AWS VPC集群扩展到Outpost时,您将拥有两种类型的计算资源。Outpost具有边缘计算节点,而VPC具有基于云的计算节点。基于云的AWS Elastic Block卷无法连接到Outpost边缘计算节点,而Outpost卷无法连接到基于云的计算节点。
因此,您无法使用CSI快照将使用持久性存储的应用程序从基于云的计算节点迁移到边缘计算节点,也无法直接使用原始持久性卷。要迁移应用程序的持久性存储数据,您必须执行手动备份和恢复操作。
AWS Outposts不支持AWS网络负载均衡器或AWS经典负载均衡器。您必须使用AWS Application Load Balancers来启用AWS Outposts环境中边缘计算资源的负载均衡。
要配置Application Load Balancer,您必须使用Ingress资源并安装AWS负载均衡器操作符。如果您的集群同时包含共享工作负载的边缘和基于云的计算实例,则需要额外的配置。
更多信息,请参见“在扩展到 Outpost 的 AWS VPC 集群中使用 AWS Load Balancer Operator”。
要将 AWS VPC 集群扩展到您的 Outpost,您必须提供有关您的 OpenShift Container Platform 集群和 Outpost 环境的信息。您使用此信息来完成网络配置任务并配置一个计算机器集,该机器集在您的 Outpost 中创建计算机器。您可以使用命令行工具收集所需详细信息。
您可以使用 OpenShift CLI (oc
) 从您的 OpenShift Container Platform 集群获取信息。
您可能会发现使用 |
您已将 OpenShift Container Platform 集群安装到 AWS 上的自定义 VPC 中。
您可以使用具有cluster-admin
权限的帐户访问集群。
您已安装 OpenShift CLI (oc
)。
通过运行以下命令列出集群的基础设施 ID。保留此值。
$ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructures.config.openshift.io cluster
通过运行以下命令,获取安装程序创建的计算机器集的详细信息
列出集群上的计算机器集
$ oc get machinesets.machine.openshift.io -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE
<compute_machine_set_name_1> 1 1 1 1 55m
<compute_machine_set_name_2> 1 1 1 1 55m
显示列出的计算机器集之一的 Amazon 机器镜像 (AMI) ID。保留此值。
$ oc get machinesets.machine.openshift.io <compute_machine_set_name_1> \
-n openshift-machine-api \
-o jsonpath='{.spec.template.spec.providerSpec.value.ami.id}'
显示 AWS VPC 集群的子网 ID。保留此值。
$ oc get machinesets.machine.openshift.io <compute_machine_set_name_1> \
-n openshift-machine-api \
-o jsonpath='{.spec.template.spec.providerSpec.value.subnet.id}'
您可以使用 AWS CLI (aws
) 从您的 AWS 账户获取信息。
您可能会发现使用 |
您拥有一个已完成所需硬件设置的 AWS Outposts 站点。
您的 Outpost 已连接到您的 AWS 账户。
您可以使用 AWS CLI (aws
) 作为具有执行所需任务的权限的用户来访问您的 AWS 账户。
通过运行以下命令列出连接到您的 AWS 账户的 Outposts
$ aws outposts list-outposts
保留aws outposts list-outposts
命令输出中的以下值
Outpost ID。
Outpost 的 Amazon 资源名称 (ARN)。
Outpost 可用区。
|
使用 Outpost ID 的值,通过运行以下命令显示 Outpost 中可用的实例类型。保留可用实例类型的值。
$ aws outposts get-outpost-instance-types \
--outpost-id <outpost_id_value>
使用 Outpost ARN 的值,通过运行以下命令显示 Outpost 的子网 ID。保留此值。
$ aws ec2 describe-subnets \
--filters Name=outpost-arn,Values=<outpost_arn_value>
要将您的 VPC 集群扩展到 Outpost,您必须完成以下网络配置任务
更改集群网络 MTU。
在您的 Outpost 中创建子网。
在安装过程中,集群网络的最大传输单元 (MTU) 将根据集群中节点的主网络接口的 MTU 自动检测。您可能需要减小集群网络的 MTU 值以支持 AWS Outposts 子网。
迁移是有破坏性的,并且随着 MTU 更新生效,集群中的节点可能会暂时不可用。 |
有关迁移过程的更多详细信息(包括重要的服务中断注意事项),请参阅此过程附加资源中的“更改集群网络的 MTU”。
您已安装 OpenShift CLI (oc
)。
您可以使用具有cluster-admin
权限的帐户访问集群。
您已确定集群的目标 MTU。OVN-Kubernetes 网络插件的 MTU 必须设置为集群中最低硬件 MTU 值的100
。
要获取集群网络的当前 MTU,请输入以下命令
$ oc describe network.config cluster
...
Status:
Cluster Network:
Cidr: 10.217.0.0/22
Host Prefix: 23
Cluster Network MTU: 1400
Network Type: OVNKubernetes
Service Network:
10.217.4.0/23
...
要开始 MTU 迁移,请通过输入以下命令指定迁移配置。机器配置操作员会对集群中的节点进行滚动重启,以准备进行 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,此值必须比<machine_to>
的值小100
。
<machine_to>
指定底层主机网络上主网络接口的 MTU。
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
'{"spec": { "migration": { "mtu": { "network": { "from": 1400, "to": 1000 } , "machine": { "to" : 1100} } } } }'
随着机器配置操作员更新每个机器配置池中的机器,它会逐个重启每个节点。您必须等到所有节点都更新完毕。通过输入以下命令检查机器配置池状态
$ oc get machineconfigpools
成功更新的节点具有以下状态:UPDATED=true
,UPDATING=false
,DEGRADED=false
。
默认情况下,机器配置操作员一次更新每个池中的一台机器,导致迁移所需的时间随着集群大小的增加而增加。 |
确认主机上新机器配置的状态
要列出机器配置状态和应用的机器配置的名称,请输入以下命令
$ 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
字段的值。
要确认机器配置是否正确,请输入以下命令
$ oc get machineconfig <config_name> -o yaml | grep ExecStart
其中<config_name>
是machineconfiguration.openshift.io/currentConfig
字段中机器配置的名称。
机器配置必须包含以下对 systemd 配置的更新
ExecStart=/usr/local/bin/mtu-migration.sh
要完成 MTU 迁移,请为 OVN-Kubernetes 网络插件输入以下命令
$ oc patch Network.operator.openshift.io cluster --type=merge --patch \
'{"spec": { "migration": null, "defaultNetwork":{ "ovnKubernetesConfig": { "mtu": <mtu> }}}}'
其中
<mtu>
指定您使用<overlay_to>
指定的新的集群网络 MTU。
完成 MTU 迁移后,每个机器配置池节点都会逐个重启。您必须等到所有节点都更新完毕。通过输入以下命令检查机器配置池状态
$ oc get machineconfigpools
成功更新的节点具有以下状态:UPDATED=true
,UPDATING=false
,DEGRADED=false
。
通过输入以下命令验证集群中的节点是否使用您指定的 MTU
$ oc describe network.config cluster
在为 OpenShift Container Platform 集群中的边缘计算节点配置机器集之前,您必须在 AWS Outposts 中创建子网。
您可以使用提供的 CloudFormation 模板并创建一个 CloudFormation 堆栈。然后,您可以使用此堆栈自定义配置子网。
如果您不使用提供的 CloudFormation 模板创建 AWS 基础设施,则必须查看提供的资料并手动创建基础设施。如果您的集群无法正确初始化,您可能需要联系 Red Hat 支持并提供您的安装日志。 |
您已配置了一个 AWS 账户。
您已通过运行 aws configure
将您的 AWS 密钥和区域添加到本地 AWS 配置文件中。
您已从您的 OpenShift Container Platform 集群、Outpost 和 AWS 账户获取有关您环境的所需信息。
转到名为“VPC 子网的 CloudFormation 模板”的文档部分,并从模板中复制语法。将复制的模板语法保存为本地系统上的 YAML 文件。此模板描述了您的集群所需的 VPC。
运行以下命令以部署 CloudFormation 模板,该模板创建一个代表 VPC 的 AWS 资源堆栈。
$ aws cloudformation create-stack --stack-name <stack_name> \(1)
--region ${CLUSTER_REGION} \
--template-body file://<template>.yaml \(2)
--parameters \
ParameterKey=VpcId,ParameterValue="${VPC_ID}" \(3)
ParameterKey=ClusterName,ParameterValue="${CLUSTER_NAME}" \(4)
ParameterKey=ZoneName,ParameterValue="${ZONE_NAME}" \(5)
ParameterKey=PublicRouteTableId,ParameterValue="${ROUTE_TABLE_PUB}" \(6)
ParameterKey=PublicSubnetCidr,ParameterValue="${SUBNET_CIDR_PUB}" \(7)
ParameterKey=PrivateRouteTableId,ParameterValue="${ROUTE_TABLE_PVT}" \(8)
ParameterKey=PrivateSubnetCidr,ParameterValue="${SUBNET_CIDR_PVT}" \(9)
ParameterKey=PrivateSubnetLabel,ParameterValue="private-outpost" \
ParameterKey=PublicSubnetLabel,ParameterValue="public-outpost" \
ParameterKey=OutpostArn,ParameterValue="${OUTPOST_ARN}" (10)
1 | <stack_name> 是 CloudFormation 堆栈的名称,例如 cluster-<outpost_name> 。 |
2 | <template> 是您保存的 CloudFormation 模板 YAML 文件的相对路径和名称。 |
3 | ${VPC_ID} 是 VPC ID,它是 VPC 的 CloudFormation 模板输出中的 VpcID 值。 |
4 | ${CLUSTER_NAME} 是用作新 AWS 资源名称前缀的 **ClusterName** 的值。 |
5 | ${ZONE_NAME} 是用于创建子网的 AWS Outpost 名称的值。 |
6 | ${ROUTE_TABLE_PUB} 是在 ${VPC_ID} 中创建的公共路由表 ID,用于关联 Outpost 上的公共子网。指定公共路由表以关联此堆栈创建的 Outpost 子网。 |
7 | ${SUBNET_CIDR_PUB} 是用于创建公共子网的有效 CIDR 块。此块必须是 VPC CIDR 块 VpcCidr 的一部分。 |
8 | ${ROUTE_TABLE_PVT} 是在 ${VPC_ID} 中创建的私有路由表 ID,用于关联 Outpost 上的私有子网。指定私有路由表以关联此堆栈创建的 Outpost 子网。 |
9 | ${SUBNET_CIDR_PVT} 是用于创建私有子网的有效 CIDR 块。此块必须是 VPC CIDR 块 VpcCidr 的一部分。 |
10 | ${OUTPOST_ARN} 是 Outpost 的 Amazon 资源名称 (ARN)。 |
arn:aws:cloudformation:us-east-1:123456789012:stack/<stack_name>/dbedae40-820e-11eb-2fd3-12a48460849f
通过运行以下命令确认模板组件是否存在。
$ aws cloudformation describe-stacks --stack-name <stack_name>
StackStatus
显示 CREATE_COMPLETE
后,输出将显示以下参数的值。
PublicSubnetId
|
CloudFormation 堆栈创建的公共子网的 ID。 |
PrivateSubnetId
|
CloudFormation 堆栈创建的私有子网的 ID。 |
确保您为创建集群的其他 CloudFormation 模板提供这些参数值。
您可以使用以下 CloudFormation 模板部署 Outpost 子网。
AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice Subnets (Public and Private)
Parameters:
VpcId:
Description: VPC ID that comprises all the target subnets.
Type: String
AllowedPattern: ^(?:(?:vpc)(?:-[a-zA-Z0-9]+)?\b|(?:[0-9]{1,3}\.){3}[0-9]{1,3})$
ConstraintDescription: VPC ID must be with valid name, starting with vpc-.*.
ClusterName:
Description: Cluster name or prefix name to prepend the Name tag for each subnet.
Type: String
AllowedPattern: ".+"
ConstraintDescription: ClusterName parameter must be specified.
ZoneName:
Description: Zone Name to create the subnets, such as us-west-2-lax-1a.
Type: String
AllowedPattern: ".+"
ConstraintDescription: ZoneName parameter must be specified.
PublicRouteTableId:
Description: Public Route Table ID to associate the public subnet.
Type: String
AllowedPattern: ".+"
ConstraintDescription: PublicRouteTableId parameter must be specified.
PublicSubnetCidr:
AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
Default: 10.0.128.0/20
Description: CIDR block for public subnet.
Type: String
PrivateRouteTableId:
Description: Private Route Table ID to associate the private subnet.
Type: String
AllowedPattern: ".+"
ConstraintDescription: PrivateRouteTableId parameter must be specified.
PrivateSubnetCidr:
AllowedPattern: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])(\/(1[6-9]|2[0-4]))$
ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/16-24.
Default: 10.0.128.0/20
Description: CIDR block for private subnet.
Type: String
PrivateSubnetLabel:
Default: "private"
Description: Subnet label to be added when building the subnet name.
Type: String
PublicSubnetLabel:
Default: "public"
Description: Subnet label to be added when building the subnet name.
Type: String
OutpostArn:
Default: ""
Description: OutpostArn when creating subnets on AWS Outpost.
Type: String
Conditions:
OutpostEnabled: !Not [!Equals [!Ref "OutpostArn", ""]]
Resources:
PublicSubnet:
Type: "AWS::EC2::Subnet"
Properties:
VpcId: !Ref VpcId
CidrBlock: !Ref PublicSubnetCidr
AvailabilityZone: !Ref ZoneName
OutpostArn: !If [ OutpostEnabled, !Ref OutpostArn, !Ref "AWS::NoValue"]
Tags:
- Key: Name
Value: !Join ['-', [ !Ref ClusterName, !Ref PublicSubnetLabel, !Ref ZoneName]]
- Key: kubernetes.io/cluster/unmanaged (1)
Value: true
PublicSubnetRouteTableAssociation:
Type: "AWS::EC2::SubnetRouteTableAssociation"
Properties:
SubnetId: !Ref PublicSubnet
RouteTableId: !Ref PublicRouteTableId
PrivateSubnet:
Type: "AWS::EC2::Subnet"
Properties:
VpcId: !Ref VpcId
CidrBlock: !Ref PrivateSubnetCidr
AvailabilityZone: !Ref ZoneName
OutpostArn: !If [ OutpostEnabled, !Ref OutpostArn, !Ref "AWS::NoValue"]
Tags:
- Key: Name
Value: !Join ['-', [!Ref ClusterName, !Ref PrivateSubnetLabel, !Ref ZoneName]]
- Key: kubernetes.io/cluster/unmanaged (2)
Value: true
PrivateSubnetRouteTableAssociation:
Type: "AWS::EC2::SubnetRouteTableAssociation"
Properties:
SubnetId: !Ref PrivateSubnet
RouteTableId: !Ref PrivateRouteTableId
Outputs:
PublicSubnetId:
Description: Subnet ID of the public subnets.
Value:
!Join ["", [!Ref PublicSubnet]]
PrivateSubnetId:
Description: Subnet ID of the private subnets.
Value:
!Join ["", [!Ref PrivateSubnet]]
1 | 您必须在 AWS Outposts 的公共子网配置中包含 kubernetes.io/cluster/unmanaged 标签。 |
2 | 您必须在 AWS Outposts 的私有子网配置中包含 kubernetes.io/cluster/unmanaged 标签。 |
要在 AWS Outposts 上创建边缘计算机器,您必须创建一个具有兼容配置的新计算机器集。
您有一个 AWS Outposts 站点。
您已将 OpenShift Container Platform 集群安装到 AWS 上的自定义 VPC 中。
您可以使用具有cluster-admin
权限的帐户访问集群。
您已安装 OpenShift CLI (oc
)。
通过运行以下命令列出集群中的计算机器集。
$ oc get machinesets.machine.openshift.io -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE
<original_machine_set_name_1> 1 1 1 1 55m
<original_machine_set_name_2> 1 1 1 1 55m
记录现有计算机器集的名称。
使用以下方法之一创建一个包含新计算机器集自定义资源 (CR) 值的 YAML 文件。
通过运行以下命令将现有计算机器集配置复制到新文件。
$ oc get machinesets.machine.openshift.io <original_machine_set_name_1> \
-n openshift-machine-api -o yaml > <new_machine_set_name_1>.yaml
您可以使用您喜欢的文本编辑器编辑此 YAML 文件。
使用您喜欢的文本编辑器创建一个名为 <new_machine_set_name_1>.yaml
的空 YAML 文件,并包含新计算机器集的所需值。
如果您不确定为特定字段设置哪个值,您可以通过运行以下命令查看现有计算机器集 CR 的值。
$ oc get machinesets.machine.openshift.io <original_machine_set_name_1> \
-n openshift-machine-api -o yaml
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
labels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
name: <infrastructure_id>-<role>-<availability_zone> (2)
namespace: openshift-machine-api
spec:
replicas: 1
selector:
matchLabels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id>
machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<availability_zone>
template:
metadata:
labels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id>
machine.openshift.io/cluster-api-machine-role: <role>
machine.openshift.io/cluster-api-machine-type: <role>
machine.openshift.io/cluster-api-machineset: <infrastructure_id>-<role>-<availability_zone>
spec:
providerSpec: (3)
# ...
1 | 集群基础设施 ID。 |
2 | 默认节点标签。对于 AWS Outposts,您使用 outposts 角色。 |
3 | 省略的 providerSpec 部分包含必须为您的 Outpost 配置的值。 |
通过编辑 <new_machine_set_name_1>.yaml
文件,配置新计算机器集以在 Outpost 中创建边缘计算机器。
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
labels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id> (1)
name: <infrastructure_id>-outposts-<availability_zone> (2)
namespace: openshift-machine-api
spec:
replicas: 1
selector:
matchLabels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id>
machine.openshift.io/cluster-api-machineset: <infrastructure_id>-outposts-<availability_zone>
template:
metadata:
labels:
machine.openshift.io/cluster-api-cluster: <infrastructure_id>
machine.openshift.io/cluster-api-machine-role: outposts
machine.openshift.io/cluster-api-machine-type: outposts
machine.openshift.io/cluster-api-machineset: <infrastructure_id>-outposts-<availability_zone>
spec:
metadata:
labels:
node-role.kubernetes.io/outposts: ""
location: outposts
providerSpec:
value:
ami:
id: <ami_id> (3)
apiVersion: machine.openshift.io/v1beta1
blockDevices:
- ebs:
volumeSize: 120
volumeType: gp2 (4)
credentialsSecret:
name: aws-cloud-credentials
deviceIndex: 0
iamInstanceProfile:
id: <infrastructure_id>-worker-profile
instanceType: m5.xlarge (5)
kind: AWSMachineProviderConfig
placement:
availabilityZone: <availability_zone>
region: <region> (6)
securityGroups:
- filters:
- name: tag:Name
values:
- <infrastructure_id>-worker-sg
subnet:
id: <subnet_id> (7)
tags:
- name: kubernetes.io/cluster/<infrastructure_id>
value: owned
userDataSecret:
name: worker-user-data
taints: (8)
- key: node-role.kubernetes.io/outposts
effect: NoSchedule
1 | 指定集群基础设施 ID。 |
2 | 指定计算机器集的名称。名称由集群基础设施 ID、outposts 角色名称和 Outpost 可用区组成。 |
3 | 指定 Amazon 机器镜像 (AMI) ID。 |
4 | 指定 EBS 卷类型。AWS Outposts 需要 gp2 卷。 |
5 | 指定 AWS 实例类型。您必须使用 Outpost 中配置的实例类型。 |
6 | 指定 Outpost 可用区所在的 AWS 区域。 |
7 | 指定 Outpost 的专用子网。 |
8 | 指定污点以防止将工作负载调度到具有 node-role.kubernetes.io/outposts 标签的节点上。要在 Outpost 中调度用户工作负载,您必须在应用程序的 Deployment 资源中指定相应的容忍度。 |
保存您的更改。
通过运行以下命令创建计算机器集 CR。
$ oc create -f <new_machine_set_name_1>.yaml
要验证是否已创建计算机器集,请运行以下命令列出集群中的计算机器集。
$ oc get machinesets.machine.openshift.io -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE
<new_machine_set_name_1> 1 1 1 1 4m12s
<original_machine_set_name_1> 1 1 1 1 55m
<original_machine_set_name_2> 1 1 1 1 55m
要列出由新计算机器集管理的机器,请运行以下命令。
$ oc get -n openshift-machine-api machines.machine.openshift.io \
-l machine.openshift.io/cluster-api-machineset=<new_machine_set_name_1>
NAME PHASE TYPE REGION ZONE AGE
<machine_from_new_1> Provisioned m5.xlarge us-east-1 us-east-1a 25s
<machine_from_new_2> Provisioning m5.xlarge us-east-1 us-east-1a 25s
要验证由新计算机器集创建的机器是否具有正确的配置,请通过运行以下命令检查新机器之一的 CR 中的相关字段。
$ oc describe machine <machine_from_new_1> -n openshift-machine-api
将 AWS VPC 集群中的 OpenShift Container Platform 扩展到 Outpost 后,您可以使用带有标签 node-role.kubernetes.io/outposts
的边缘计算节点在 Outpost 中创建用户工作负载。
您已将 AWS VPC 集群扩展到 Outpost。
您可以使用具有cluster-admin
权限的帐户访问集群。
您已安装 OpenShift CLI (oc
)。
您已创建了一个部署与 Outpost 环境兼容的边缘计算机的计算机器集。
为要部署到边缘子网中边缘计算节点的应用程序配置一个 Deployment
资源文件。
Deployment
清单示例kind: Namespace
apiVersion: v1
metadata:
name: <application_name> (1)
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: <application_name>
namespace: <application_namespace> (2)
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: gp2-csi (3)
volumeMode: Filesystem
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: <application_name>
namespace: <application_namespace>
spec:
selector:
matchLabels:
app: <application_name>
replicas: 1
template:
metadata:
labels:
app: <application_name>
location: outposts (4)
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
nodeSelector: (5)
node-role.kubernetes.io/outpost: ''
tolerations: (6)
- key: "node-role.kubernetes.io/outposts"
operator: "Equal"
value: ""
effect: "NoSchedule"
containers:
- image: openshift/origin-node
command:
- "/bin/socat"
args:
- TCP4-LISTEN:8080,reuseaddr,fork
- EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
imagePullPolicy: Always
name: <application_name>
ports:
- containerPort: 8080
volumeMounts:
- mountPath: "/mnt/storage"
name: data
volumes:
- name: data
persistentVolumeClaim:
claimName: <application_name>
1 | 为您的应用程序指定一个名称。 |
2 | 为您的应用程序指定一个命名空间。应用程序命名空间可以与应用程序名称相同。 |
3 | 指定存储类名称。对于边缘计算配置,您必须使用 gp2-csi 存储类。 |
4 | 指定一个标签来标识在 Outpost 中部署的工作负载。 |
5 | 指定将目标设置为边缘计算节点的节点选择器标签。 |
6 | 指定与边缘计算机的计算机器集中的 key 和 effects 污点匹配的容忍度。按所示设置 value 和 operator 容忍度。 |
通过运行以下命令创建 Deployment
资源。
$ oc create -f <application_deployment>.yaml
配置一个 Service
对象,该对象将来自目标边缘计算节点的 pod 暴露给在边缘网络内部运行的服务。
Service
清单示例apiVersion: v1
kind: Service (1)
metadata:
name: <application_name>
namespace: <application_namespace>
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: NodePort
selector: (2)
app: <application_name>
1 | 定义 service 资源。 |
2 | 指定要应用于托管 pod 的标签类型。 |
运行以下命令创建Service
CR
$ oc create -f <application_service>.yaml
当您将 AWS VPC 集群扩展到 Outpost 时,Outpost 使用边缘计算节点,而 VPC 使用基于云的计算节点。以下负载均衡器注意事项适用于扩展到 Outpost 的 AWS VPC 集群
Outpost 无法运行 AWS 网络负载均衡器或 AWS 经典负载均衡器,但扩展到 Outpost 的 VPC 集群的经典负载均衡器可以连接到 Outpost 边缘计算节点。更多信息,请参见 在扩展到 Outpost 的 AWS VPC 集群中使用 AWS 经典负载均衡器。
要在 Outpost 实例上运行负载均衡器,必须使用 AWS 应用负载均衡器。您可以使用 AWS Load Balancer Operator 部署 AWS Load Balancer Controller 的实例。控制器为 Kubernetes Ingress 资源配置 AWS 应用负载均衡器。更多信息,请参见 在扩展到 Outpost 的 AWS VPC 集群中使用 AWS Load Balancer Operator。
AWS Outpost 基础设施无法运行 AWS 经典负载均衡器,但如果边缘和基于云的子网位于相同的可用区,则 AWS VPC 集群中的经典负载均衡器可以将目标指向 Outpost 边缘计算节点。因此,VPC 集群上的经典负载均衡器可能会在这两种类型的节点上调度 Pod。
在边缘计算节点和基于云的计算节点上调度工作负载可能会引入延迟。如果要阻止 VPC 集群中的经典负载均衡器将目标指向 Outpost 边缘计算节点,可以为基于云的计算节点应用标签,并将经典负载均衡器配置为仅在应用了标签的节点上进行调度。
如果您不需要阻止 VPC 集群中的经典负载均衡器将目标指向 Outpost 边缘计算节点,则无需完成这些步骤。 |
您已将 AWS VPC 集群扩展到 Outpost。
您可以使用具有cluster-admin
权限的帐户访问集群。
您已安装 OpenShift CLI (oc
)。
您已在 Outpost 中创建了具有与边缘计算机器污点匹配的容忍度的用户工作负载。
可选:通过运行以下命令并验证输出仅包含 Outpost 中的边缘计算节点,来验证边缘计算节点是否具有location=outposts
标签
$ oc get nodes -l location=outposts
通过运行以下命令,为 VPC 集群中的基于云的计算节点添加键值对标签
$ for NODE in $(oc get node -l node-role.kubernetes.io/worker --no-headers | grep -v outposts | awk '{print$1}'); do oc label node $NODE <key_name>=<value>; done
其中<key_name>=<value>
是您要用来区分基于云的计算节点的标签。
node1.example.com labeled
node2.example.com labeled
node3.example.com labeled
可选:通过运行以下命令并确认输出包含 VPC 集群中的所有基于云的计算节点,来验证基于云的计算节点是否具有指定的标签
$ oc get nodes -l <key_name>=<value>
NAME STATUS ROLES AGE VERSION
node1.example.com Ready worker 7h v1.30.3
node2.example.com Ready worker 7h v1.30.3
node3.example.com Ready worker 7h v1.30.3
通过将基于云的子网信息添加到Service
清单的annotations
字段来配置经典负载均衡器服务
apiVersion: v1
kind: Service
metadata:
labels:
app: <application_name>
name: <application_name>
namespace: <application_namespace>
annotations:
service.beta.kubernetes.io/aws-load-balancer-subnets: <aws_subnet> (1)
service.beta.kubernetes.io/aws-load-balancer-target-node-labels: <key_name>=<value> (2)
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 8080
selector:
app: <application_name>
type: LoadBalancer
1 | 指定 AWS VPC 集群的子网 ID。 |
2 | 指定与节点标签中的键值对匹配的键值对。 |
运行以下命令创建Service
CR
$ oc create -f <file_name>.yaml
通过运行以下命令,验证service
资源的状态以显示已配置的经典负载均衡器的主机
$ HOST=$(oc get service <application_name> -n <application_namespace> --template='{{(index .status.loadBalancer.ingress 0).hostname}}')
通过运行以下命令,验证已配置的经典负载均衡器主机的状态
$ curl $HOST
在 AWS 控制台中,验证只有已标记的实例显示为负载均衡器的目标实例。
您可以将 AWS Load Balancer Operator 配置为在扩展到 Outpost 的 AWS VPC 集群中配置 AWS 应用负载均衡器。AWS Outpost 不支持 AWS 网络负载均衡器。因此,AWS Load Balancer Operator 无法在 Outpost 中配置网络负载均衡器。
您可以在云子网或 Outpost 子网中创建 AWS 应用负载均衡器。云中的应用负载均衡器可以连接到基于云的计算节点,而 Outpost 中的应用负载均衡器可以连接到边缘计算节点。您必须使用 Outpost 子网或 VPC 子网注释 Ingress 资源,但不能同时使用两者。
您已将 AWS VPC 集群扩展到 Outpost。
您已安装 OpenShift CLI (oc
)。
您已安装 AWS Load Balancer Operator 并创建了 AWS Load Balancer Controller。
配置Ingress
资源以使用指定的子网
Ingress
资源配置apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: <application_name>
annotations:
alb.ingress.kubernetes.io/subnets: <subnet_id> (1)
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: <application_name>
port:
number: 80
1 | 指定要使用的子网。
|