Describe configuring an internal load balancer for cloud #16963
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,66 @@ | ||
| // Module included in the following assemblies: | ||
| // | ||
| // * networking/ingress-operator.adoc | ||
|
|
||
| [id="nw-ingress-setting-internal-lb_{context}"] | ||
| = Configuring an Ingress Controller to use an internal load balancer | ||
|
|
||
| When creating an Ingress Controller on cloud platforms, the Ingress Controller is published by a public cloud load balancer by default. | ||
| As an administrator, you can create an Ingress Controller that uses an internal cloud load balancer. | ||
|
|
||
| You can configure the `default` Ingress Controller for your cluster to be internal by deleting and recreating it. | ||
|
|
||
| [WARNING] | ||
| ==== | ||
| If your cloud provider is Azure, you must have at least one public load balancer that points to your nodes. | ||
| If you do not, all of your nodes will lose egress connectivity to the Internet. | ||
| ==== | ||
|
|
||
| [IMPORTANT] | ||
| ==== | ||
| If you want to change the `scope` for an `IngressController` object, you must delete and then recreate that `IngressController` object. You cannot change the `.spec.endpointPublishingStrategy.loadBalancer.scope` parameter after the Custom Resource (CR) is created. | ||
| ==== | ||
|
|
||
| See the link:https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer[Kubernetes Services documentation] | ||
| for implementation details. | ||
|
|
||
| .Prerequisites | ||
|
|
||
| * Install the OpenShift Command-line Interface (CLI), commonly known as `oc`. | ||
| * Log in as a user with `cluster-admin` privileges. | ||
|
|
||
| .Procedure | ||
|
|
||
| . Create an `IngressController` Custom Resource (CR) in a file named `<name>-ingress-controller.yaml`, such as in the following example: | ||
| + | ||
| [source,yaml] | ||
| ---- | ||
| apiVersion: operator.openshift.io/v1 | ||
| kind: IngressController | ||
| metadata: | ||
| namespace: openshift-ingress-operator | ||
| name: <name> <1> | ||
| spec: | ||
| domain: <domain> <2> | ||
| endpointPublishingStrategy: | ||
| type: LoadBalancerService | ||
| loadBalancer: | ||
| scope: Internal <3> | ||
| ---- | ||
| <1> Replace `<name>` with a name for the `IngressController` object. | ||
| <2> Specify the `domain` for the application published by the controller. | ||
| If the `name` for the controller is `default` and you do not specify the `domain` parameter, the default cluster domain is used. | ||
| <3> Specify a value of `Internal` to use an internal load balancer. | ||
|
|
||
| . Create the Ingress Controller defined in the previous step by running the following command: | ||
| + | ||
| ---- | ||
| $ oc create -f <name>-ingress-controller.yaml <1> | ||
| ---- | ||
| <1> Replace `<name>` with the name of the `IngressController` object. | ||
|
|
||
| . Optional: Confirm that the Ingress Controller was created by running the following command: | ||
| + | ||
| ---- | ||
| $ oc --all-namespaces=true get ingresscontrollers | ||
| ---- | ||
|
Contributor
There was a problem hiding this comment. @jboxman, this restriction came up on the Group G arch call:
I think that we might need a step to confirm that you have such a service.
Contributor
There was a problem hiding this comment. I'm surprised to learn there is such a restriction, and it seems like a very serious defect. Is there an associated Bugzilla report?
Contributor
There was a problem hiding this comment. @abhinavdahiya, was there a bug for the need to have at least one public k8s service if you switch the ingress controller to private?
Contributor
There was a problem hiding this comment. It should be noted that the restriction applies specifically to Azure, not to other cloud platforms. (It has already been noted in the Group G arch call, but I'm repeating it here for the benefit of anyone who learns of the issue from seeing this thread.)
Contributor
There was a problem hiding this comment. I'm going to talk with @Miciah and @abhinavdahiya and @wking about how we solve this transparently. I think we should treat the issue as a blocker bug that we'll solve before release and remove the note here entirely.
Contributor
There was a problem hiding this comment. Sounds like the installer already sets up egress for private clusters in 4.3 by installing a public LB, so there's nothing to note here after all? There was a problem hiding this comment. the installer only sets up egress by creating a dummy public standard load balancer, when users request Internal clusters. so for public cluster users, that want to make their ingress private as Day-2, there should be warning that, all nodes of the cluster will loose egress to internet in case there is no public LB pointing to those nodes...
Contributor
Author
There was a problem hiding this comment. @abhinavdahiya, is that for any public cloud provider user, or just for Azure? As I'm still trying to internalize this, my first pass at this is simply the following:
But if I include this as part of the procedure, is there a way to confirm if there is at least one public load-balancer point to all nodes? Doesn't having a public load-balancer defeat the purpose of private ingress? Thanks.
Contributor
Author
There was a problem hiding this comment. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.spec.domainis required unless we're talking about thedefaultresource (which can omit.spec.domainand claim the default domain).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ironcladlou I'm helping out to get this PR merged and just want to verify - this is the only update this PR needs? Thanks!
(I'll also likely have follow-up questions related to "User defined IngressControllers at installation".)