사이드카 활용 패턴과 namespace 활용 전략

sidecar pattern - Adapter

주 컨테이너가 출력하는 데이터를 외부 시스템이 이해할 수 있도록 변환해주는 역할

 

• 주 컨테이너는 로그나 데이터를 자체 포맷으로 출력 / 외부 시스템 (모니터링 툴, 로깅 시스템)은 특정 포맷(JSON 등)을 요구하는 경우
• 기존 시스템을 바꾸기 어려울 때 중간에서 변환기로서 사용
• Metrics data를 Prometheus가 이해할 수 있도록 변환하는 Exporter도  adapter로 볼 수 있음
• 주 컨테이너가 단순 text로 로그를 출력 -> 로그 수집기인 Fluentd 형식(JSON)으로 변환하여 전달하는 경우

Pod
├── main-container (앱: 로그를 plain text로 출력)
└── adapter-container (텍스트를 JSON으로 변환해서 log collector로 전달)

 

 

 

sidecar pattern - Ambassador

주 컨테이너 대신 외부와의 통신을 담당하는 프록시 역할, 네트워크 요청을 가로채거나 중계하는 역할을 함

 

• 주 컨테이너가 외부 시스템과 직접 통신하면 복잡해지거나 보안상 위험할 때
• 인증, 로깅, 트래픽 제어 등을 사이드카가 처리하게 하고, 주 컨테이너는 로직에만 집중하게 할 때
• 주 컨테이너는 내부 시스템과만 통신하고, 외부 요청은 모두 envoy sidecar가 받아서 라우팅함
• 데이터베이스 접근을 ambassador sidecar가 프록시해서 보안/로깅 적용

Pod
├── main-container (앱: localhost의 DB에 접속한다고 가정)
└── ambassador-container (외부 DB에 연결하고, main에서 온 요청을 중계)

 

 

항목	Adapter Pattern	Ambassador Pattern
주 역할	출력 변환기 (Output Translator)	네트워크 프록시 (Network Proxy)
방향	내부 → 외부	외부 ↔ 내부
주요 목적	포맷 변환, 호환성 확보	네트워크 중계, 보안/정책 적용
예시	로그 변환기, metrics exporter	envoy, DB 프록시, API gateway 사이드카 등

 

---

자원 격리

• 여러 팀, 프로젝트, 환경(예: dev/staging/prod) 간의 충돌 방지 및 독립성 보장
• 각각의 팀/프로젝트마다 별도의 네임스페이스를 생성하여 워크로드, 서비스, 구성요소 등을 분리
• 이름 충돌 방지 (app이라는 서비스가 여러 네임스페이스에 존재 가능)
• 접근 제어 및 모니터링 단위로 활용 가능

---

리소스 할당 제한 (ResourceQuota, LimitRange)

ResourceQuota

• 네임스페이스 내에서 사용할 수 있는 리소스 총량(CPU, 메모리, 오브젝트 수 등)을 제한

예시

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "100"

 

 

LimitRange

• 네임스페이스 내 Pod/Container 단위로 최소/최대 자원 사용량 또는 기본값 설정

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    type: Container

---

접근 제어 및 보안 (RBAC + Namespace)

• Role 및 RoleBinding을 통해 네임스페이스 단위로 접근 권한을 세밀하게 제어할 수 있음
• 특정 네임스페이스에 대해 read-only 권한만 부여
• 팀 A는 team-a 네임스페이스에만 권한, 팀 B는 team-b에만 권한

# Role: dev-team 네임스페이스에서 Pod만 조회할 수 있는 권한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# RoleBinding: 사용자 alice에게 위 Role을 부여
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev-team
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

---

네트워크 분리 (NetworkPolicy)

• 네임스페이스 기반으로 인그레스/이그레스 트래픽을 제어
• 특정 네임스페이스는 외부 인터넷으로 나가는 것을 차단
• 팀 간 네임스페이스 간 통신을 차단하여 보안 강화

 

특정 namespace의 모든 ingress 트래픽 차단

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: finance
spec:
  podSelector: {}
  policyTypes:
  - Ingress

 

 

app-team namespace 내 pod만 동일 namespace의 pod와 통신 허용

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: app-team
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
  policyTypes:
  - Ingress

 

 

---

모니터링 및 로깅 분리

• 네임스페이스 단위로 메트릭, 로그 수집 경로를 분리하여 각 팀이 자신들의 시스템만 관찰 가능
• Prometheus Operator: 네임스페이스 단위 ServiceMonitor 생성
• Loki / Fluentd: 네임스페이스별 로그 수집 필터링 적용

---

네임스페이스 별 환경 구성

• 개발/테스트/운영 환경을 각각 네임스페이스로 구성하여 환경 별 설정 및 리소스 격리
• dev, stage, prod 네임스페이스에 동일한 애플리케이션을 배포하되, ConfigMap이나 Secret은 각기 다르게 구성

---

오토스케일 및 비용 관리

• 네임스페이스 단위로 사용 리소스를 측정하여 부서/팀 별 비용 산정 가능
• Horizontal Pod Autoscaler, Vertical Pod Autoscaler를 네임스페이스 단위로 운영 가능

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
  namespace: team-a
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70