Telemetry API 로 신호를 설계한다

목표

프록시가 만들어 주는 신호를 설정으로 다듬는 법을 익힙니다. 메시 전체에 기본
로그를 깔고, 실패만 남기는 조건을 걸고, 워크로드 하나에 샘플링과 태그를 붙이고,
카디널리티를 폭발시키는 태그를 배포 전에 거르는 데까지 갑니다.

왜 중요한가

메시가 파는 것은 균일함입니다. 계측이 없는 서비스에도 같은 이름과 같은 라벨의
메트릭이 생기고, 그 균일함이 대시보드를 비교 가능하게 만듭니다. 그런데 기본값
그대로 두면 두 가지가 문제가 됩니다. 액세스 로그는 요청마다 한 줄이라 트래픽이
많은 서비스에서 저장 비용이 금방 커지고, 커스텀 태그를 잘못 넣으면 시계열이
라벨 값의 종류만큼 늘어나 저장소와 질의가 함께 무너집니다.

Telemetry API 는 그 조정을 선언으로 하게 해 줍니다. 범위가 세 층이라는 점이
핵심입니다. 설치 네임스페이스에 셀렉터 없이 두면 메시 전체, 일반 네임스페이스에
셀렉터 없이 두면 그 네임스페이스, selector 를 붙이면 그 워크로드입니다. 그리고
셀렉터 없는 것은 네임스페이스마다 하나뿐이어야 합니다. 둘 이상이면 어느 것이
이기는지 정의되지 않기 때문입니다.

환경

이 파드에는 진짜 istiod 도 사이드카도 없습니다. 요청이 흐르지 않으니 메트릭도
로그도 만들어지지 않습니다. 대신 Telemetry CRD 가 등록된 진짜 apiserver 와
istioctl 이 있어서, 설정이 유효한가와 범위가 올바른가는 그대로
검증됩니다. 그 둘이 현장에서 사람을 잡는 자리이기도 합니다. 작업 디렉터리는
/root/istio-obs 이고 그 아래 k8s/·reject/·bin/·out/ 을 씁니다.

단계

1. mesh-obs 를 만들고 istio-system 에 메시 기본 액세스 로그를 깝니다.
2. mesh-obs 에 실패만 남기는 로그 필터를 겁니다.
3. app=reviews 에 샘플링 10% 와 리터럴 태그를 걸고, 범위를 벗어난 값이 막히는 것을 봅니다.
4. app=ratings 에 메트릭 조정을 겁니다.
5. bin/tag-lint.sh 로 위험한 태그를 배포 전에 거릅니다.
6. 워크로드 둘을 만들고 istioctl analyze 로 범위 규칙을 확인합니다.
7. out/effective.txt 에 한 파드에 실제로 걸리는 것을 계산해 적습니다.
8. out/summary.txt 에 여섯 줄로 정리합니다.

참고

• 셀렉터 없는 Telemetry 는 네임스페이스마다 하나뿐입니다. 3단계와 4단계에는

반드시 셀렉터를 붙이세요. 빠뜨리면 6단계에서 드러납니다.

• 셀렉터는 Deployment 이름이 아니라 파드 라벨을 봅니다.
• 3단계의 거절당할 파일은 k8s/ 가 아니라 reject/ 에 두세요. 마지막 단계에서

k8s/ 의 파일이 모두 유효해야 합니다.

• 태그 값은 CEL 식입니다. 상수 문자열을 넣으려면 작은따옴표로 감싸야 합니다.

단계 8개

1. 메시 전체에 기본 액세스 로그를 깐다
2. 실패한 요청만 로그로 남긴다
3. 샘플링 비율과 커스텀 태그를 워크로드에 건다
4. 표준 메트릭을 끄고 태그를 더한다
5. 카디널리티를 폭발시키는 태그를 배포 전에 거른다
6. 범위 규칙을 정적 분석으로 확인한다
7. 한 파드에 실제로 걸리는 것을 계산한다
8. 만든 것을 세고 모두 유효한지 확인한다