サイドカーを付けて資源を測ってみる

목표

사이드카를 실제로 붙여 보고 그 대가를 숫자로 확인합니다. 자원이 어떻게 더해지는지, 누가 먼저 뜨는지, 무엇이 공유되는지를 클러스터에 물어봅니다.

왜 중요한가

사이드카는 "기능을 하나 더 붙인다" 로 보이지만 실제로는 배포 단위가 커지는 일입니다. 파드의 요청량이 더해지고, 기동이 느려지고, 실패 지점이 하나 늡니다. 그 대가를 모르고 늘리면 어느 순간 컨테이너 다섯 개짜리 파드가 됩니다.

환경

이 파드는 kwok 으로 진짜 kube-apiserver 를 띄웁니다. 파드가 실제로 실행되지는 않지만 스펙·상태·QoS 계산은 전부 진짜입니다.

단계

1. 사이드카 없는 Deployment → /root/sc/01-plain.yaml
2. 정식 사이드카 추가 → /root/sc/02-sidecar.yaml
3. 요청량의 합 → /root/sc/03-sum.txt
4. 기동 순서 → /root/sc/04-order.txt
5. 공유되는 것 → /root/sc/05-share.txt
6. 볼륨으로 잇기 → /root/sc/06-volume.yaml
7. QoS 등급 → /root/sc/07-qos.txt
8. DaemonSet 과의 비교 → /root/sc/08-decide.md

참고

• 정식 사이드카는 initContainers 에 restartPolicy: Always 를 준 것입니다. containers 에 그냥 하나 더 넣는 것과 다릅니다.
• 사이드카의 자원은 requests 작게, limits 넉넉하게 — 본체와 반대입니다.

사이드카 없는 파드부터

사이드카 없는 Deployment → /root/sc/01-plain.yaml

/root/sc/01-plain.yaml 에 컨테이너 하나짜리 Deployment 를 씁니다. 이름 web, 이미지 nginx:1.27-alpine, replicas 2, 그리고 resources.requests 에 cpu 100m·memory 128Mi. kubectl apply -f 로 적용하세요.

정식 사이드카를 붙인다

정식 사이드카 추가 → /root/sc/02-sidecar.yaml

같은 Deployment 에 사이드카를 더해 /root/sc/02-sidecar.yaml 로 저장하고 적용합니다.

containers 가 아니라 initContainers 에 넣고 restartPolicy: Always 를 줍니다. 그게 쿠버네티스 1.29 부터의 정식 사이드카이고, 본체보다 먼저 떠서 본체가 끝나면 함께 종료됩니다. 이름은 proxy, 이미지는 아무거나(busybox:1.36 에 sleep infinity), requests 는 cpu 50m·memory 64Mi.

파드의 요청량은 합이다

요청량의 합 → /root/sc/03-sum.txt

kubectl get pod <파드> -o jsonpath 로 두 컨테이너의 cpu requests 를 각각 뽑고, 그 합을 /root/sc/03-sum.txt 에 본체 + 사이드카 = 합 형식 한 줄로 적으세요(단위는 m). 스케줄러가 자리를 찾을 때 보는 값이 이 합입니다.

누가 먼저 뜨는가

기동 순서 → /root/sc/04-order.txt

kubectl get pod <파드> -o jsonpath='{.status.initContainerStatuses[*].name} {.status.containerStatuses[*].name}' 로 확인하고, /root/sc/04-order.txt 에 두 줄로 적습니다: (1) 먼저 뜨는 컨테이너 이름 (2) 왜 그 순서여야 하는지. 프록시가 늦게 뜨면 첫 요청들이 어디로 갈지 생각해 보세요.

무엇을 공유하나

공유되는 것 → /root/sc/05-share.txt

두 컨테이너가 공유하는 것과 아닌 것을 /root/sc/05-share.txt 에 적습니다. 네 줄: 네트워크 / 파일시스템 루트 / 프로세스 목록 / 볼륨. 각 줄은 <항목>: 공유|비공유 형식이고, 비공유인 것에는 어떻게 하면 공유되는지 덧붙이세요.

볼륨으로 잇는다

볼륨으로 잇기 → /root/sc/06-volume.yaml

본체가 쓴 파일을 사이드카가 읽게 하려면 같은 볼륨을 양쪽에 마운트해야 합니다. emptyDir 하나를 만들어 본체는 /var/log/app, 사이드카는 /logs 에 마운트한 매니페스트를 /root/sc/06-volume.yaml 에 쓰고 적용하세요.

QoS 등급을 확인한다

QoS 등급 → /root/sc/07-qos.txt

kubectl get pod <파드> -o jsonpath='{.status.qosClass}' 를 보고 /root/sc/07-qos.txt 에 두 줄: (1) 등급 (2) requests 를 아예 안 줬다면 어떤 등급이 되고 왜 위험한지. BestEffort 는 메모리 압박 시 가장 먼저 죽습니다.

DaemonSet 이 나은가

DaemonSet 과의 비교 → /root/sc/08-decide.md

/root/sc/08-decide.md 에 세 줄. (1) 사이드카가 정당한 세 가지 조건 중 이 경우가 어디에 걸리는지 (2) 안 걸린다면 DaemonSet 이 나은 이유 (3) 자원 관점에서의 차이. 붙이기 전에 물어야 할 질문이 이것입니다.