방화벽이 기본 차단인 온프레미스 환경에서 Kubernetes 노드 사이에 열어야 하는 포트를 정리한 것이다. 외부 사용자나 로드밸런서에서 들어오는 경로는 제외하고 노드 대 노드만 다룬다. 기본 포트는 어느 배포판에서나 같지만, CNI 모드와 그 위에 올리는 워크로드에 따라 추가로 열어야 하는 것이 달라진다. 특히 오버레이 네트워크의 UDP 포트는 기본 설치 문서에 빠져 있는 경우가 많아 "파드는 뜨는데 다른 노드의 파드와 통신이 안 되는" 증상으로 나타난다.
kubeadm 이 요구하는 포트다.
| 포트 | 프로토콜 | 방향 | 용도 |
|---|---|---|---|
| 6443 | TCP | 전 노드 → 컨트롤 플레인 | kube-apiserver |
| 2379-2380 | TCP | 컨트롤 플레인 ↔ 컨트롤 플레인 | etcd client · peer |
| 10250 | TCP | 컨트롤 플레인 → 전 노드 | kubelet API |
| 10256 | TCP | 노드 ↔ 노드 | kube-proxy health |
| 10257 | TCP | 컨트롤 플레인 ↔ 컨트롤 플레인 | kube-controller-manager |
| 10259 | TCP | 컨트롤 플레인 ↔ 컨트롤 플레인 | kube-scheduler |
| 30000-32767 | TCP · UDP | 노드 ↔ 노드 | NodePort |
2379-2380 과 10257 · 10259 는 컨트롤 플레인 노드끼리만 필요하다. 워커에 열어 둘 이유가 없다.
NodePort 는 UDP 도 함께 여는 것을 잊기 쉽다. UDP NodePort 서비스를 쓰지 않는다면 TCP 만 열어도 된다.
이 부분이 실제로 가장 자주 빠진다. 열어야 할 포트는 CNI 제품이 아니라 동작 모드가 결정한다.
| CNI · 모드 | 포트 | 프로토콜 |
|---|---|---|
| Calico VXLAN | 4789 | UDP |
| Calico IPIP | IP 프로토콜 4 (IPIP) | — |
| Calico BGP(비오버레이) | 179 | TCP |
| Calico WireGuard | 51820 | UDP |
| Flannel VXLAN | 8472 | UDP |
| Cilium VXLAN | 8472 | UDP |
| Cilium Geneve | 6081 | UDP |
Calico 를 VXLAN 으로 쓰면 BGP 포트 179 는 필요 없다. 반대로 IPIP 모드는 포트 번호가 아니라 IP 프로토콜 4 자체를 허용해야 해서, 포트 단위로만 정책을 쓰는 방화벽에서는 별도 규칙이 필요하다.
firewall-cmd --permanent --add-protocol=ipip
VXLAN 포트가 막히면 증상이 광범위하다. 파드는 Running 이지만 다른 노드의 파드로 가는 패킷이 사라지므로 CoreDNS 조회부터 실패하고, 그 결과 애플리케이션 전반이 이름 해석 오류로 무너진다. 노드 하나짜리 테스트에서는 재현되지 않아 원인을 찾기 어렵다.
Calico 의 상태 확인 포트도 같이 본다.
| 포트 | 프로토콜 | 용도 |
|---|---|---|
| 9099 | TCP | calico-node(Felix) 의 liveness·readiness |
| 5473 | TCP | Typha (노드 수가 많을 때 도입) |
Typha 를 쓰지 않는 구성이면 5473 은 필요 없다.
CoreDNS 는 클러스터 내부 주소로 동작하지만, 오버레이를 거치는 트래픽이 노드 방화벽을 지나는 구성에서는 53 을 열어야 한다.
| 포트 | 프로토콜 |
|---|---|
| 53 | UDP |
| 53 | TCP |
TCP 53 을 빠뜨리는 경우가 많다. UDP 응답이 512바이트를 넘으면 클라이언트가 TCP 로 재시도하므로, SRV 레코드가 많거나 LDAP·OIDC 를 쓰는 환경에서 "가끔 로그인이 안 된다" 는 형태로 나타난다.
| 포트 | 프로토콜 | 용도 |
|---|---|---|
| 2049 | TCP · UDP | NFS |
| 111 | TCP · UDP | rpcbind |
| 20048 | TCP · UDP | mountd (고정한 경우) |
| 3260 | TCP | iSCSI |
NFSv4 만 쓰면 2049 하나로 충분하다. v3 가 섞이면 rpcbind 와 함께 statd·mountd 가 임의 포트를 쓰므로, 방화벽 환경에서는 /etc/nfs.conf 로 포트를 고정한 뒤 그 포트를 여는 것이 낫다.
| 포트 | 프로토콜 | 용도 |
|---|---|---|
| 4443 | TCP | metrics-server |
| 9100 | TCP | node-exporter |
| 123 | UDP | NTP |
NTP 는 방화벽 목록에서 빠지기 쉬운데, 노드 사이에 시각이 어긋나면 인증서 검증과 토큰 만료 판정이 틀어져 나중에 원인을 찾기 어려운 장애로 돌아온다.
CAS 컨트롤러와 워커는 노드 사이에서 TCP 로 직접 통신한다. 이 경로가 막히면 CAS 세션 생성 단계에서 바로 실패한다.
| 포트 | 프로토콜 | 용도 |
|---|---|---|
| 5570 | TCP | CAS 컨트롤러 ↔ 워커 (바이너리) |
| 5571 | TCP | CAS REST |
대화 기록에는 8777 과 8591-8592 도 함께 열어야 한다고 적혀 있었으나 공식 문서로 확인하지 못했다 (확인 필요). 실제 배포에서는 kubectl get svc -n <VIYA_NS> 로 CAS 관련 서비스의 포트를 확인해 목록을 맞추는 편이 안전하다.
# CNI (Calico VXLAN)
firewall-cmd --permanent --add-port=4789/udp
firewall-cmd --permanent --add-port=9099/tcp
# Kubernetes
firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --add-port=10250/tcp
firewall-cmd --permanent --add-port=10256/tcp
firewall-cmd --permanent --add-port=30000-32767/tcp
firewall-cmd --permanent --add-port=30000-32767/udp
# DNS
firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp
# NFS
firewall-cmd --permanent --add-port=2049/tcp
firewall-cmd --permanent --add-port=2049/udp
firewall-cmd --permanent --add-port=111/tcp
firewall-cmd --permanent --add-port=111/udp
firewall-cmd --reload
firewall-cmd --list-all
컨트롤 플레인 노드에만 추가한다.
firewall-cmd --permanent --add-port=2379-2380/tcp
firewall-cmd --permanent --add-port=10257/tcp
firewall-cmd --permanent --add-port=10259/tcp
firewall-cmd --reload
포트를 나열하는 대신 노드 대역 전체를 신뢰하는 방법도 있다. 노드끼리는 사실상 완전 신뢰 관계이므로 운영상 이쪽이 단순하다.
firewall-cmd --permanent --zone=trusted --add-source=<NODE_CIDR>
firewall-cmd --reload
포트가 실제로 통하는지는 노드에서 직접 두드려 본다.
nc -vz <PEER_NODE_IP> 6443
nc -vzu <PEER_NODE_IP> 4789
UDP 는 nc -u 로도 확실히 판정되지 않는다. VXLAN 이 실제로 통하는지는 서로 다른 노드에 파드를 하나씩 띄워 통신시키는 것이 가장 확실하다.
kubectl run t1 --image=busybox --restart=Never -- sleep 3600
kubectl run t2 --image=busybox --restart=Never -- sleep 3600
kubectl get pod -o wide
kubectl exec t1 -- ping -c3 <T2_POD_IP>
두 파드가 다른 노드에 배치됐는지 -o wide 로 먼저 확인해야 의미가 있다.
"192.100.100.32/27 에 모두 허용했다" 는 말은 192.100.100. 으로 시작하는 전체가 아니라 그 대역의 32개 주소만 허용했다는 뜻이다. /27 은 호스트 비트가 5개이므로 192.100.100.32 부터 192.100.100.63 까지다. 노드가 .70 에 있으면 그 규칙에 걸리지 않는다. 방화벽 승인 결과를 받으면 대역을 계산해 노드 주소가 실제로 포함되는지 확인한다.
ipcalc -n -b 192.100.100.32/27