docs/doc/source/planning/kubernetes/oam-network-planning.rst
Ron Stone 2b62f49a9d Fix symlinks
Changed paths to avoid '..', which breaks symlinks in newer versions of sphinx.
Consolidated installation include files under /_includes. Prefixed r5 versions with 'r5_'
Moved files that are used up/down, but at different paths under /shared/_includes
and /shared/figures
Move two include files to /_includes
Moved addtional images to /shared/figures/... Required for DS platform builds.

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: Ia38f4205c5803b3d1fc043e6c59617c34a4e5cbd
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
2021-09-02 13:31:45 +00:00

3.2 KiB
Executable File

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