[k8s] 10. Namespace, ResourceQuota, LimitRange

Namespace, ResourceQuota, LimitRange

왜 써야하는가

• 쿠버네티스 클러스터는 사용할 수 있는 전체 자원이 있음
• 일반적으로 Memory, CPU가 자원임
• 클러스터 안에는 여러 네임스페이스를 만들 수 있고, 그 네임스페이스에는 여러 파드를 만들 수 있음
• 각 파드는 클러스터의 자원을 공유하여 사용
• 한 네임스페이스의 파드가 클러스터의 자원을 다 써버리면 다른 네임스페이스의 파드가 쓸 자원이 없는 문제 발생
• 이런 자원 관리를 ResourceQuota가 해줌
• ResourceQuota를 네임스페이스에 달면 네임스페이스마다 사용할 수 있는 자원의 최대 한계를 설정할 수 있음
• 한 파드가 자원 사용량을 너무 크게하면 다른 파드들이 네임스페이스에 들어오지 못함
• Limit Range를 설정하여 파드가 네임스페이스에 들어올 수 있는 자원의 크기를 제한함
• Limit Range와 Resource Quota는 쿠버네티스 클러스터에도 설정할 수 있음

1. Namespace

• 네임스페이스안 같은 타입의 오브젝트는 이름이 중복되면 안 됨
• 다른 네임스페이스의 자원과 분리되어서 관리됨
• PV나 Node는 네임스페이스가 공용으로 사용할 수 있음
• 네임스페이스를 지우면 네임스페이스 내의 자원도 지워짐
• 한 네임스페이스 파드에서 다른 네임스페이스의 파드의 아이피에 접근하면 기본적으로 연결이 됨 --> Network policy에서 제한 가능

Sample YAML

• 네임스페이스를 만들 땐, 이름외에 특별히 들어가는 값은 없음
• 파드나 서비스를 만들 땐, 속할 네임스페이스를 지정함
• 예시의 파드와 서비스는 네임스페이스가 서로 달라 라벨과 셀렉터의 nm이 같아도 연결되지 않음

2. ResourceQuota

• 네임스페이스의 자원한계를 설정하는 오브젝트
• ResourceQuota가 있는 네임스페이스에 파드를 만들 때, 파드에는 requests, limits의 스펙을 명시해야 함
• 파드를 추가할 때, 파드의 Requests, limits가 ResourceQuota에 명시된 request와 limits를 초과하게 되면 파드를 만들 땐 만들어지지 않음

Sample YAML

• ResourceQuota의 스펙에 hard라는 속성에 requests와 limits 속성이 들어감
• CPU, Memory 등의 Compute Resource 외에 Object Count도 제한할 수 있으며, 버전이 업그레이드 되면서 점점 제한할 수 있는게 늘어남

3. LimitRange

• 각각의 파드마다 네임스페이스에 들어올 수 있는지 자원을 확인
• min: 파드에서 설정되는 메모리의 limit이 0.1Gi를 넘어야 함
• max: 파드에서 설정되는 메모리의 limit이 0.4Gi를 초과하면 안 됨
• maxLimitRequestRatio: request와 limit의 비율이 3을 넘으면 안 됨
• Pod1은 메모리 초과해서 생성 안 됨
• Pod2는 requests와 limits의 비율이 3을 넘어서 안 됨
• defaultRequest: 파드에 아무런 스펙 설정을 하지 않으면 파드 생성 시 requests 사이즈로 설정됨
• default: 파드에 아무런 스펙 설정을 하지 않으면 파드 생성 시 limits 사이즈로 설정됨

Sample YAML

• LimitRange를 만들 때, 네임스페이스를 명시
• limits를 컨테이너별로 제한할 때 옵션들을 설정할 수 있음
• 파드단위와 PVC단위 각각 적용되는 설정 옵션이 다름

출처

인프런 - 대세는 쿠버네티스