本物のメッシュの確認

요즘 Istio 에서 istio-proxy 는 파드 스펙의 어디에 들어가나?

• spec.initContainers
• spec.containers
• spec.ephemeralContainers
• 별도 파드로 뜬다

메시 밖 파드에서 STRICT 인 워크로드를 부르면?

• 인가 정책에서 걸려 403 과 RBAC 거부 메시지가 온다
• 라우팅 대상을 못 찾아 404 가 온다
• TLS 핸드셰이크에서 끊겨 응답 코드 자체가 없다
• PERMISSIVE 로 자동 강등되어 200 이 온다

PeerAuthentication 을 PERMISSIVE 로 한동안 두는 이유는?

• 성능이 좋아서
• 인증서 발급이 느려서
• 메시 밖 워크로드가 남아 있어도 끊기지 않아 전환 중 장애를 막으려고
• STRICT 가 폐기 예정이라서

VirtualService 의 http 목록에서 포괄 규칙을 맨 위에 두면?

• 오류가 난다
• 모든 규칙이 순서대로 다 적용된다
• 경고가 나온다
• 아래 규칙들이 영영 안 걸린다

istio-injection=enabled 라벨을 네임스페이스에 붙인 뒤 반드시 해야 하는 일은?

• istiod 를 재시작해 라벨을 다시 읽게 한다
• 이미 떠 있는 파드를 다시 만들어 사이드카를 주입시킨다
• 네임스페이스를 지웠다가 같은 이름으로 다시 만든다
• PeerAuthentication 을 STRICT 로 먼저 바꾼다

메시 장애에서 응답 코드가 아예 없는 경우와 403 이 오는 경우를 먼저 가르는 이유는?

• 연결 계층 문제인지 정책 계층 문제인지가 그 한 번에 갈리기 때문이다
• 403 은 언제나 사이드카 주입 실패를 뜻하기 때문이다
• 응답 코드가 없으면 언제나 istiod 가 죽은 것이기 때문이다
• 두 경우 모두 VirtualService 규칙 순서 문제이기 때문이다