Skip to content

OCPBUGS#45054: Maintain linear nomenclature for nodes in the "Installing Cluster on any platform" documentation #85475

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

OCPBUGS#45054: Maintain linear nomenclature for nodes in the "Installing Cluster on any platform" documentation #85475

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f1c3e78
OCPBUGS#45054: Maintain linear nomenclature for nodes in the examples…
Atharva-Shinde Nov 26, 2024
5f94619
Update modules/installation-load-balancing-user-infra.adoc
Atharva-Shinde Dec 3, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 13 additions & 7 deletions modules/installation-load-balancing-user-infra.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -145,7 +145,13 @@ ifdef::user-managed-lb[]
This section provides an example API and application Ingress load balancer configuration that meets the load balancing requirements for clusters that are deployed with user-managed load balancers. The sample is an `/etc/haproxy/haproxy.cfg` configuration for an HAProxy load balancer. The example is not meant to provide advice for choosing one load balancing solution over another.
endif::user-managed-lb[]

In the example, the same load balancer is used for the Kubernetes API and application ingress traffic. In production scenarios, you can deploy the API and application ingress load balancers separately so that you can scale the load balancer infrastructure for each in isolation.
This example specifies the following:

* The cluster name is `ocp4`.
* The base domain is `example.com`.
* The same load balancer is used for the Kubernetes API and application ingress traffic.

In production scenarios, you can deploy the API and application ingress load balancers separately so that you can scale the load balancer infrastructure for each in isolation.

[NOTE]
====
Expand Down Expand Up @@ -184,16 +190,16 @@ listen api-server-6443 <1>
option log-health-checks
balance roundrobin
server bootstrap bootstrap.ocp4.example.com:6443 verify none check check-ssl inter 10s fall 2 rise 3 backup <2>
server master0 master0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
server master1 master1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
server master2 master2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
server control-plane0 control-plane0.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
server control-plane1 control-plane1.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
server control-plane2 control-plane2.ocp4.example.com:6443 weight 1 verify none check check-ssl inter 10s fall 2 rise 3
listen machine-config-server-22623 <3>
bind *:22623
mode tcp
server bootstrap bootstrap.ocp4.example.com:22623 check inter 1s backup <2>
server master0 master0.ocp4.example.com:22623 check inter 1s
server master1 master1.ocp4.example.com:22623 check inter 1s
server master2 master2.ocp4.example.com:22623 check inter 1s
server control-plane0 control-plane0.ocp4.example.com:22623 check inter 1s
server control-plane1 control-plane1.ocp4.example.com:22623 check inter 1s
server control-plane2 control-plane2.ocp4.example.com:22623 check inter 1s
listen ingress-router-443 <4>
bind *:443
mode tcp
Expand Down