쿠버네티스에서의 리소스
apiVersion: v1 kind: Pod metadata: name: requests-pod spec: containers: - image: busybox command: ["dd", "if=/dev/zero", "of=/dev/null"] name: main resources: requests: #미니멈 개념, 최소 X가 필요하다. cpu: 200m #200밀리코어 memory: 10Mi #10메가
## pod A가 request설정, pod B도 request설정 pod C도 request설정 그러나 실제 usage는 너무 작다
## 즉, 실제 CPU사용량은 request와는 무관하다.(작을수도, 클수도)
## 하지만! Scheduler가 pod를 배포할 수있을까 말까는 request값에 따라 pod 배포여부를 결정한다. 넘어가버리면 배포를 안함
## request 합은 100을 넘지 못한다. - request sum can not over 100
POD 리소스 전략
## LeastRequestedPriority : 최대한 node에 분산배포한다.
## MostRequestedPriority : request가 한 node로 몰아버린다. aws와 같이 node당 과금이 일어날때 node 최소화할때 사용하면됨. 그러나 병목이 일어날 가능성이 있다!!
## request에 대비하여 실제 usage가 넘어버리면 request의 비율로 몰아버린다.
POD 리소스 limit 설정
## 말그대로 최대값을 제한
## vm vs container에서의 memory : vm에서 memory를 제한걸면 아에 커널에서부터 제한됨, 그러나 컨테이너에서는 실제 node의 memory가 보임. 그래서 process가 수시로 제한된 memory를 넘기려고함. -> 해결방법 : kill
## 그래서, limit을 지나버리면 pod을 restart(kill and start)시켜버린다.
(너무 작게 하면 안됨, 그렇다고 너무 크게 해도 문제, cpu는 상관없음. hz조절 알아서 잘함)
## request를 안주고 limit만 해버리면? limit의 값을 request라고 판단함. 반드시 두개다 설정하는게 가장 좋다.
POD 리소스가 딸릴때 우선순위?
## pod에 대한 QOS classes : BestEffort, Burstable, Guaranteed
## 리소스가 딸려서 위급한 상황에서 죽이는 놈들을 판단하여 죽인다. 즉, process kill 순서임
## BestEffort(가장 우선적으로 죽음) : request나 limit을 둘다 설정하지 않은 애들
## Burstable : best effort, guaranteed 둘다 아닌 경우
## Guaranteed(가장 마지막으로 죽음) : request, limit을 둘다 명시적으로 설정하고, 둘다 같은 값으로 구성한 경우
ABCD 누가 누가 먼저 죽을까?
## 스케쥴러가 볼때는 request 값 기준으로 본다.
## 스케쥴러가 죽일때 request대비 used의 %에 따라 죽이는 여부를 판단한다.
## 즉 B(90% used)가 C(70% used)보다 먼저죽는다.
POD의 Limit Range
apiVersion: v1 kind: LimitRange metadata: name: example spec: limits: - type: Pod ##pod들은 cpu나 메모리를 아래 값에 셋팅됨 min: cpu: 50m memory: 5Mi max: cpu: 1 memory: 1Gi - type: Container defaultRequest: ##requeset cpu: 100m memory: 10Mi default: ##limit cpu: 200m memory: 100Mi min: cpu: 50m memory: 5Mi max: cpu: 1 memory: 1Gi maxLimitRequestRatio: cpu: 4 memory: 10 - type: PersistentVolumeClaim min: storage: 1Gi max: storage: 10Gi
$ k create -f limit.yml
$ k get limitrange
$ k describe limitrange example
## 앞으로 배포될 값들은 상기 limitrange를 따르게 된다.
POD가 limit에 대비해 더 큰 pod를 배포하려고하면?
apiVersion: v1 kind: Pod metadata: name: too-big spec: containers: - image: busybox args: ["sleep", "9999999"] name: main resources: requests: cpu: 2
$ k create -f limits-pod-too-big.yaml ##오류가 나면서 배포되지 않는다.
$ k delete limitrange example ## limit 지우기
$ k create -f limits-pod-too-big.yaml ## limit지우니깐 배포 잘됨
POD quota 설정하기
apiVersion: v1 kind: ResourceQuota metadata: name: cpu-and-mem spec: hard: requests.cpu: 400m requests.memory: 200Mi limits.cpu: 600m limits.memory: 500Mi ##해당 네임스페이스의 토탈이 넘어가지 못하도록 설정
$ k create -f quota-cpu-memory.yaml
$ k get quota
$ k describe quota cpu-and-mem
생성 가능한 POD수 제한
apiVersion: v1 kind: ResourceQuota metadata: name: objects spec: hard: pods: 10 replicationcontrollers: 5 secrets: 10 configmaps: 10 persistentvolumeclaims: 5 services: 5 services.loadbalancers: 1 services.nodeports: 2 ssd.storageclass.storage.k8s.io/persistentvolumeclaims: 2
## 각 팀별로 namespace로 배포해주고, 그 안에서 양을 제한해주는 방법이 있음
## cloud에서는 이것을 빌링시스템으로 붙여버림.
그림 퍼온 사이트 : https://livebook.manning.com/#!/book/kubernetes-in-action/chapter-14/92
'DevOps > 쿠버네티스' 카테고리의 다른 글
쿠버네티스 yaml 선언시 어떤 apiVersion을 사용해야 할까? (1447) | 2018.06.24 |
---|---|
쿠버네티스 yaml 스펙 상세 설명 (1079) | 2018.06.24 |
쿠버네티스 관리자 계정 들어가기 (1101) | 2018.05.03 |
쿠버네티스 Deployment를 통한 배포 및 롤백 (949) | 2018.05.03 |
쿠버네티스를 통한 지속적 배포 전략(rolling, blue green) 실습 (977) | 2018.05.03 |
쿠버네티스 배포를 하기 위한 준비 readinessProbe, livenessProbe (975) | 2018.05.03 |