Kubernetes 실전 가이드

RBAC·ServiceAccount부터 Tekton·Argo CD, Autoscaler, GitOps까지
쿠버네티스 클러스터를 운영하면서 실제로 부딪힌 개념‧실습 내용을 개발 Velog에 기록하기 위해 정리했다.
한 번 읽고 끝내기보다 “필요할 때 바로 찾아보는 레퍼런스”를 목표로, 주요 토픽을 단계별로 모았다.

---

1. RBAC & ServiceAccount ― “통신의 최소 필수 조건”

1‑1. 왜 필요한가?

• 쿠버네티스의 모든 통신은 API Server가 관장한다.
• kubectl, Pod 등 어떤 엔터티라도 API Server와 대화하려면
  1) ServiceAccount
  2) ServiceAccount에 바인딩된 토큰
  3) 해당 토큰에 부여된 Role/ClusterRole
  4) (옵션) TLS 인증서
  가 반드시 필요하다.

1‑2. 토큰 탐색 순서

1. KUBECONFIG 환경 변수
2. $HOME/.kube/config
3. Pod 내 /var/run/secrets/kubernetes.io/serviceaccount

1‑3. Role vs ClusterRole

구분	권한 범위	예시
Role	하나의 Namespace	kubectl get pod ← 해당 Namespace 안의 Pod만 조회
ClusterRole	클러스터 전체	kubectl get ns ← 모든 Namespace 조회

• Binding = Role(또는 ClusterRole)과 Subject(ServiceAccount 등)를 연결
• 하나의 ServiceAccount는 여러 Binding을 가질 수 있고, 쿠버네티스 RBAC에는 “deny” 개념이 없다. → 허용(allow)만 누적된다.

---

2. CI & CD ― Jenkins → Tekton (💡CI 특화) + Argo CD (💡CD 특화)

2‑1. Why Tekton?

• Daemon‑less 빌드 환경에서 kaniko 컨테이너로 Docker Build & Push 수행 →
  노드 CRI (containerd/crio)와 충돌 無
• Kubernetes 네이티브 CI Pipeline: CRD 기반으로 파이프라인 정의 → Git 저장소와 연동

2‑2. Why Argo CD?

• GitOps 패러다임: “Git = 단일 진실 원천(Single Source of Truth)”
• Application CRD가 Git Repo를 추적 → 클러스터 상태(Etcd)와 자동 Sync
• Prune 옵션으로 Git에서 삭제된 리소스를 클러스터에서도 즉시 삭제

---

3. 배포 전략 ― Rolling Update vs Blue/Green vs Canary

전략	특징	언제?
Rolling Update	Pod를 일정 비율로 교체 maxSurge, maxUnavailable 조정	스키마 변화가 없는 소규모 기능 릴리즈
Blue/Green	두 세트를 완전히 분리해 한 번에 트래픽 스위칭	DB 스키마 변경 등 단계적 교체가 불가한 경우
Canary	새 버전을 일부 트래픽에만 우선 적용	위험도 높은 기능 검증, A/B 테스트

Sidecar (Service Mesh)를 붙이면 Header·Path 기반 세밀 라우팅으로 Canary/Blue‑Green을 더 우아하게 운용할 수 있다.

---

4. Autoscaling ― HPA·VPA·Cluster Autoscaler 비교

오브젝트	스케일 대상	트리거 메트릭	설치 필요
HPA	Pod Replica	CPU·Memory 사용률 등	기본 내장
VPA	Pod 자원(Limit/Request)	CPU·Memory 실측치	별도 설치
Cluster Autoscaler / Karpenter	Node 수	Pod Pending 상태	별도 설치

• Metrics Server → metrics.k8s.io 구현체로 CPU/Memory 데이터 제공
• Custom Metrics Adapter (Prometheus Adapter/KEDA 등) → custom.metrics.k8s.io 확장

---

5. 프로브(Probe) ― Pod 헬스체크 3종

1. Startup Probe : 초기 부팅 지연 감지 → 실패 시 CrashLoopBackOff
2. Readiness Probe : 트래픽 수신 가능 여부 → 실패 시 Service Endpoint 제외
3. Liveness Probe : 런타임 헬스 체크 → 실패 시 컨테이너 재시작

---

6. 스토리지 전략 ― EmptyDir·HostPath·PVC·StorageClass

• EmptyDir : 같은 Pod 안 Init ↔ Main 컨테이너 간 임시 볼륨 공유
• HostPath : 특정 Node 로컬 디스크 사용(개발/테스트 전용)
• PVC + StorageClass : 동적 프로비저닝으로 EBS/EFS 등 외부 스토리지 자동 할당
  • ReadWriteOnce (RWO) → 블록 스토리지
  • ReadWriteMany (RWX) → 파일 스토리지

---

7. 네트워킹 핵심 ― Service·Endpoints·Ingress Controller

1. Service : ClusterIP(NodePort) 생성 → Endpoints 리소스와 Pod IP 매핑
2. Ingress Controller(Nginx etc.) : L7 라우터 역할, TLS Termination 지원
3. Path Rewrite·정규식 라우팅·ExternalName로 Cross‑Namespace 호출도 가능

---

8. TLS & Secret 관리

• Secret = Key‑Value 저장소 (Base64 인코딩, type: Opaque etc.)
• TLS Secret : tls.crt(Public Key) + tls.key(Private Key) → Ingress HTTPS 구간 종료
• cert‑manager → Let’s Encrypt ACME 프로토콜로 자동 발급·갱신

---

9. QoS & Priority Class ― 리소스 경합 시 생존 전략

QoS Class	조건	Eviction 우선순위
Guaranteed	Request = Limit 모두 설정	가장 안전
Burstable	Request ≠ Limit	중간
BestEffort	Request·Limit 미설정	가장 먼저 Kill

• Priority Class : 숫자 값이 클수록 우선권 ↑ (System Pod > Business Pod)

---

10. Helm & Kustomize ― Manifest Templating 비교

도구	장점	단점
Helm	차트 패키징·버전 관리 ⬆	“Pull 모드”라 대규모 릴리즈 시 느릴 수 있음
Kustomize	Base + Overlay 구조로 가벼움	복잡한 템플릿 로직은 직접 스크립팅 필요

Argo CD는 두 방식을 모두 지원하므로 팀 선호도에 따라 선택 가능.

---

11. 실전 CI/CD 파이프라인 예시

graph TD
A["Git Commit"] --> B[ⓐ Tekton Pipeline<br/>• Lint/Test<br/>• Kaniko Build/Push];
B --> C{이미지 배포?};
C -->|태그/버전 변경| D[(Harbor/ECR)];
D --> E[ⓑ Argo CD Sync<br/>• Helm/Kustomize Render<br/>• `kubectl apply`];
E --> F[Cluster State (Etcd)];
F -->|Diff 발생| G[Controller Patch/Scale];

---

12. Cheatsheet

# ServiceAccount 확인
kubectl get sa [-n <ns>]

# 토큰·CA 조회 (Pod 내부에서)
cat /var/run/secrets/kubernetes.io/serviceaccount/{token,ca.crt}

# ClusterRole·RoleBinding 권한 열람
kubectl get clusterrole admin -o yaml
kubectl describe rolebinding <name> -n <ns>

# HPA 생성 예시
kubectl autoscale deploy my-app \
  --cpu-percent=50 --min=2 --max=10

# Ingress Path Rewrite Anotation
nginx.ingress.kubernetes.io/rewrite-target: /$2

13. Jenkins vs Argo CD ― "CI 특화"와 "CD 특화"

13‑1. Jenkins가 쿠버네티스 CI에 강한 까닭

특징	상세 설명
플러그인 생태계	kubernetes-plugin, kaniko, docker-buildx 등 빌드·테스트 스테이지에 필요한 거의 모든 플러그인을 보유.
파이프라인 DSL (Groovy)	SCM 브랜치별 CI 스크립트를 코드로 버전 관리. 복잡한 매트릭스 빌드도 선언적으로 작성.
멀티‑에이전트 전략	Label로 Node Selector/Pod Template 분리 → GPU/ARM 등 이질적 워커에 맞춤 빌드 가능.
Webhook 트리거	Git Commit·PR 이벤트 감지 → Lint/Test/Build 파이프라인 자동 실행.

▶ 한마디로, “코드를 이미지 로 변환하는 영역”에 최적화되어 있다.

---

13‑2. Jenkins에게 CD까지 맡기면 생기는 문제

1. kubectl 스파게티 : 배포 단계마다 kubectl apply, kubectl rollout status …
2. 상태 추적 누락 : Jenkins Job이 끝나면 Controller ↔ Etcd Diff를 지속 감시하지 않는다.
3. Rollback 복잡도 : 실패 감지 후 kubectl rollout undo를 추가 스크립트로 처리해야 한다.
4. 멀티 Cluster/Namespace 관리 난이도 ↑ : Job 매개변수 확장 → 유지보수 지옥.

---

13‑3. Argo CD가 CD에 특화된 이유

핵심 기능	Jenkins와의 차이
GitOps Sync Loop	Git Repo를 지속적으로 Watch → Etcd 매니페스트와 자동 동기화(Prune 포함)
Declarative Rollout	kubectl 명령 필요 없이 Controller가 상태만 보고 Desired State 적용
Health & Rollback 내장	Progressing/Degraded 상태 판별 → 실패 시 Auto Rollback (옵션)
멀티 Cluster 지원	clusterSecret, project 단위로 여러 Cluster/Namespace 일괄 관리

▶ 요약하면, “배포 이후 계속 상태를 지켜보고 자동으로 맞춰주는 역할”이 Argo CD의 존재 이유다.

---

13‑4. 실전 선택 가이드

사용 시나리오	권장 툴
코드 → 컨테이너 이미지 빌드 & 테스트	Jenkins/Tekton
컨테이너 이미지 → 쿠버네티스 배포 + 상태 지속 모니터링	Argo CD

결론 : CI(Continuous Integration)과 CD(Continuous Delivery/Deployment)를 명확히 분리 하면 파이프라인이 단순해지고,
롤백·추적·보안(권한 최소화)까지 자연스럽게 확보된다. 🚀

---

마무리 한마디

쿠버네티스 = 선언적 오케스트레이션
결국 API Server ↔ Etcd ↔ Controller 간 이벤트 루프를 이해해야 실전에서 흔들리지 않는다.