배포하기 전에 틀린 것을 찾는다

목표

Istio 설정은 문법이 맞아도 동작하지 않는 경우가 대부분입니다. 이름이
서로를 가리키는 구조라서, 한쪽 이름만 바뀌어도 조용히 끊깁니다.

이 실습은 클러스터 없이 배포하기 전에 그런 것들을 찾아냅니다.

두 도구의 차이

| | 보는 것 | 잡는 것 |
|---|---|---|
| istioctl validate | 한 파일의 문법 | 오타, 알 수 없는 필드 |
| istioctl analyze | 리소스 사이의 참조 | 없는 subset·게이트웨이, 호스트 충돌 |

쿠버네티스는 둘 다 안 잡아 줍니다. CRD 스키마에서 알 수 없는 필드는 조용히
버려지므로 kubectl apply 는 성공하고 트래픽만 안 흐릅니다.

쓰는 법

istioctl validate -f vs.yamlistioctl analyze --use-kube=false vs.yaml dr.yamlecho $?          # 0 이면 깨끗, 79 면 문제 있음

--use-kube=false 는 클러스터를 안 보고 파일만 본다는 뜻입니다.

단계

1. 오타 → 01-validate.txt
2. 참조가 깨진 것 → 02-analyze.txt
3. 고쳐서 통과 → vs.yaml, dr.yaml
4. 호스트 충돌 → 04-conflict.txt
5. 없는 게이트웨이 → 05-gateway.txt
6. 사이드카 주입 → 06-inject.txt
7. analyze 가 못 잡는 것 → 07-blind.txt
8. 정리 → 08-notes.md

참고

7단계는 아무 문제도 안 나오는 것이 정답입니다. 정적 분석의 한계를 직접
보는 것이 목적입니다.

단계 8개

1. 오타를 잡는다
2. 스키마는 맞는데 동작은 틀린 것
3. 고쳐서 통과시킨다
4. 같은 호스트를 둘이 잡으면
5. 없는 게이트웨이를 가리키면
6. 사이드카가 실제로 어떻게 생기나
7. analyze 가 못 잡는 것
8. 세 가지를 정리한다