LabHub
배우기 러닝패스 코스

Istio 서비스 메시 · 사이드카의 수명주기와 자원 · 실습

프록시가 붙은 다음에 벌어지는 일 — 자원, 시작 순서, 끝나지 않는 Job

LabHub 에서 이어서 보기

목표

istioctl kube-inject 를 오프라인으로 돌려 주석 하나하나가 주입 결과의 어느 필드로 내려가는지 확인한다. 자원 요청과 상한, 프록시 설정(concurrency·드레인 시간), 시작 순서 보장, 나갈 포트 제외, 주입 제외, 그리고 배치 작업이 끝나지 않는 고전적 사고와 그 해법까지 필드 단위로 본다.

왜 중요한가

사이드카를 붙이는 일은 한 줄이지만, 붙인 다음에 생기는 문제는 대개 설정 한 칸에서 온다. 기본 프록시는 CPU 100m 과 메모리 128Mi 를 요청한다 — 파드 2천 개면 그것만으로 CPU 200 코어다. 시작 순서도 문제다. 앱이 프록시보다 먼저 뜨면 첫 몇 초의 나가는 요청이 그냥 실패한다. 가장 오래된 함정은 배치 작업이다. 프록시가 일반 컨테이너로 들어가면 작업이 끝나도 파드가 완료로 넘어가지 못하고, 예전에는 앱이 끝나면서 프록시에게 종료를 요청하는 방식으로 우회했다. 지금은 쿠버네티스가 재시작 정책을 가진 초기화 컨테이너를 지원하므로 프록시를 그쪽으로 옮겨 근본적으로 해결한다. 이 실습은 이 모든 손잡이를 주입 결과 매니페스트에서 직접 확인하는 법을 익히는 자리다. 클러스터에 올리기 전에 확인할 수 있으면 설정 변경이 리뷰 대상이 된다.

단계

1. /root/ist-lifecycle 를 만들고 /root/ist-lifecycle/dep.yaml 에 lifecycle 네임스페이스의 Deployment orders 를 쓰세요 — replicas 2, 라벨 app: orders, 컨테이너 하나(app, 이미지 nginx:1.27, 컨테이너 포트 8080), 주석은 없습니다. 이 파일을 주입해 결과를 /root/ist-lifecycle/baseline.yaml 에 저장하고, 거기서 읽은 네 가지를 /root/ist-lifecycle/baseline.tsv 에 containers·initContainers·proxyCpuRequest·proxyMemRequest 네 줄로 적으세요(컨테이너 이름은 나온 순서대로 쉼표로 잇습니다).
2. /root/ist-lifecycle/dep-resources.yaml 은 1단계 Deployment 를 이름 orders-res 로 복사하고 파드 템플릿 주석 네 개를 더한 것입니다 — sidecar.istio.io/proxyCPU 는 250m, sidecar.istio.io/proxyMemory 는 192Mi, sidecar.istio.io/proxyCPULimit 은 1500m, sidecar.istio.io/proxyMemoryLimit 은 512Mi 입니다. 주입 결과를 /root/ist-lifecycle/resources.yaml 에 저장하세요.
3. /root/ist-lifecycle/dep-proxyconfig.yaml 은 이름 orders-pc 로 복사한 판에 proxy.istio.io/config 주석 하나를 넣은 것입니다 — 값은 여러 줄 YAML 로 concurrency: 3 과 terminationDrainDuration: 45s 두 가지입니다. 주입 결과를 /root/ist-lifecycle/proxyconfig.yaml 에 저장하고, 결과에서 istio-proxy 의 환경변수 PROXY_CONFIG 값을 /root/ist-lifecycle/proxy-config.json 에 저장하세요.
4. /root/ist-lifecycle/dep-hold.yaml 은 이름 orders-hold 로 복사한 판에 proxy.istio.io/config 주석으로 holdApplicationUntilProxyStarts: true 하나만 넣은 것입니다. 주입 결과를 /root/ist-lifecycle/hold.yaml 에 저장하고, 컨테이너 순서와 프록시에 생긴 수명주기 훅을 /root/ist-lifecycle/hold.tsv 에 containerOrder 와 postStart 두 줄로 적으세요 (postStart 칸에는 훅이 실행하는 명령을 공백으로 이어 씁니다).
5. /root/ist-lifecycle/dep-exclude.yaml 은 이름 orders-exc 로 복사한 판에 주석 traffic.sidecar.istio.io/excludeOutboundPorts 를 "3306,5432" 로 넣은 것입니다. 주입 결과를 /root/ist-lifecycle/exclude.yaml 에 저장하고, istio-init 컨테이너의 인자를 공백으로 이어 /root/ist-lifecycle/init-args.txt 에 한 줄로 적으세요.
6. /root/ist-lifecycle/dep-nosidecar.yaml 은 이름 orders-off 로 복사한 판에 주석 sidecar.istio.io/inject 를 "false" 로 넣은 것입니다. 주입 결과를 /root/ist-lifecycle/nosidecar.yaml 에 저장하세요 — 결과에 프록시가 없어야 합니다.
7. /root/ist-lifecycle/job.yaml 에 lifecycle 네임스페이스의 Job nightly-settle 을 쓰세요 — 파드 라벨 app: nightly-settle, restartPolicy: Never, 컨테이너 하나(worker, 이미지 busybox:1.36). /root/ist-lifecycle/job-native.yaml 은 이름만 nightly-settle-native 로 바꾸고 파드 주석 sidecar.istio.io/nativeSidecar 를 "true" 로 더한 판입니다. 둘을 각각 주입해 /root/ist-lifecycle/job-injected.yaml 과 /root/ist-lifecycle/job-native-injected.yaml 에 저장하고, 차이를 /root/ist-lifecycle/job-compare.tsv 에 plain 과 native 두 줄로 <이름>\t<containers>\t<initContainers>\t<프록시의 restartPolicy> 형식으로 적으세요(restartPolicy 가 없으면 - 를 씁니다).
8. /root/ist-lifecycle/inject-summary.sh 를 만들어 이 디렉터리의 원본 매니페스트 여덟 장(dep.yaml·dep-resources.yaml·dep-proxyconfig.yaml·dep-hold.yaml·dep-exclude.yaml·dep-nosidecar.yaml·job.yaml·job-native.yaml)을 차례로 다시 주입하고, 파일마다 <파일이름>\t<containers>\t<initContainers>\t<프록시 CPU 요청> 을 그 순서대로 표준출력에만 찍게 하세요(없는 칸은 -). 출력을 /root/ist-lifecycle/inject-summary.tsv 에 저장하세요.

참고

단계 8개

  1. 아무 주석도 없을 때 프록시가 어떤 모양으로 들어가나
  2. 프록시의 자원을 주석으로 조정한다
  3. 프록시 자체의 설정은 주석 하나에 YAML 로 넣는다
  4. 앱이 프록시보다 먼저 뜨는 경합을 막는다
  5. 프록시를 지나면 안 되는 포트를 빼 둔다
  6. 이 파드만 프록시를 받지 않게 한다
  7. 끝나지 않는 배치 작업과 그 해법
  8. 여덟 장을 한 번에 다시 주입해 표로 굳힌다