You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/cluster-installation/hosted-control-plane/tenant-network/index.md
+9-21Lines changed: 9 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,7 +19,7 @@ Tested with:
19
19
20
20
Challenge: running an hosted cluster with in different tenant network segment/vlan without widely open access from tenant segment to managment segment.
21
21
22
-
Addtional requirement, the hub cluster should not have any address or network connection into the tenant network segment. It's only allowed to place virtual machines into the network segment.
22
+
Addtional requirement, the hub cluster should not have any address or network connection into the tenant network segment. It's only allowed to place virtual machines into the network segment.
23
23
24
24
{ page="Page-1" }
25
25
@@ -30,7 +30,7 @@ The hosted control plane compontents to expose into tenant network segment is mo
30
30
* API Server
31
31
* OAuth
32
32
* Konnectivity
33
-
* Ignition
33
+
* Ignition
34
34
35
35
Here an list of possible exposing options for these components:
36
36
@@ -44,19 +44,16 @@ Here an list of possible exposing options for these components:
44
44
For our proof of concept we want to try following, exposing the components via:
45
45
46
46
* API Server: LoadBalancer
47
-
* OAuth: Router/Ingress: via a dedicted router shard.
48
-
* Konnectivity: via a dedicted router shard.
49
-
* Ignition: via a dedicted router shard.
47
+
* OAuth: Router/Ingress: via a dedicted router shard.
48
+
* Konnectivity: via a dedicted router shard.
49
+
* Ignition: via a dedicted router shard.
50
50
51
51
## Exposing compontents via router/ingress shard
52
52
53
-
The idea with the dedicated router/ingress shared is to expose the router/ingress shard into the tenant network segment and only for the hosted cluster components.
53
+
The idea with the dedicated router/ingress shared is to expose the router/ingress shard into the tenant network segment and only for the hosted cluster components.
54
54
55
55
In front of the router/ingress shared is an external load balancer (for example, f5 bigip, netscaler,..) with access into the managment network segment and expose the router shared into the tenant network segment.
56
56
57
-
58
-
59
-
60
57
## Proof of concept envrioment overview
61
58
62
59
{ page="Page-2" }
@@ -76,7 +73,6 @@ In front of the router/ingress shared is an external load balancer (for example,
76
73
*[2.3.4. Ingress sharding in OpenShift Container Platform](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/configuring-ingress-cluster-traffic#nw-ingress-sharding-concept_configuring-ingress-cluster-traffic-ingress-controller)
77
74
*[3.1.3.8.1. Example load balancer configuration for user-provisioned clusters](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/installing_on_vmware_vsphere/user-provisioned-infrastructure)
78
75
79
-
80
76
???+ example "Ingress Controller"
81
77
82
78
```yaml
@@ -102,22 +98,15 @@ Ingress sharding load balancer is an RHEL 9 system with haproxy.
0 commit comments