Networking Guide
Overview
This guide describes the network architecture and firewall configuration requirements for the AgileTV CDN Manager (ESB3027). Proper network configuration is essential for cluster communication and external access to services.
Note: The installer script automatically detects if firewalld is enabled. If so, it will verify that the required inter-node ports are open through the firewall in the default zone before proceeding. If any required ports are missing, the installer will report an error and exit. Application service ports (such as Kafka, VictoriaMetrics, and Telegraf) are not checked by the installer as they are configurable.
Network Architecture
Physical Network
Each cluster node must have at least one network interface card (NIC) configured as the default gateway. If the node lacks a pre-configured default route, one must be established prior to installation.
Overlay Network
Kubernetes creates virtual network interfaces for pods that are typically not associated with any specific firewalld zone. The cluster uses the following network ranges:
| Network | CIDR | Purpose |
|---|---|---|
| Pod Network | 10.42.0.0/16 | Inter-pod communication |
| Service Network | 10.43.0.0/16 | Kubernetes service discovery |
Firewall regulations should target the primary physical interface. The overlay network traffic is handled by Flannel VXLAN.
IP Routing
Proper IP routing is critical for cluster communication. Ensure your network infrastructure allows routing between all subnets used by the cluster.
Port Requirements
Inter-Node Communication
The following ports must be permitted between all cluster nodes for Kubernetes and cluster infrastructure:
| Port | Protocol | Source | Destination | Purpose |
|---|---|---|---|---|
| 2379-2380 | TCP | Server nodes | Server nodes | etcd cluster communication |
| 6443 | TCP | All nodes | Server nodes | Kubernetes API server |
| 8472 | UDP | All nodes | All nodes | Flannel VXLAN overlay network |
| 10250 | TCP | All nodes | All nodes | Kubelet metrics and management |
| 5001 | TCP | All nodes | Server nodes | Spegel registry mirror |
| 9500-9503 | TCP | All nodes | All nodes | Longhorn management API |
| 8500-8504 | TCP | All nodes | All nodes | Longhorn agent communication |
| 10000-30000 | TCP | All nodes | All nodes | Longhorn data replication |
| 3260 | TCP | All nodes | All nodes | Longhorn iSCSI |
| 2049 | TCP | All nodes | All nodes | Longhorn RWX (NFS) |
Application Services Ports
The following ports must be accessible for application services within the cluster:
| Port | Protocol | Service |
|---|---|---|
| 6379 | TCP | Redis |
| 9092 | TCP | Kafka (internal cluster communication) |
| 9093 | TCP | Kafka (controller) |
| 9094 | TCP | Kafka (internal) |
| 9095 | TCP | Kafka (external client connections) |
| 8428 | TCP | VictoriaMetrics (Analytics) |
| 8880 | TCP | VictoriaMetrics (Alerting) |
| 8429 | TCP | VictoriaMetrics (Billing) |
| 9093 | TCP | Alertmanager |
| 8125 | TCP/UDP | Telegraf (metrics collection) |
| 8080 | TCP | Telegraf (API/Metrics) |
| 8086 | TCP | Telegraf (API/Metrics) |
External Access Ports
The following ports must be accessible from external clients to cluster nodes:
| Port | Protocol | Service |
|---|---|---|
| 80 | TCP | HTTP ingress (Optional, redirects to HTTPS) |
| 443 | TCP | HTTPS ingress (Required, all services) |
| 9095 | TCP | Kafka (external client connections) |
| 6379 | TCP | Redis (external client connections) |
| 8125 | TCP/UDP | Telegraf (metrics collection) |
Firewall Configuration
firewalld Configuration
firewalld Configuration
For systems using firewalld, it is recommended to use separate zones for internal cluster traffic and external public access. This ensures that sensitive inter-node communication is restricted to the internal network.
Assign Interfaces to Zones: First, assign your network interfaces to the appropriate zones. For example, if
eth0is your public interface andeth1is your internal cluster interface:firewall-cmd --permanent --zone=public --add-interface=eth0 firewall-cmd --permanent --zone=internal --add-interface=eth1Configure Firewall Rules: The following commands configure the minimum required firewall rules.
# Inter-node communication (Internal Zone) firewall-cmd --permanent --zone=internal --add-port=2379-2380/tcp firewall-cmd --permanent --zone=internal --add-port=6443/tcp firewall-cmd --permanent --zone=internal --add-port=8472/udp firewall-cmd --permanent --zone=internal --add-port=10250/tcp firewall-cmd --permanent --zone=internal --add-port=5001/tcp firewall-cmd --permanent --zone=internal --add-port=9500-9503/tcp firewall-cmd --permanent --zone=internal --add-port=8500-8504/tcp firewall-cmd --permanent --zone=internal --add-port=10000-30000/tcp firewall-cmd --permanent --zone=internal --add-port=3260/tcp firewall-cmd --permanent --zone=internal --add-port=2049/tcp # Pod and service networks (Internal Zone) firewall-cmd --permanent --zone=internal --add-source=10.42.0.0/16 firewall-cmd --permanent --zone=internal --add-source=10.43.0.0/16 # External access (Public Zone) firewall-cmd --permanent --zone=public --add-port=80/tcp firewall-cmd --permanent --zone=public --add-port=443/tcp firewall-cmd --permanent --zone=public --add-port=9095/tcp firewall-cmd --permanent --zone=public --add-port=6379/tcp firewall-cmd --permanent --zone=public --add-port=8125/tcp firewall-cmd --permanent --zone=public --add-port=8125/udp # Apply changes firewall-cmd --reloadFor more restrictive configurations, you can scope rules to specific source subnets using
--add-source=<subnet>within the internal zone.
Internal Application Ports (Optional)
For internal cluster communication, the following ports may be opened if direct application access is required:
firewall-cmd --permanent --add-port=9092/tcp
Note: This port is used for internal Kafka cluster communication only.
Security Warning: Do not expose VictoriaMetrics (8428, 8429), or PostgreSQL (5432) directly. These services require authentication and their direct ports do not use TLS connections, creating a security risk. Always access these services through the secure HTTPS ingress (port 443).
Externally Accessible Application Ports: The following application ports are safe for external access and are already configured in the External Access section:
| Port | Service | Notes |
|---|---|---|
| 9095 | Kafka | External client connections |
| 6379 | Redis | External client connections |
| 8125 | Telegraf | Metrics collection |
Verification
Verify firewall rules are applied:
firewall-cmd --list-all
Verify ports are accessible between nodes:
# From one node, test connectivity to another
nc -zv <node-ip> 6443
nc -zv <node-ip> 8472
Kubernetes Port Forwarding
For accessing internal Kubernetes services that are not exposed via ingress or services, use kubectl port-forward to create a secure tunnel from your local machine to the service.
Basic Port Forwarding
# Forward local port to a service
kubectl port-forward -n <namespace> svc/<service-name> <local-port>:<service-port>
# Example: Forward local port 8080 to Grafana (port 3000)
kubectl port-forward -n default svc/acd-manager-grafana 8080:3000
Note: “Local” refers to the machine where you run kubectl. This can be:
- A Server node in the cluster (common for administrative tasks)
- A remote machine with
kubectlconfigured to access the cluster
Accessing the Forwarded Service
Once the port-forward is established, access the service at http://localhost:<local-port> from the machine where you ran kubectl port-forward.
If running on a Server node: To access the forwarded port from your local workstation, you need to:
- Ensure the firewall on the Server node allows traffic on the forwarded port from your network
- Use the Server node’s IP address instead of
localhostfrom your workstation
# From your workstation (if firewall allows)
curl http://<server-node-ip>:<local-port>
For simplicity, consider running port-forward from your local machine (if kubectl is configured for remote cluster access) rather than from a Server node.
Background Port Forwarding
To run port-forward in the background:
kubectl port-forward -n <namespace> svc/<service-name> <local-port>:<service-port> &
Security Considerations
Port forwarding is recommended for:
- Administrative interfaces (e.g., Longhorn UI) that should not be publicly exposed
- Debugging and troubleshooting internal services
- Temporary access to services without modifying ingress configuration
The port-forward tunnel remains active only while the kubectl port-forward command is running. Press Ctrl+C to terminate the tunnel.
Example: The Longhorn storage UI is intentionally not exposed via ingress due to security risks. Access it via port-forward:
kubectl port-forward -n longhorn-system svc/longhorn-frontend 8080:80Then navigate to
http://localhost:8080in your browser.
Network Security Considerations
Network Segmentation
For production deployments, consider network segmentation:
- Management Network: Dedicated network for Kubernetes control plane traffic
- Application Network: Separate network for application service traffic
- External Network: Public-facing network for ingress traffic
Traffic Encryption
- All external traffic uses HTTPS (TLS 1.2 or higher)
- Internal cluster traffic uses Flannel VXLAN encryption (if enabled)
- Database connections (PostgreSQL, Redis) are internal to the cluster
Access Control
- External access is limited to ports 80 and 443 by default
- Application service ports should not be exposed externally
- Use Kubernetes NetworkPolicies for fine-grained pod-to-pod traffic control
Troubleshooting
Nodes Cannot Communicate
Verify firewall rules allow inter-node traffic:
firewall-cmd --list-allTest connectivity between nodes:
ping <node-ip> nc -zv <node-ip> 6443Check network routing:
ip route
Pods Cannot Reach Services
Verify Flannel is running:
kubectl get pods -n kube-system | grep flannelCheck VXLAN interface:
ip link show flannel.1Verify pod network routes:
ip route | grep 10.42
External Access Fails
Verify ingress controller is running:
kubectl get pods -n kube-system | grep traefikCheck ingress configuration:
kubectl get ingressVerify external firewall allows ports 80 and 443
Next Steps
After configuring networking:
- Installation Guide - Proceed with cluster installation
- System Requirements - Review hardware and OS requirements
- Architecture Guide - Understand component communication patterns