강제되지 않는 상태가 정상처럼 보인다

한 줄 요약

메시에서 가장 위험한 것은 틀린 설정이 아니라 아무 데도 적용되지 않은 설정입니다. 전자는 오류를 내지만 후자는 정상처럼 보입니다.

왜 이것이 문제인가

서비스 메시에서 가장 위험한 상태는 "설정이 틀린 것" 이 아니라 "설정이 아무 데도 적용되지 않는 것" 입니다. 전자는 오류를 내지만 후자는 조용하기 때문입니다.

사이드카가 없으면 전부 무의미하다

네임스페이스에 istio-injection=enabled 를 붙이기 전에 만든 파드는 사이드카가 없습니다. 그 파드는 Running 이고 서비스도 정상 응답합니다. 그런데 트래픽이 메시를 통과하지 않으므로 mTLS 도 인가 정책도 라우팅도 적용되지 않습니다.

보안 정책을 다 써 두고 아무것도 지켜지지 않는 상태입니다.

확인 방법이 바뀌었다

Istio 는 이제 쿠버네티스의 네이티브 사이드카를 씁니다. istio-proxy 가 spec.containers 가 아니라 spec.initContainers 에 들어갑니다(restartPolicy: Always 로).

그래서 kubectl get pod -o jsonpath='{.spec.containers[*].name}' 로 확인하던 습관은 이제 사이드카가 있는데도 없다고 답합니다. 그 답을 믿으면 주입이 안 됐다고 판단하고 엉뚱한 곳을 고치게 됩니다.

옮긴 이유는 순서 문제였습니다. 옛 방식에서는 앱이 사이드카보다 먼저 떠서 네트워크가 준비되지 않은 채 요청을 보내거나, 앱이 끝났는데 사이드카가 남아 Job 이 영원히 안 끝나는 일이 있었습니다. 네이티브 사이드카는 앱보다 먼저 시작하고 나중에 끝납니다.

두 종류의 "안 된다"

| 증상 | 원인 | 볼 곳 |
|---|---|---|
| 응답 코드가 없음 (curl 000, exit 56) | mTLS 미충족 — TLS 핸드셰이크에서 끊김 | 상대가 메시 밖인가, 사이드카가 있는가 |
| 403 (RBAC: access denied) | 인가 거부 — 연결과 mTLS 는 성공 | AuthorizationPolicy 의 principals |

응답 코드 하나로 연결 계층인지 정책 계층인지 갈립니다. 이 구분이 없으면 메시 장애를 볼 때마다 처음부터 훑게 됩니다.

실무에서 진짜 중요한 것

라벨을 붙인 뒤에는 반드시 파드를 다시 만듭니다. istio-injection=enabled 는 앞으로 만들어질 파드에만 적용됩니다. 이미 떠 있는 파드를 그대로 두면 영원히 메시 밖에 남는데, 그 상태로도 서비스는 정상 응답하므로 아무도 눈치채지 못합니다.

사이드카 확인은 initContainers 까지 봅니다. 네이티브 사이드카로 옮겨 간 뒤로 spec.containers 만 보는 습관은 있는 것을 없다고 답합니다. kubectl get pod -o jsonpath='{.spec.initContainers[*].name}' 를 함께 봐야 합니다.

응답 코드로 계층을 먼저 가릅니다. 코드가 아예 없으면(curl 000) 연결 계층이고 403 이면 정책 계층입니다. 이 한 번의 분기가 없으면 메시 장애를 볼 때마다 처음부터 훑게 됩니다.

다음 실습에서 이것들을 진짜 Istio 위에서 직접 확인합니다.