프로파일과 메시 설정 — 되돌리기 비싼 두 결정

한 줄 요약

Istio 설치는 "프로파일이라는 묶음을 고르는 일" 과 "메시 전역 설정에 값을 적는 일" 두 층으로 나뉘고, 둘 다
클러스터에 닿기 전에 istioctl manifest generate 로 통째로 읽어 볼 수 있다.

왜 설치를 미리 읽어야 하나

메시를 처음 올릴 때 사람들이 가장 자주 하는 일은 문서의 설치 명령 한 줄을 그대로 복사해 붙이는 것이다.
그 한 줄 뒤에는 40개 가까운 오브젝트가 있고, 그중 몇 개는 클러스터 전역 권한을 가진다. 더 중요한 것은
그 명령이 함께 심는 기본값이다. 메시 전역 설정은 이후 주입되는 모든 프록시가 읽는 값이라, 나중에
고치면 메시 안의 모든 워크로드가 설정을 다시 받는다. 되돌리는 비용이 올리는 비용보다 훨씬 크다.

가장 험한 예가 outboundTrafficPolicy.mode 다. 기본값 ALLOW_ANY 는 등록되지 않은 바깥 주소로 나가는
호출을 그냥 통과시킨다. REGISTRY_ONLY 로 바꾸면 그 순간부터 메시가 아는 목적지로만 나갈 수 있다.
보안 관점에서는 옳은 방향이지만, 켜는 날 아무도 예고하지 않았다면 결제 대행사·사내 SMTP·외부 로그
수집기로 나가던 호출이 한꺼번에 끊긴다. 이런 값은 "깔고 나서 확인" 이 아니라 "깔기 전에 합의" 여야 한다.

두 개의 손잡이 — 프로파일과 값

프로파일은 무엇을 띄울지를 고르는 묶음이다. 1.24 기준으로 자주 쓰는 네 가지는 이렇게 갈린다.

| 프로파일 | 컨트롤 플레인 | 게이트웨이 | 앰비언트 구성요소 |
| --- | --- | --- | --- |
| minimal | istiod | 없음 | 없음 |
| default | istiod | ingress | 없음 |
| demo | istiod | ingress + egress | 없음 |
| ambient | istiod | 없음 | ztunnel + istio-cni-node |

minimal 은 게이트웨이 한 벌(Deployment·Service·HPA·PDB·Role·RoleBinding·ServiceAccount)이 통째로
빠진 것이고, demo 는 거기에 egress 한 벌을 더한 것이다. 묶음이 아니라 값 하나만 바꾸고 싶을 때는
--set values.… 를 쓴다. 예를 들어 --set values.gateways.istio-ingressgateway.autoscaleMin=3 은
프로파일은 그대로 두고 렌더된 HPA 의 minReplicas 만 1에서 3으로 바꾼다. 두 손잡이를 섞어 쓰면
"프로파일을 바꾼 줄 알았는데 값 하나만 바뀌어 있는" 상태가 만들어진다.

메시 전역 설정은 세 번째 자리다. --set meshConfig.… 로 넣으며, 렌더 결과에서는 별도의 CRD 가 아니라
istio-system 네임스페이스의 ConfigMap istio 안 mesh 키에 YAML 덩어리로 들어간다.

istioctl manifest generate --set profile=minimal \  --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY \  --set meshConfig.trustDomain=lab.internal

여기서 trustDomain 은 워크로드 신원(SPIFFE ID)의 앞부분을 정하는 값이라 나중에 바꾸면 이미 발급된
신원을 기준으로 쓴 인가 정책이 전부 어긋난다. defaultConfig 아래에 적는 것들은 프록시 하나하나의
기본 동작이다 — 프록시가 준비될 때까지 앱 컨테이너를 붙잡아 둘지, 종료할 때 얼마나 기다릴지 같은 것들.

값을 틀리면 클러스터에 닿기도 전에 걸린다. 열거형에 없는 값을 주면 렌더가
unknown value ... for enum istio.mesh.v1alpha1.MeshConfig.OutboundTrafficPolicy.Mode 로 끝나고,
없는 프로파일 이름을 주면 프로파일 파일을 찾지 못했다고 한다. 한 가지 더 — 1.24 에는 --profile 이라는
플래그가 아예 없다. --set profile= 이 맞고, 틀리면 unknown flag 로 끝난다.

현장에서 만나는 모습

첫 번째는 "설치는 같은데 클러스터마다 다르게 동작한다" 는 신고다. 원인은 대개 사람마다 다른
--set 을 붙여 깔았고 그 명령이 어디에도 기록되지 않은 것이다. 렌더 결과를 저장소에 두고 비교하는
습관이 이걸 막는다. 매니페스트는 클러스터 없이 만들 수 있으니, 설치 변경을 코드 리뷰에 올릴 수 있다.

두 번째는 범위를 좁히지 않은 전역 설정이다. 어느 한 팀이 프록시 스레드 수를 늘려 달라고 해서
메시 전역 defaultConfig.concurrency 를 올리면, 파드 수천 개의 메모리 사용량이 함께 올라간다.
이럴 때 쓰는 것이 ProxyConfig CRD 다 — 네임스페이스나 워크로드 셀렉터 단위로 전역 기본값을
덮어쓴다. 값 검사는 istioctl 이 아니라 CRD 스키마가 하므로, 음수 같은 값은 API 서버가 거절한다.

이 실습 환경의 한계

실습 파드에는 istiod 도 게이트웨이도 뜨지 않는다. 그래서 "REGISTRY_ONLY 로 바꿨더니 호출이 끊겼다" 는
직접 볼 수 없고, 프록시가 이 설정을 실제로 읽는 장면도 확인할 수 없다. 대신 설치를 결정하는 그 문서
자체는 오프라인으로 완전하게 만들 수 있고, 진짜 API 서버가 붙어 있어 ProxyConfig 처럼 CRD 로 들어가는
설정은 스키마 강제까지 실제로 확인할 수 있다.

다음 실습에서 할 것

네 프로파일을 차례로 렌더해 무엇이 늘고 주는지 파일로 비교하고, 메시 전역 설정 네 가지를 넣어 렌더된
ConfigMap istio 안에서 찾아본다. 일부러 틀린 값·없는 프로파일·없는 플래그로 세 번 거절당해 보고,
마지막에는 프로파일과 구성요소의 표를 만들어 스스로 다시 렌더해 검증하는 스크립트를 짠다.