クイズ: サイドカーとデータプレーン

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

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

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

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

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

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

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

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

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

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

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

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

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

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