퀴즈: 사이드카와 데이터플레인

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

1. 네임스페이스에 `istio-injection=enabled` 라벨을 붙였는데 기존 파드에 사이드카가 없습니다. 원인으로 옳은 것은?

   1. istiod 가 네임스페이스 라벨을 주기적으로 재조정하므로 다음 주기를 기다려야 하기 때문
   2. 네임스페이스 라벨은 앞으로 만들 Deployment 에만 적용되고 기존 워크로드는 대상이 아니기 때문
   3. 주입은 파드 생성 시점의 웹훅 동작이라 기존 파드는 재생성돼야 하기 때문
   4. 라벨 값이 `enabled` 가 아니라 `true` 여야 웹훅이 그 네임스페이스를 인식하기 때문

2. `istio-init` 초기화 컨테이너가 UID 1337 의 트래픽을 리다이렉트에서 제외하는 이유는?

   1. 헬스 체크와 메트릭 스크레이프 트래픽이 프록시를 거치지 않고 곧장 처리되도록 하려고
   2. 프록시를 루트 권한 없이 실행하기 위해 전용 UID 를 트래픽 규칙에서 분리해 두려고
   3. kubelet 이 보내는 프로브가 iptables 리다이렉트에 걸려 실패하는 것을 막으려고
   4. 프록시 자신이 내보내는 트래픽이 다시 프록시로 돌아와 무한 루프가 나는 것을 막으려고

3. istiod 가 잠시 다운됐습니다. 이미 설정을 받은 사이드카의 동작으로 옳은 것은?

   1. 마지막으로 받은 설정으로 계속 트래픽을 처리하되 새 설정은 반영되지 않는다
   2. 설정 스트림이 끊긴 사이드카가 재시작되면서 애플리케이션 컨테이너도 함께 내려간다
   3. 설정을 갱신받지 못한 프록시가 들어오는 요청을 즉시 503 으로 끊어 낸다
   4. 인증서를 새로 받지 못한 사이드카가 mTLS 를 포기하고 평문 통신으로 자동 전환된다

4. `istioctl manifest generate` 를 설치 전에 쓰는 실무적 이유로 가장 적절한 것은?

   1. 무엇이 설치되는지 파일로 남겨 검토·커밋하고 업그레이드 때 diff 를 볼 수 있기 때문
   2. 생성된 매니페스트에는 CRD 가 빠져 있어 클러스터를 가볍게 유지할 수 있기 때문
   3. generate 가 이미 스키마 검증을 끝낸 결과라 별도의 `istioctl validate` 가 필요 없기 때문
   4. 미리 만들어 둔 매니페스트를 적용하면 `istioctl install` 보다 설치가 훨씬 빨리 끝나기 때문

5. xDS 를 ADS 하나의 스트림으로 합쳐 보내는 이유는?

   1. 설정 종류마다 gRPC 연결을 따로 열면 mTLS 핸드셰이크 비용이 커져 하나로 합치려고
   2. Envoy 가 CDS·EDS·LDS·RDS 를 개별 스트림으로는 받지 못하고 통합 스트림만 지원하기 때문
   3. 설정 전체를 매번 다시 보내는 대신 변경분만 보내는 증분 전송이 ADS 에서만 되기 때문
   4. 클러스터·엔드포인트·리스너·라우트가 서로 어긋난 순서로 도착해 설정이 깨지는 것을 막으려고

6. `istioctl kube-inject` 의 성격으로 옳은 것은?

   1. 입력한 매니페스트를 클러스터에 적용해 사이드카가 붙은 파드를 곧바로 만들어 준다
   2. 이미 떠 있는 파드에 사이드카 컨테이너를 덧붙여 재시작 없이 메시에 넣어 준다
   3. 사이드카 이미지를 미리 내려받아 노드에 캐시해 두어 주입 시 기동을 앞당긴다
   4. 웹훅이 파드 생성 시 하는 스펙 변경을 매니페스트 파일에 미리 적용해 결과를 보여 준다

7. 사이드카 방식의 비용으로 실제로 자주 문제가 되는 것은?

   1. VirtualService 와 DestinationRule 이 쌓여 etcd 용량을 크게 잡아먹는 것
   2. 파드당 추가 메모리와 시작 지연, 그리고 업그레이드 시 전 파드 재시작
   3. 언어별 트래픽 관리 SDK 를 애플리케이션 코드에 넣고 함께 배포해야 하는 것
   4. 컨트롤 플레인이 모든 요청을 중계하면서 홉이 하나 늘어 지연이 커지는 것