AWS EC2 Role(역할) 매핑하기

리소스란

• 적절한 크기의 노트 수와 용량을 가진 쿠베 클러스터가 있다고 하면 어떻게 비용 효율성을 높일 수 있을까?
• 워크로드에 사용 가능한 클러스터 리소스를 최대한 활용하는 동시에 트래픽 폭증, 노드 장애, 잘못된 배포 상황에 대처할 수 있는 충분한 여유공간을 확보하는 방법까지 알아야 한다.
• 특정 파드가 너무 많은 리소스를 점유하여 같은 노드에 있는 다른 팟에 영향을 준다면 스케줄러는 적절한 조치를 취할 수 있어야 한다.
• 쿠버네티스는 CPU와 메모리, 이 두 종류의 리소스를 관리할 수 있다.

리소스 단위

• 파드의 CPU 사용량은 CPU 단위로 표시된다
• 즉 쿠버네티스 용어로 1CPU는 일반적인 CPU 단위와 같다.
• 대부분 팟은 CPU 전체가 필요하지 않기 때문에 요청(requests)과 상한(limits)은 millicpus (또는 millicores)로 표시된다. 메모리는 바이트나 mebibytes (MiB)로 측정된다.

리소스 요청 (requests)

• 쿠버네티스 리소스 요청에서는 팟을 실행하기 위한 최소 리소스 양을 지정한다.
  • ex) CPU 100m ( 100 millicpus ) 와 메모리 250Mi ( 250 MiB )로 리소스를 요청하면, 팟은 이보다 적은 리소스를 가진 노드에는 스케줄링되지 않는다.
• 만약 사용할 수 있는 요량이 충분한 노드가 없으면, 파드는 여유 용량이 확보될 때까지 대기 상태
• 예를 들어 클러스터 내 모든 노드가 CPU 코어 2개와 메모리 4GiB일 경우 2.5CPU를 요청하는 컨테이너는 스케줄링되지 않으며 5GiB 메모리를 요청하는 컨테이너 또한 스케줄링되지 않음

spec:
  containers:
    - name: demo
  image: socar/demo:1v
  ports:
    - containerPort: 8080
  resources:
    requests:
      memory: "10Mi"
        cpu: "100m"

리소스 상한 ( limits )

• 리소스 상한은 팟이 사용할 수 있는 최대 리소스 양을 지정한다.
• 팟이 상한을 초과하여 CPU를 사용하려고 하면 해당 팟은 제한되고 성능 저하가 발생한다.
  • 메모리 상한을 초과해서 사용되는 팟은 종료되며 다시 스케줄링 된다.
  • 실제로는 동일한 노드에서 팟이 단순히 다시 뜨는 것
• 리소스 상한을 지정해야 클러스터 용량을 과다하게 먹어 다른 서비스에 영향을 주는 것을 막을 수 있다.

spec:
  containers:
    - name: demo
    image: socar/demo:1v
    ports:
      - containerPort: 8080
    resources:
      limits:
        memory: "20Mi"
        cpu: "250m"

오버커밋

• 오버커밋은 노드 내 컨테이너의 모든 리소스의 상한의 합계가 노드 전체의 리소스 양을 초과한 상태
• 쿠버네티스는 오버커밋을 허용한다.
• 보통은 노드가 스케일업 되어지거나, 팟이 죽고 다시 뜬다.
  • 팟이 죽어야 하는 상황이 오면 가장 리소스 요청을 많이 초과한 팟부터 죽인다.

생명주기 관리하기

• 쿠버네티스는 컨테이너화된 어플리케이션이 언제든 스턱 상태에 빠질 수 있음을 감지하고 문제를 해결 할 수 있어야 한다.

활성프로브 ( liveness probe )

• 컨테이너가 잘 살아있는지 확인하는 헬스 체크를 컨테이너 스펙에 지정할 수 있다. → 활성 프로브
• http 서버 컨테이너의 경우 활성 프로브 스펙은 다음과 같다

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

• 해당 path와 port로 헬스체크를 한다.
• 어플리케이션의 http응답 코드가 2xx 혹은 3xx 상태면 쿠버네티스는 해당 컨테이너를 활성 상태라고 간주한다.
• 만약 다른 값으로 응답하거나 응답이 없으면 컨테이너가 죽은 것으로 판단해 다시 실행한다.

프로브 딜레이, 주기

• initialDelaySeconds: 3 → 컨테이너가 시작하고 3초 뒤부터 헬스체크 ( 모든 어플리케이션은 컨테이너가 뜸과 동시에 활성화 되는것이 아니므로 )
• periodSeconds: 3 → 3초에 한번씩 헬스 체크

다른 종류의 프로브

• httpGet
• tcpSocket
• exec
• gRPC
  • http 서버는 없고 단순히 gRPC 서버만 존재하는 경우
  • grpc-health-probe 도구를 컨테이너 추가하고, exec 프로부를 사용하여 상태를 확인
  • https://github.com/grpc-ecosystem/grpc-health-probe

준비성 프로브 ( readiness probe )

• 초기화 과정이 길거나 하위 프로세스가 완료될 때까지 오래 기다려야 하는 컨테이너도 있다.
• 이때 어플리켕션은 쿠버네티스에 일시적으로 요청을 처리할 수 없다는 신호를 보내야 한다.
• 준비성 프로브가 이 기능을 한다.
• 어플리케이션이 준비를 오나료할 때까지 http를 수신하지 않는 경우에 준비성 프로브는 활성 프로브와 동일한 스펙으로 지정해야 한다.

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

• 준비성 프로브 검사에 실패한 컨테이너는 해당 팟이 속한 서비스에서 제거된다.
  • 마치 로드밸런서에 대상그룹에서 제외되는 느낌과 비슷하다.
  • 준비성 프로브가 다시 성공할 때까지 트래픽은 해당 팟으로 전달되지 않는다.
• 문제가 있는 팟에 아예 트래픽을 보내지 않기 때문에 매우 중요하다.
• 준비성 프로브는 무조건 2xx 응답을 반환해야만 성공이다.

minReadySeconds

• 준비성 프로브가 성공하는 순간에 준비가 완료된 것으로 판단 하지만
• 상황에 따라는 잠시 대기하면서 컨테이너가 안정적인 상태인지 확인을 한번더 하고 싶은 경우도 있다.
• 배포를 하는 동안 쿠버네티스는 새 팟이 준비될 때 까지 기다렸다가 다음 단계를 시작한다.
  • 결함이 있는 컨테이너에서 문제가 바로 발생하면 롤아웃이 중단된다.
  • 하지만, 문제가 발생하는데 몇 초가 더 덜리는 경우에는 이를 발견하기 전에 모든 레플리카가 롤아웃 될 수 있다.
  • 이를 막으려면 컨테이너의 minReadySeconds필드를 사용해야한다.
• 컨테이너나 팟은 minReadySeconds ( 최소 준비시간, 기본값은 0 )가 될 때까지 준비 상태로 판단하지 않는다.

PodDisruptionBudgets

• 때때로 쿠버네티스는 팟이 활성 상태이며 준비 상태여도 팟을 중지해야 한다. (이를 퇴출 이라고 한다.)
• 예를 들어 업그레이드 전에 실행 중인 노드를 비우거나 팟을 다른 노드로 옮겨야 할 때가 있다.
• 레플리카를 충분히 실행할 수 있다면, 퇴출 과정 때문에 어플리케이션이 다운타임이 발생하지 않는다.
• 특정 어플리케이션에 PodDisruptionBudgets 리소스를 사용하면, 주어진 시간에 제거할 수 있는 팟의 양을 제한할 수 있다.
  • ex) 어플리케이션의 팟의 10% 이상은 한번에 중단될 수 없다고 지정한다.
  • ex) 최소 3개 이상의 팟이 있다면 쿠버네티스가 마음대로 팟을 퇴출 시킬 수 있게 한다.
• 다음은 PodDisruptionBudget를 사용한 예제이다.

minAvailable 최소한 실행해야 하는 팟의 개수 pod-name의 팟이 적어도 3개는 실행 중이어야 한다는 것

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: demo-pdb
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: pod-name

maxUnavailable 반대로 쿠버네티스가 퇴출할 수 있는 팟의 총 개수나 비율을 제한 가능

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: demo-pdb
spec:
  maxUnavailable: 10%
  selector:
    matchLabels:
      app: pod-name

여기서 10% 이상의 팟을 한번에 퇴출시킬 수 없는데, 이는 오직 쿠버네티스가 시작한 자발적 퇴출의 경우에만 적용된다.

(업그레이드를 위한 노드 드레이닝도 자발적 퇴출에 해당 된다고 한다.. ) https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/

예를들면 노드에 하드웨어 장애가 발생하거나 제거되면 PodDisruptionBudget을 위반하더라도 해당 노드의 팟은 비자발적으로 퇴출된다.