Networking Prerequisites
The Linux nodes that run PMK need to allow several kinds of incoming network access points. They also need to access various external services to handle updates and resource downloads.
Following are the networking prerequisites for the linux nodes for your PMK cluster:
- Each node should have at least one physical (or VLAN backed) NIC with an IP address.
- All nodes in the cluster should be able to communicate with each other over the NIC
- The cluster will also require two unused IP subnets.
- Make sure that the subnets are not in use by any of your internal network
- The subnets are specified in CIDR form as part of cluster creation, and are referred to as Containers CIDR and Services CIDR.
In general, you should not configure your network equipment to route or otherwise be aware of those subnets. Kubernetes uses the first network range to route packets between pods or containers in a cluster. The network mask is subdivided into two portions:
- The intra-node portion determines how many Kubernetes pods can run on a single node,
- The internode portion determines the maximum number of nodes in a cluster.
By default, the intra-node portion is 8 bits, i.e., up to 256 pods per node.
- So, a network mask of 12 bits would allow clusters to have up to 16 nodes. For example, a new cluster named DevCluster is created with Containers CIDR=10.20.0.0/16 and Services CIDR=10.21.0.0/16
A node in a PMK cluster will access the following types of data sources during cluster creation:
- CentOS yum repository
- Docker yum repository
- Public docker registries from Docker, Inc. and Google (Kubernetes project)
Network Port Configurations
Port vs. Protocol
Port numbers are used by TCP and UDP protocols, while Protocol numbers are special numbers reserved to identify protocols.
A Port number or range defines or identifies the access point of a particular application or service on a system.
The Protocol field number in an IP packet identifies the upper layer protocol where the type of data contained in the packet is to be sent. When a router receives an IP packet, it examines this Protocol field to learn where to interpret the data which is encapsulated within that packet. These protocol numbers can usually be seen in the /etc/protocol file.
Master
All Kubernetes master nodes must be able to receive incoming connections on the following ports:
| Protocol | Port Range | Purpose |
|---|---|---|
| AH | 51 | To allow the authentication of East-West traffic between masters, as part of the keepalived daemond |
| TCP | 443 | Requests to Kubernetes API from worker nodes and external clients (eg kubectl) |
| TCP | 2379-2380, 4001 | Etcd cluster specific traffic between master nodes |
| VRRP | 112 | To allow East-West VRRP traffic to flow among masters |
Nodes
All Kubernetes master and worker nodes must be able to receive incoming connections on the following ports.
| Protocol | Port Range | Purpose |
|---|---|---|
| TCP | 10250 | Requests from master and worker nodes to the kubelet API for exec and logs |
| TCP | 10255 | Requests from master and worker nodes to read-only kubelet API |
| TCP | 10256 | Requests from master and worker nodes to kubeproxy |
| TCP | 4194 | Requests from master and worker nodes to cAdvisor |
| TCP | 30000-32767 | Requests from external clients (eg kubectl) to default port range for NodePort Services |
Worker nodes must also be able to receive incoming connections on ports used by any Kubernetes add-ons or applications that you install on those nodes. For instance, installing a Prometheus instance for monitoring will require specific ports to be opened. Refer to the documentation specific to the application being installed for more details.
Network Plugin-specific Prerequisites
In addition to these generic networking prerequisites, you will need to follow prerequisites specific to the specific CNI plugin you plan to use with your Kubernetes clusters. See CNI Integrations for more info.