[k8s] 리소스 제한: 디스크와 네트워크

관련 포스트
https://blog.naver.com/sssang97/223659644778
보통 리소스의 분배나 제한을 걸게되면 cpu/메모리를 기준으로 고려를 하는 경우가 대부분이다.

하지만 그게 리소스의 전부는 아니다. I/O 또한 CPU와 마찬가지로 사용량의 한도가 명확히 존재하는 자원이고, 경우에 따라서는 I/O에 대해서 제한을 걸고 싶을 수도 있는 것이다.

일단, 쿠버네티스 코어 모듈에서는 I/O limit과 관련된 기능을 직접적으로 제공하지 않는다. 추가 서드파티 지원을 찾거나 직접 뭔가를 만들어야 할 확률이 높다.

임시 디스크 공간 예약/제한

Pod의 임시 디스크 공간은 기본 Core 모듈에서 지원하는 영역에 속한다.
이건 Pod가 디스크를 얼마나 쓸지, 얼마나 제한할지를 정의할 수 있다. 사용법은 memory와 비슷하다.

resources:
  requests:
    ephemeral-storage: "1Gi"
  limits:
    ephemeral-storage: "2Gi"

이러면 쿠버네티스는 Pod가 1Gi 정도 쓴다고 가정하고 스케줄링을 시도한다. 디스크 용량을 고려해서 말이다.
그리고 2Gi에 도달하면 스로틀링을 건다. 2Gi를 쓴 상태에서 추가 쓰기를 시도하면 "No space left on device"와 같은 오류를 보게 될 것이다.

디스크 I/O 제한 (Disk IOPS)

그럼 디스크에 대한 접근 횟수를 제한하려고 하면 어떻게 할 수 있을까?
AWS의 EBS만 하더라도 초당 I/O 성능(IOPS)에 대한 제한을 빡세게 걸고 확장 비용을 받는다. 그만큼 확장에 어려움이 있는 리소스라는 것이다.

만약 AWS 같은 클라우드를 쓴다고 하면 그냥 명시적으로 제한하거나 돈 더 내서 늘릴 수 있지만, 온프레미스 클러스터에서는 그렇게 쉽지는 않다.

상기했듯 이건 쿠버네티스의 기본 기능이 아니기 때문에, 별도 스토리지 계층에서의 기능 지원이 필요하다.
IOPS 제한을 지원하는 시스템은 대표적으로 오픈소스 스토리지 시스템인 ceph가 있다.
ceph RBD를 사용하면 특정 볼륨 마운트(PVC)나, 그룹(pool) 단위로 IOPS 제한을 걸 수 있다.

ceph가 이런저런 고통스런 관리 지점들이 많음에도 쓰는 이유가, 이런 고급 기능이 많기 때문이다.

네트워크 I/O 제한 (bandwidth)

디스크 I/O 제한을 구성하는 방법이 스토리지 시스템(Ceph)에 종속적인 것과 마찬가지로, 네트워크에 대한 고급 제어 기능들도 CNI에 매여있다.
그래서 어떤 CNI 구성을 쓰는지에 따라서 제한이 불가능할 수도 있고, 가능한 기능 범위도 다를 수 있다.

근데 그래도 이건 쿠버에서 공식적으로 정의해둔 인터페이스가 있더라.

이런 식이다. engress는 아웃바운드 트래픽에 대한 제한, ingress는 인바운드 트래픽에 대한 제한이다.
cpu limit과 마찬가지로 정의한 수치를 초과하면 스로틀링을 건다.

그리고 다른 리소스들과는 다르게 스케줄링을 위한 request 값이 없다.

k3s에서 쓰는 flannel은 기본적으로 이와 같은 기능을 제공하지 않는다. 추가 플러그인을 설치하면 될 수도 있는데, 그게 기본값은 아니다. 그래서 이런 고급 기능이 필요한 사례에는 그닥 맞지 않는다.

calico는 관련된 기본 모듈에 포함되어있다. 즉시 limit을 구성해서 사용할 수 있다.
Cilium도 calico와 마찬가지로 기본 지원한다.

참조
https://github.com/kubernetes/kubernetes/issues/92287
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
https://gemtd-dev.tistory.com/127
https://kubernetes.io/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/