8.1. 설정 리소스
어떨 때 보는가
- 파드를 만들려는데 자원 한도 초과 오류가 날 때
- 우리 팀이 쓸 수 있는 자원 상한을 확인할 때
- 자원을 요청하지 않았는데 값이 붙어 있을 때
- 자원을 만들려는데 알 수 없는 이유로 거부될 때
이 장의 설정은 대부분 운영 담당자가 정합니다. 사용자는 현재 값을 확인하는 용도로 봅니다.
리소스 쿼터
네임스페이스가 쓸 수 있는 자원의 상한 입니다. 관리 > 리소스 할당량 로 들어갑니다.
상세 화면에 항목별로 지금 쓰는 양과 상한이 나옵니다.
| 제한 대상 | 뜻 |
|---|---|
requests.cpu · requests.memory | 파드들이 요청한 양의 합계 |
limits.cpu · limits.memory | 파드들이 상한으로 잡은 양의 합계 |
pods | 파드 개수 |
persistentvolumeclaims | 저장 공간 요청 개수 |
services | Service 개수 |
requests.storage | 요청한 저장 공간 크기 합계 |
쿼터에 걸렸을 때
상한에 닿으면 새 자원을 만들 수 없고 한도 초과 오류가 납니다.
| 확인 순서 | 할 일 |
|---|---|
| 1 | 어느 항목이 한도에 닿았는지 상세에서 확인 |
| 2 | 쓰지 않는 자원을 정리 (멈춘 Deployment, 오래된 PVC) |
| 3 | 파드의 자원 요청량이 실제보다 과하지 않은지 확인 |
| 4 | 그래도 모자라면 운영 담당자에게 상한 조정 요청 |
쿼터가 걸린 네임스페이스 에서는 모든 파드에 자원 요청량이 있어야 합니다. 요청량 없는 파드는 만들어지지 않습니다. 리밋 레인지에 기본값이 있으면 자동으로 붙습니다.
빌드도 파드로 돌기 때문에 쿼터에 걸리면 빌드가 시작되지 않습니다(4.2 장).
리밋 레인지
파드 하나가 요청할 수 있는 자원의 범위 입니다. 관리 > 제한 범위 에서 봅니다.
| 항목 | 설명 |
|---|---|
| 최소 | 이보다 적게 요청할 수 없습니다 |
| 최대 | 이보다 많이 요청할 수 없습니다 |
| 기본 요청량 | 요청량을 적지 않으면 자동으로 붙는 값 |
| 기본 상한 | 상한을 적지 않으면 자동으로 붙는 값 |
리소스 쿼터와 역할이 다릅니다.
| 자원 | 무엇을 제한하나 |
|---|---|
| 리소스 쿼터 | 네임스페이스 전체 합계 |
| 리밋 레인지 | 파드 하나 의 범위 |
기본값이 설정되어 있으면 요청량을 적지 않아도 파드가 만들어집니다. 다만 자동 조절(HPA)은 요청량을 근거로 사용률을 계산하므로 명시하는 편이 좋습니다(3.5 장).
만들기 — YAML
이 둘은 보통 운영 담당자가 네임스페이스를 내줄 때 함께 만듭니다.
리소스 쿼터
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-quota
namespace: my-app
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
limits.cpu: "40"
limits.memory: 80Gi
pods: "50"
persistentvolumeclaims: "10"
requests.storage: 500Gi
services.loadbalancers: "2"
적은 항목만 제한합니다. pods 를 적지 않으면 파드 개수는 제한되지 않습니다.
requests.cpu 를 적으면 그 네임스페이스의 모든 파드에 요청량이 있어야 합니다. 없는
파드는 만들어지지 않습니다. 아래 리밋 레인지로 기본값을 함께 주는 이유입니다.
리밋 레인지
apiVersion: v1
kind: LimitRange
metadata:
name: team-limits
namespace: my-app
spec:
limits:
- type: Container
default: # 상한을 안 적으면 붙는 값
cpu: "1"
memory: 1Gi
defaultRequest: # 요청량을 안 적으면 붙는 값
cpu: 200m
memory: 256Mi
min: # 이보다 적게는 요청할 수 없습니다
cpu: 50m
memory: 64Mi
max: # 이보다 많이는 요청할 수 없습니다
cpu: "4"
memory: 8Gi
- type: PersistentVolumeClaim
min:
storage: 1Gi
max:
storage: 100Gi
| 항목 | 설명 |
|---|---|
type | Container · Pod · PersistentVolumeClaim |
default | 상한을 적지 않은 컨테이너에 자동으로 붙습니다 |
defaultRequest | 요청량을 적지 않은 컨테이너에 자동으로 붙습니다 |
min · max | 허용 범위. 벗어나면 파드가 거부됩니다 |
둘을 함께 만드는 것이 실무 조합입니다. 쿼터만 만들면 요청량 없는 파드가 전부 거부되어 사용자가 영문을 모른 채 막힙니다. 리밋 레인지로 기본값을 주면 아무것도 적지 않아도 파드가 뜨고, 쿼터는 합계로만 통제됩니다.
이미 떠 있는 파드에는 적용되지 않습니다. 기본값은 새로 만들어지는 파드에만 붙습니다.
우선순위 클래스
자원이 모자랄 때 어떤 파드를 먼저 남길지 정합니다. 관리 > 우선순위 클래스 에서 봅니다.
| 항목 | 설명 |
|---|---|
| 값 | 숫자가 클수록 우선순위가 높습니다 |
| 기본 여부 | 지정하지 않은 파드에 적용될지 |
| 선점 정책 | 자리가 없을 때 낮은 우선순위 파드를 밀어낼지 |
시스템 구성요소에는 높은 값이 미리 설정되어 있습니다. 애플리케이션에 시스템보다 높은 값을 주지 마십시오.
우선순위가 낮은 파드는 자원이 모자라면 밀려납니다. 밀려난 파드는 다른 노드에 다시 배치를
시도하지만, 클러스터 전체가 꽉 차 있으면 Pending 에 머뭅니다.
런타임 클래스
컨테이너를 실행하는 방식을 고릅니다. 관리 > 런타임 클래스 에서 등록된 목록을 봅니다.
보통 기본값 하나만 씁니다. GPU 를 쓰는 워크로드에는 별도 런타임이 지정되기도 합니다(8.3 장).
리스
구성요소가 여럿일 때 누가 대표로 일할지 정하는 잠금 장치입니다. 관리 > 리스 에서 봅니다.
사용자가 직접 다룰 일은 없습니다. 컨트롤러가 정상 동작하는지 확인할 때 참고합니다. 각 노드의
kubelet 도 리스를 갱신하며, 갱신이 멈추면 그 노드가 NotReady 로 바뀝니다.
웹훅 설정
자원을 만들거나 고칠 때 중간에서 검사하거나 값을 바꾸는 설정입니다.
| 종류 | 하는 일 | 예 |
|---|---|---|
| MutatingWebhookConfiguration | 요청 내용을 자동으로 고칩니다 | 사이드카 자동 주입, 기본 레이블 추가 |
| ValidatingWebhookConfiguration | 규칙에 맞는지 검사하고 맞지 않으면 거부합니다 | 보안 정책 검사, 이미지 출처 제한 |
관리 메뉴 아래에 각각 있습니다. 자원을 만들 때 예상하지 못한 값이 붙거나 거부당하면 여기에 등록된 웹훅을 확인하십시오.
웹훅이 요청을 거부할 때
오류 메시지에 웹훅 이름이 들어 있습니다. 그 이름으로 목록에서 찾아 무엇을 검사하는지 확인하십시오.
| 흔한 거부 사유 | 뜻 |
|---|---|
| Pod Security 위반 | 컨테이너가 요구하는 권한이 정책보다 높습니다 |
| 이미지 출처 제한 | 허용되지 않은 레지스트리의 이미지입니다 |
| 필수 레이블 누락 | 조직이 요구하는 레이블이 없습니다 |
웹훅을 담당하는 파드가 내려가 있으면 모든 요청이 거부되거나 아예 응답이 없을 수 있습니다. 갑자기 아무것도 만들 수 없게 되면 이 경우를 의심하고 운영 담당자에게 알리십시오.