클러스터를 만든 뒤 IP가 바뀌면 인증서와 kubelet 통신까지 확인해야 합니다. 설치 전에 재부팅해도 같은 주소와 설정으로 돌아오는지 확인해 두면 편해요. 아래 Linux 명령은 별도 표시가 없으면 세 노드 모두에서 labadmin으로 실행합니다.
목차
1. 고정 IP와 SSH
nmcli device status
nmcli -f NAME,UUID,DEVICE connection show
ip -4 address예제의 NIC와 연결 이름은 ens160, ens160입니다. 실제 목록이 Wired connection 1 또는 ens33이라면 그 이름을 사용합니다. IP 변경 중 SSH가 끊길 수 있으므로 첫 설정은 VMware 콘솔에서 진행합니다.
# cp01의 VMware 콘솔에서 실행
CON="ens160" # 실제 연결 이름으로 수정
sudo hostnamectl set-hostname cp01
sudo nmcli connection modify "$CON" \
ipv4.method manual \
ipv4.addresses 192.168.80.10/24 \
ipv4.gateway 192.168.80.2 \
ipv4.dns "1.1.1.1 9.9.9.9" \
connection.autoconnect yes
sudo nmcli connection up "$CON"wk01에는 wk01 / 192.168.80.11, wk02에는 wk02 / 192.168.80.12를 적용합니다. 외부 DNS가 제한돼 있으면 허용된 사내 DNS를 사용합니다. Windows에서 ssh labadmin@192.168.80.10으로 접속해 보고, 거부되면 게스트의 sshd와 SSH 방화벽 허용 상태를 확인합니다.
sudo tee -a /etc/hosts > /dev/null <<'EOF'
192.168.80.10 cp01 k8s-api.lab
192.168.80.11 wk01
192.168.80.12 wk02
EOF
getent hosts cp01 wk01 wk02 k8s-api.lab
ping -c 2 192.168.80.2
curl -I https://pkgs.k8s.io/etc/hosts에 같은 이름을 중복해서 추가하지 않습니다. 기존 항목이 있다면 주소를 편집합니다. k8s-api.lab은 이후 API 서버를 찾을 고정 이름이에요. 이름을 붙이는 작업만으로 컨트롤 플레인이 이중화되지는 않습니다.
2. 패키지 업데이트·시간 동기화
sudo dnf upgrade --refresh -y
sudo dnf install -y curl vim-enhanced bash-completion chrony \
iproute iputils bind-utils conntrack-tools socat python3
sudo systemctl enable --now chronyd
chronyc tracking
chronyc sources -v
cat /etc/rocky-release
uname -r9.6으로 설치했어도 일반 Rocky 9 저장소로 업데이트하면 지원 중인 9.x로 올라갈 수 있습니다. 노드마다 커널과 런타임이 다르면 결과도 달라질 수 있으니 설치 날짜와 rpm -qa | sort를 남깁니다. 시간 동기화도 확인하세요. 인증서 검증과 이벤트 시간 비교를 위해 chronyc sources에서 선택된 소스가 있는지 봅니다.
3. swap과 부팅 설정
이 실습은 메모리 동작을 단순하게 확인하기 위해 swap을 끕니다. Kubernetes에 swap을 사용하는 구성이 없는 것은 아닙니다. swapoff는 현재 상태만 바꾸므로 부팅 설정도 수정해야 재부팅 뒤 다시 켜지지 않습니다.
sudo swapoff -a
sudo cp -a /etc/fstab /etc/fstab.before-k8s
sudo sed -ri '/^[[:space:]]*[^#].*[[:space:]]swap[[:space:]]/s/^/# k8s-lab /' /etc/fstab
swapon --show
systemctl list-units --type=swapswapon --show에 장치가 없어야 합니다. zram이나 별도의 systemd swap 유닛을 사용했다면 그 경로도 확인합니다. fstab만 편집한 상태에서 점검을 끝내지 않습니다.
4. 커널 모듈과 패킷 전달
sudo tee /etc/modules-load.d/k8s.conf > /dev/null <<'EOF'
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
sudo tee /etc/sysctl.d/99-kubernetes.conf > /dev/null <<'EOF'
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sudo sysctl --system
stat -fc %T /sys/fs/cgroupip_forward=1은 다른 목적지로 패킷을 전달하도록 허용합니다. br_netfilter는 브리지 트래픽을 netfilter 규칙과 연결하고, overlay는 컨테이너의 레이어 파일시스템에 사용합니다. Rocky 9의 기본 cgroup v2 환경이면 마지막 명령에 cgroup2fs가 나와야 합니다. cgroup은 CPU와 메모리를 컨테이너별로 제어하는 Linux 기능입니다.
5. SELinux·방화벽의 실습 설정
# 이 연재 전용 VM 세 대에서 실행
sudo setenforce 0
sudo sed -ri 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config
sudo systemctl disable --now firewalld
getenforce여기서는 kubeadm 문서의 SELinux permissive 경로를 사용합니다. 정책 위반은 기록하되 차단하지 않는 상태이며 SELinux를 제거하는 작업은 아닙니다. Calico 규칙과의 충돌을 줄이기 위해 게스트 firewalld도 끕니다. 외부 접근을 제한한 전용 학습 VM에서만 적용합니다. Windows와 공유기의 방화벽까지 끄지 않습니다.
| 통신 | 이 실습의 사용처 |
|---|---|
| TCP 6443 → cp01 | Kubernetes API |
| TCP 2379~2380 → cp01 | etcd, 외부 사용자에게 개방하지 않음 |
| TCP 10250 → 노드 | kubelet API, API 서버의 로그·exec 등 |
| UDP 4789 ↔ 노드 | Calico VXLAN |
| TCP 30080 → 노드 | 6편의 웹 앱 NodePort |
표에는 연재에서 확인할 주요 경로를 정리했습니다. 운영 환경의 방화벽은 Kubernetes 포트 문서와 실제 Calico 구성에 맞춰 별도로 설계해야 합니다. 출발지 제한과 HostEndpoint 정책도 검토합니다. NetworkPolicy만으로 호스트 포트까지 보호된다고 판단하지 않습니다.
6. 재부팅 후 점검
sudo reboot
# 재접속한 뒤 세 노드에서 확인
hostnamectl --static
ip -4 route
swapon --show
sysctl net.ipv4.ip_forward
getenforce
systemctl is-active chronyd
cat /etc/machine-id
sudo cat /sys/class/dmi/id/product_uuid재부팅 후 IP와 이름, swap 상태가 유지되는지 확인합니다. 시간 동기화와 세 노드의 machine-id·product UUID도 비교해 보세요. 확인을 마치면 VM을 종료하고 os-ready 스냅샷을 남겨 다음 설치를 반복할 때 사용합니다.
참고 자료
공식 문서와 배포 파일 확인 기준: 2026년 10월 18일. 출력은 완료 여부를 판단하기 위한 예시이며 환경별로 달라질 수 있습니다.
답글 남기기