From 976c6f601499def4517bf27c4c6bda6dcfe38c2e Mon Sep 17 00:00:00 2001 From: Jason Boxman Date: Tue, 1 Oct 2019 11:27:20 -0400 Subject: [PATCH] Describe configuring an internal load balancer for cloud - https://github.com/openshift/openshift-docs/pull/16410#discussion_r327634216 --- modules/nw-ingress-setting-internal-lb.adoc | 66 +++++++++++++++++++ .../nw-ingress-sharding-namespace-labels.adoc | 2 +- modules/nw-ingress-sharding-route-labels.adoc | 4 +- networking/ingress-operator.adoc | 4 +- 4 files changed, 72 insertions(+), 4 deletions(-) create mode 100644 modules/nw-ingress-setting-internal-lb.adoc diff --git a/modules/nw-ingress-setting-internal-lb.adoc b/modules/nw-ingress-setting-internal-lb.adoc new file mode 100644 index 000000000000..68a11fcdc3af --- /dev/null +++ b/modules/nw-ingress-setting-internal-lb.adoc @@ -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 `-ingress-controller.yaml`, such as in the following example: ++ +[source,yaml] +---- +apiVersion: operator.openshift.io/v1 +kind: IngressController +metadata: + namespace: openshift-ingress-operator + name: <1> +spec: + domain: <2> + endpointPublishingStrategy: + type: LoadBalancerService + loadBalancer: + scope: Internal <3> +---- +<1> Replace `` 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 -ingress-controller.yaml <1> +---- +<1> Replace `` 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 +---- diff --git a/modules/nw-ingress-sharding-namespace-labels.adoc b/modules/nw-ingress-sharding-namespace-labels.adoc index 2b7f9b308089..25df930892e9 100644 --- a/modules/nw-ingress-sharding-namespace-labels.adoc +++ b/modules/nw-ingress-sharding-namespace-labels.adoc @@ -4,7 +4,7 @@ // * ingress-operator.adoc [id="nw-ingress-sharding-namespace-labels_{context}"] -= Configuring ingress controller sharding by using namespace labels += Configuring Ingress Controller sharding by using namespace labels Ingress Controller sharding by using namespace labels means that the Ingress Controller serves any route in any namespace that is selected by the namespace diff --git a/modules/nw-ingress-sharding-route-labels.adoc b/modules/nw-ingress-sharding-route-labels.adoc index f262622b3661..26d68b83009d 100644 --- a/modules/nw-ingress-sharding-route-labels.adoc +++ b/modules/nw-ingress-sharding-route-labels.adoc @@ -1,10 +1,10 @@ // Module included in the following assemblies: // // * configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-ingress-controller.adoc -// * ingress-operator.adoc +// * networking/ingress-operator.adoc [id="nw-ingress-sharding-route-labels_{context}"] -= Configuring ingress controller sharding by using route labels += Configuring Ingress Controller sharding by using route labels Ingress Controller sharding by using route labels means that the Ingress Controller serves any route in any namespace that is selected by the route diff --git a/networking/ingress-operator.adoc b/networking/ingress-operator.adoc index 78dbe5c4a450..4fd0ea268cce 100644 --- a/networking/ingress-operator.adoc +++ b/networking/ingress-operator.adoc @@ -7,7 +7,7 @@ toc::[] The Ingress Operator implements the `ingresscontroller` API and is the component responsible for enabling external access to {product-title} -cluster services. The operator makes this possible by deploying and +cluster services. The Operator makes this possible by deploying and managing one or more HAProxy-based link:https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/[Ingress Controllers] to handle routing. You can use the Ingress Operator to route traffic by @@ -31,4 +31,6 @@ include::modules/nw-ingress-sharding-route-labels.adoc[leveloffset=+1] include::modules/nw-ingress-sharding-namespace-labels.adoc[leveloffset=+1] +include::modules/nw-ingress-setting-internal-lb.adoc[leveloffset=+1] + //include::modules/nw-ingress-select-route.adoc[leveloffset=+1]