1. Node Pool 분산 배치 - 가용성과 성능의 기본
(1) 멀티 AZ 구성
- 목적: 특정 Zone 장애 시 서비스 전체 중단을 방지
- 구성 방법
az aks nodepool add \
--resource-group MyRG
--cluster-name MyAKS \
--name np-app \
--zones 1 2 3 \
--node-count 3
- 주의
- 단일 Zone에 Node Pool을 구성하면 해당 Zone 장애 시 모든 Pod가 중단될 수 있음
- 다중 Zone 배치 시 네트워크 지연(latency)과 데이터 동기화 방식 고려 필요
2. Worker Node 자원 컨트롤 - 안정적인 워크로드 운영
(1) Requests / Limits 설정
- Requests: Pod 스케줄링 시 반드시 보장되는 자원
- Limits: 컨테이너가 사용할 수 있는 최대 자원
- 설정 예시
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1000m
memory: 1.5Gi
3. Worker Node 부하 분산과 무중단 업그레이드
(1) Pod 분산 배치 (Pod Topology Spread Constraints)
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: my-service
- 목적: Pod가 특정 Node나 Zone에 쏠리지 않게 분산
- 핵심 개념
- 분산(Spreading): 같은 애플리케이션의 여러 Pod를 서로 다른 노드/존에 골고루 퍼뜨려 장애 한 번에 전부 죽지 않게 하자
- 근접성(Affinity): 같이 붙여두면 좋은 애들(예: 앱 Pod ↔ 캐시 Pod)을 가깝게 놓아 지연을 줄이자.
- 분리(Anti-affinity): 서로 떨어뜨려야 안전한 애들(예: 동일 앱의 복제본)을 같은 노드에 몰아넣지 말자. - 실행
- 고가용성/재해복구: 복제본을 서로 다른 노드/가용영역에 분산 → 노드/존 장애에도 서비스 지속.
- 성능: 앱 Pod를 캐시/DB 프록시 Pod와 가까이(같은 노드/같은 존) 배치 → 지연(Latency) 감소.
- 비용/자원 활용: Spread로 핫스팟과 과부하를 피하고, 필요 시 ScheduleAnyway로 유연성 확보. - 주의사항
- 노드 라벨 확인: 토폴로지 키는 실제 노드 라벨로 존재해야 합니다.- 존: topology.kubernetes.io/zone
- 호스트: kubernetes.io/hostname
- Bash 예시> kubectl get nodes --show-labels | grep topology.kubernetes.io/zone
- whenUnsatisfiable 선택:- 엄격한 HA가 필요하면 DoNotSchedule.
- 일단 배치가 중요하면 ScheduleAnyway.
- labelSelector 일치: Spread는 선택자에 매칭되는 Pod끼리 균등 비교합니다. 라벨 불일치로 효과 없어진 경우가 흔해요.
- 노드/존 수 부족: 3존에 고르게 퍼뜨리려면 실제로 3존에 스케줄 가능한 노드가 있어야 해요. 없으면 스케줄 실패 → 노드 증설이나 제약 완화 필요.
- 다른 조건과의 충돌: nodeSelector/affinity/taints 등과 함께 쓰면 충돌로 스케줄이 막힐 수 있어요. 점진적으로 제약을 더하세요.
- 오토스케일러: CA(HPA/Cluster Autoscaler)와 함께 쓰면 분산 제약을 만족시키기 위해 특정 존의 노드만 늘어나는 현상이 생길 수 있어요. 의도에 맞는지 확인하세요.
(2) Cluster Autoscaler
- Node Pool별 최소/최대 노드 수 지정
az aks nodepool update \
--resource-group MyRG \
--cluster-name MyAKS \
--name np-app \
--enable-cluster-autoscaler \
--min-count 2 \
--max-count 10
(3) Pod 배치 전략 - Taint & Toleration
- 의미 : 노드에 Taint를 설정하여, 특정 파드 외에는 다른 pod 스케줄 배치를 막는 설정
- 종류 :
- NoSchedule : 오염을 관용하지 않는 Pod는 절대 스케줄링되지 않음.
- PreferNoSchedule : 가능한 한 스케줄하지 않으려고 하지만, 불가피하면 스케줄될 수 있음 (soft)
- NoExecute : 새 Pod가 스케줄되지 않을 뿐 아니라, 이미 올라와 있는 Pod도 퇴출(evict)됨,
단, TolerationSeconds 설정으로 "얼마나 버틸지" 조절 가능.
(4) Node Pool 무중단 업그레이드 절차
- 컨트롤 플레인 업그레이드
- 임시 Node Pool(newagentpool) 추가
- 기존 Node Pool AutoScaling 비활성화
- 기존 Node Pool Pod 스케줄링 비활성화(Cordon) + Drain
- 임시 Node Pool로 Pod 이동 및 정상 동작 확인
- 기존 Node Pool 업그레이드
- 기존 Node Pool Autoscaling 활성화
- 기존 Node Pool Pod 스케줄링 활성화
- 임시 Node Pool Pod 스케줄링 비활성화 + Drain
- 서비스 정상 확인 후 임시 Node Pool 삭제
4. 네트워크 & 스토리지 성능 최적화
(1) Network Policy 적용
- 목적
- Pod간 불필요한 트래픽 차단
- 마이크로서비스 간 최소 권한 통신 모델 적용 (Zero Trust) - 옵션
| 옵션 | 특징 |
| Azure NPM (network policy manager) | - Azure Native 관리, Calico 보다 설정 단순 - AKS 네트워크 플러그인 azure일 때 사용 가능 |
| Calico | - 오픈 소스, 기능 유연성 높음 - azure / kubenet 네트워크 플러그인 모두 지원 |
- 예시 정책
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-frontend-to-backend
namespace: app
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
(2) Storage 최적화
- AKS 환경에서는 스토리지 선택이 워크로드 특성에 따라 성능·비용에 직접 영향.
시나리오 권장 스토리지 이유 랜덤 읽기/쓰기 파일 Azure Files SMB/NFS 대규모 순차 엑세스 Azure Blob Storage 대용량 스트리밍·분석에 최적, 저비용 고 IOPS 필요 Premium SSD 높은 성능, 저지연 - SAS 토큰을 통한 Blob 직접 접근
- 장점: WAS 서버 부하 감소, 네트워크 홉 최소화
- 예시
az storage blob generate-sas \
--account-name mystorage \
--container-name mycontainer \
--name bigfile.mp4 \
--permissions r \
--expiry 2025-08-20T00:00:00Z
- Access Key는 계정 전체 권한을 부여하므로 최소 권한 원칙에 위배됨.
- Premium SSD는 가격이 높으므로, 필요한 워크로드에만 적용.
5. 참고 문서
'Azure 상식' 카테고리의 다른 글
| RAG를 위한 저장소/DBMS Azure 서비스 선택 (0) | 2025.08.21 |
|---|---|
| TerraForm의 이해 (0) | 2025.08.19 |
| AKS Node Pool 이해와 운영 모범 가이드 (0) | 2025.08.19 |
| CI/CD Pipeline 구성 시 Credential 관리 주의 사항과 방법 (1) | 2025.08.18 |
| AKS Istio add-on 적용 시 유의 사항 (1) | 2025.08.18 |