mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-3467: Updated configuration-externalip.adoc for private cluster
This commit is contained in:
committed by
openshift-cherrypick-robot
parent
69732bbe0d
commit
141fbfb7de
@@ -46,9 +46,9 @@ The status of this Operator is General Availability for {aws-first}, {gcp-first}
|
||||
The Operator is available as a link:https://access.redhat.com/support/offerings/techpreview[Technology Preview] for {ibm-power-server-name}.
|
||||
====
|
||||
|
||||
The Cloud Controller Manager Operator manages and updates the cloud controller managers deployed on top of {product-title}. The Operator is based on the Kubebuilder framework and `controller-runtime` libraries. It is installed via the Cluster Version Operator (CVO).
|
||||
The Cloud Controller Manager Operator manages and updates the cloud controller managers deployed on top of {product-title}. The Operator is based on the Kubebuilder framework and `controller-runtime` libraries. You can install the Cloud Controller Manager Operator by using the Cluster Version Operator (CVO).
|
||||
|
||||
It contains the following components:
|
||||
The Cloud Controller Manager Operator includes the following components:
|
||||
|
||||
* Operator
|
||||
* Cloud configuration observer
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
[id="configuration-externalip_{context}"]
|
||||
= Configuration for ExternalIP
|
||||
|
||||
Use of an external IP address in {product-title} is governed by the following parameters in the `Network.config.openshift.io` custom resource (CR) that is named `cluster`:
|
||||
The following parameters in the `Network.config.openshift.io` custom resource (CR) govern the use of an external IP address in {product-title}:
|
||||
|
||||
* `spec.externalIP.autoAssignCIDRs` defines an IP address block used by the load balancer when choosing an external IP address for the service. {product-title} supports only a single IP address block for automatic assignment. This configuration requires less steps than manually assigning ExternalIPs to services, which requires managing the port space of a limited number of shared IP addresses. If you enable automatic assignment, a `Service` object with `spec.type=LoadBalancer` is allocated an external IP address.
|
||||
* `spec.externalIP.autoAssignCIDRs` defines an IP address block used by the load balancer when choosing an external IP address for the service. {product-title} supports only a single IP address block for automatic assignment. This configuration requires less steps than manually assigning ExternalIPs to services, which requires managing the port space of a limited number of shared IP addresses. If you enable automatic assignment, the Cloud Controller Manager Operator allocates an external IP address to a `Service` object with `spec.type=LoadBalancer` defind in its configuration.
|
||||
|
||||
* `spec.externalIP.policy` defines the permissible IP address blocks when manually specifying an IP address. {product-title} does not apply policy rules to IP address blocks that you defined in the `spec.externalIP.autoAssignCIDRs` parameter.
|
||||
|
||||
@@ -19,7 +19,7 @@ If routed correctly, external traffic from the configured external IP address bl
|
||||
As a cluster administrator, you must configure routing to externalIPs. You must also ensure that the IP address block you assign terminates at one or more nodes in your cluster. For more information, see link:https://kubernetes.io/docs/concepts/services-networking/service/#external-ips[Kubernetes External IPs].
|
||||
====
|
||||
|
||||
{product-title} supports both the automatic and manual assignment of IP addresses, where each address is guaranteed to be assigned to a maximum of one service. This configuration ensures that each service can expose its chosen ports regardless of the ports exposed by other services.
|
||||
{product-title} supports both automatic and manual IP address assignment. This support guarantees that each address gets assigned to a maximum of one service and that each service can expose its chosen ports regardless of the ports exposed by other services.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -56,3 +56,12 @@ status:
|
||||
- ip: 192.168.132.253
|
||||
# ...
|
||||
----
|
||||
|
||||
If you run a private cluster on a cloud-provider platform, you can change the publishing scope to `internal` for the load balancer of the Ingress Controller by running the following `patch` command:
|
||||
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc -n openshift-ingress-operator patch ingresscontrollers/ingress-controller-with-nlb --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"loadBalancer":{"scope":"Internal"}}}}'
|
||||
----
|
||||
|
||||
After you run this command, the Ingress Controller restricts access to routes for {product-title} applications to internal networks only.
|
||||
|
||||
@@ -99,7 +99,7 @@ ifdef::aws-china,aws-secret[]
|
||||
* You have uploaded a custom RHCOS AMI.
|
||||
endif::aws-china,aws-secret[]
|
||||
ifndef::ibm-cloud-restricted[]
|
||||
* You have an SSH public key on your local machine to provide to the installation program. The key will be used for SSH authentication onto your cluster nodes for debugging and disaster recovery.
|
||||
* You have an SSH public key on your local machine for use with the installation program. You can use the key for SSH authentication onto your cluster nodes for debugging and disaster recovery.
|
||||
endif::ibm-cloud-restricted[]
|
||||
* You have obtained the {product-title} installation program and the pull secret for your
|
||||
cluster.
|
||||
@@ -124,16 +124,10 @@ $ mkdir <installation_directory>
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
You must create a 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 {product-title} version.
|
||||
You must create a directory. Some installation assets, such as 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 {product-title} version.
|
||||
====
|
||||
|
||||
. Customize the sample `install-config.yaml` file template that is provided and save
|
||||
it in the `<installation_directory>`.
|
||||
. Customize the provided sample `install-config.yaml` file template and save the file in the `<installation_directory>`.
|
||||
ifdef::ibm-cloud-restricted[]
|
||||
+
|
||||
[NOTE]
|
||||
@@ -142,7 +136,7 @@ You must name this configuration file `install-config.yaml`.
|
||||
====
|
||||
+
|
||||
When customizing the sample template, be sure to provide the information that is required for an installation in a restricted network:
|
||||
|
||||
+
|
||||
.. Update the `pullSecret` value to contain the authentication information for your registry:
|
||||
+
|
||||
[source,yaml]
|
||||
@@ -150,10 +144,8 @@ When customizing the sample template, be sure to provide the information that is
|
||||
pullSecret: '{"auths":{"<mirror_host_name>:5000": {"auth": "<credentials>","email": "you@example.com"}}}'
|
||||
----
|
||||
+
|
||||
For `<mirror_host_name>`, specify the registry domain name
|
||||
that you specified in the certificate for your mirror registry, and for
|
||||
`<credentials>`, specify the base64-encoded user name and password for
|
||||
your mirror registry.
|
||||
For `<mirror_host_name>`, specify the registry domain name that you specified in the certificate for your mirror registry, and for `<credentials>`, specify the base64-encoded user name and password for your mirror registry.
|
||||
+
|
||||
.. Add the `additionalTrustBundle` parameter and value.
|
||||
+
|
||||
[source,yaml]
|
||||
@@ -165,6 +157,7 @@ additionalTrustBundle: |
|
||||
----
|
||||
+
|
||||
The value must be the contents of the certificate file that you used for your mirror registry. The certificate file can be an existing, trusted certificate authority, or the self-signed certificate that you generated for the mirror registry.
|
||||
+
|
||||
.. Define the network and subnets for the VPC to install the cluster in under the parent `platform.ibmcloud` field:
|
||||
+
|
||||
[source,yaml]
|
||||
@@ -175,6 +168,7 @@ computeSubnets: <compute_subnet>
|
||||
----
|
||||
+
|
||||
For `platform.ibmcloud.vpcName`, specify the name for the existing {ibm-cloud-title} Virtual Private Cloud (VPC) network. For `platform.ibmcloud.controlPlaneSubnets` and `platform.ibmcloud.computeSubnets`, specify the existing subnets to deploy the control plane machines and compute machines, respectively.
|
||||
+
|
||||
.. Add the image content resources, which resemble the following YAML excerpt:
|
||||
+
|
||||
[source,yaml]
|
||||
@@ -189,6 +183,7 @@ imageContentSources:
|
||||
----
|
||||
+
|
||||
For these values, use the `imageContentSourcePolicy.yaml` file that was created when you mirrored the registry.
|
||||
+
|
||||
.. If network restrictions limit the use of public endpoints to access the required {ibm-cloud-name} services, add the `serviceEndpoints` stanza to `platform.ibmcloud` to specify an alternate service endpoint.
|
||||
+
|
||||
[NOTE]
|
||||
@@ -219,6 +214,7 @@ serviceEndpoints:
|
||||
url: <global_tagging_alternate_endpoint_url>
|
||||
# ...
|
||||
----
|
||||
+
|
||||
.. Optional: Set the publishing strategy to `Internal`:
|
||||
+
|
||||
[source,yaml]
|
||||
@@ -244,10 +240,7 @@ endif::ibm-cloud-restricted[]
|
||||
|
||||
ifdef::restricted,restricted-upi[]
|
||||
|
||||
** Unless you use a registry that {op-system} trusts by default, such as
|
||||
`docker.io`, you must provide the contents of the certificate for your mirror
|
||||
repository in the `additionalTrustBundle` section. In most cases, you must
|
||||
provide the certificate for your mirror.
|
||||
** Unless you use a registry that {op-system} trusts by default, such as `docker.io`, you must provide the contents of the certificate for your mirror repository in the `additionalTrustBundle` section. In most cases, you must provide the certificate for your mirror.
|
||||
** You must include the `imageContentSources` section from the output of the command to
|
||||
mirror the repository.
|
||||
|
||||
@@ -315,11 +308,11 @@ ifdef::vsphere-upi-vsphere[]
|
||||
. If you are installing a three-node cluster, modify the `install-config.yaml` file by setting the `compute.replicas` parameter to `0`. This ensures that the cluster's control planes are schedulable. For more information, see "Installing a three-node cluster on {platform}".
|
||||
endif::vsphere-upi-vsphere[]
|
||||
|
||||
. Back up the `install-config.yaml` file so that you can use it to install multiple clusters.
|
||||
. Back up the `install-config.yaml` file so that you can use it to install many clusters.
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
The `install-config.yaml` file is consumed during the next step of the installation process. You must back it up now.
|
||||
Back up the `install-config.yaml` file now, because the installation process consumes the file in the next step.
|
||||
====
|
||||
|
||||
ifeval::["{context}" == "installing-azure-government-region"]
|
||||
|
||||
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
As a cluster administrator, you can designate an IP address block that is external to the cluster that can send traffic to services in the cluster.
|
||||
As a cluster administrator, you can select an IP address block that is external to the cluster that can send traffic to services in the cluster.
|
||||
|
||||
This functionality is generally most useful for clusters installed on bare-metal hardware.
|
||||
|
||||
@@ -17,13 +17,6 @@ This functionality is generally most useful for clusters installed on bare-metal
|
||||
// About ExternalIP
|
||||
include::modules/nw-externalip-about.adoc[leveloffset=+1]
|
||||
|
||||
[id="additional-resources_{context}"]
|
||||
== Additional resources
|
||||
|
||||
* xref:../../../networking/configuring_network_settings/configuring-ipfailover.adoc#configuring-ipfailover[Configuring IP failover]
|
||||
|
||||
* xref:../../../networking/networking_operators/metallb-operator/about-metallb.adoc#about-metallb[About MetalLB and the MetalLB Operator]
|
||||
|
||||
// Configuration for ExternalIP
|
||||
include::modules/configuration-externalip.adoc[leveloffset=+1]
|
||||
|
||||
@@ -39,6 +32,13 @@ include::modules/nw-externalip-object.adoc[leveloffset=+1]
|
||||
// Configure external IP address blocks for your cluster
|
||||
include::modules/nw-externalip-configuring.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
* xref:../../../networking/configuring_network_settings/configuring-ipfailover.adoc#configuring-ipfailover[Configuring IP failover]
|
||||
|
||||
* xref:../../../networking/networking_operators/metallb-operator/about-metallb.adoc#about-metallb[About MetalLB and the MetalLB Operator]
|
||||
|
||||
[id="configuring-externalip-next-steps"]
|
||||
== Next steps
|
||||
|
||||
|
||||
Reference in New Issue
Block a user