Chapter 13. Installing a cluster on AWS with worker nodes on AWS Local Zones

13.1. Prerequisites
Link kopieren

You reviewed details about the OpenShift Container Platform installation and update processes.
You read the documentation on selecting a cluster installation method and preparing it for users.
You configured an AWS account to host the cluster.
Important
If you have an AWS profile stored on your computer, it must not use a temporary session token that you generated while using a multi-factor authentication device. The cluster continues to use your current AWS credentials to create AWS resources for the entire life of the cluster, so you must use key-based, long-term credentials. To generate appropriate keys, see Managing Access Keys for IAM Users in the AWS documentation. You can supply the keys when you run the installation program.
You noted the region and supported AWS Local Zones locations to create the network resources in.
You read the Features for each AWS Local Zones location.
You downloaded the AWS CLI and installed it on your computer. See Install the AWS CLI Using the Bundled Installer (Linux, macOS, or UNIX) in the AWS documentation.
If you use a firewall, you configured it to allow the sites that your cluster requires access to.
Note
Be sure to also review this site list if you are configuring a proxy.

Add permission for the user who creates the cluster to modify the Local Zone group with ec2:ModifyAvailabilityZoneGroup. For example:

An example of a permissive IAM policy to attach to a user or role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:ModifyAvailabilityZoneGroup"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:ModifyAvailabilityZoneGroup"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Copy to Clipboard

Toggle word wrap

13.2. Cluster limitations in AWS Local Zones
Link kopieren

Some limitations exist when you attempt to deploy a cluster with a default installation configuration in Amazon Web Services (AWS) Local Zones.

Important

The following list details limitations when deploying a cluster in AWS Local Zones:

The Maximum Transmission Unit (MTU) between an Amazon EC2 instance in a Local Zone and an Amazon EC2 instance in the Region is 1300. This causes the cluster-wide network MTU to change according to the network plugin that is used on the deployment.
Network resources such as Network Load Balancer (NLB), Classic Load Balancer, and Network Address Translation (NAT) Gateways are not globally supported in AWS Local Zones.
For an OpenShift Container Platform cluster on AWS, the AWS Elastic Block Storage (EBS) gp3 type volume is the default for node volumes and the default for the storage class. This volume type is not globally available on Local Zone locations. By default, the nodes running in Local Zones are deployed with the gp2 EBS volume. The gp2-csi StorageClass must be set when creating workloads on Local Zone nodes.

If you want the installation program to automatically create Local Zone subnets for your OpenShift Container Platform cluster, specific configuration limitations apply with this method.

Important

The following configuration limitation applies when you set the installation program to automatically create subnets for your OpenShift Container Platform cluster:

The private subnets for an AWS Local Zone associate with the route table of the parent zone, so that each private subnet can route egress traffic to the internet. If this route table does not exist during cluster installation, the private subnet associates with the first available private route table in the Virtual Private Cloud (VPC). This approach is valid only for AWS Local Zones subnets in an OpenShift Container Platform cluster.

13.3. Internet access for OpenShift Container Platform
Link kopieren

In OpenShift Container Platform 4.14, you require access to the internet to install your cluster.

You must have internet access to:

Access OpenShift Cluster Manager to download the installation program and perform subscription management. If the cluster has internet access and you do not disable Telemetry, that service automatically entitles your cluster.
Access Quay.io to obtain the packages that are required to install your cluster.
Obtain the packages that are required to perform cluster updates.

Important

If your cluster cannot have direct internet access, you can perform a restricted network installation on some types of infrastructure that you provision. During that process, you download the required content and use it to populate a mirror registry with the installation packages. With some installation types, the environment that you install your cluster in will not require internet access. Before you update the cluster, you update the content of the mirror registry.

13.4. Obtaining an AWS Marketplace image
Link kopieren

If you are deploying an OpenShift Container Platform cluster using an AWS Marketplace image, you must first subscribe through AWS. Subscribing to the offer provides you with the AMI ID that the installation program uses to deploy worker nodes.

Note

You should only modify the RHCOS image for compute machines to use an AWS Marketplace image. Control plane machines and infrastructure nodes do not require an OpenShift Container Platform subscription and use the public RHCOS default image by default, which does not incur subscription costs on your AWS bill. Therefore, you should not modify the cluster default boot image or the control plane boot images. Applying the AWS Marketplace image to them will incur additional licensing costs that cannot be recovered.

Prerequisites

You have an AWS account to purchase the offer. This account does not have to be the same account that is used to install the cluster.

Procedure

Complete the OpenShift Container Platform subscription from the AWS Marketplace.
Record the AMI ID for your specific region. As part of the installation process, you must update the install-config.yaml file with this value before deploying the cluster.

Sample install-config.yaml file with AWS Marketplace worker nodes

apiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      amiID: ami-06c4d345f7c207239 
      type: m5.4xlarge
  replicas: 3
metadata:
  name: test-cluster
platform:
  aws:
    region: us-east-2 
sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'

apiVersion: v1
baseDomain: example.com
compute:
- hyperthreading: Enabled
  name: worker
  platform:
    aws:
      amiID: ami-06c4d345f7c207239

1


      type: m5.4xlarge
  replicas: 3
metadata:
  name: test-cluster
platform:
  aws:
    region: us-east-2

2


sshKey: ssh-ed25519 AAAA...
pullSecret: '{"auths": ...}'

Copy to Clipboard

Toggle word wrap

1: The AMI ID from your AWS Marketplace subscription.
2: Your AMI ID is associated with a specific AWS region. When creating the installation configuration file, ensure that you select the same AWS region that you specified when configuring your subscription.

13.5. Installing the OpenShift CLI by downloading the binary
Link kopieren

You can install the OpenShift CLI (oc) to interact with OpenShift Container Platform from a command-line interface. You can install oc on Linux, Windows, or macOS.

Important

If you installed an earlier version of oc, you cannot use it to complete all of the commands in OpenShift Container Platform 4.14. Download and install the new version of oc.

Installing the OpenShift CLI on Linux

You can install the OpenShift CLI (oc) binary on Linux by using the following procedure.

Procedure

Navigate to the OpenShift Container Platform downloads page on the Red Hat Customer Portal.
Select the architecture from the Product Variant drop-down list.
Select the appropriate version from the Version drop-down list.
Click Download Now next to the OpenShift v4.14 Linux Client entry and save the file.
Unpack the archive:
```
tar xvf <file>
```
```
$ tar xvf <file>
```
Copy to Clipboard Toggle word wrap
Place the oc binary in a directory that is on your PATH.
To check your PATH, execute the following command:
```
echo $PATH
```
```
$ echo $PATH
```
Copy to Clipboard Toggle word wrap

Verification

After you install the OpenShift CLI, it is available using the oc command:
```
oc <command>
```
```
$ oc <command>
```
Copy to Clipboard Toggle word wrap

Installing the OpenShift CLI on Windows

You can install the OpenShift CLI (oc) binary on Windows by using the following procedure.

Procedure

Navigate to the OpenShift Container Platform downloads page on the Red Hat Customer Portal.
Select the appropriate version from the Version drop-down list.
Click Download Now next to the OpenShift v4.14 Windows Client entry and save the file.
Unzip the archive with a ZIP program.
Move the oc binary to a directory that is on your PATH.
To check your PATH, open the command prompt and execute the following command:
```
path
```
```
C:\> path
```
Copy to Clipboard Toggle word wrap

Verification

After you install the OpenShift CLI, it is available using the oc command:
```
oc <command>
```
```
C:\> oc <command>
```
Copy to Clipboard Toggle word wrap

Installing the OpenShift CLI on macOS

You can install the OpenShift CLI (oc) binary on macOS by using the following procedure.

Procedure

Navigate to the OpenShift Container Platform downloads page on the Red Hat Customer Portal.
Select the appropriate version from the Version drop-down list.
Click Download Now next to the OpenShift v4.14 macOS Client entry and save the file.
Note
For macOS arm64, choose the OpenShift v4.14 macOS arm64 Client entry.
Unpack and unzip the archive.
Move the oc binary to a directory on your PATH.
To check your PATH, open a terminal and execute the following command:
```
echo $PATH
```
```
$ echo $PATH
```
Copy to Clipboard Toggle word wrap

Verification

Verify your installation by using an oc command:
```
oc <command>
```
```
$ oc <command>
```
Copy to Clipboard Toggle word wrap

13.6. Preparing for the installation
Link kopieren

Before you extend nodes to local zones, you must prepare certain resources for the cluster installation environment.

13.6.1. Obtaining the installation program
Link kopieren

Before you install OpenShift Container Platform, download the installation file on the host you are using for installation.

Prerequisites

You have a computer that runs Linux or macOS, with at least 1.2 GB of local disk space.

Procedure

Go to the Cluster Type page on the Red Hat Hybrid Cloud Console. If you have a Red Hat account, log in with your credentials. If you do not, create an account.
Select your infrastructure provider from the Run it yourself section of the page.
Select your host operating system and architecture from the dropdown menus under OpenShift Installer and click Download Installer.
Place the downloaded file in the directory where you want to store the installation configuration files.
Important
- The installation program creates several files on the computer that you use to install your cluster. You must keep the installation program and the files that the installation program creates after you finish installing the cluster. Both of the files are required to delete the cluster.
- Deleting the files created by the installation program does not remove your cluster, even if the cluster failed during installation. To remove your cluster, complete the OpenShift Container Platform uninstallation procedures for your specific cloud provider.
Extract the installation program. For example, on a computer that uses a Linux operating system, run the following command:
```
tar -xvf openshift-install-linux.tar.gz
```
```
$ tar -xvf openshift-install-linux.tar.gz
```
Copy to Clipboard Toggle word wrap
Download your installation pull secret from Red Hat OpenShift Cluster Manager. This pull secret allows you to authenticate with the services that are provided by the included authorities, including Quay.io, which serves the container images for OpenShift Container Platform components.

Tip

Alternatively, you can retrieve the installation program from the Red Hat Customer Portal, where you can specify a version of the installation program to download. However, you must have an active subscription to access this page.

13.6.2. Generating a key pair for cluster node SSH access
Link kopieren

During an OpenShift Container Platform installation, you can provide an SSH public key to the installation program. The key is passed to the Red Hat Enterprise Linux CoreOS (RHCOS) nodes through their Ignition config files and is used to authenticate SSH access to the nodes. The key is added to the ~/.ssh/authorized_keys list for the core user on each node, which enables password-less authentication.

After the key is passed to the nodes, you can use the key pair to SSH in to the RHCOS nodes as the user core. To access the nodes through SSH, the private key identity must be managed by SSH for your local user.

If you want to SSH in to your cluster nodes to perform installation debugging or disaster recovery, you must provide the SSH public key during the installation process. The ./openshift-install gather command also requires the SSH public key to be in place on the cluster nodes.

Important

Do not skip this procedure in production environments, where disaster recovery and debugging is required.

Note

You must use a local key, not one that you configured with platform-specific approaches such as AWS key pairs.

Procedure

If you do not have an existing SSH key pair on your local machine to use for authentication onto your cluster nodes, create one. For example, on a computer that uses a Linux operating system, run the following command:
```
ssh-keygen -t ed25519 -N '' -f <path>/<file_name>
```
```
$ ssh-keygen -t ed25519 -N '' -f <path>/<file_name> 
```
1
Copy to Clipboard Toggle word wrap
1
Specify the path and file name, such as ~/.ssh/id_ed25519, of the new SSH key. If you have an existing key pair, ensure your public key is in the your ~/.ssh directory.
Note
If you plan to install an OpenShift Container Platform cluster that uses the RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 Validation on only the x86_64, ppc64le, and s390x architectures, do not create a key that uses the ed25519 algorithm. Instead, create a key that uses the rsa or ecdsa algorithm.
View the public SSH key:
```
cat <path>/<file_name>.pub
```
```
$ cat <path>/<file_name>.pub
```
Copy to Clipboard Toggle word wrap
For example, run the following to view the ~/.ssh/id_ed25519.pub public key:
```
cat ~/.ssh/id_ed25519.pub
```
```
$ cat ~/.ssh/id_ed25519.pub
```
Copy to Clipboard Toggle word wrap
Add the SSH private key identity to the SSH agent for your local user, if it has not already been added. SSH agent management of the key is required for password-less SSH authentication onto your cluster nodes, or if you want to use the ./openshift-install gather command.
Note
On some distributions, default SSH private key identities such as ~/.ssh/id_rsa and ~/.ssh/id_dsa are managed automatically.
1. If the ssh-agent process is not already running for your local user, start it as a background task:
  $ eval "$(ssh-agent -s)"
  Copy to Clipboard Toggle word wrap
  Example output
  Agent pid 31874
  
  Copy to Clipboard Toggle word wrap
  Note
  If your cluster is in FIPS mode, only use FIPS-compliant algorithms to generate the SSH key. The key must be either RSA or ECDSA.
Add your SSH private key to the ssh-agent:
```
ssh-add <path>/<file_name>
```
```
$ ssh-add <path>/<file_name> 
```
1
Copy to Clipboard Toggle word wrap
1
Specify the path and file name for your SSH private key, such as ~/.ssh/id_ed25519
Example output
```
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
```
```
Identity added: /home/<you>/<path>/<file_name> (<computer_name>)
```
Copy to Clipboard Toggle word wrap

Next steps

When you install OpenShift Container Platform, provide the SSH public key to the installation program.

13.6.3. Creating the installation files for AWS
Link kopieren

To install OpenShift Container Platform on Amazon Web Services (AWS) using user-provisioned infrastructure, you must generate the files that the installation program needs to deploy your cluster and modify them so that the cluster creates only the machines that it will use. You generate and customize the install-config.yaml file, Kubernetes manifests, and Ignition config files. You also have the option to first set up a separate var partition during the preparation phases of installation.

13.6.4. Minimum resource requirements for cluster installation
Link kopieren

Each cluster machine must meet the following minimum requirements:

Expand

Table 13.1. Minimum resource requirements
Machine	Operating System	vCPU ^[1]	Virtual RAM	Storage	Input/Output Per Second (IOPS)^[2]
Bootstrap	RHCOS	4	16 GB	100 GB	300
Control plane	RHCOS	4	16 GB	100 GB	300
Compute	RHCOS, RHEL 8.6 and later ^[3]	2	8 GB	100 GB	300

One vCPU is equivalent to one physical core when simultaneous multithreading (SMT), or Hyper-Threading, is not enabled. When enabled, use the following formula to calculate the corresponding ratio: (threads per core × cores) × sockets = vCPUs.
OpenShift Container Platform and Kubernetes are sensitive to disk performance, and faster storage is recommended, particularly for etcd on the control plane nodes which require a 10 ms p99 fsync duration. Note that on many cloud platforms, storage size and IOPS scale together, so you might need to over-allocate storage volume to obtain sufficient performance.
As with all user-provisioned installations, if you choose to use RHEL compute machines in your cluster, you take responsibility for all operating system life cycle management and maintenance, including performing system updates, applying patches, and completing all other required tasks. Use of RHEL 7 compute machines is deprecated and has been removed in OpenShift Container Platform 4.10 and later.

Note

As of OpenShift Container Platform version 4.13, RHCOS is based on RHEL version 9.2, which updates the micro-architecture requirements. The following list contains the minimum instruction set architectures (ISA) that each architecture requires:

x86-64 architecture requires x86-64-v2 ISA
ARM64 architecture requires ARMv8.0-A ISA
IBM Power architecture requires Power 9 ISA
s390x architecture requires z14 ISA

For more information, see RHEL Architectures.

If an instance type for your platform meets the minimum requirements for cluster machines, it is supported to use in OpenShift Container Platform.

13.6.5. Tested instance types for AWS
Link kopieren

The following Amazon Web Services (AWS) instance types have been tested with OpenShift Container Platform for use with AWS Local Zones.

Note

Use the machine types included in the following charts for your AWS instances. If you use an instance type that is not listed in the chart, ensure that the instance size you use matches the minimum resource requirements that are listed in "Minimum resource requirements for cluster installation".

Example 13.1. Machine types based on 64-bit x86 architecture for AWS Local Zones

c5.*
c5d.*
m6i.*
m5.*
r5.*
t3.*

13.6.6. Creating the installation configuration file
Link kopieren

Generate and customize the installation configuration file that the installation program needs to deploy your cluster.

Prerequisites

You obtained the OpenShift Container Platform installation program and the pull secret for your cluster.
You checked that you are deploying your cluster to a region with an accompanying Red Hat Enterprise Linux CoreOS (RHCOS) AMI published by Red Hat. If you are deploying to a region that requires a custom AMI, such as an AWS GovCloud region, you must create the install-config.yaml file manually.

Procedure

Create the install-config.yaml file.
1. Change to the directory that contains the installation program and run the following command:
  $ ./openshift-install create install-config --dir <installation_directory>
  1
  Copy to Clipboard Toggle word wrap
  1
  For <installation_directory>, specify the directory name to store the files that the installation program creates.
  Important
  Specify an empty directory. Some installation assets, like bootstrap X.509 certificates have short expiration intervals, so you must not reuse an installation directory. If you want to reuse individual files from another cluster installation, you can copy them into your directory. However, the file names for the installation assets might change between releases. Use caution when copying installation files from an earlier OpenShift Container Platform version.
2. At the prompts, provide the configuration details for your cloud:
  1. Optional: Select an SSH key to use to access your cluster machines.
    Note
    For production OpenShift Container Platform clusters on which you want to perform installation debugging or disaster recovery, specify an SSH key that your ssh-agent process uses.
  2. Select aws as the platform to target.
  3. If you do not have an AWS profile stored on your computer, enter the AWS access key ID and secret access key for the user that you configured to run the installation program.
    Note
    The AWS access key ID and secret access key are stored in ~/.aws/credentials in the home directory of the current user on the installation host. You are prompted for the credentials by the installation program if the credentials for the exported profile are not present in the file. Any credentials that you provide to the installation program are stored in the file.
  4. Select the AWS region to deploy the cluster to. The region that you specify must be the same region that contains the Local Zone that you opted in to for your AWS account.
  5. Select the base domain for the Route 53 service that you configured for your cluster.
  6. Enter a descriptive name for your cluster.
  7. Paste the pull secret from Red Hat OpenShift Cluster Manager.
Optional: Back up the install-config.yaml file.
Important
The install-config.yaml file is consumed during the installation process. If you want to reuse the file, you must back it up now.

13.6.7. Edge compute pools and AWS Local Zones
Link kopieren

Edge worker nodes are tainted worker nodes that run in AWS Local Zones locations.

When deploying a cluster that uses Local Zones, consider the following points:

Amazon EC2 instances in the Local Zones are more expensive than Amazon EC2 instances in the Availability Zones.
Latency between applications and end users is lower in Local Zones, and latency might vary by location. A latency impact exists for some workloads if, for example, ingress traffic is mixed between Local Zones and Availability Zones.

Important

Generally, the maximum transmission unit (MTU) between an Amazon EC2 instance in a Local Zone and an Amazon EC2 instance in the Region is 1300. For more information, see How Local Zones work in the AWS documentation. The cluster network MTU must be always less than the EC2 MTU to account for the overhead. The specific overhead is determined by the network plugin, for example:

OVN-Kubernetes: 100 bytes
OpenShift SDN: 50 bytes

The network plugin can provide additional features, like IPsec, that also must be decreased the MTU. For additional information, see the documentation.

OpenShift Container Platform 4.12 introduced a new compute pool, edge, that is designed for use in remote zones. The edge compute pool configuration is common between AWS Local Zones locations. Because of the type and size limitations of resources like EC2 and EBS on Local Zone resources, the default instance type can vary from the traditional worker pool.

The default Elastic Block Store (EBS) for Local Zone locations is gp2, which differs from the regular worker pool. The instance type used for each Local Zone on edge compute pool also might differ from worker pools, depending on the instance offerings on the zone.

The edge compute pool creates new labels that developers can use to deploy applications onto AWS Local Zones nodes. The new labels are:

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

By default, the machine sets for the edge compute pool defines the taint of NoSchedule to prevent regular workloads from spreading on Local Zone instances. Users can only run user workloads if they define tolerations in the pod specification.

The following examples show install-config.yaml files that use the edge machine pool.

Configuration that uses an edge pool with a custom instance type

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-localzone
compute:
- name: edge
  platform:
    aws:
      type: m5.4xlarge
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-localzone
compute:
- name: edge
  platform:
    aws:
      type: m5.4xlarge
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

Copy to Clipboard

Toggle word wrap

Instance types differ between locations. To verify availability in the Local Zone in which the cluster runs, see the AWS documentation.

Configuration that uses an edge pool with a custom EBS type

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-localzone
compute:
- name: edge
  platform:
    aws:
      rootVolume:
        type: gp3
        size: 120
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-localzone
compute:
- name: edge
  platform:
    aws:
      rootVolume:
        type: gp3
        size: 120
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

Copy to Clipboard

Toggle word wrap

EBS types differ between locations. Check the AWS documentation to verify availability in the Local Zone in which the cluster runs.

Configuration that uses an edge pool with custom security groups

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-localzone
compute:
- name: edge
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1 
        - sg-2
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

apiVersion: v1
baseDomain: devcluster.openshift.com
metadata:
  name: ipi-localzone
compute:
- name: edge
  platform:
    aws:
      additionalSecurityGroupIDs:
        - sg-1

1


        - sg-2
platform:
  aws:
    region: us-west-2
pullSecret: '{"auths": ...}'
sshKey: ssh-ed25519 AAAA...

Copy to Clipboard

Toggle word wrap

1: Specify the name of the security group as it appears in the Amazon EC2 console, including the sg prefix.

13.7. Opting in to AWS Local Zones
Link kopieren

If you plan to create the subnets in AWS Local Zones, you must opt in to each zone group separately.

Prerequisites

You have installed the AWS CLI.
You have determined an AWS Region for where you want to deploy your OpenShift Container Platform cluster.

You have attached a permissive IAM policy to a user or role account that opts in to the zone group. Consider the following configuration as an example IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:ModifyAvailabilityZoneGroup"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:ModifyAvailabilityZoneGroup"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Copy to Clipboard

Toggle word wrap

Procedure

List the zones that are available in your AWS Region by running the following command:

aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
    --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
    --filters Name=zone-type,Values=local-zone \
    --all-availability-zones

$ aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
    --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
    --filters Name=zone-type,Values=local-zone \
    --all-availability-zones

Copy to Clipboard

Toggle word wrap

Depending on the AWS Region, the list of available zones can be long. The command returns the following fields:

ZoneName: The name of the Local Zone.
GroupName: The group that comprises the zone. To opt in to the region, save the name.
Status: The status of the Local Zone group. If the status is not-opted-in, you must opt in the GroupName by running the commands that follow.

Opt in to the zone group on your AWS account by running the following command:
```
aws ec2 modify-availability-zone-group \
    --group-name "<value_of_GroupName>" \
    --opt-in-status opted-in
```
```
$ aws ec2 modify-availability-zone-group \
    --group-name "<value_of_GroupName>" \
```
1
```
    --opt-in-status opted-in
```
Copy to Clipboard Toggle word wrap
1
For <value_of_GroupName>, specify the name of the group of the Local Zone where you want to create subnets. For example, specify us-east-1-nyc-1 to use the zone us-east-1-nyc-1a (US East New York).

13.8. Cluster installation options for an AWS Local Zones environment
Link kopieren

To install an OpenShift Container Platform cluster in an AWS Local Zones environment on AWS infrastructure, choose one of the following installation options:

Installing a cluster to quickly extend workers to edge compute pools, where the installation program automatically creates resources for the OpenShift Container Platform cluster.
Installing a cluster on AWS into an existing VPC, where you must add Local Zone subnets to the install-config.yaml file.

Next steps

Choose one of the following options to install an OpenShift Container Platform cluster in an AWS Local Zones environment:

13.9. Install a cluster quickly in AWS Local Zones
Link kopieren

For OpenShift Container Platform 4.14, you can quickly install a cluster on Amazon Web Services (AWS) to extend compute nodes to Local Zone locations. By using this installation route, the installation program automatically creates network resources and Local Zone subnets for each Local Zone that you defined in your configuration file. To customize the installation, you must modify parameters in the install-config.yaml file before you deploy the cluster.

13.9.1. Modifying an installation configuration file to use AWS Local Zones
Link kopieren

Modify an install-config.yaml file to include AWS Local Zones.

Prerequisites

You have configured an AWS account.
You added your AWS keys and region to your local AWS profile by running aws configure.
You have read the configuration limitations that apply when you specify the installation program to automatically create subnets for your OpenShift Container Platform cluster. See the section named "Cluster limitations in AWS Local Zones".
You opted in to the Local Zone group for each zone.
You created an install-config.yaml file by using the procedure "Creating the installation configuration file".

Procedure

Modify the install-config.yaml file by specifying Local Zone names in the platform.aws.zones property of the edge compute pool. For example:

...
platform:
  aws:
    region: <region_name> 
compute:
- name: edge
  platform:
    aws:
      zones: 
      - <local_zone_name>
#...

...
platform:
  aws:
    region: <region_name>

1


compute:
- name: edge
  platform:
    aws:
      zones:

2


      - <local_zone_name>
#...

Copy to Clipboard

Toggle word wrap

1: The AWS Region name.
2: The list of Local Zone names that must belong in the same AWS Region.

Example of a configuration to install a cluster in the us-west-2 AWS Region that extends edge nodes to Local Zones in Los Angeles and Las Vegas locations.

apiVersion: v1
baseDomain: example.com
metadata:
  name: cluster-name
platform:
  aws:
    region: us-west-2
compute:
- name: edge
  platform:
    aws:
      zones:
      - us-west-2-lax-1a
      - us-west-2-lax-1b
      - us-west-2-las-1a
pullSecret: '{"auths": ...}'
sshKey: 'ssh-ed25519 AAAA...'
#...

apiVersion: v1
baseDomain: example.com
metadata:
  name: cluster-name
platform:
  aws:
    region: us-west-2
compute:
- name: edge
  platform:
    aws:
      zones:
      - us-west-2-lax-1a
      - us-west-2-lax-1b
      - us-west-2-las-1a
pullSecret: '{"auths": ...}'
sshKey: 'ssh-ed25519 AAAA...'
#...

Copy to Clipboard

Toggle word wrap

Deploy your cluster.

Next steps

Deploying the cluster

13.10. Installing a cluster in an existing VPC that has Local Zone subnets
Link kopieren

You can install a cluster into an existing Amazon Virtual Private Cloud (VPC) on Amazon Web Services (AWS). The installation program provisions the rest of the required infrastructure, which you can further customize. To customize the installation, modify parameters in the install-config.yaml file before you install the cluster.

Installing a cluster on AWS into an existing VPC requires extending workers to the edge of the Cloud Infrastructure by using AWS Local Zones.

Local Zone subnets extend regular workers' nodes to edge networks. Each edge worker nodes runs a user workload. After you create an Amazon Web Service (AWS) Local Zone environment, and you deploy your cluster, you can use edge worker nodes to create user workloads in Local Zone subnets.

You can use a provided CloudFormation template to create the VPC and public subnets. Additionally, you can modify a template to customize your infrastructure or use the information that they contain to create AWS objects according to your company’s policies.

Note

If you want to create private subnets, you must either modify the provided CloudFormation template or create your own template.

13.10.1. Creating a VPC in AWS
Link kopieren

You can create a Virtual Private Cloud (VPC), and subnets for each Local Zone location, in Amazon Web Services (AWS) for your OpenShift Container Platform cluster to extend worker nodes to the edge locations. You can further customize the VPC to meet your requirements, including VPN, route tables, and add new Local Zone subnets that are not included at initial deployment.

You can use the provided CloudFormation template and a custom parameter file to create a stack of AWS resources that represent the VPC.

Note

If you do not use the provided CloudFormation template to create your AWS infrastructure, you must review the provided information and manually create the infrastructure. If your cluster does not initialize correctly, you might have to contact Red Hat support with your installation logs.

Prerequisites

You configured an AWS account.
You added your AWS keys and region to your local AWS profile by running aws configure.
You opted in to the AWS Local Zones on your AWS account.

Procedure

Create a JSON file that contains the parameter values that the template requires:

[
  {
    "ParameterKey": "VpcCidr", 
    "ParameterValue": "10.0.0.0/16" 
  },
  {
    "ParameterKey": "AvailabilityZoneCount", 
    "ParameterValue": "3" 
  },
  {
    "ParameterKey": "SubnetBits", 
    "ParameterValue": "12" 
  }
]

[
  {
    "ParameterKey": "VpcCidr",

1


    "ParameterValue": "10.0.0.0/16"

2


  },
  {
    "ParameterKey": "AvailabilityZoneCount",

3


    "ParameterValue": "3"

4


  },
  {
    "ParameterKey": "SubnetBits",

5


    "ParameterValue": "12"

6

}
]

Copy to Clipboard

Toggle word wrap

1: The CIDR block for the VPC.
2: Specify a CIDR block in the format x.x.x.x/16-24.
3: The number of availability zones to deploy the VPC in.
4: Specify an integer between 1 and 3.
5: The size of each subnet in each availability zone.
6: Specify an integer between 5 and 13, where 5 is /27 and 13 is /19.

Copy the template from the CloudFormation template for the VPC section of this topic and save it as a YAML file on your computer. This template describes the VPC that your cluster requires.
Launch the CloudFormation template to create a stack of AWS resources that represent the VPC by running the following command:
Important
You must enter the command on a single line.
```
aws cloudformation create-stack --stack-name <name> \
     --template-body file://<template>.yaml \
     --parameters file://<parameters>.json
```
```
$ aws cloudformation create-stack --stack-name <name> \  
```
1
```
     --template-body file://<template>.yaml \  
```
2
```
     --parameters file://<parameters>.json  
```
3
Copy to Clipboard Toggle word wrap
1
<name> is the name for the CloudFormation stack, such as cluster-vpc. You need the name of this stack if you remove the cluster.
2
<template> is the relative path to and name of the CloudFormation template YAML file that you saved.
3
<parameters> is the relative path to and name of the CloudFormation parameters JSON file.
Example output
```
arn:aws:cloudformation:us-east-1:123456789012:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f
```
```
arn:aws:cloudformation:us-east-1:123456789012:stack/cluster-vpc/dbedae40-2fd3-11eb-820e-12a48460849f
```
Copy to Clipboard Toggle word wrap

Confirm that the template components exist by running the following command:

aws cloudformation describe-stacks --stack-name <name>

$ aws cloudformation describe-stacks --stack-name <name>

Copy to Clipboard

Toggle word wrap

After the StackStatus displays CREATE_COMPLETE, the output displays values for the following parameters. You must provide these parameter values to the other CloudFormation templates that you run to create your cluster:

`VpcId`	The ID of your VPC.
`PublicSubnetIds`	The IDs of the new public subnets.
`PrivateSubnetIds`	The IDs of the new private subnets.
`PublicRouteTableId`	The ID of the new public route table ID.

13.10.2. Creating a subnet in AWS Local Zones
Link kopieren

You must create a subnet in AWS Local Zones before you configure a worker machineset for your OpenShift Container Platform cluster.

You must repeat the following process for each Local Zone you want to deploy worker nodes to.

You can use the provided CloudFormation template and a custom parameter file to create a stack of AWS resources that represent the subnet.

Note

If you do not use the provided CloudFormation template to create your AWS infrastructure, you must review the provided information and manually create the infrastructure. If your cluster does not initialize correctly, you might have to contact Red Hat support with your installation logs.

Prerequisites

You configured an AWS account.
You added your AWS keys and region to your local AWS profile by running aws configure.
You opted in to the Local Zone group.

Procedure

Create a JSON file that contains the parameter values that the template requires:

[
  {
    "ParameterKey": "VpcId",
    "ParameterValue": "<value_of_VpcId>" 
  },
  {
    "ParameterKey": "PublicRouteTableId",
    "ParameterValue": "<value_of_PublicRouteTableId>" 
  },
  {
    "ParameterKey": "ZoneName",
    "ParameterValue": "<value_of_ZoneName>" 
  },
  {
    "ParameterKey": "SubnetName",
    "ParameterValue": "<value_of_SubnetName>"
  },
  {
    "ParameterKey": "PublicSubnetCidr",
    "ParameterValue": "10.0.192.0/20" 
  }
]

[
  {
    "ParameterKey": "VpcId",
    "ParameterValue": "<value_of_VpcId>"

1


  },
  {
    "ParameterKey": "PublicRouteTableId",
    "ParameterValue": "<value_of_PublicRouteTableId>"

2


  },
  {
    "ParameterKey": "ZoneName",
    "ParameterValue": "<value_of_ZoneName>"

3


  },
  {
    "ParameterKey": "SubnetName",
    "ParameterValue": "<value_of_SubnetName>"
  },
  {
    "ParameterKey": "PublicSubnetCidr",
    "ParameterValue": "10.0.192.0/20"

4

}
]

Copy to Clipboard

Toggle word wrap

1: Specify the VPC ID, which is the value VpcID in the output of the CloudFormation template. for the VPC.
2: Specify the Route Table ID, which is the value of the PublicRouteTableId in the CloudFormation stack for the VPC.
3: Specify the AWS Local Zone name, which is the value of the ZoneName field in the AvailabilityZones object that you retrieve in the section "Opting in to AWS Local Zones".
4: Specify a CIDR block that is used to create the Local Zone subnet. This block must be part of the VPC CIDR block VpcCidr.

Copy the template from the CloudFormation template for the subnet section of this topic and save it as a YAML file on your computer. This template describes the VPC that your cluster requires.
Launch the CloudFormation template to create a stack of AWS resources that represent the VPC by running the following command:
Important
You must enter the command on a single line.
```
aws cloudformation create-stack --stack-name <subnet_stack_name> \
     --template-body file://<template>.yaml \
     --parameters file://<parameters>.json
```
```
$ aws cloudformation create-stack --stack-name <subnet_stack_name> \ 
```
1
```
     --template-body file://<template>.yaml \ 
```
2
```
     --parameters file://<parameters>.json 
```
3
Copy to Clipboard Toggle word wrap
1
<subnet_stack_name> is the name for the CloudFormation stack, such as cluster-lz-<local_zone_shortname>. You need the name of this stack if you remove the cluster.
2
<template> is the relative path to and name of the CloudFormation template YAML file that you saved.
3
<parameters> is the relative path to and name of the CloudFormation parameters JSON file.
Example output
```
arn:aws:cloudformation:us-east-1:123456789012:stack/<subnet_stack_name>/dbedae40-2fd3-11eb-820e-12a48460849f
```
```
arn:aws:cloudformation:us-east-1:123456789012:stack/<subnet_stack_name>/dbedae40-2fd3-11eb-820e-12a48460849f
```
Copy to Clipboard Toggle word wrap
Confirm that the template components exist by running the following command:
```
aws cloudformation describe-stacks --stack-name <subnet_stack_name>
```
```
$ aws cloudformation describe-stacks --stack-name <subnet_stack_name>
```
Copy to Clipboard Toggle word wrap
After the StackStatus displays CREATE_COMPLETE, the output displays values for the following parameters. You must provide these parameter values to the other CloudFormation templates that you run to create your cluster:

PublicSubnetIds

The IDs of the new public subnets.

13.10.3. CloudFormation template for the VPC
Link kopieren

You can use the following CloudFormation template to deploy the VPC that you need for your OpenShift Container Platform cluster.

Example 13.2. CloudFormation template for the VPC

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice VPC with 1-3 AZs

Parameters:
  VpcCidr:
    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.0.0/16
    Description: CIDR block for VPC.
    Type: String
  AvailabilityZoneCount:
    ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)"
    MinValue: 1
    MaxValue: 3
    Default: 1
    Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)"
    Type: Number
  SubnetBits:
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27.
    MinValue: 5
    MaxValue: 13
    Default: 12
    Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)"
    Type: Number

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcCidr
      - SubnetBits
    - Label:
        default: "Availability Zones"
      Parameters:
      - AvailabilityZoneCount
    ParameterLabels:
      AvailabilityZoneCount:
        default: "Availability Zone Count"
      VpcCidr:
        default: "VPC CIDR"
      SubnetBits:
        default: "Bits Per Subnet"

Conditions:
  DoAz3: !Equals [3, !Ref AvailabilityZoneCount]
  DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3]

Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      EnableDnsSupport: "true"
      EnableDnsHostnames: "true"
      CidrBlock: !Ref VpcCidr
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
  GatewayToInternet:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway
  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: GatewayToInternet
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation3:
    Condition: DoAz3
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet3
      RouteTableId: !Ref PublicRouteTable
  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable
  NAT:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP
        - AllocationId
      SubnetId: !Ref PublicSubnet
  EIP:
    Type: "AWS::EC2::EIP"
    Properties:
      Domain: vpc
  Route:
    Type: "AWS::EC2::Route"
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable2:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PrivateSubnet2
      RouteTableId: !Ref PrivateRouteTable2
  NAT2:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz2
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP2
        - AllocationId
      SubnetId: !Ref PublicSubnet2
  EIP2:
    Type: "AWS::EC2::EIP"
    Condition: DoAz2
    Properties:
      Domain: vpc
  Route2:
    Type: "AWS::EC2::Route"
    Condition: DoAz2
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable2
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT2
  PrivateSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable3:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation3:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz3
    Properties:
      SubnetId: !Ref PrivateSubnet3
      RouteTableId: !Ref PrivateRouteTable3
  NAT3:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz3
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP3
        - AllocationId
      SubnetId: !Ref PublicSubnet3
  EIP3:
    Type: "AWS::EC2::EIP"
    Condition: DoAz3
    Properties:
      Domain: vpc
  Route3:
    Type: "AWS::EC2::Route"
    Condition: DoAz3
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable3
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT3
  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      - !Ref PrivateRouteTable
      - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"]
      - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"]
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VPC

Outputs:
  VpcId:
    Description: ID of the new VPC.
    Value: !Ref VPC
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join [
        ",",
        [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]]
      ]
  PrivateSubnetIds:
    Description: Subnet IDs of the private subnets.
    Value:
      !Join [
        ",",
        [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]]
      ]
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable

AWSTemplateFormatVersion: 2010-09-09
Description: Template for Best Practice VPC with 1-3 AZs

Parameters:
  VpcCidr:
    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.0.0/16
    Description: CIDR block for VPC.
    Type: String
  AvailabilityZoneCount:
    ConstraintDescription: "The number of availability zones. (Min: 1, Max: 3)"
    MinValue: 1
    MaxValue: 3
    Default: 1
    Description: "How many AZs to create VPC subnets for. (Min: 1, Max: 3)"
    Type: Number
  SubnetBits:
    ConstraintDescription: CIDR block parameter must be in the form x.x.x.x/19-27.
    MinValue: 5
    MaxValue: 13
    Default: 12
    Description: "Size of each subnet to create within the availability zones. (Min: 5 = /27, Max: 13 = /19)"
    Type: Number

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
    - Label:
        default: "Network Configuration"
      Parameters:
      - VpcCidr
      - SubnetBits
    - Label:
        default: "Availability Zones"
      Parameters:
      - AvailabilityZoneCount
    ParameterLabels:
      AvailabilityZoneCount:
        default: "Availability Zone Count"
      VpcCidr:
        default: "VPC CIDR"
      SubnetBits:
        default: "Bits Per Subnet"

Conditions:
  DoAz3: !Equals [3, !Ref AvailabilityZoneCount]
  DoAz2: !Or [!Equals [2, !Ref AvailabilityZoneCount], Condition: DoAz3]

Resources:
  VPC:
    Type: "AWS::EC2::VPC"
    Properties:
      EnableDnsSupport: "true"
      EnableDnsHostnames: "true"
      CidrBlock: !Ref VpcCidr
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PublicSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [2, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
  GatewayToInternet:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway
  PublicRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PublicRoute:
    Type: "AWS::EC2::Route"
    DependsOn: GatewayToInternet
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicRouteTable
  PublicSubnetRouteTableAssociation3:
    Condition: DoAz3
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet3
      RouteTableId: !Ref PublicRouteTable
  PrivateSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [3, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 0
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable:
    Type: "AWS::EC2::RouteTable"
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref PrivateRouteTable
  NAT:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP
        - AllocationId
      SubnetId: !Ref PublicSubnet
  EIP:
    Type: "AWS::EC2::EIP"
    Properties:
      Domain: vpc
  Route:
    Type: "AWS::EC2::Route"
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT
  PrivateSubnet2:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [4, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 1
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable2:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz2
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation2:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz2
    Properties:
      SubnetId: !Ref PrivateSubnet2
      RouteTableId: !Ref PrivateRouteTable2
  NAT2:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz2
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP2
        - AllocationId
      SubnetId: !Ref PublicSubnet2
  EIP2:
    Type: "AWS::EC2::EIP"
    Condition: DoAz2
    Properties:
      Domain: vpc
  Route2:
    Type: "AWS::EC2::Route"
    Condition: DoAz2
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable2
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT2
  PrivateSubnet3:
    Type: "AWS::EC2::Subnet"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [5, !Cidr [!Ref VpcCidr, 6, !Ref SubnetBits]]
      AvailabilityZone: !Select
      - 2
      - Fn::GetAZs: !Ref "AWS::Region"
  PrivateRouteTable3:
    Type: "AWS::EC2::RouteTable"
    Condition: DoAz3
    Properties:
      VpcId: !Ref VPC
  PrivateSubnetRouteTableAssociation3:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Condition: DoAz3
    Properties:
      SubnetId: !Ref PrivateSubnet3
      RouteTableId: !Ref PrivateRouteTable3
  NAT3:
    DependsOn:
    - GatewayToInternet
    Type: "AWS::EC2::NatGateway"
    Condition: DoAz3
    Properties:
      AllocationId:
        "Fn::GetAtt":
        - EIP3
        - AllocationId
      SubnetId: !Ref PublicSubnet3
  EIP3:
    Type: "AWS::EC2::EIP"
    Condition: DoAz3
    Properties:
      Domain: vpc
  Route3:
    Type: "AWS::EC2::Route"
    Condition: DoAz3
    Properties:
      RouteTableId:
        Ref: PrivateRouteTable3
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId:
        Ref: NAT3
  S3Endpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
        - Effect: Allow
          Principal: '*'
          Action:
          - '*'
          Resource:
          - '*'
      RouteTableIds:
      - !Ref PublicRouteTable
      - !Ref PrivateRouteTable
      - !If [DoAz2, !Ref PrivateRouteTable2, !Ref "AWS::NoValue"]
      - !If [DoAz3, !Ref PrivateRouteTable3, !Ref "AWS::NoValue"]
      ServiceName: !Join
      - ''
      - - com.amazonaws.
        - !Ref 'AWS::Region'
        - .s3
      VpcId: !Ref VPC

Outputs:
  VpcId:
    Description: ID of the new VPC.
    Value: !Ref VPC
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join [
        ",",
        [!Ref PublicSubnet, !If [DoAz2, !Ref PublicSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PublicSubnet3, !Ref "AWS::NoValue"]]
      ]
  PrivateSubnetIds:
    Description: Subnet IDs of the private subnets.
    Value:
      !Join [
        ",",
        [!Ref PrivateSubnet, !If [DoAz2, !Ref PrivateSubnet2, !Ref "AWS::NoValue"], !If [DoAz3, !Ref PrivateSubnet3, !Ref "AWS::NoValue"]]
      ]
  PublicRouteTableId:
    Description: Public Route table ID
    Value: !Ref PublicRouteTable

Copy to Clipboard

Toggle word wrap

13.10.4. AWS security groups
Link kopieren

By default, the installation program creates and attaches security groups to control plane and compute machines. The rules associated with the default security groups cannot be modified.

However, you can apply additional existing AWS security groups, which are associated with your existing VPC, to control plane and compute machines. Applying custom security groups can help you meet the security needs of your organization, in such cases where you need to control the incoming or outgoing traffic of these machines.

As part of the installation process, you apply custom security groups by modifying the install-config.yaml file before deploying the cluster.

For more information, see "Edge compute pools and AWS Local Zones".

13.10.5. CloudFormation template for the subnet that uses AWS Local Zones
Link kopieren

You can use the following CloudFormation template to deploy the subnet that you need for your OpenShift Container Platform cluster that uses AWS Local Zones.

Example 13.3. CloudFormation template for the subnet

# CloudFormation template used to create Local Zone subnets and dependencies
AWSTemplateFormatVersion: 2010-09-09
Description: Template for create Public Local Zone subnets

Parameters:
  VpcId:
    Description: VPC Id
    Type: String
  ZoneName:
    Description: Local Zone Name (Example us-east-1-nyc-1a)
    Type: String
  SubnetName:
    Description: Local Zone Name (Example cluster-public-us-east-1-nyc-1a)
    Type: String
  PublicRouteTableId:
    Description: Public Route Table ID to associate the Local Zone subnet
    Type: String
  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

Resources:
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PublicSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Ref SubnetName
      - Key: kubernetes.io/cluster/unmanaged
        Value: "true"

  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTableId

Outputs:
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join ["", [!Ref PublicSubnet]]

# CloudFormation template used to create Local Zone subnets and dependencies
AWSTemplateFormatVersion: 2010-09-09
Description: Template for create Public Local Zone subnets

Parameters:
  VpcId:
    Description: VPC Id
    Type: String
  ZoneName:
    Description: Local Zone Name (Example us-east-1-nyc-1a)
    Type: String
  SubnetName:
    Description: Local Zone Name (Example cluster-public-us-east-1-nyc-1a)
    Type: String
  PublicRouteTableId:
    Description: Public Route Table ID to associate the Local Zone subnet
    Type: String
  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

Resources:
  PublicSubnet:
    Type: "AWS::EC2::Subnet"
    Properties:
      VpcId: !Ref VpcId
      CidrBlock: !Ref PublicSubnetCidr
      AvailabilityZone: !Ref ZoneName
      Tags:
      - Key: Name
        Value: !Ref SubnetName
      - Key: kubernetes.io/cluster/unmanaged
        Value: "true"

  PublicSubnetRouteTableAssociation:
    Type: "AWS::EC2::SubnetRouteTableAssociation"
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTableId

Outputs:
  PublicSubnetIds:
    Description: Subnet IDs of the public subnets.
    Value:
      !Join ["", [!Ref PublicSubnet]]

Copy to Clipboard

Toggle word wrap

13.10.6. Modifying an installation configuration file to use AWS Local Zones subnets
Link kopieren

Modify an install-config.yaml file to include AWS Local Zones subnets.

Prerequisites

You created subnets by using the procedure "Creating a subnet in AWS Local Zones".
You created an install-config.yaml file by using the procedure "Creating the installation configuration file".

Procedure

Modify the install-config.yaml configuration file by specifying Local Zone subnets in the platform.aws.subnets property, as demonstrated in the following example:

...
platform:
  aws:
    region: us-west-2
    subnets: 
    - publicSubnetId-1
    - publicSubnetId-2
    - publicSubnetId-3
    - privateSubnetId-1
    - privateSubnetId-2
    - privateSubnetId-3
    - publicSubnetId-LocalZone-1
...

...
platform:
  aws:
    region: us-west-2
    subnets:

1


    - publicSubnetId-1
    - publicSubnetId-2
    - publicSubnetId-3
    - privateSubnetId-1
    - privateSubnetId-2
    - privateSubnetId-3
    - publicSubnetId-LocalZone-1
...

Copy to Clipboard

Toggle word wrap

1: List of subnets created in the Availability and Local Zones.

13.11. Deploying the cluster
Link kopieren

You can install OpenShift Container Platform on a compatible cloud platform.

Important

You can run the create cluster command of the installation program only once, during initial installation.

Prerequisites

You have configured an account with the cloud platform that hosts your cluster.
You have the OpenShift Container Platform installation program and the pull secret for your cluster.
You have verified that the cloud provider account on your host has the correct permissions to deploy the cluster. An account with incorrect permissions causes the installation process to fail with an error message that displays the missing permissions.

Procedure

Change to the directory that contains the installation program and initialize the cluster deployment:
```
./openshift-install create cluster --dir <installation_directory> \
    --log-level=info
```
```
$ ./openshift-install create cluster --dir <installation_directory> \ 
```
1
```
    --log-level=info 
```
2
Copy to Clipboard Toggle word wrap
1
For <installation_directory>, specify the location of your customized ./install-config.yaml file.
2
To view different installation details, specify warn, debug, or error instead of info.
Optional: Remove or disable the AdministratorAccess policy from the IAM account that you used to install the cluster.
Note
The elevated permissions provided by the AdministratorAccess policy are required only during installation.

Verification

When the cluster deployment completes successfully:

The terminal displays directions for accessing your cluster, including a link to the web console and credentials for the kubeadmin user.
Credential information also outputs to <installation_directory>/.openshift_install.log.

Important

Do not delete the installation program or the files that the installation program creates. Both are required to delete the cluster.

Example output

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s

Copy to Clipboard

Toggle word wrap

Important

The Ignition config files that the installation program generates contain certificates that expire after 24 hours, which are then renewed at that time. If the cluster is shut down before renewing the certificates and the cluster is later restarted after the 24 hours have elapsed, the cluster automatically recovers the expired certificates. The exception is that you must manually approve the pending node-bootstrapper certificate signing requests (CSRs) to recover kubelet certificates. See the documentation for Recovering from expired control plane certificates for more information.
It is recommended that you use Ignition config files within 12 hours after they are generated because the 24-hour certificate rotates from 16 to 22 hours after the cluster is installed. By using the Ignition config files within 12 hours, you can avoid installation failure if the certificate update runs during installation.

Next steps

Creating user workloads in AWS Local Zones

13.12. Logging in to the cluster by using the CLI
Link kopieren

You can log in to your cluster as a default system user by exporting the cluster kubeconfig file. The kubeconfig file contains information about the cluster that is used by the CLI to connect a client to the correct cluster and API server. The file is specific to a cluster and is created during OpenShift Container Platform installation.

Prerequisites

You deployed an OpenShift Container Platform cluster.
You installed the oc CLI.

Procedure

Export the kubeadmin credentials:
```
export KUBECONFIG=<installation_directory>/auth/kubeconfig
```
```
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
```
1
Copy to Clipboard Toggle word wrap
1
For <installation_directory>, specify the path to the directory that you stored the installation files in.
Verify you can run oc commands successfully using the exported configuration:
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
Example output
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

/validating-an-installation.adoc

13.13. Logging in to the cluster by using the web console
Link kopieren

The kubeadmin user exists by default after an OpenShift Container Platform installation. You can log in to your cluster as the kubeadmin user by using the OpenShift Container Platform web console.

Prerequisites

You have access to the installation host.
You completed a cluster installation and all cluster Operators are available.

Procedure

Obtain the password for the kubeadmin user from the kubeadmin-password file on the installation host:
```
cat <installation_directory>/auth/kubeadmin-password
```
```
$ cat <installation_directory>/auth/kubeadmin-password
```
Copy to Clipboard Toggle word wrap
Note
Alternatively, you can obtain the kubeadmin password from the <installation_directory>/.openshift_install.log log file on the installation host.

List the OpenShift Container Platform web console route:

oc get routes -n openshift-console | grep 'console-openshift'

$ oc get routes -n openshift-console | grep 'console-openshift'

Copy to Clipboard

Toggle word wrap

Note

Alternatively, you can obtain the OpenShift Container Platform route from the <installation_directory>/.openshift_install.log log file on the installation host.

Example output

console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

console     console-openshift-console.apps.<cluster_name>.<base_domain>            console     https   reencrypt/Redirect   None

Copy to Clipboard

Toggle word wrap

Navigate to the route detailed in the output of the preceding command in a web browser and log in as the kubeadmin user.

13.14. Verifying nodes that were created with edge compute pool
Link kopieren

After you install a cluster that uses AWS Local Zones, check the status of the machine that was created by the machine set manifests created at install time.

To check the machine sets created from the subnet you added to the install-config.yaml file, run the following command:

oc get machineset -n openshift-machine-api

$ oc get machineset -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Example output

NAME                                  DESIRED   CURRENT   READY   AVAILABLE   AGE
cluster-7xw5g-edge-us-east-1-nyc-1a   1         1         1       1           3h4m
cluster-7xw5g-worker-us-east-1a       1         1         1       1           3h4m
cluster-7xw5g-worker-us-east-1b       1         1         1       1           3h4m
cluster-7xw5g-worker-us-east-1c       1         1         1       1           3h4m

NAME                                  DESIRED   CURRENT   READY   AVAILABLE   AGE
cluster-7xw5g-edge-us-east-1-nyc-1a   1         1         1       1           3h4m
cluster-7xw5g-worker-us-east-1a       1         1         1       1           3h4m
cluster-7xw5g-worker-us-east-1b       1         1         1       1           3h4m
cluster-7xw5g-worker-us-east-1c       1         1         1       1           3h4m

Copy to Clipboard

Toggle word wrap

To check the machines that were created from the machine sets, run the following command:

oc get machines -n openshift-machine-api

$ oc get machines -n openshift-machine-api

Copy to Clipboard

Toggle word wrap

Example output

NAME                                        PHASE     TYPE          REGION      ZONE               AGE
cluster-7xw5g-edge-us-east-1-nyc-1a-wbclh   Running   c5d.2xlarge   us-east-1   us-east-1-nyc-1a   3h
cluster-7xw5g-master-0                      Running   m6i.xlarge    us-east-1   us-east-1a         3h4m
cluster-7xw5g-master-1                      Running   m6i.xlarge    us-east-1   us-east-1b         3h4m
cluster-7xw5g-master-2                      Running   m6i.xlarge    us-east-1   us-east-1c         3h4m
cluster-7xw5g-worker-us-east-1a-rtp45       Running   m6i.xlarge    us-east-1   us-east-1a         3h
cluster-7xw5g-worker-us-east-1b-glm7c       Running   m6i.xlarge    us-east-1   us-east-1b         3h
cluster-7xw5g-worker-us-east-1c-qfvz4       Running   m6i.xlarge    us-east-1   us-east-1c         3h

NAME                                        PHASE     TYPE          REGION      ZONE               AGE
cluster-7xw5g-edge-us-east-1-nyc-1a-wbclh   Running   c5d.2xlarge   us-east-1   us-east-1-nyc-1a   3h
cluster-7xw5g-master-0                      Running   m6i.xlarge    us-east-1   us-east-1a         3h4m
cluster-7xw5g-master-1                      Running   m6i.xlarge    us-east-1   us-east-1b         3h4m
cluster-7xw5g-master-2                      Running   m6i.xlarge    us-east-1   us-east-1c         3h4m
cluster-7xw5g-worker-us-east-1a-rtp45       Running   m6i.xlarge    us-east-1   us-east-1a         3h
cluster-7xw5g-worker-us-east-1b-glm7c       Running   m6i.xlarge    us-east-1   us-east-1b         3h
cluster-7xw5g-worker-us-east-1c-qfvz4       Running   m6i.xlarge    us-east-1   us-east-1c         3h

Copy to Clipboard

Toggle word wrap

To check nodes with edge roles, run the following command:

oc get nodes -l node-role.kubernetes.io/edge

$ oc get nodes -l node-role.kubernetes.io/edge

Copy to Clipboard

Toggle word wrap

Example output

NAME                           STATUS   ROLES         AGE    VERSION
ip-10-0-207-188.ec2.internal   Ready    edge,worker   172m   v1.25.2+d2e245f

NAME                           STATUS   ROLES         AGE    VERSION
ip-10-0-207-188.ec2.internal   Ready    edge,worker   172m   v1.25.2+d2e245f

Copy to Clipboard

Toggle word wrap

13.15. Telemetry access for OpenShift Container Platform
Link kopieren

In OpenShift Container Platform 4.14, the Telemetry service, which runs by default to provide metrics about cluster health and the success of updates, requires internet access. If your cluster is connected to the internet, Telemetry runs automatically, and your cluster is registered to OpenShift Cluster Manager.

After you confirm that your OpenShift Cluster Manager inventory is correct, either maintained automatically by Telemetry or manually by using OpenShift Cluster Manager, use subscription watch to track your OpenShift Container Platform subscriptions at the account or multi-cluster level.

13.16. Next steps
Link kopieren

Creating user workloads in AWS Local Zones.
Validating an installation.
Customize your cluster.
If necessary, you can opt out of remote health reporting.

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

13.1. PrerequisitesLink kopierenLink in die Zwischenablage kopiert!

13.2. Cluster limitations in AWS Local ZonesLink kopierenLink in die Zwischenablage kopiert!

13.3. Internet access for OpenShift Container PlatformLink kopierenLink in die Zwischenablage kopiert!

13.4. Obtaining an AWS Marketplace imageLink kopierenLink in die Zwischenablage kopiert!

13.5. Installing the OpenShift CLI by downloading the binaryLink kopierenLink in die Zwischenablage kopiert!

Installing the OpenShift CLI on Linux

Installing the OpenShift CLI on Windows

Installing the OpenShift CLI on macOS

13.6. Preparing for the installationLink kopierenLink in die Zwischenablage kopiert!

13.6.1. Obtaining the installation programLink kopierenLink in die Zwischenablage kopiert!

13.6.2. Generating a key pair for cluster node SSH accessLink kopierenLink in die Zwischenablage kopiert!

13.6.3. Creating the installation files for AWSLink kopierenLink in die Zwischenablage kopiert!

13.6.4. Minimum resource requirements for cluster installationLink kopierenLink in die Zwischenablage kopiert!

13.6.5. Tested instance types for AWSLink kopierenLink in die Zwischenablage kopiert!

13.6.6. Creating the installation configuration fileLink kopierenLink in die Zwischenablage kopiert!

13.6.7. Edge compute pools and AWS Local ZonesLink kopierenLink in die Zwischenablage kopiert!

13.7. Opting in to AWS Local ZonesLink kopierenLink in die Zwischenablage kopiert!

13.8. Cluster installation options for an AWS Local Zones environmentLink kopierenLink in die Zwischenablage kopiert!

13.9. Install a cluster quickly in AWS Local ZonesLink kopierenLink in die Zwischenablage kopiert!

13.9.1. Modifying an installation configuration file to use AWS Local ZonesLink kopierenLink in die Zwischenablage kopiert!

13.10. Installing a cluster in an existing VPC that has Local Zone subnetsLink kopierenLink in die Zwischenablage kopiert!

13.10.1. Creating a VPC in AWSLink kopierenLink in die Zwischenablage kopiert!

13.10.2. Creating a subnet in AWS Local ZonesLink kopierenLink in die Zwischenablage kopiert!

13.10.3. CloudFormation template for the VPCLink kopierenLink in die Zwischenablage kopiert!

13.10.4. AWS security groupsLink kopierenLink in die Zwischenablage kopiert!

13.10.5. CloudFormation template for the subnet that uses AWS Local ZonesLink kopierenLink in die Zwischenablage kopiert!

13.10.6. Modifying an installation configuration file to use AWS Local Zones subnetsLink kopierenLink in die Zwischenablage kopiert!

13.11. Deploying the clusterLink kopierenLink in die Zwischenablage kopiert!

13.12. Logging in to the cluster by using the CLILink kopierenLink in die Zwischenablage kopiert!

13.13. Logging in to the cluster by using the web consoleLink kopierenLink in die Zwischenablage kopiert!

13.14. Verifying nodes that were created with edge compute poolLink kopierenLink in die Zwischenablage kopiert!

13.15. Telemetry access for OpenShift Container PlatformLink kopierenLink in die Zwischenablage kopiert!

13.16. Next stepsLink kopierenLink in die Zwischenablage kopiert!

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Mehr Inklusion in Open Source

Über Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

13.1. Prerequisites
Link kopieren

13.2. Cluster limitations in AWS Local Zones
Link kopieren

13.3. Internet access for OpenShift Container Platform
Link kopieren

13.4. Obtaining an AWS Marketplace image
Link kopieren

13.5. Installing the OpenShift CLI by downloading the binary
Link kopieren

13.6. Preparing for the installation
Link kopieren

13.6.1. Obtaining the installation program
Link kopieren

13.6.2. Generating a key pair for cluster node SSH access
Link kopieren

13.6.3. Creating the installation files for AWS
Link kopieren

13.6.4. Minimum resource requirements for cluster installation
Link kopieren

13.6.5. Tested instance types for AWS
Link kopieren

13.6.6. Creating the installation configuration file
Link kopieren

13.6.7. Edge compute pools and AWS Local Zones
Link kopieren

13.7. Opting in to AWS Local Zones
Link kopieren

13.8. Cluster installation options for an AWS Local Zones environment
Link kopieren

13.9. Install a cluster quickly in AWS Local Zones
Link kopieren

13.9.1. Modifying an installation configuration file to use AWS Local Zones
Link kopieren

13.10. Installing a cluster in an existing VPC that has Local Zone subnets
Link kopieren

13.10.1. Creating a VPC in AWS
Link kopieren

13.10.2. Creating a subnet in AWS Local Zones
Link kopieren

13.10.3. CloudFormation template for the VPC
Link kopieren

13.10.4. AWS security groups
Link kopieren

13.10.5. CloudFormation template for the subnet that uses AWS Local Zones
Link kopieren

13.10.6. Modifying an installation configuration file to use AWS Local Zones subnets
Link kopieren

13.11. Deploying the cluster
Link kopieren

13.12. Logging in to the cluster by using the CLI
Link kopieren

13.13. Logging in to the cluster by using the web console
Link kopieren

13.14. Verifying nodes that were created with edge compute pool
Link kopieren

13.15. Telemetry access for OpenShift Container Platform
Link kopieren

13.16. Next steps
Link kopieren