Eraser

Eraser

[CS] 리눅스 커널 파라미터와 sysctl

· 11 분 소요


Kubernetes를 학습하다 보면 커널 파라미터가 끊임없이 등장한다. 클러스터를 구성할 때마다 net.bridge.bridge-nf-call-iptables, net.ipv4.ip_forward를 설정해야 하고, 컨테이너 환경에서 vm.swappiness를 조정해야 한다는 이야기도 심심치 않게 들린다. 워커 노드의 /etc/sysctl.d/를 들여다보니 번호가 붙은 설정 파일들이 여러 개 있고, 누가 어떤 순서로 적용하는지도 궁금해졌다. 간단하게라도 정리해 본다.


TL;DR

  • 커널 파라미터: 리눅스 커널의 동작을 런타임에 조정하는 설정 값이다. net.*, vm.*, fs.*, kernel.* 등의 네임스페이스로 분류된다.
  • sysctl: 커널 파라미터를 조회·변경하는 인터페이스로, 모든 Linux 배포판에서 동일하게 동작한다.
  • 커널 파라미터 설정값: /etc/sysctl.d/의 .conf 파일들은 번호 → 알파벳 순서로 로드되며, 같은 파라미터가 여러 파일에 있으면 나중에 읽힌 값이 이긴다.
  • 컨테이너 환경에서의 커널 파라미터: VM과 달리 컨테이너는 자체 커널 없이 호스트 커널을 공유하므로, 커널 파라미터 설정이 모든 컨테이너에 직접 영향을 미친다. Kubernetes 환경에서 IP 포워딩, 브릿지, 메모리 오버커밋 등의 설정이 필수적인 이유다.


리눅스 커널 파라미터

커널 파라미터란

리눅스 커널은 OS의 핵심으로, 하드웨어·네트워크·메모리·프로세스 등을 관리한다. 커널 파라미터는 이러한 커널의 동작 방식을 런타임에 조정할 수 있는 설정 값이다. 커널을 다시 컴파일하거나 재부팅하지 않고도 동작을 바꿀 수 있다.

대부분의 커널 파라미터는 런타임에 변경 가능하지만, 일부 파라미터는 부팅 시에만 설정되거나 read-only로 노출되어 sysctl -w로 변경할 수 없는 경우도 있다. 변경 시 sysctl: setting key "...": Invalid argument 등의 에러가 발생하면 해당 파라미터의 변경 가능 여부를 확인해야 한다.

예를 들어:

  • net.ipv4.ip_forward = 1 → IP 패킷 포워딩 활성화 (라우터·컨테이너 환경 필수)
  • vm.overcommit_memory = 1 → 메모리 오버커밋 정책 제어
  • fs.file-max = 1048576 → 시스템 전체 최대 열린 파일 수 제한

/proc/sys/와 procfs

커널 파라미터는 /proc/sys/ 디렉토리를 통해 노출된다. /proc/는 procfs(proc filesystem)라는 가상 파일시스템으로, 디스크에 실제 파일이 저장되어 있는 것이 아니라 커널이 메모리 상의 내부 데이터를 파일처럼 보여주는 인터페이스다. 파일을 읽으면 커널이 그 시점의 값을 동적으로 생성해서 반환하고, 파일에 쓰면 커널이 해당 값을 즉시 변경한다.

/proc/ 전체가 커널 정보를 노출하는 가상 파일시스템이고, 그 중 /proc/sys/ 하위가 런타임에 변경 가능한 커널 파라미터를 담당한다. 후술할 sysctl 명령어는 결국 이 /proc/sys/ 하위 파일을 읽고 쓰는 래퍼(wrapper)다.

# procfs 마운트 확인
mount | grep proc
# proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

# /proc/sys/ 하위의 최상위 디렉토리 = 네임스페이스
ls /proc/sys/
# abi  crypto  debug  dev  fs  kernel  net  sunrpc  user  vm

네임스페이스

커널 파라미터는 관리 영역별 네임스페이스로 분류되며, /proc/sys/ 하위 디렉토리 구조가 이 네임스페이스를 그대로 반영한다.

네임스페이스 /proc/sys/ 경로 관리 영역 대표 파라미터
kernel /proc/sys/kernel/ 프로세스, 스케줄링, 패닉 kernel.panic, kernel.pid_max
vm /proc/sys/vm/ 가상 메모리, 스왑, 페이지 캐시 vm.swappiness, vm.overcommit_memory
net /proc/sys/net/ 네트워크 스택 (IPv4, IPv6, bridge 등) net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables
fs /proc/sys/fs/ 파일시스템, 파일 디스크립터 fs.file-max, fs.inotify.max_user_watches
dev /proc/sys/dev/ 디바이스 드라이버 dev.cdrom.autoclose 
# 네임스페이스별 파라미터 수 확인
sysctl -a 2>/dev/null | grep -c ^kernel   # kernel.*
sysctl -a 2>/dev/null | grep -c ^vm       # vm.*
sysctl -a 2>/dev/null | grep -c ^net      # net.*
sysctl -a 2>/dev/null | grep -c ^fs       # fs.*


sysctl

sysctl이란

sysctl은 커널 파라미터를 런타임에 조회·변경하는 인터페이스다. 내부적으로 /proc/sys/ 디렉토리의 가상 파일을 읽고 쓴다.

# 조회
sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 1

# 같은 값을 /proc/sys/로 직접 조회
cat /proc/sys/net/ipv4/ip_forward
# 1

sysctl 명령어의 파라미터 이름에서 .은 /proc/sys/ 하위의 디렉토리 구분자(/)에 대응한다.

sysctl 파라미터 /proc/sys/ 경로
net.ipv4.ip_forward /proc/sys/net/ipv4/ip_forward
vm.overcommit_memory /proc/sys/vm/overcommit_memory
kernel.panic /proc/sys/kernel/panic
fs.file-max /proc/sys/fs/file-max

배포판 호환성

sysctl은 Linux 커널이 제공하는 /proc/sys/ 인터페이스를 사용하므로, Ubuntu, RHEL, Rocky, Amazon Linux, Debian, SUSE 등 모든 Linux 배포판에서 동일하게 동작한다. procps 패키지(또는 procps-ng)에 포함되어 있으며 사실상 모든 배포판에 기본 설치된다.

다만 배포판마다 다를 수 있는 것들이 있다:

  • 기본값: 배포판에 따라 다를 수 있음 (예: vm.dirty_ratio 등)
  • 커널 버전에 따른 파라미터 차이: 새 커널에서 파라미터가 추가되거나 동작이 변경될 수 있음
  • 설정 파일 경로 관례: /etc/sysctl.conf만 사용하는 구형 배포판 vs /etc/sysctl.d/를 지원하는 최신 배포판

BSD 계열(macOS, FreeBSD)에도 sysctl 명령어가 있지만 파라미터 체계가 다르다. 이 글에서 다루는 내용은 Linux sysctl에 한정한다.


설정 파일 체계와 로드 순서

커널 파라미터를 변경하는 방법을 이해하려면, 먼저 설정 파일이 어디에 있고 어떤 순서로 읽히는지를 알아야 한다.

설정 파일 디렉토리

커널 파라미터의 영구 설정은 여러 디렉토리에 분산될 수 있다. sysctl --system 실행 시(또는 부팅 시) 아래 디렉토리들에서 .conf 파일을 수집한다.

경로 용도
/usr/lib/sysctl.d/ 패키지·배포판 기본값 (패키지 관리자가 관리, 직접 수정 비권장)
/run/sysctl.d/ 런타임 생성 설정 (임시, 재부팅 시 사라짐)
/etc/sysctl.d/ 관리자 커스텀 설정 (가장 많이 사용)
/etc/sysctl.conf 전통적 설정 파일 (항상 마지막에 적용되는 특수 케이스)

관리자가 커스텀 설정을 넣을 때는 /etc/sysctl.d/에 파일을 추가하는 것이 권장된다.

로드 순서: 파일명 기준 머지

핵심 규칙은 디렉토리 순서가 아니라 파일명 순서다. 모든 디렉토리의 .conf 파일을 한데 모은 뒤, 파일명의 문자열(lexicographic) 정렬 순서대로 적용한다. 같은 파라미터가 여러 파일에 있으면 나중에 적용된 파일의 값이 덮어쓴다. /etc/sysctl.conf만 예외로 항상 마지막에 적용된다.

예를 들어 /etc/sysctl.d/00-defaults.conf와 /usr/lib/sysctl.d/10-default-yama-scope.conf가 있으면, /etc/sysctl.d/가 “나중” 디렉토리임에도 파일명 00-*이 10-*보다 앞이므로 00-defaults.conf가 먼저 적용된다.

같은 파일명이 여러 디렉토리에 존재하는 경우에만 디렉토리 우선순위가 적용된다. /etc/sysctl.d/가 /run/sysctl.d/를, /run/sysctl.d/가 /usr/lib/sysctl.d/를 이긴다. 우선순위가 낮은 쪽의 동명 파일은 무시된다.

파일명 규칙

파일명에 대해 systemd가 강제하는 형식 제한은 없다. 100-custom.conf, 999-override.conf 같은 세 자리 이상의 숫자도 유효하고, 숫자 없이 custom.conf처럼 문자로 시작하는 파일명도 정상적으로 로드된다. 문자열 정렬에서 숫자(0-9)가 알파벳(a-z)보다 앞이므로, 숫자로 시작하는 파일이 먼저 로드되고 문자로 시작하는 파일이 그 뒤에 온다.

다만, 정렬이 숫자 크기가 아닌 문자열 기준이라는 점이 중요하다. 두 자리 숫자(00-99) 범위에서는 문자열 순서와 숫자 순서가 일치하지만, 세 자리 이상을 섞으면 의도와 다르게 동작할 수 있다.

# 문자열 정렬 순서 (숫자 크기 순서가 아님)
100-custom.conf      # "1" < "2"이므로 20보다 앞
20-defaults.conf
50-default.conf
99-amazon.conf
custom.conf          # 문자로 시작 → 숫자 뒤에 정렬

위 예시에서 100-custom.conf는 숫자상 100이지만, 문자열 "1" < "2"이므로 20-defaults.conf보다 앞에 로드된다.

번호 대역 관례

실무에서는 관례적으로 00-99 두 자리 숫자를 사용한다.

  • 대부분의 배포판과 패키지가 두 자리 컨벤션을 따름
  • 두 자리 범위에서는 문자열 순서와 숫자 순서가 일치하므로 직관적
  • 세 자리 이상이 필요할 만큼 파일이 많아지면, 설정 관리 자체를 재고해야 할 신호

번호 대역 별 용도도 관례적으로 정해져 있다.

번호 대역 관례적 용도
00-09 시스템 최초 기본값
10-29 배포판 기본값, 보안 정책
50 시스템 기본 설정
70-89 서비스별 설정 (Kubernetes, Docker 등)
99 최종 오버라이드 — 여기 설정이 최종 승리

핵심은 나중에 읽힌 값이 이긴다는 것이다. 최종적으로 적용하고 싶은 설정은 99번대에 넣는다.

같은 번호 내 알파벳 순서

같은 번호의 파일이 여러 개 있으면 파일명 알파벳 순서대로 로드된다.

# 예: EKS 워커 노드의 /etc/sysctl.d/
tree /etc/sysctl.d
# /etc/sysctl.d
# ├── 00-defaults.conf
# ├── 99-amazon.conf
# ├── 99-kubernetes-cri.conf
# └── 99-sysctl.conf -> ../sysctl.conf

이 경우 99번대 파일의 로드 순서는 99-amazon.conf → 99-kubernetes-cri.conf → 99-sysctl.conf(알파벳: a < k < s)이다.

파라미터 충돌 시 동작

같은 파라미터가 여러 파일에 있어도 에러가 발생하지 않는다. 나중에 읽힌 값이 조용히 덮어쓸 뿐이다.

# 99-amazon.conf
vm.overcommit_memory = 1

# 99-sysctl.conf (= /etc/sysctl.conf)
vm.overcommit_memory = 0

위 경우 99-sysctl.conf가 알파벳 순서상 나중이므로(s > a) 최종 적용값은 0이 된다.

이 동작은 의도적인 오버라이드에 활용할 수 있지만, 같은 번호 내에서 알파벳 순서를 인지하지 못하면 의도치 않은 덮어쓰기가 발생할 수 있다. 같은 번호대에 여러 파일이 있을 때는 파라미터가 겹치지 않도록 관리하거나, 겹칠 경우 알파벳 순서를 명확히 인지해야 한다.

실제 로드 순서 확인: sysctl –system 출력

sysctl --system을 실행하면 어떤 파일을 어떤 순서로 로드했는지 출력되므로, 위에서 설명한 규칙이 실제로 어떻게 적용되는지 직접 확인할 수 있다. 아래는 EKS 워커 노드(Amazon Linux 2023)에서의 실제 출력 예시다.

[root@ip-192-168-2-21 ~]# sysctl --system
* Applying /etc/sysctl.d/00-defaults.conf ... # 00번대
kernel.printk = 8 4 1 7
kernel.panic = 5
net.ipv4.neigh.default.gc_thresh1 = 0
...
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ... # 10번대
kernel.yama.ptrace_scope = 0
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
...
* Applying /usr/lib/sysctl.d/50-default.conf ... # 50번대
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
sysctl: setting key "net.ipv4.conf.all.rp_filter": Invalid argument
...
* Applying /usr/lib/sysctl.d/60-amazon-linux-coredump.conf ... # 60번대
fs.suid_dumpable = 0
* Applying /etc/sysctl.d/99-amazon.conf ... # 99번대
vm.overcommit_memory = 1
kernel.panic = 10
kernel.panic_on_oops = 1
* Applying /etc/sysctl.d/99-kubernetes-cri.conf ...
net.ipv4.ip_forward = 1
* Applying /etc/sysctl.d/99-sysctl.conf ...
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 8192
vm.max_map_count = 524288
kernel.pid_max = 4194304
* Applying /etc/sysctl.conf ... # sysctl.conf
fs.inotify.max_user_watches = 524288
...

출력에서 확인할 수 있는 것들을 살펴 보자.

  • 파일명 기준 머지: /etc/sysctl.d/00-defaults.conf가 /usr/lib/sysctl.d/10-*보다 먼저 적용된다. 디렉토리가 다르지만 파일명 00-*이 10-*보다 앞이기 때문이다. 이후 50-*, 60-*, 99-* 순으로 모든 디렉토리의 파일이 파일명 순서대로 적용되고, /etc/sysctl.conf가 마지막에 온다.
  • 파라미터 덮어쓰기: kernel.panic이 00-defaults.conf에서 5로 설정된 후 99-amazon.conf에서 10으로 덮어쓰인다.
  • 에러 처리: 50-default.conf 로드 시 sysctl: setting key "net.ipv4.conf.all.rp_filter": Invalid argument 에러가 출력되는데, 이는 해당 파라미터가 현재 커널에서 해당 값을 지원하지 않는 경우다. 이런 에러는 설정이 무시될 뿐 시스템 동작에는 영향을 주지 않는다.


조회·변경 방법

설정 파일 체계를 이해했으니, 실제로 커널 파라미터를 조회하고 변경하는 방법을 알아보자.

조회

설정 파일이 여러 곳에 분산되어 있어도, 실제로 커널에 적용된 최종값은 sysctl 명령어로 한 번에 확인할 수 있다.

# 전체 파라미터 조회
sysctl -a

# 특정 파라미터 확인
sysctl net.bridge.bridge-nf-call-iptables
# net.bridge.bridge-nf-call-iptables = 1

# 네임스페이스별 필터링
sysctl -a | grep ^net.bridge
sysctl -a | grep ^vm
sysctl -a | grep ^kernel

/proc/sys/ 파일을 직접 읽어도 같은 값을 확인할 수 있다.

cat /proc/sys/net/bridge/bridge-nf-call-iptables

런타임(임시) 변경

sysctl -w 또는 /proc/sys/ 파일에 직접 쓰면 즉시 반영되지만, 재부팅하면 사라진다.

# sysctl -w로 변경
sysctl -w net.ipv4.ip_forward=1

# /proc/sys/에 직접 쓰기 (동일한 효과)
echo 1 > /proc/sys/net/ipv4/ip_forward

영구 변경

설정 파일에 기록하면 부팅 시 자동 적용된다. 앞서 설명한 디렉토리 중 관리자가 커스텀 설정을 넣는 곳은 /etc/sysctl.d/이며, 전통적인 /etc/sysctl.conf도 사용할 수 있다.

# /etc/sysctl.d/에 설정 파일 생성
cat <<EOF | tee /etc/sysctl.d/99-k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
EOF

# 모든 설정 파일 다시 로드 (재부팅 없이 즉시 적용)
sysctl --system
명령어 동작
sysctl --system 모든 디렉토리의 설정 파일을 로드 순서대로 다시 적용
sysctl -p <파일> 특정 파일 하나만 로드


컨테이너·Kubernetes 환경에서의 중요성

왜 커널 파라미터가 중요한가

컨테이너는 VM과 달리 호스트 커널을 공유한다. 컨테이너 내부에서 별도 커널을 실행하는 것이 아니라, 호스트의 커널 파라미터가 모든 컨테이너의 동작에 직접 영향을 미친다.

Kubernetes 환경에서는 Pod 간 네트워킹, 브릿지 트래픽 처리, IP 포워딩 등이 커널 수준에서 동작하기 때문에 커널 파라미터 설정이 필수적이다. 설정이 누락되면 Pod 간 통신 실패, Service 접근 불가 등의 문제가 발생한다.

Kubernetes에서 자주 설정하는 파라미터

파라미터 값 이유
net.ipv4.ip_forward 1 Pod 간 패킷 라우팅에 필수. 커널 기본값은 0(포워딩 비활성)
net.bridge.bridge-nf-call-iptables 1 브릿지 트래픽이 iptables 규칙을 거치도록 함. Service ClusterIP 라우팅에 필수
net.bridge.bridge-nf-call-ip6tables 1 IPv6 브릿지 트래픽에 ip6tables 적용
vm.overcommit_memory 1 kubelet(Go 런타임)의 대규모 가상 메모리 예약이 거부되지 않도록 함
kernel.panic 10 커널 패닉 시 10초 후 자동 재부팅으로 노드 복구
vm.panic_on_oom 0 OOM 시 커널 패닉 대신 OOM Killer가 처리

각 파라미터의 상세 설명은 Kubernetes 시리즈 글에서 다루고 있다:

kubelet의 커널 파라미터 자동 설정

kubelet은 시작 시 kernel.panic, vm.overcommit_memory 등을 자동으로 설정한다(--protect-kernel-defaults=false일 때). 이 설정은 sysctl -w로 런타임에 적용하는 것이므로 /etc/sysctl.d/의 파일 체계와 별개로 동작한다. 재부팅 후에도 값이 유지되는 것은 kubelet이 매번 시작할 때마다 다시 설정하기 때문이다.

반면 Kubespray 같은 배포 도구는 /etc/sysctl.d/99-sysctl.conf에 파라미터를 영구 기록한다. 이 경우 kubelet이 아닌 systemd가 부팅 시 적용하므로, kubelet 시작 전에도 값이 설정되어 있다.

Pod 수준 sysctl (safe/unsafe sysctl)

호스트 커널을 공유한다고 해서 Pod에서 커널 파라미터를 전혀 조정할 수 없는 것은 아니다. Linux namespace로 격리되는 일부 파라미터는 Pod의 securityContext.sysctls를 통해 Pod 단위로 설정할 수 있다.

Kubernetes는 이를 safe sysctl과 unsafe sysctl로 구분한다.

구분 설명 예시
Safe namespace로 격리되어 다른 Pod·호스트에 영향 없음. 기본 허용 kernel.shm_rmid_forced, net.ipv4.ping_group_range
Unsafe 호스트나 다른 Pod에 영향을 줄 수 있음. kubelet의 --allowed-unsafe-sysctls 플래그로 명시적 허용 필요 net.core.somaxconn, net.ipv4.ip_local_port_range 
# Pod spec에서 safe sysctl 설정 예시
apiVersion: v1
kind: Pod
spec:
  securityContext:
    sysctls:
    - name: net.ipv4.ping_group_range
      value: "0 65535"

unsafe sysctl을 허용하려면 kubelet 설정에서 명시적으로 지정해야 한다.

# kubelet 설정 예시
--allowed-unsafe-sysctls="net.core.somaxconn,net.ipv4.ip_local_port_range"

앞서 다룬 net.ipv4.ip_forward, vm.overcommit_memory 같은 파라미터는 namespace로 격리되지 않으므로 Pod 수준에서 설정할 수 없고, 반드시 호스트(노드) 수준에서 설정해야 한다.

/etc/sysctl.d/ 파일 체계를 이해해야 하는 이유

컨테이너·Kubernetes 환경에서 /etc/sysctl.d/의 로드 순서를 이해하는 것이 운영·트러블슈팅에서 중요하다.

  • 배포판 기본값, 클라우드 벤더 설정, CRI 설정, 사용자 커스텀 설정이 여러 파일에 분산됨
  • 어떤 파일이 어떤 순서로 로드되어 최종 값을 결정하는지 알아야 문제를 추적할 수 있음
  • 예: EKS에서 99-amazon.conf와 99-kubernetes-cri.conf가 공존할 때, 파라미터 충돌 여부와 최종 적용값을 판단하려면 알파벳 순서 규칙을 알아야 함


자주 나오는 트러블슈팅 사례

파일 디스크립터 부족 (Too many open files)

프로세스가 열 수 있는 파일 수 제한에 걸리면 Too many open files 에러가 발생한다. 고부하 서버, 많은 Pod를 실행하는 Kubernetes 노드에서 흔히 발생한다.

관련 파라미터는 커널 계층(sysctl)과 사용자 공간 계층(ulimit)으로 나뉜다:

계층 파라미터 기본값 설명
커널(시스템 전체) fs.file-max 커널·메모리 크기에 따라 자동 계산 시스템 전체에서 열 수 있는 최대 파일 디스크립터 수
커널(프로세스당) fs.nr_open 일반적으로 1048576 단일 프로세스가 열 수 있는 파일 디스크립터 수의 상한
사용자 공간 ulimit -n 배포판·설정에 따라 다름 셸·프로세스별 실제 제한 (/etc/security/limits.conf 또는 systemd LimitNOFILE로 설정)

fs.file-max은 sysctl로, ulimit -n은 limits.conf나 systemd 유닛 파일의 LimitNOFILE로 설정한다.

# 시스템 전체 제한 확인
sysctl fs.file-max
# fs.file-max = 9223372036854775807

# 프로세스당 상한 확인
sysctl fs.nr_open
# fs.nr_open = 1048576

# 현재 열린 파일 수 확인
cat /proc/sys/fs/file-nr
# 3520    0    9223372036854775807
# (사용 중 / 할당 후 미사용 / 최대)

Kubernetes 노드에서 수백 개의 Pod가 실행되면 파일 디스크립터 소비가 급격히 늘어나므로, fs.file-max과 LimitNOFILE을 충분히 높여두어야 한다.

inotify watch 부족

많은 파일을 감시(watch)하는 워크로드에서 inotify_add_watch: no space left on device 에러가 발생할 수 있다. IDE, 파일 동기화 도구, Kubernetes의 ConfigMap/Secret 마운트 등이 inotify를 사용한다.

# 현재 제한 확인
sysctl fs.inotify.max_user_watches
# fs.inotify.max_user_watches = 8192

# 늘리기 (런타임)
sysctl -w fs.inotify.max_user_watches=524288

# 영구 설정
echo "fs.inotify.max_user_watches=524288" | tee /etc/sysctl.d/99-inotify.conf

conntrack 테이블 가득 참

Kubernetes Service(ClusterIP, NodePort)는 커널의 conntrack(연결 추적) 모듈을 사용한다. 트래픽이 많은 클러스터에서 conntrack 테이블이 가득 차면 패킷이 drop되며, dmesg에 다음과 같은 로그가 남는다.

nf_conntrack: table full, dropping packet

# conntrack 최대 크기 확인
sysctl net.netfilter.nf_conntrack_max
# net.netfilter.nf_conntrack_max = 131072

# 현재 사용량 확인
sysctl net.netfilter.nf_conntrack_count

# dmesg에서 conntrack 관련 로그 확인
dmesg | grep conntrack

nf_conntrack_max의 기본값은 커널이 시스템 메모리 크기에 비례하여 자동 계산한다. 트래픽이 많은 환경에서는 이 값을 늘리고, nf_conntrack_tcp_timeout_established 등 타임아웃 값을 조정하여 오래된 연결이 빨리 정리되도록 한다.

브릿지·IP 포워딩 미설정

Kubernetes 노드 사전 설정에서 가장 흔한 실수다. net.bridge.bridge-nf-call-iptables나 net.ipv4.ip_forward가 0이면 Pod 간 통신이나 Service 접근이 실패한다.

# 확인
sysctl net.bridge.bridge-nf-call-iptables
sysctl net.ipv4.ip_forward

# 둘 다 1이어야 함

특히 net.bridge.bridge-nf-call-iptables는 br_netfilter 커널 모듈이 로드되어 있어야 파라미터 자체가 존재한다. 모듈 미로드가 이 파라미터 설정 실패의 가장 흔한 원인이다.

# br_netfilter 모듈 로드 확인
lsmod | grep br_netfilter

# 모듈이 없으면 로드
modprobe br_netfilter

# 재부팅 후에도 자동 로드되도록 설정
echo "br_netfilter" | tee /etc/modules-load.d/br_netfilter.conf


결론

커널 파라미터는 결국 리눅스 커널의 튜닝 노브다. 어떤 파라미터가 있고, 어떻게 조회·설정하며, 설정 파일이 어떤 순서로 로드되는지를 알면 대부분의 상황에 대응할 수 있다.

특히 컨테이너·Kubernetes 환경에서는 호스트 커널 하나를 모든 컨테이너가 공유하므로, 커널 파라미터 하나가 노드 전체에 영향을 미친다. 클러스터를 구성할 때마다 반복적으로 등장하는 ip_forward, bridge-nf-call-iptables, vm.overcommit_memory 같은 설정들이 왜 필요한지, 그리고 /etc/sysctl.d/에 여러 파일이 공존할 때 최종적으로 어떤 값이 적용되는지를 이해하면, 설정 누락이나 의도치 않은 덮어쓰기로 인한 트러블슈팅 시간을 크게 줄일 수 있다.


참고 자료

추후 필요할 때 아래 자료를 참고하면 좋다.



이 글을 참조하는 글



hit count

댓글남기기

참고