Istio 심화 — 왜 그렇게 흐르는가 · pilot-agent 가 Envoy 에게 넘기는 것 · 测验
프록시 부트스트랩 확인
6道题. 完成作答后会显示正确答案和解析。
사이드카 컨테이너 `istio-proxy` 의 인자가 `proxy sidecar --domain …` 로 시작한다. 이 컨테이너에서 가장 먼저 뜨는 프로세스는?
- Envoy 가 먼저 뜨고, 이어서 istiod 가 Envoy 에 설정 파일을 밀어 넣는다
- pilot-agent 가 먼저 떠서 부트스트랩을 만들고 Envoy 를 자식으로 띄운다
- istio-init 이 규칙을 심은 뒤 같은 컨테이너에서 Envoy 로 바뀐다
- kubelet 이 부트스트랩을 만들어 Envoy 에게 인자로 넘긴다
`--domain $(POD_NAMESPACE).svc.cluster.local` 의 `$(POD_NAMESPACE)` 는 언제 누가 채우는가?
- istioctl kube-inject 가 주입하는 순간 현재 네임스페이스로 바꿔 쓴다
- 컨테이너 안의 셸이 시작할 때 환경 변수를 펼친다
- istiod 가 xDS 응답에 네임스페이스를 넣어 덮어쓴다
- kubelet 이 컨테이너를 띄울 때 같은 이름의 환경 변수 값으로 바꿔 넣는다
부트스트랩의 ADS 설정이 `cluster_name: istiod-xds` 인데 정적 클러스터 이름은 `xds-grpc` 다. 무슨 일이 일어나는가?
- Envoy 가 설정을 거절해 뜨지 못하고, 쿠버네티스에서는 사이드카가 CrashLoopBackOff 가 된다
- Envoy 는 뜨지만 설정을 받지 못해 PRE_INITIALIZING 에 머문다
- Envoy 가 DNS 로 istiod-xds 를 찾아 연결하므로 정상 동작한다
- istiod 가 이름을 보고 올바른 클러스터를 내려보내 스스로 고친다
istiod 가 내려가 있는 동안 새로 뜬 사이드카의 모습으로 맞는 것은?
- 프로세스가 즉시 끝나고 CrashLoopBackOff 가 된다
- Envoy 가 기본 설정으로 LIVE 가 되어 모든 트래픽을 그대로 통과시킨다
- Envoy 는 떠 있지만 PRE_INITIALIZING 에 머물러 /ready 가 503 이고 파드가 Ready 가 되지 않는다
- istio-init 이 규칙을 되돌려 사이드카 없이 동작한다
`ISTIO_META_CLUSTER_ID` 같은 환경 변수가 부트스트랩에서 가는 자리는?
- static_resources 의 클러스터 이름으로 쓰여 xDS 서버 주소를 정한다
- admin 의 접근 로그 경로가 되어 프록시별 로그 파일을 가른다
- 리스너의 stat_prefix 가 되어 통계 이름 앞에 붙는다
- 접두사를 뗀 이름으로 node.metadata 에 들어가 istiod 가 이 프록시를 알아보는 이름표가 된다
사이드카의 투영 서비스 계정 토큰에 audience 를 `istio-ca` 로 좁혀 두는 이유로 가장 적절한 것은?
- 토큰이 쿠버네티스 API 서버에서만 쓰이도록 막기 위해서
- 이 토큰은 istiod 의 CA 에 신원을 증명하는 용도로만 받아들여지게 하려고
- 토큰의 만료 시간을 없애 인증서를 영구히 발급받기 위해서
- 앱 컨테이너가 같은 토큰으로 외부 서비스에 로그인하게 하려고