|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * installing/installing_vsphere/ipi/installing-vsphere-installer-provisioned-network-customizations.adoc |
| 4 | +// * installing/installing_vsphere/upi/installing-vsphere-network-customizations.adoc |
| 5 | + |
| 6 | +:_mod-docs-content-type: PROCEDURE |
| 7 | +[id="nw-operator-vsphere-multiple-subnets_{context}"] |
| 8 | += Specifying multiple subnets for your network |
| 9 | + |
| 10 | +Before you install an {product-title} cluster on a {vmw-short} host, you can specify multiple subnets for a networking implementation so that the {vmw-short} cloud controller manager (CCM) can select the appropriate subnet for a given networking situation. {vmw-short} can use the subnet for managing pods and services on your cluster. |
| 11 | + |
| 12 | +For this configuration, you must specify internal and external Classless Inter-Domain Routing (CIDR) implementations in the {vmw-short} CCM configuration. Each CIDR implementation lists an IP address range that the CCM uses to decide what subnets interact with traffic from internal and external networks. |
| 13 | + |
| 14 | +[IMPORTANT] |
| 15 | +==== |
| 16 | +Failure to configure internal and external CIDR implementations in the {vmw-short} CCM configuration can cause the {vmw-short} CCM to select the wrong subnet. This situation causes the following error: |
| 17 | +
|
| 18 | +---- |
| 19 | +ERROR Bootstrap failed to complete: timed out waiting for the condition |
| 20 | +ERROR Failed to wait for bootstrapping to complete. This error usually happens when there is a problem with control plane hosts that prevents the control plane operators from creating the control plane. |
| 21 | +---- |
| 22 | +
|
| 23 | +This configuration can cause new nodes that associate with a `MachineSet` object with a single subnet to become unusable as each new node receives the `node.cloudprovider.kubernetes.io/uninitialized` taint. These situations can cause communication issues with the Kubernetes API server that can cause installation of the cluster to fail. |
| 24 | +==== |
| 25 | + |
| 26 | +.Prerequisites |
| 27 | + |
| 28 | +* You created Kubernetes manifest files for your {product-title} cluster. |
| 29 | +
|
| 30 | +.Procedure |
| 31 | + |
| 32 | +. From the directory where you store your {product-title} cluster manifest files, open the `manifests/cluster-infrastructure-02-config.yml` manifest file. |
| 33 | + |
| 34 | +. Add a `nodeNetworking` object to the file and specify internal and external network subnet CIDR implementations for the object. |
| 35 | ++ |
| 36 | +[TIP] |
| 37 | +==== |
| 38 | +For most networking situations, consider setting the standard multiple-subnet configuration. This configuration requires that you set the same IP address ranges in the `nodeNetworking.internal.networkSubnetCidr` and `nodeNetworking.external.networkSubnetCidr` parameters. |
| 39 | +==== |
| 40 | ++ |
| 41 | +.Example of a configured `cluster-infrastructure-02-config.yml` manifest file |
| 42 | +[source,yaml] |
| 43 | +---- |
| 44 | +apiVersion: config.openshift.io/v1 |
| 45 | +kind: Infrastructure |
| 46 | +metadata: |
| 47 | + name: cluster |
| 48 | +spec: |
| 49 | + cloudConfig: |
| 50 | + key: config |
| 51 | + name: cloud-provider-config |
| 52 | + platformSpec: |
| 53 | + type: VSphere |
| 54 | + vsphere: |
| 55 | + failureDomains: |
| 56 | + - name: generated-failure-domain |
| 57 | + ... |
| 58 | + nodeNetworking: |
| 59 | + external: |
| 60 | + networkSubnetCidr: |
| 61 | + - <machine_network_cidr_ipv4> |
| 62 | + - <machine_network_cidr_ipv6> |
| 63 | + internal: |
| 64 | + networkSubnetCidr: |
| 65 | + - <machine_network_cidr_ipv4> |
| 66 | + - <machine_network_cidr_ipv6> |
| 67 | +# ... |
| 68 | +---- |
0 commit comments