LabHub

CNPE — 클라우드 네이티브 플랫폼 엔지니어 (전문가) · 관측과 운영 · 퀴즈

퀴즈: 관측과 운영

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. 플랫폼 팀이 자기 플랫폼의 상태를 재는 지표로 가장 알맞은 것은 무엇입니까?

    1. 노드별 CPU 사용률과 메모리 사용률의 평균값
    2. 셀프서비스 발급 요청의 성공 비율과 소요 시간
    3. 클러스터에 등록된 CRD 와 컨트롤러의 개수
    4. etcd 데이터베이스의 크기와 컴팩션 주기
  2. 성공률 비율을 알림 조건 안에서 매번 계산하지 않고 기록 규칙으로 따로 정의하는 이유는 무엇입니까?

    1. 기록 규칙으로 만든 지표만 Alertmanager 가 라우팅할 수 있기 때문입니다
    2. 기록 규칙은 원본 시계열을 삭제해 저장 공간을 줄여 주기 때문입니다
    3. 같은 식이 여러 알림에 흩어지면 한 곳만 고치고 나머지를 잊게 되기 때문입니다
    4. 알림 조건에서는 나눗셈 연산자를 쓸 수 없기 때문입니다
  3. 알림 규칙에 for 를 두지 않으면 실무에서 무슨 일이 생깁니까?

    1. 알림이 발송되지 않고 Prometheus 내부에서만 상태가 유지됩니다
    2. 표현식이 참인 동안 같은 알림이 초 단위로 반복 발송됩니다
    3. Alertmanager 가 severity 라벨을 읽지 못해 라우팅이 실패합니다
    4. 순간의 튐으로 사람을 깨우게 되고, 결국 그 알림을 아무도 보지 않게 됩니다
  4. 노드를 세 대 늘렸는데도 워크로드가 계속 Pending 입니다. 분류의 첫 단계에서 세야 할 값은 무엇입니까?

    1. 그 워크로드의 선택자를 만족하는 노드가 몇 대인지
    2. 클러스터 전체에 남아 있는 allocatable CPU 의 합
    3. 그 네임스페이스의 파드 개수와 쿼터 상한의 차이
    4. kube-scheduler 가 마지막으로 재시도한 시각
  5. Pending 인 파드를 뜨게 하려고 nodeSelector 를 지웠습니다. 이 조치를 무엇이라고 불러야 합니까?

    1. 임시 완화이며, 원인이 사라지지 않았으므로 알림은 계속 울립니다
    2. 요구사항 삭제이며, 화면에서는 복구와 구별되지 않습니다
    3. 정상 복구이며, 선택자는 어차피 스케줄러의 참고 사항입니다
    4. 롤백이며, 배포 이전 상태로 되돌린 것에 해당합니다
  6. 비용을 줄이라는 요구를 받았을 때 올바른 순서는 무엇입니까?

    1. 노드를 먼저 줄이고, 못 뜨는 워크로드가 생기면 그때 요청을 조정합니다
    2. 쿼터 상한을 먼저 낮추고, 거절되는 요청을 보며 실사용을 추정합니다
    3. 오토스케일러의 최소 노드 수를 먼저 0 으로 내리고 부하를 관찰합니다
    4. 요청을 실사용에 맞춰 내리고, 그다음에 남은 노드를 정리합니다