Communication Matrix

This page lists the ports that components listen on for cluster nodes that run a traditional operating system. Use it to build the allow rules when you enable a host firewall on those nodes.

Scope of This Matrix

This matrix covers the ports used by core components and by Aligned extensions. Ports required by Agnostic extensions are maintained by those extensions and are not listed here.

Some of the listed components run only on global cluster nodes. A workload cluster node listens on the subset of these ports that applies to the components it runs.

This Page Is Not a Complete Firewall Configuration

The matrix is a component port inventory, not a finished rule set. Several deployment options add requirements that are not expressed as a listening port on a node. See What This Matrix Does Not Cover before you apply any firewall rules.

When to Use This Page

You need this page only when a host firewall, such as firewalld or ufw, is enabled on the cluster nodes. Keeping the host firewall disabled is the default and recommended node configuration. Before you enable a host firewall, read Hardened Node Security Configuration, which gives the init.sh arguments, the additional ports used by the node that runs the installer, and the order in which to apply the configuration.

This page does not apply to clusters running Alauda OS, where the platform maintains the node port configuration.

This page is not the same as the port occupancy check in Node Preprocessing. That check confirms that no other process has already bound the ports the platform needs before the installation starts. This page describes which ports a host firewall must allow. Both apply when a host firewall is enabled.

Allow Cluster-Internal Traffic Before You Apply Firewall Rules

This matrix lists the ports that the nodes listen on. Pod-to-Pod and Pod-to-Service traffic uses arbitrary ports and is not covered by this matrix, so a firewall that allows only the ports listed here breaks cluster networking.

When you enable a host firewall, also treat the Pod CIDR, the Service CIDR, and the network interfaces created by the CNI plugin as trusted sources, so that cluster-internal traffic is not filtered by port. The interface names depend on the CNI plugin and on the environment, so read them from the node instead of assuming a fixed name.

What This Matrix Does Not Cover

Check each of the following against your own deployment. A requirement that applies to your cluster but is not in the matrix still has to be allowed.

  • Pod and Service traffic. See the warning above.
  • Secondary and non-default container networks. The 6081/UDP entry in the table is the port used by the default Kube-OVN Geneve tunnel. If you change the Kube-OVN tunnel type, or attach a secondary network with Multus on top of the default one, those networks carry Pod traffic between node IP addresses using their own encapsulation, which is not listed here. Confirm what your configuration uses and allow it between the nodes.
  • Traffic between the global cluster and a workload cluster. The global cluster has to reach the control plane nodes of every workload cluster it manages, and a workload cluster's own load balancer has to reach them as well. See Creating an On-Premise Cluster for the ports involved.
  • Load balancer forwarding. When a load balancer fronts the platform access address, its forwarded traffic does not originate from a cluster node IP address. See LoadBalancer Forwarding Rules for the ports involved.
  • Self-built VIP. This option runs keepalived, which uses the VRRP protocol rather than a TCP or UDP port. firewalld and ufw block VRRP by default, so the VIP never comes up unless you allow it between the nodes that share the VIP.
  • Global disaster recovery. A DR pair needs several ports open in both directions between the Primary and Standby cluster networks. See the network requirements in Global Disaster Recovery.

Platform Ports

PortProtocolComponent
22TCPsshd
80TCPalb2
443TCPglobal-alb2
1936TCPalb2
2049TCPnfs
2379TCPetcd
2380TCPetcd
6081UDPkube-ovn
6443TCPkube-apiserver
6641TCPovsdb-server
6642TCPovsdb-server
6643TCPovsdb-server
6644TCPovsdb-server
7473TCPfrr-metrics
9000TCPminio
9100TCPnode_exporter
10250TCPkubelet
10257TCPkube-controller-manager
10259TCPkube-scheduler
10660TCPkube-ovn-controller
10661TCPkube-ovn-monitor
10665TCPkube-ovn-daemon
11443TCPregistry
11780TCPglobal-alb2
11782TCPglobal-alb2
17472TCPspeaker
17946TCPspeaker
30000-32767TCPUser application NodePort range
30000-32767UDPUser application NodePort range

Reachability

  • Every port in the table has to be reachable between the cluster nodes and from the node that runs the installer.
  • 443/tcp additionally carries the platform access address, so it has to be reachable by the users and systems that access the platform.
  • Specific deployment options require some of these ports to be reachable from outside the cluster network as well. See What This Matrix Does Not Cover.

NodePort Range

30000-32767 is the port range reserved for NodePort Services created by user applications. A port in this range is opened on the nodes when an application that uses it is deployed, and it is closed again when the corresponding Service is deleted. Allow this range on the host firewall only if your applications use NodePort Services, and restrict it to the sources those applications are meant to serve.

Conditional Ports

Calico

The following ports are required only when the cluster uses the Calico CNI plugin.

PortProtocolComponent
179TCPcalico-node, BGP
9091TCPcalico-node
9324TCPbird_exporter