부트스트랩을 만들어 보고 뜨지 않는 두 경우를 가른다

목표

주입 산출물에서 pilot-agent 의 재료를 뽑고, istiod 식 부트스트랩을 손으로 써서 거르고, 사이드카가 뜨지 않는 두 경우(설정 거절과 설정 서버 부재)를 직접 만들어 가른다.

왜 중요한가

사이드카 장애의 절반은 두 증상으로 온다 — 컨테이너가 CrashLoop 이거나, 떠 있는데 Ready 가 아니거나. 앞의 것은 부트스트랩이 틀린 것이고 뒤의 것은 istiod 에서 설정을 못 받은 것이다. 부트스트랩이 무엇으로 만들어지는지 알면 로그 한 줄과 관리 포트 한 번으로 둘을 가를 수 있다.

단계

1. /root/ist2-boot 에서 istioctl kube-inject 로 /opt/lab/fixtures/istio/inject-target.yaml 에 사이드카를 넣어 /root/ist2-boot/inject.yaml 로 저장하세요(주입 설정 세 파일을 모두 넘깁니다). 그다음 istio-proxy 컨테이너의 args 를 읽어 /root/ist2-boot/01-args.txt 에 네 줄을 적으세요 — role=(두 번째 인자), domain=(--domain 다음 인자 그대로), proxy_log_level=(--proxyLogLevel= 의 값), component_log_level=(--proxyComponentLogLevel= 의 값).
2. /root/ist2-boot/inject.yaml 의 istio-proxy 환경 변수에서 일곱 개를 골라 /root/ist2-boot/02-env.txt 에 이름=값 으로 적으세요 — CA_ADDR, PILOT_CERT_PROVIDER, ISTIO_META_CLUSTER_ID, TRUST_DOMAIN, ISTIO_META_WORKLOAD_NAME 은 value 를 그대로, POD_NAMESPACE, SERVICE_ACCOUNT 는 값이 파드에서 오므로 fieldRef:<fieldPath> 꼴(예: fieldRef:metadata.name)로 적습니다.
3. /opt/istio/mesh-config.yaml 을 읽어 /root/ist2-boot/03-mesh.txt 에 네 줄을 적으세요 — discovery_address=(defaultConfig.discoveryAddress), root_namespace=, trust_domain=, 그리고 ca_addr_same= 에는 그 discoveryAddress 가 2단계의 CA_ADDR 과 글자 그대로 같으면 yes, 아니면 no.
4. /root/ist2-boot/bootstrap.yaml 에 부트스트랩을 쓰세요 — 관리 포트 9982; node.id 는 네 칸 sidecar, 10.0.0.7, payments-6d5f9.default, default.svc.cluster.local 을 이 순서로 물결표(~)로 이은 것, node.cluster 는 payments.default, node.metadata 에는 CLUSTER_ID·MESH_ID·NAMESPACE·WORKLOAD_NAME 네 열쇠(값은 2단계의 ISTIO_META_ 변수와 네임스페이스 default); dynamic_resources 는 ADS(gRPC)로 cds_config·lds_config 를 받고 initial_fetch_timeout: 0s; ADS 가 가리키는 정적 클러스터 이름은 xds-grpc, STRICT_DNS 로 3단계의 discovery_address 를 가리키며 HTTP/2 를 씁니다. envoy --mode validate 의 출력과 종료 코드를 /root/ist2-boot/04-validate.txt 에 담으세요(마지막 줄 rc=0).
5. /root/ist2-boot/bootstrap.yaml 을 /root/ist2-boot/boot-typo.yaml 로 복사한 뒤 ADS 쪽(ads_config 의 cluster_name)만 istiod-xds 로 바꾸세요(정적 클러스터 이름 xds-grpc 는 그대로). envoy --mode validate 로 검사해 출력과 종료 코드를 /root/ist2-boot/05-typo.txt 에 담으세요(마지막 줄 rc= 로).
6. /root/ist2-boot/bootstrap.yaml 로 Envoy 를 띄우세요(이 파드에는 istiod 가 없습니다). 관리 포트의 /config_dump 에서 부트스트랩의 node 중 id·cluster·metadata 세 필드만 뽑아 /root/ist2-boot/06-node.json 에 저장하고, /root/ist2-boot/06-ready.txt 에 세 줄을 적으세요 — ready_code=(/ready 의 HTTP 코드), ready_body=(그 본문), connected_state=(통계 control_plane.connected_state 의 값).
7. /root/ist2-boot/inject.yaml 에서 신원의 재료를 찾아 /root/ist2-boot/07-identity.txt 에 다섯 줄을 적으세요 — token_volume=(serviceAccountToken 을 투영하는 볼륨 이름), token_audience=(그 토큰의 audience), token_mount=(그 볼륨이 istio-proxy 에 붙는 경로), ca_configmap=(볼륨 istiod-ca-cert 가 읽는 ConfigMap 이름), ca_mount=(istiod-ca-cert 가 istio-proxy 에 붙는 경로).
8. /root/ist2-boot/08-report.md 에 xds_address=, xds_cluster=, typo_rc=, ready_without_istiod= 네 줄을 적고(각각 xDS 를 받는 주소, ADS 가 가리켜야 하는 정적 클러스터 이름, 5단계의 종료 코드, 6단계에서 본 /ready 본문), 그 아래 - 로 시작하는 설명을 네 줄 이상 적으세요.

참고

• 이 파드에는 진짜 istiod 도 진짜 사이드카도 없습니다. 그래서 istioctl proxy-config 로 실제 생성물을 볼 수 없고, 번역 규칙을 알고 손으로 등가 Envoy 설정을 만들어 동작을 확인합니다. 같은 규칙이 운영 클러스터의 proxy-config 출력에 그대로 보입니다.
• 주입 산출물 끝의 빈 문서 때문에 yq 는 항상 select(.kind=="Deployment") | … 로 거르세요.
• 6단계의 Envoy 는 LIVE 가 되지 않는 것이 정상입니다. 기동을 기다릴 때 /ready 가 LIVE 인지가 아니라 관리 포트가 응답하는지로 기다리세요.
• Envoy 를 띄울 때는 setsid --fork nohup envoy -c <파일> --log-level warn > <로그> 2>&1 </dev/null 로 셸에서 완전히 떼어 놓으세요. 다시 띄우기 전에는 pkill -x envoy 로 정리합니다 (pkill -f 'envoy -c' 는 그 문자열이 든 셸 자신까지 죽입니다).

8个步骤

1. 프록시 컨테이너는 Envoy 가 아니라 pilot-agent 를 띄운다
2. 환경 변수가 프록시의 이름표와 주소록이 된다
3. 메시 설정의 기본값과 CA 주소를 대조한다
4. istiod 식 부트스트랩을 손으로 써서 거른다
5. 클러스터 이름 한 글자가 CrashLoop 을 만든다
6. istiod 에 닿지 못한 프록시는 준비되지 않는다
7. 신원은 두 볼륨에서 시작한다
8. 사이드카가 뜨지 않을 때의 점검표로 정리한다