사이드카를 붙이고 자원을 재 본다

목표

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

왜 중요한가

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

환경

이 파드는 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 넉넉하게 — 본체와 반대입니다.

단계 8개

사이드카 없는 파드부터
정식 사이드카를 붙인다
파드의 요청량은 합이다
누가 먼저 뜨는가
무엇을 공유하나
볼륨으로 잇는다
QoS 등급을 확인한다
DaemonSet 이 나은가