본문 바로가기
기술/네트워크

[후기] 쿠버네티스 네트워크까지 다뤄본 핸즈온 세미나 후기

by 한결이상 2025. 9. 17.

배경

인프라 엔지니어로 일해왔지만 여전히 네트워크는 쉽지 않은 영역이다.
그렇다고 피하기보다는 세미나나 책 등을 통해 꾸준히 접하며 이해의 폭을 넓혀가고자 한다.
한 번에 모든 것을 이해하기는 어렵지만 반복적으로 경험하다 보면 조금씩 감이 잡히는 것 같다.

2025년 9월 15일에는 리얼리눅스에서 진행한 네트워크 세미나에 참석했다.
리눅스부터 쿠버네티스 네트워크까지 실습 중심으로 진행된 유익한 자리였고 그 경험을 정리해 보려 한다.

세미나 내용

이번 세미나는 리눅스 네트워크의 기본 구조부터 도커, 쿠버네티스 환경에서의 문제 해결까지 직접 실습하는 방식이였다.
단순히 개념을 설명하는 수준이 아니라 실제로 명령어를 실행하고 문제를 재현하고 분석하는 과정을 설명해주어서 더 와닿았다.

1. 웹 클라이언트에서 서버까지: TCP/IP 구조

네트워크 통신의 기본 흐름을 이해하기 위해, 브라우저에서 웹 서버까지 요청이 전달되는 과정을 살펴보았다. 내부망과 다르게 외부망은 망과 망 사이를 라우터로 연결된다. 이렇게 라우터를 통해 패킷이 전달되는 과정을 traceroute 명령으로 확인할 수 있다.

traceroute google.com
traceroute -n 8.8.8.8
  • google.com은 ICMP 패킷을 허용하기 때문에 ping과 traceroute가 정상 동작함.
  • naver.com은 ICMP를 허용하지 않아 응답이 오지 않음. → 단순히 “네트워크가 안 된다”로 오해할 수 있지만, 정책적 차이임.

2. 포트 충돌 문제 진단

서버 운영에서 빈번히 발생하는 포트 충돌 문제를 직접 재현했다.
nginx와 Apache(httpd)를 동시에 기동해 포트 충돌을 유발했을 때, httpd가 “Address already in use” 에러로 기동되지 않는 상황을 직접 확인할 수 있었다. 이러한 상황에서 조치 과정은 다음과 같다.

2-1. 특정 포트 사용 중인 프로세스 확인

## 80번 포트 점유 확인
# ss -tulpn |grep ':80'
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*    users:(("nginx",pid=3826,fd=6),("nginx",pid=3825,fd=6),("nginx",pid=3824,fd=6))
tcp   LISTEN 0      511             [::]:80            [::]:*    users:(("nginx",pid=3826,fd=7),("nginx",pid=3825,fd=7),("nginx",pid=3824,fd=7))

# netstat -tulpn |grep ':80'
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      3824/nginx: master
tcp6       0      0 :::80                   :::*                    LISTEN      3824/nginx: master

## fuser 명령어로 80번 포트 사용 중인 프로세스 확인
# fuser 80/tcp
80/tcp:               3824  3825  3826

## 프로세스 이름(nginx)으로 PID 찾아 상세 정보 확인
# ps -fp $(pgrep nginx)
UID          PID    PPID  C STIME TTY      STAT   TIME CMD
root        3824       1  0 01:38 ?        Ss     0:00 nginx: master process /usr/sbin/nginx
nginx       3825    3824  0 01:38 ?        S      0:00 nginx: worker process
nginx       3826    3824  0 01:38 ?        S      0:00 nginx: worker process

출력 결과를 통해 nginx 프로세스가 80번 포트를 점유하고 있음을 확인할 수 있었다.

2-2. 프로세스 관리와 종료

단순히 kill -9로 종료하면 자원 해제가 제대로 이뤄지지 않을 수 있다. 서비스나 컨테이너에서 기동된 프로세스라면 다음과 같이 정상적인 stop을 권장한다.

systemctl stop <service-name>

3. 패킷 캡처와 ICMP 분석

네트워크 문제는 “ping 된다/안 된다”로 단순화하기 쉽지만, 실제로는 패킷 레벨에서 확인해야 한다.

3-1. 구글 DNS ICMP 캡처

ping -q 8.8.8.8 &
sudo timeout 5 tshark -i eth0 -f icmp

출력 결과:

  • 로컬 IP(10.0.2.15) → 8.8.8.8 요청
  • 8.8.8.8 → 로컬 응답

ICMP 요청/응답 패킷이 정상적으로 오가는 것을 눈으로 확인할 수 있었다.

3-2. 네이버 ICMP 정책 확인

네이버는 ICMP 응답을 허용하지 않으므로, tshark 캡처 결과 요청 패킷만 남고 응답은 없는 것을 확인했다.

ping -q www.naver.com &
sudo timeout 5 tshark -i eth0 -f icmp -Y "ip.dst == $NAVER or ip.src == $NAVER"

이를 통해 ICMP 정책 차이가 곧 “네트워크 불가”를 의미하는 것은 아님을 명확히 알 수 있었다.

4. DNS 문제 진단

DNS 설정 오류로 인한 문제도 실습했다.

  • 증상: IP 주소로는 접속이 되지만, 도메인으로는 접속 불가
  • 원인: /etc/resolv.conf 내 DNS 서버 설정 오류 가능

테스트:

nslookup google.com 8.8.8.8

이렇게 직접 DNS 서버를 지정하면, 시스템 DNS 설정 문제와 전체 네트워크 문제를 구분할 수 있다.

5. 도커 네트워크 구조

컨테이너 환경에서 기본적으로 docker0 브리지가 생성된다.

# brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02424dc403e6       no              veth0d89a19
                                                        veth59d0472
                                                        vethb523c00

출력 결과:

  • docker0 브리지에 여러 veth 인터페이스가 연결
  • 각 veth는 컨테이너 내부의 eth0와 호스트 네트워크를 연결

또한, 도커 네트워크가 내부적으로 iptables 규칙을 활용하기 때문에 외부 보안 프로그램이 iptables를 초기화하면 네트워크 통신이 끊길 수 있다는 점도 확인했다.

systemctl restart docker

도커를 재시작하면 iptables 규칙이 다시 복원되지만 컨테이너를 재기동해야 하는 번거로움이 있다.

6. 쿠버네티스 네트워크와 CoreDNS

쿠버네티스 환경에서 CoreDNS는 내부 도메인 기반 통신의 핵심이다.

  • Pod와 Service는 IP로 직접 접근하기 불편하므로, CoreDNS가 내부 도메인 주소를 매핑
  • CoreDNS 장애를 재현해 DNS 기반 접근이 실패하는 상황을 경험
  • CoreDNS 파드를 재기동하여 정상 복구되는 것을 확인

이 과정을 통해 쿠버네티스 네트워크 문제의 상당수가 DNS와 관련이 있다는 점을 알 수 있었다.

느낀 점

이번 세미나는 단순히 듣는 강의가 아니라 문재을 재현하고 직접 해결해보는 실습이라 훨씬 재미있었다.
특히 tshark 같은 패킷 분석 도구를 처음 써봤는데 네트워크 흐름이 눈에 보이니까 훨씬 이해가 잘 되었다.
tshark는 설치하기도 간편해서 실무에서도 활용할 수 있을 것 같다.
이번 경험 덕분에 네트워크 이해의 폭이 조금 더 넓어진 것 같아 보람 있었다.

티스토리툴바