Lifecycle Check

사이드카의 자원을 정하는 원칙으로 맞는 것은?

• requests 넉넉하게, limits 작게
• requests 작게, limits 넉넉하게
• 둘 다 크게 잡는다
• 둘 다 아예 주지 않는다

requests 를 아예 주지 않으면 생기는 문제는?

• 스케줄러가 자리를 못 찾아 파드가 Pending 에 머문다
• limits 값이 자동으로 requests 로 복사된다
• 노드에 자원이 남아 있는 한 아무 문제가 없다
• OOM 점수가 최악이 되어 메모리 압박 때 가장 먼저 죽는다

파드의 스케줄링에 쓰이는 요청량은?

• 가장 큰 컨테이너 하나의 requests 값
• 본체 컨테이너의 requests 값만
• 컨테이너들의 requests 평균값
• 일반 컨테이너와 사이드카의 requests 합

사이드카가 정당한 조건이 아닌 것은?

• 파드의 네트워크 네임스페이스가 필요하다
• 노드 전체의 지표를 모아야 한다
• 파드의 볼륨에 있는 파일이 필요하다
• 테넌트별로 설정이 달라야 한다

사이드카가 계속 OOM 으로 죽으면?

• 재시작 간격이 점점 늘며 파드가 CrashLoopBackOff 로 표시된다
• 재시작 횟수만 오르고 상태는 계속 Running 으로 보인다
• kubelet 이 파드를 다른 노드로 다시 스케줄한다
• 메모리 한도가 자동으로 올라가 결국 안정된다