쿠버네티스 클러스터에서 sysctl 사용하기
Kubernetes v1.21 [stable]
이 문서는 쿠버네티스 클러스터에서 sysctl 인터페이스를 사용하여 커널 파라미터를 어떻게 구성하고, 사용하는지를 설명한다.
시작하기 전에
쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.
일부 단계에서는 실행 중인 클러스터의 kubelet에서 커맨드 라인 옵션을 재구성할 필요가 있다.
모든 sysctl 파라미터 나열
리눅스에서 sysctl 인터페이스는 관리자들이 런타임에 커널 파라미터를 수정할 수 있도록
허용한다. 파라미터는 /proc/sys 가상 파일 시스템을 통해 이용할 수 있다. 파라미터는
다음과 같은 다양한 서브 시스템을 포함한다.
- 커널 (공통 접두사:
kernel.) - 네트워크 (공통 접두사:
net.) - 가상 메모리 (공통 접두사:
vm.) - MDADM (공통 접두사:
dev.) - 더 많은 서브 시스템은 커널 문서에 설명되어 있다.
모든 파라미터 리스트를 가져오려면 다음 명령을 실행한다.
sudo sysctl -a
unsafe sysctl 활성화하기
sysctl은 safe sysctl과 unsafe sysctl로 구성되어 있다. safe sysctl은 적절한 네임스페이스 뿐만 아니라 동일한 노드의 파드 사이에 고립 되어야 한다. 즉, 하나의 파드에 safe sysctl을 설정한다는 것은 다음을 의미한다.
- 노드의 다른 파드에 영향을 미치지 않아야 한다
- 노드의 상태를 손상시키지 않아야 한다
- CPU 또는 메모리 리소스가 파드의 리소스 제한에 벗어나는 것을 허용하지 않아야 한다
아직까지 대부분 네임스페이스된 sysctl은 safe sysctl로 고려되지 않았다.
다음 sysctl은 safe 명령을 지원한다.
kernel.shm_rmid_forced,net.ipv4.ip_local_port_range,net.ipv4.tcp_syncookies,net.ipv4.ping_group_range(Kubernetes 1.18 이후).
net.ipv4.tcp_syncookies 예시는 리눅스 커널 버전 4.4 또는 이하에서 네임스페이스되지 않는다.
kubelet이 더 고립된 방법을 지원하면 추후 쿠버네티스 버전에서 확장될 것이다.
모든 safe sysctl은 기본적으로 활성화된다.
모든 unsafe sysctl은 기본적으로 비활성화되고, 노드별 기본 클러스터 관리자에 의해 수동으로 메뉴얼로 허용되어야 한다. unsafe sysctl이 비활성화된 파드는 스케줄링되지만, 시작에 실패한다.
위의 경고를 염두에 두고 클러스터 관리자는 고성능 또는 실시간 애플리케이션 조정과 같은 매우 특수한 상황에 대해 특정 unsafe sysctl을 허용할 수 있다. unsafe sysctl은 kubelet 플래그를 사용하여 노드별로 활성화된다. 예를 들면, 다음과 같다.
kubelet --allowed-unsafe-sysctls \
'kernel.msg*,net.core.somaxconn' ...
Minikube의 경우, extra-config 플래그를 통해 이 작업을 수행할 수 있다.
minikube start --extra-config="kubelet.allowed-unsafe-sysctls=kernel.msg*,net.core.somaxconn"...
네임스페이스 sysctl만 이 방법을 사용할 수 있다.
파드에 대한 sysctl 설정
수많은 sysctl은 최근 리눅스 커널에서 네임스페이스 되어 있다. 이는 노드의 각 파드에 대해 개별적으로 설정할 수 있다는 것이다. 쿠버네티스의 파드 securityContext를 통해 네임스페이스 sysctl만 구성할 수 있다.
다음 sysctls는 네임스페이스로 알려져 있다. 이 목록은 이후 버전의 Linux 커널에서 변경될 수 있다.
kernel.shm*,kernel.msg*,kernel.sem,fs.mqueue.*,net.*아래의 파라미터는 컨테이너 네트워킹 네임스페이스에서 설정할 수 있다. 그러나 예외가 존재한다. (예,net.netfilter.nf_conntrack_max와net.netfilter.nf_conntrack_expect_max는 컨테이너 네트워킹 네임스페이스에서 설정되지만, 네임스페이스가 없다.)
네임스페이스가 없는 sysctl은 node-level sysctl이라고 부른다. 이를 설정해야 한다면, 각 노드의 OS에서 수동으로 구성하거나 특권있는 컨테이너의 데몬셋을 사용하여야 한다.
네임스페이스 sysctl을 구성하기 위해서 파드 securityContext를 사용한다. securityContext는 동일한 파드의 모든 컨테이너에 적용된다.
이 예시는 safe sysctl kernel.shm_rmid_forced와 두 개의 unsafe sysctl인
net.core.somaxconn 과 kernel.msgmax 를 설정하기 위해 파드 securityContext를 사용한다.
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
spec:
securityContext:
sysctls:
- name: kernel.shm_rmid_forced
value: "0"
- name: net.core.somaxconn
value: "1024"
- name: kernel.msgmax
value: "65536"
...
특별한 sysctl 설정이 있는 노드를 클러스터 내에서 _tainted_로 간주하고 sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다. 이를 구현하려면 쿠버네티스 테인트(taint)와 톨러레이션(toleration) 기능 을 사용하는 것이 좋다.
두 unsafe sysctl을 명시적으로 활성화하지 않은 노드에서 unsafe sysctl을 사용하는 파드가 시작되지 않는다. node-level sysctl과 마찬가지로 테인트와 톨러레이션 특징 또는 노드 테인트를 사용하여 해당 파드를 오른쪽 노드에 스케줄하는 것을 추천한다.
파드시큐리티폴리시(PodSecurityPolicy)
Kubernetes v1.21 [deprecated]
또한 파드시큐리티폴리시의 forbiddenSysctls 및/또는 allowedUnsafeSysctls 필드에
sysctl 또는 sysctl 패턴 목록을 지정하여 파드에서 설정할
수 있는 sysctl를 제어할 수 있다. sysctl 패턴은 kernel.*과 같은 *
문자로 끝난다. * 문자 자체는
모든 sysctl와 일치한다.
기본적으로 모든 safe sysctl은 허용된다.
forbiddenSysctls와 allowedUnsafeSysctls는 모두 단순한 sysctl 이름 또는
sysctl 패턴 목록이다(*로 끝남). * 문자는 모든 sysctl과 일치한다.
forbiddenSysctls 필드에는 특정 sysctl이 제외된다.
목록에서 safe sysctl과 unsafe sysctl의 조합을 금지할 수 있다.
sysctl 설정을 금지하기 위해서는 *를 사용한다.
allowedUnsafeSysctls 필드에 unsafe sysctl을 지정하고 forbiddenSysctls 필드가
존재하지 않는 경우, 파드시큐리티폴리시를 사용하여
sysctl을 파드에서 사용할 수 있다.
파드시큐리티폴리시의 모든 unsafe sysctl을 설정하려면 *를 사용한다.
이 두 필드를 겹치도록 구성하지 않는다. 이는 지정된 sysctl이 허용 및 금지됨을 의미한다.
이 예에서는 kernel.msg 접두사가 붙은 unsafe sysctl을 설정할 수 있으며,
kernel.shm_rmid_forced sysctl의 설정을 허용하지 않는다.
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: sysctl-psp
spec:
allowedUnsafeSysctls:
- kernel.msg*
forbiddenSysctls:
- kernel.shm_rmid_forced
...