starlingx/docs
Code Issues Proposed changes
d466920c10
docs/doc/source/planning/kubernetes/oam-network-planning.rst
Ron Stone f125a8b892 Remove spurious escapes (r8,dsR8) 
This change addresses a long-standing issue in rST documentation imported from XML.
That import process added backslash escapes in front of various characters. The three
most common being '(', ')', and '_'.
These instances are removed.

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: Id43a9337ffcd505ccbdf072d7b29afdb5d2c997e
2023-03-01 11:19:04 +00:00

3.2 KiB
Executable File
Raw Blame History

OAM Network Planning

The network enables ingress access to the Horizon Web interface, the command-line management clients -- using and interfaces, and the REST APIs to remotely manage the cluster.

The Network is also used for egress access to remote Docker Registries, and for Elastic Beats connectivity to a Remote Log server if remote logging is configured.

The network provides access to the board management controllers.

The network supports IPv4 or IPv6 addressing. Use the following guidelines:

  • Dual-stack configuration is not supported. With the exception of the PXE boot network, all networks must use either IPv4 or IPv6 addressing.

  • Deploy proper firewall mechanisms to access this network. The primary concern of a firewall is to ensure that access to the management interfaces is not compromised.

    includes a default firewall for the network, using Kubernetes Network Policies. You can configure the system to support additional rules. For more information, see Firewall Options <network-planning-firewall-options>.

  • Consider whether the network needs access to the internet. Limiting access to an internal network might be advisable, although access to a configured DNS server, a remote Docker registry with at least the container images, and or servers may still be needed.

  • tagging is supported, enabling the network to share an interface with the internal management or infrastructure networks.

  • The IP addresses of the DNS, and / servers must match the IP address plan (IPv4 or IPv6) of the network.

  • For an IPv4 address plan:

    • The floating IP address is the only address that needs to be visible externally. You must therefore plan for valid definitions of its IPv4 subnet and default gateway.
    • The physical IPv4 addresses for the controllers do not need to be visible externally, unless you plan to use them during sessions to prevent potential service breaks during the connection. You need to plan for their IPv4 subnet, but you can limit access to them as required.
    • Outgoing packets from the active or secondary controller use the controller's IPv4 physical address, not the floating IP address, as the source address.

  • For an IPv6 address plan:

    • Outgoing packets from the active controller use the floating IP address as the source address. Outgoing packets from the secondary controller use the secondary controller's IPv6 physical IP address.

  • Systems with two controllers use IP multicast messaging on the internal management network. To prevent loss of controller synchronization, ensure that the switches and other devices on these networks are configured with appropriate settings.

partner