1. Documentation
×

Allocating Load Balancers to Specific Subnets

You can manage application traffic efficiently by allocating load balancers. Network administrators can allocate load balancers to customize deployments which can ensure optimal traffic distribution, high availability of applications, uninterrupted service, and network segmentation.

Allocating API and Ingress Load Balancers to Specific Subnets on AWS

You can control the network placement of OKD Load Balancers on AWS, including Load Balancers for the Ingress Controller, by explicitly defining your subnets from the virtual private cloud (VPC). You can then assign the subnets specific roles directly within the platform.aws.vpc.subnets section of the install-config.yaml file.

By using this method, you have granular control of subnets that are used for resources, such as the Ingress Controller and other cluster components.

Specifying AWS subnets for OpenShift API and ingress load balancers at installation

You can allocate API and ingress load balancers to specific subnets for the purposes of aligning security and networking policies with your organization requirements.

When defining entries for control plane load balancers in the subnets list, ensure that you adhere to the following pattern:

# ... (within platform.aws.vpc.subnets list)
      - id: subnet-0fcf8e0392f0910d6 # Public Subnet for External API LB
        roles:
        - type: ControlPlaneExternalLB
      - id: subnet-0fcf8e0392f0910d7 # Private Subnet for Internal API LB
        roles:
        - type: ControlPlaneInternalLB
# ...

For the default public Ingress Controller, any subnet assigned the IngressControllerLB role in your install-config.yaml file must be a public subnet. For example, the subnet must have a route table entry in AWS that directs outbound traffic to an internet gateway (IGW). Ensure you list all necessary subnets, public and private across the AZs, and assign them appropriate roles according to your cluster architecture.

Subnet IDs define the subnets in an existing VPC and can optionally specify their intended roles. If no roles are specified on any subnet, the subnet roles are decided automatically. In this case, the VPC must not contain any other non-cluster subnets without the kubernetes.io/cluster/<cluster-id> tag.

If roles are specified for subnets, each subnet must have at least one assigned role, and the ClusterNode, BootstrapNode, IngressControllerLB, ControlPlaneExternalLB, and ControlPlaneInternalLB roles must be assigned to at least one subnet. However, if the cluster scope is internal, ControlPlaneExternalLB is not required.

Prerequisites

  • An existing AWS virtual private cloud (VPC).

  • Pre-configured AWS subnets intended for use by the OKD cluster, with the following considerations:

    • You have a list of their subnet IDs (for example, subnet-0123456789abcdef0). These IDs will be used in the install-config.yaml file.

    • Use subnets spanning at least two availability zones (AZs) for high availability of load balancers and other critical components, like control planes.

    • You have sufficient available IP addresses within these subnets for all assigned roles.

    • The AWS configuration for these subnets, including network ACLs and security groups, must permit necessary traffic for all roles assigned to them. For subnets hosting an ingress controller, this typically includes TCP ports 80 and 443 from required sources.

  • You have the OKD installation program binary for your target OKD version.

  • You have an install-config.yaml file.

Procedure

  1. Generate the installation configuration file by using the OKD installation program by entering the following command:

    $ openshift-install create install-config --dir=<your_installation_directory>

  2. Use a text editor to open the install-config.yaml file.

  3. Define subnets and assign roles. You must define your VPC subnets and their designated roles under the platform.aws.vpc.subnets parameter. For each AWS subnet, create an entry by specifying an id and a list of roles. Each role is an object with a type key. To designate a subnet for the default Ingress Controller, assign a role with type: IngressControllerLB to the subnet.

    apiVersion: v1
baseDomain: example.com
metadata:
  name: my-cluster # Example cluster name
platform:
  aws:
    region: us-east-1
    vpc:
      subnets:
      - id: subnet-0fcf8e0392f0910d5 # Public Subnet in AZ us-east-1a
        roles:
        - type: IngressControllerLB
        - type: BootstrapNode
      - id: subnet-0xxxxxxxxxxxxxxza # Public Subnet in another AZ for HA
        roles:
        - type: IngressControllerLB
      - id: subnet-0fcf8e0392f0910d4 # Private Subnet in AZ us-east-1a
        roles:
        - type: ClusterNode
      - id: subnet-0yyyyyyyyyyyyyyzb # Private Subnet in another AZ for HA
        roles:
        - type: ClusterNode
      # Add other subnet IDs and their roles as needed for your cluster architecture
pullSecret: '...'
sshKey: '...'

    where:

    baseDomain

    Specifies the base domain.

    region

    Specifies the AWS region.

    vpc

    Specifies the VPC object under platform.aws contains the subnets list.

    subnets

    Specifies a list of all subnet objects that OpenShift will use. Each object defines a subnet id and its roles.

    id

    Specifies the AWS Subnet ID.

    type.IngressControllerLB

    Specifies the type: IngressControllerLB role specifically designates this subnet for the default Ingress Controller’s LoadBalancer. In private/internal cluster, the subnet with IngressControllerLB role must be private.

    type.ClusterNode

    Specifies the type: ClusterNode role designates this subnet for control plane and compute nodes. These are typically private subnets.

    pullSecret

    Specifies the pull secret.

    sshKey

    Specifies the SSH key.

  4. Save you changes to the install-config.yaml file.

  5. Install the cluster by running the following command:

    $ openshift-install create cluster --dir=<your_installation_directory>

    The installation program uses the subnet definitions and explicit role assignments from the platform.aws.vpc.subnets section of your install-config.yaml file to provision cluster resources. This includes placing the LoadBalancer of the Ingress Controller in the subnets you designated with the IngressControllerLB role.

    The role assignment mechanism within platform.aws.vpc.subnets, such as specifying types like IngressControllerLB, ClusterNode, ControlPlaneExternalLB, ControlPlaneInternalLB, BootstrapNode is the comprehensive way the installation program identifies suitable subnets for various cluster services and components.