카테고리 없음

성덕이의 티티티2

seongduck 2025. 8. 28. 01:18

AKS 성능 개선에 대한 이해

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
    - maxSkew 설정: 너무 빡빡하면(예: maxSkew: 0) 스케줄 실패가 잦아요. 1~2 정도로 시작하세요.
    - 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 무중단 업그레이드 절차 

  1. 컨트롤 플레인 업그레이드
  2. 임시 Node Pool(newagentpool) 추가
  3. 기존 Node Pool AutoScaling 비활성화
  4. 기존 Node Pool Pod 스케줄링 비활성화(Cordon) + Drain
  5. 임시 Node Pool로 Pod 이동 및 정상 동작 확인
  6. 기존 Node Pool 업그레이드
  7. 기존 Node Pool Autoscaling 활성화
  8. 기존 Node Pool Pod 스케줄링 활성화
  9. 임시 Node Pool Pod 스케줄링 비활성화 + Drain
  10. 서비스 정상 확인 후 임시 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. 참고 문서

TerraForm의 이해

. 서론

  • 클라우드 리소스 배포는 단순한 서버 생성 이상을 요구합니다. 네트워크, 보안 그룹, 스토리지, 애플리케이션 구성까지 모두 정교하게 관리되어야 하죠. 이를 사람이 수동으로 Azure 포털에서 일일이 설정한다면 실수 가능성이 높고, 변경 이력 관리도 어렵습니다.
    이 문제를 해결하기 위해 등장한 접근 방식이 Infrastructure as Code(IaC)이며, 그 대표 도구가 Terraform입니다. Terraform은 HashiCorp에서 만든 오픈소스 IaC 도구로, 선언적 언어를 이용해 Azure와 같은 클라우드 인프라를 코드로 정의하고 자동으로 배포·관리할 수 있게 해줍니다.

2. 본론

A. 기본 구조 이해하기

  • Terraform은 .tf 확장자를 가진 코드 파일에 인프라 구성을 선언합니다.
    아주 단순한 예시는 아래와 같습니다.

provider “azurerm” {
features {}
}

resource “azurerm_resource_group” “example” {
name = “rg-example”
location = “koreacentral”
}

  • provider "azurerm": Azure 리소스를 다룰 때는 반드시 Provider를 정의해야 합니다. 여기서 features {} 블록은 AzureRM Provider의 필수 초기화 구문으로, 특정 기능을 켜거나 끄는 옵션을 포함할 수 있습니다.
  • resource "azurerm_resource_group": 실제 생성할 리소스입니다. "example"이라는 로컬 이름으로 관리되며, 코드 안에서 참조할 수 있습니다.
  • location: Azure 리소스는 지역성을 갖기 때문에 반드시 명시해야 합니다.

B. 스토리지 계정 예시

  • 리소스 그룹 다음으로 자주 쓰이는 것이 스토리지 계정입니다.

resource “azurerm_storage_account” “example” {
name = “stexample12345”
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
account_tier = “Standard”
account_replication_type = “LRS”
}

  • resource_group_name, location: 위에서 만든 리소스 그룹을 그대로 참조합니다. 이렇게 코드를 연결하면 사람이 일일이 위치를 지정할 필요가 없어집니다.
  • account_tier, account_replication_type: Azure 스토리지 성능과 가용성을 결정하는 핵심 옵션입니다. IaC로 작성해두면, 나중에 성능 조정 시 변경사항이 코드에 남아 형상 관리가 가능합니다.

C. Variables와 Outputs 활용

  • 하드코딩을 피하고 재사용성을 높이려면 변수를 씁니다.

variable “prefix” {
default = “demo”
}

resource “azurerm_resource_group” “rg” {
name = “${var.prefix}-rg”
location = “koreacentral”
}

output “resource_group_name” {
value = azurerm_resource_group.rg.name
}

  • variable: 동일한 코드가 여러 환경(dev, test, prod)에서 재사용될 수 있게 합니다.
  • output: 배포 후 다른 모듈이나 사용자에게 필요한 값을 노출합니다. 예를 들어 리소스 그룹 이름을 CI/CD 파이프라인에서 참조할 수 있습니다.

D. 운영에서 중요한 개념 — State 관리

  • Terraform은 terraform.tfstate라는 파일에 현재 리소스 상태를 기록합니다. 이 파일을 바탕으로 “코드와 실제 Azure 환경의 차이”를 판단하고, terraform plan 명령으로 변경 내용을 미리 보여줍니다.
  • 장점: 운영자가 실수로 리소스를 삭제할 위험을 줄여줍니다.
  • 주의: 팀 협업 시 이 파일은 반드시 **원격 스토리지(예: Azure Storage Backend)**에 보관해야 충돌을 피할 수 있습니다.

E. 모듈화

  • 규모가 커지면 리소스를 모듈 단위로 쪼개야 관리가 편해집니다. 예를 들어 네트워크, VM, 데이터베이스를 각각 모듈로 정의해두고, 메인 코드에서 불러옵니다. 이렇게 하면 팀별로 분업이 가능하고, 재사용성도 높아집니다.

F. 예제 코드

provider “azurerm” {
features {}
}

# 1. 리소스 그룹 생성
resource “azurerm_resource_group” “rg” {
name = “demo-rg”
location = “koreacentral”
}

# 2. 스토리지 계정 생성
resource “azurerm_storage_account” “storage” {
name = “demostorage12345”
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
account_tier = “Standard”
account_replication_type = “LRS”
}

# 3. 가상 네트워크 + 서브넷 (VM 배포를 위해 필요)
resource “azurerm_virtual_network” “vnet” {
name = “demo-vnet”
address_space = [“10.0.0.0/16”]
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
}

resource “azurerm_subnet” “subnet” {
name = “demo-subnet”
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
address_prefixes = [“10.0.1.0/24”]
}

# 4. 네트워크 인터페이스
resource “azurerm_network_interface” “nic” {
name = “demo-nic”
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name

ip_configuration {
name = “internal”
subnet_id = azurerm_subnet.subnet.id
private_ip_address_allocation = “Dynamic”
}
}

# 5. 가상머신 생성
resource “azurerm_linux_virtual_machine” “vm” {
name = “demo-vm”
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
size = “Standard_B1s”
admin_username = “azureuser”
network_interface_ids = [azurerm_network_interface.nic.id]

os_disk {
caching = “ReadWrite”
storage_account_type = “Standard_LRS”
}

source_image_reference {
publisher = “Canonical”
offer = “UbuntuServer”
sku = “18.04-LTS”
version = “latest”
}

admin_ssh_key {
username = “azureuser”
public_key = file(“~/.ssh/id_rsa.pub”)
}
}

3. Azure Terraform CLI 작성시 몇가지 유의사항

  •    pod_cidr 옵션 설정
     => Azure CNI 인 경우 각 Pod IP들은 서브넷에서 직접 할당받기 때문에 pod_cidr 옵션을 쓰지 않아야 한다.
          다음은 AKS 네트워크 추가 옵션 별 작성 요령을 정리한 표이다.
    항목 Kubenet Azure CNI Azure CNI + Overlay
    Pod IP 출처 Pod 전용 CIDR(노드 VNet과 분리)에서 할당 노드와 같은 VNet 서브넷에서 직접 할당 Pod 전용 CIDR(노드 VNet과 분리)에서 할당
    외부로 나갈 때 노드 IP로 SNAT돼 나감 같은 VNet 내 대상은 Pod IP가 그대로 보임 기본적으로 노드 IP로 NAT하여 외부 도달
    VNet IP 소모 적음 많음(대규모 시 서브넷 IP 고갈 위험) 적음(대규모 확장 유리)
    설정 키 포인트 network_plugin="kubenet" + pod_cidr 지정 network_plugin="azure" (일반) → pod_cidr 미사용 network_plugin="azure" + network_plugin_mode="overlay" + pod_cidr 지정
    공식 개념 문서 kubenet 개요(별도 Pod 대역) “Pod가 서브넷에서 IP를 받음”  “Pod는 VNet과 다른 private CIDR에서 IP” + NAT
  • Azure ARM Terraform 문법 기본 규칙
    필드 이름 형태 기대하는 값 예시 기타
    *_name, name 이름 문자열 name = "vnet-app" / resource_group_name = azurerm_resource_group.rg.name 이름은 짧은 리소스명(포털에 보이는 이름)
    id, *_id, resource_id, target_resource_id, parent_id, scope ARM 리소스 ID(풀경로) subnet_id = azurerm_subnet.app.id / scope = azurerm_resource_group.rg.id 포털의 “리소스 ID”에 해당. **.id**로 참조하는 게 정석
    location 리전 문자열 location = azurerm_resource_group.rg.location 혹은 "Korea Central" 보통 RG의 location을 그대로 상속
    숫자/불리언/맵 타입에 맞는 리터럴 port = 80, enabled = true, tags = { env = "prod" }  
    문자열 내 참조 문자열 보간 name = "vm-${var.env}-01" HCL 0.12+에서는 name = "${var.env}"도 가능하지만 위가 가독성↑
  • 추가 체크리스트
    - 이 필드는 이름 자리인가요? → "..." 또는 … .name
    - 이 필드는 ARM ID 자리인가요? → … .id (따옴표 없이)
    - location은 RG에서 그대로 상속했나요? → …rg.location
    - 포털 ID를 하드코딩하지 않았나요? → data 소스/리소스 참조로 대체
    - 모듈 변수는 “이름/ID 중 하나로 타입을 표준화”했나요?

4. 중요 예제 코드

# Create Public Load Balancer
resource "azurerm_lb" "example" {
  name                = var.load_balancer_name
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku                 = "Standard"

  frontend_ip_configuration {
    name                 = var.public_ip_name
    public_ip_address_id = azurerm_public_ip.example.id
  }
}

# Create Backend Address Pool for the Load Balancer
resource "azurerm_lb_backend_address_pool" "example" {
  loadbalancer_id = azurerm_lb.example.id
  name            = "test-pool"
}

# Create Load Balancer Health Probe
resource "azurerm_lb_probe" "example" {
  loadbalancer_id = azurerm_lb.example.id
  name            = "test-probe"
  port            = 80
}

# Create Load Balancer Rule
# This rule will forward traffic from the frontend IP configuration to the backend address pool
# on port 80 using TCP protocol. It also disables outbound SNAT for the backend pool.
# The probe is used to check the health of the backend instances.
resource "azurerm_lb_rule" "example_rule" {
  loadbalancer_id                = azurerm_lb.example.id
  name                           = "test-rule"
  protocol                       = "Tcp"
  frontend_port                  = 80
  backend_port                   = 80
  disable_outbound_snat          = true
  frontend_ip_configuration_name = var.public_ip_name
  probe_id                       = azurerm_lb_probe.example.id
  backend_address_pool_ids       = [azurerm_lb_backend_address_pool.example.id]
}

resource "azurerm_lb_outbound_rule" "example" {
  name                    = "test-outbound"
  loadbalancer_id         = azurerm_lb.example.id
  protocol                = "Tcp"
  backend_address_pool_id = azurerm_lb_backend_address_pool.example.id

  frontend_ip_configuration {
    name = var.public_ip_name
  }

5. 참고 문헌

RAG를 위한 저장소/DBMS Azure 서비스 선택

 

1. 서론

RAG(Retrieval-Augmented Generation) 아키텍처에서 가장 중요한 요소 중 하나는 “정보를 어디에, 어떻게 저장하고 검색할 것인가”입니다. 단순한 데이터 보관을 넘어, 벡터 검색 · meta data · 필터링 · 검색 품질 최적화까지 고려해야 합니다. Azure는 이를 위해 다양한 선택지를 제공하며, 각 서비스는 특징과 적합한 시나리오가 다릅니다.

 

2. 본론

(1) Azure AI Search

  • 특징: 하이브리드 검색(키워드+벡터), Reciprocal Rank Fusion(RRF), Semantic ranker 지원.
  • 적합 시나리오: “검색 품질+운영 편의”가 최우선일 때.
  • 장점: Blob/ADLS 등에서 문서를 직접 인덱싱 가능, 관리형 서비스.

(2) Azure Cosmos DB

  • 특징: 벡터 필드를 문서/레코드와 함께 저장 가능, 글로벌 분산, 낮은 지연.
  • 적합 시나리오: 트랜잭션 데이터베이스와 벡터 검색을 통합하고 싶을 때.
  • 장점: MongoDB vCore/NoSQL 모두 벡터 검색 지원.

(3) Azure Database for PostgreSQL (pgvector)

  • 특징: pgvector 확장을 통한 HNSW/IVF 인덱스, SQL 기반 운영.
  • 적합 시나리오: 오픈소스 생태계 활용, SQL 친화 환경에서 자유롭게 벡터 검색을 통제하고 싶을 때.

(4) Azure Cache for Redis (Enterprise)

  • 특징: 인메모리 벡터 검색, 초저지연 응답.
  • 적합 시나리오: 세션 캐시, 피드 재랭킹, 실시간 추천 등 고QPS 환경.
  • 장점: 주 스토어 앞단 캐싱/가속 계층으로 사용.
  • 주의 : 벡터 검색은 Basic/Standard 에서 사용 불가. Premium 혹은 Enterpise 만 가능

(5) Azure SQL Database (벡터 기능)

  • 특징: SQL 환경 그대로 벡터 저장 및 유사도 검색 제공(미리보기/지역 한정 기능).
  • 적합 시나리오: 기존 SQL 생태계 변경 없이 최소한의 수정으로 RAG 통합.

3. 결론

  • 검색 품질 최우선: Azure AI Search → 기본 선택
  • 데이터베이스 일원화: Cosmos DB → 문서+벡터 통합
  • SQL 친화적·자유도: PostgreSQL(pgvector) → 세밀한 컨트롤
  • 극저지연 요구: Redis → 캐시형 보조 레이어
  • 레거시 SQL 유지: Azure SQL 벡터 기능
  • 즉, 단일 정답은 없으며, RAG의 목적(검색 품질, 데이터 통합, 성능 요구)에 따라 적합한 서비스를 조합하는 것이 가장 효과적

4. 참고 자료

Azure Function Tier 특징 이해와 선택(대용량 Batch를 위한 Function Tier)

1. 서론

  • Azure Functions는 다양한 가격 및 성능 요구 조건을 만족시키는 여러 **호스팅 플랜(Tier)**을 제공하며, 이는 커스텀 워크로드 — 특히 Durable Functions 기반의 대용량 Batch 처리 — 에 매우 중요합니다. Microsoft 공식 문서를 기반으로, 각 Tier의 특성과 비교, 그리고 Durable Functions 실행에 적합한 Azure Function Tier 선택 기준을 정리합니다.

2. 본론

A. 주요 Azure Function 호스팅 Tier 비교

  • Consumption Plan : 완전 서버리스, 사용량 기반 과금. 콜드 스타트 있으며, 실행 시간 기본 5분 최대 10분 제한. 무료 그랜트 포함.
  • Flex Consumption Plan : 서버리스 + virtual network, Always Ready 인스턴스 옵션, 확장 시간 제한 없음. GA 상태이며, 동시에 Availability Zone 대응 가능.
  • Premium Plan (Elastic Premium) : Always Ready / Pre-warmed 인스턴스로 콜드 스타트 제거, VNet, 긴 실행, 컨테이너 지원. 실행 시간 제약 없음, 예측 가능한 과금.
  • Dedicated (App Service) Plan : App Service 기반 VM에 항상 실행, Autoscale 설정 가능. Always On 설정 필요, 예측 가능한 고정 과금.

B. Durable Functions를 위한 호스팅 제약사항

  • “Durable Functions(지속형 함)”는 서버리스(Azure Functions) 위에서 상태를 가지는(내구성 있는) 워크플로를 코드로 작성할 수 있게 해주는 확장
  • Execution Time : Consumption Plan: Orchestrator replay 시 재실행마다 과금, 실행 시간 제한 (예: 기본 5분) 유의.
  • 스케일링 및 내결함성 : Flex 및 Premium Plan에서 Availability Zone 지원 가능 → 가용성 향상.
  • 스케일 아웃 성능 : Premium Plan이 더 빠른 스케일 아웃 및 긴 단일 실행 시간 지원 (30분 대 5분).

C. Durable Functions를 쓰는 목적

  • 팬아웃/팬인: 1000개 작업을 병렬(Activity)로 던지고 결과 집계. 대량 처리/ETL에 적합
  • 비동기 HTTP API: 230초 제한이 있는 일반 HTTP 호출 대신, “수락(202)+상태 조회 URL” 패턴으로 장기 작업 진행률을 제공.
  • 휴먼 인터랙션: 승인/입력 같은 외부 이벤트를 오케스트레이터가 기다림(타이머로 타임아웃도 동시 설정).
  • Aggregator/엔티티: 이벤트를 누적 집계하거나 개별 키별 상태를 관리(가벼운 가상 액터).
  • 모니터 패턴: 워크플로에서 유연하고 반복되는 프로세스

3. 결론

  • Durable Functions 기반 대용량 Batch 처리에서는 Premium Plan이 가장 안정적이고 확장성 있는 선택입니다. 다만, 비용 효율을 우선시한다면 Flex Consumption Plan이 현실적인 대안이 될 수 있습니다. 결국 선택은 **워크로드의 우선순위 — 성능 vs 비용 vs 가용성 — 에 따라 달라집니다.

4. 참고 문서

Azure Managed Disk 에 대한 이해

1. 관리형 디스크란?

  • Azure 관리형 디스크는 Azure에서 관리하고 Azure Virtual Machines와 함께 사용되는 블록 수준 저장소 볼륨입니다. 관리형 디스크는 온-프레미스 서버의 실제 디스크와 유사하지만 가상화되며, 관리형 디스크를 사용하는 경우 디스크 유형과 크기만 지정하고 디스크를 프로비저닝하면 됩니다.
  • 비관리형 디스크도 존재합니다. 다만, 이는 이전 세대 방식으로 '25년 지금은 거의 사용하지 않으며, 사용자가 직접 생성/관리해야하는 레거시 형태로 권장하지 않습니다.

2. 주요 장점

  • 스토리지 계정 관리 불필요: IOPS, 용량 분산, 가용성 등을 Azure가 알아서 관리.
  • 고가용성: 디스크 데이터는 3중 복제 (LRS) 또는 지역 간 복제 (ZRS/GRS) 가능.
  • 확장성: 수천 개 디스크를 붙여도 스토리지 계정 한도에 걸리지 않음.
  • 스냅샷/백업 지원: 스냅샷, 이미지, Shared Disk 기능 제공.
  • 보안: Azure Disk Encryption, 고객 관리형 키(CMK), Private Link 지원.

3. 종류별 특징

  • Premium SSD v2
    • 최신 세대, 초저지연, 고성능 (최대 수십만 IOPS).
    • 워크로드에 맞춰 성능(Throughput/IOPS)을 세밀히 설정 가능.
    • 고성능 DB, 미션 크리티컬 앱에 적합.
  • Premium SSD
    • 고성능 SSD, 예측 가능한 IOPS.
    • OLTP DB, 고성능 애플리케이션 적합.
  • Standard SSD
    • 가성비 좋은 SSD, 성능은 Premium보단 낮음.
    • 웹 서버, 테스트/개발용 환경에 적합.
  • Standard HDD
    • 저비용, 대용량 HDD.
    • 백업, 저빈도 액세스 워크로드에 적합.
  • Ultra Disk
    • 가장 높은 성능 (최대 160K IOPS, 2,000 MB/s).
    • 초저지연 (밀리초 단위).
    • SAP HANA, 금융 거래 DB 등 초고성능 워크로드.

4. 디스크 변경/확장 축소에 대해

  • 직접 축소는 지원되지 않습니다. 관리형 디스크는 포털/CLI에서 확장만 할 수 있어요. 줄이려면 작은 새 디스크를 만든 뒤 데이터 마이그레이션(복사) → 기존 디스크 삭제가 권장 방식입니다.
  • 디스크 확장은 OS디스크와 데이터 디스크 차이가 있습니다.
  • OS 디스크: 무중단 확장 불가 → VM 중지/재시작 필요합니다. (무중단 확장은 “데이터 디스크에만” 적용) 또한 OS 디스크는 최대 4,095 GiB 한도가 있으며, 2 TiB 넘어가려면 GPT 파티션이어야 합니다.
  • 데이터 디스크: 대부분 무중단(Deallocate 없이) 확장 가능합니다. 단, 아래 예외가 있어요. Microsoft Learn
    • (표준 HDD/표준 SSD/기존 Premium SSD)가 4 TiB 이하일 때 4 TiB를 넘겨 키우려면 한 번 VM 중지/분리 후 확장해야 합니다. 이미 4 TiB 초과 상태라면 계속 무중단 확장 가능. Microsoft Learn
    • Shared Disk에는 무중단 확장 미지원. Microsoft Learn
    • Premium SSD v2 / Ultra Disk는 위 4 TiB 경계 제한이 없음(다만 아래 스냅샷/백그라운드 복사 중일 땐 불가). 또한 NVMe 컨트롤러로 붙은 경우 대부분 지역에서 무중단 확장 가능(일부 예외 지역 언급). Microsoft Learn
  • “재기동 없이 확장: Ultra, Premium SSD v2는 크기상 제약이 없고, 그 이하 모델은 4 TB 이하/초과 조건에 따라 다름”
  • 운영팁
    -     확장 전: 백업/스냅샷 잡이 도는지 확인(특히 PS v2/Ultra는 백그라운드 복사 중 확장 금지)
    - 포털/CLI에서 디스크 크기 증설(데이터 디스크는 무중단 가능 조건 확인)
    - 게스트 OS에서 파티션/파일시스템 확장(Linux: lsblk/LVM/resize2fs 등, Windows: 디스크관리/DiskPart). (ADE 사용 시 가이드 따라 진행)
    - OS 디스크라면 사전에 다운타임 계획 수립. MBR→2 TiB 한계 주의(필요 시 GPT)
  • MBR (Master Boot Record)
    • 오래된 디스크 파티션 방식으로, BIOS 기반 시스템에서 주로 사용.
    • 구조적으로 주소 지정 한계가 2TiB라, 디스크 크기가 그 이상이면 인식하지 못합니다.
    • 즉, OS 디스크를 MBR로 포맷해 두면 2TB까지만 확장 가능해요.
  • GPT (GUID Partition Table)
    • UEFI 기반 시스템에서 사용되는 최신 파티션 방식.
    • 수십 TB 이상도 지원하며, 복원력·보안성이 높음.
  • Azure에서의 의미: OS 디스크가 MBR이면 2TB까지만 확장되므로, 그 이상 크기를 원하면 GPT로 변환해야 합니다. (Windows/Linux 모두 변환 방법 제공)

“반드시 재기동(중지/시작)이 필요한” 대표 케이스

  • OS 디스크 확장(무중단 확장 미지원). Microsoft Learn
  • Standard/Premium(기존) 데이터 디스크를 4 TiB 경계 넘겨 키울 때(≤4 TiB → >4 TiB): 디스크 분리/VM Deallocate 필요. Microsoft Learn
  • 디스크 타입 전환(예: Standard↔Premium, Premium SSD v2 전환 등): 변경 전 VM 중지가 요구됩니다. (Ultra/PS v2 간 이관은 보통 스냅샷 기반 마이그레이션) Microsoft Learn
  • Shared Disk는 무중단 확장 미지원. Microsoft Learn
  • 확장 후 OS에서 새 용량 인식 문제가 있으면, OS 재스캔이 필요하고 상황에 따라 재부팅이 가장 빠른 해결일 수 있습니다. Microsoft Learn

 

5. 디스크 암호화와 확장과의 관계

A. Server‑Side Encryption (SSE) — PMK/CMK

  • Azure는 모든 관리형 디스크·스냅샷·이미지를 기본적으로 암호화합니다(플랫폼 키 PMK). CMK(Disk Encryption Set) 사용 시에도 일반적인 디스크 확장 기능에는 제약이 없습니다. 스냅샷/이미지도 암호화가 유지됩니다.
  • 단, CMK 사용 중이면 디스크와 해당 스냅샷이 같은 DES를 공유해야 합니다(혼합 불가). Microsoft LearnAzure 문서

B. Azure Disk Encryption (ADE: BitLocker/LUKS)

  • ADE는 게스트 OS 내부 볼륨 암호화라, 디스크 크기를 늘린 후 OS 내 볼륨/파일시스템 확장 단계를 별도로 수행해야 합니다.
    • Linux(ADE+LVM): LVM 확장 절차 가이드가 공식 문서에 있습니다. Microsoft Learn
    • Windows(ADE/BitLocker): OS 볼륨 확장이 바로 안 될 수 있어 우회 절차가 안내돼 있습니다(보호 일시 해제/재스캔 등). Microsoft Learn

C. 백업/스냅샷 동작 중 확장

  • Premium SSD v2 / Ultra Disk는 증분 스냅샷 생성 시 “백그라운드 복사(backfill)”가 진행되며, 이 동안 크기 증가 작업은 실패합니다. → 스냅샷 백그라운드 복사 완료 후 확장하세요. Microsoft Learn+1
  • 그 외 디스크 타입도 백업/스냅샷 진행 중엔 변경 작업을 피하는 것이 안전합니다(일부 항목은 정책/제품에 따라 제한). Microsoft Learn

6. 참고 문서

AKS권한 관리 방식: K8S의 IAM처리 방식의 이해 Entra ID, Service Account 등 이해와 차이점

1. AKS 권한 관리

AKS에서는 권한 관리 시스템이 크게 두 계층으로 나뉩니다:

  • Azure RBAC: Azure 구독과 리소스에 대한 권한 부여. Microsoft Entra ID(구 Azure AD) 기반 인증과 권한 관리 서비스.
  • Kubernetes RBAC: Kubernetes API 리소스(네임스페이스, 리소스, 오브젝트)에 대한 세분화된 권한 정책 및 Role, RoleBinding 메커니즘.

두 시스템은 역할 및 범위를 각각 관리하나, AKS에서는 통합된 사용자 경험을 위해 Microsoft Entra ID와 Azure RBAC 통합 인증이 가능

 

2. Kubernetes IAM 처리 방식 - Kubernetes RBAC

  • Kubernetes RBAC(Role-Based Access Control) 은 네임스페이스/전체 클러스터 단위로 리소스 접근 권한을 역할(Role)에 할당하며, 이 역할을 사용자, 그룹, 서비스 계정에 RoleBinding 또는 ClusterRoleBinding으로 연결해 권한을 부여합니다.
  • Kubernetes Role은 네임스페이스 내 권한, ClusterRole은 클러스터 전역 권한을 뜻합니다.
  • Kubernetes의 인증(Authentication)과 권한 부여(Authorization) 체계가 분리되어 있어, 인증은 Microsoft Entra ID 등 외부 시스템과 연동이 가능하며, 권한 부여는 Kubernetes RBAC가 수행합니다.

3. Microsoft Entra ID(기존 Azure AD)와 연동

  • AKS는 Microsoft Entra ID로부터 사용자 및 그룹 인증을 받아, Azure RBAC와 연동하여 Azure 및 Kubernetes 리소스에 대한 권한을 관리합니다.
  • Microsoft Entra ID는 SAML, OAuth, OpenID Connect 등의 표준 프로토콜을 지원하며, 2단계 인증(MFA), 조건부 액세스 정책 등 강력한 보안 기능을 제공합니다.
  • 관리자는 Entra ID 내 사용자 또는 그룹을 AKS 클러스터와 연동하여 Kubernetes API 서버에 대한 인증 및 권한 관리를 일원화할 수 있습니다.
  • 회사 계정(SSO)와 통합 → 별도 계정 없이 조직의 Entra ID 계정 그대로 사용
  • RBAC(Role-Based Access Control)과 연결 → 예: 특정 Entra 그룹에 “개발자” 권한 부여
  • 계정 lifecycle 자동 관리 (직원이 퇴사/이동 시 Entra에서 비활성화되면 K8s 접근도 자동 차단)
  • MFA(다중 인증), 조건부 액세스 같은 기업 보안 정책과 연동 가능

4. Kubernetes Service Account

  • Service Account는 Kubernetes 내에서 Pod가 API 서버와 통신하거나 외부 리소스에 접근할 때 사용하는 ID입니다.
  • 기본적으로 Pod 생성 시 자동 부여되는 기본 서비스 계정(default service account) 이 있으나, 사용 용도에 따라 별도의 Service Account를 직접 생성하고 필요한 권한을 부여할 수 있습니다.
  • AKS에서는 Service Account와 Azure Managed Identity를 연동하여, Azure 리소스에 안전하게 액세스하는 Workload Identity 패턴도 지원합니다.

5. Azure Service Principal과 Managed Identity

  • Service Principal은 애플리케이션 또는 자동화 프로세스에 권한을 부여하는 Azure AD 내 ID입니다.
  • Service Principal은 Secret 유출/만료 리스크가 있어, Key Vault 보관, 만료 알림·로테션 자동화가 사실상 필수.
  • 다만, 최근에는 Service Principal에 OIDC(페더레이션) 를 쓰면 “비밀 없는 SP”가 가능 → 보안·감사 측면 크게 개선.
  • Managed Identity는 Azure 내 서비스에 제공되는 ID로, 별도의 비밀번호/키 관리 없이 Azure 리소스 접근 권한을 부여할 수 있어 보안성이 높습니다.
  • Pod 레벨 권한 위임을 위해서는 Managed Identity가 Service Account와 연결되어 Azure 리소스 접근에 사용됩니다.

6. AKS 권한 부여 과정 흐름

단계 설명
1. 사용자 인증 Microsoft Entra ID가 사용자 또는 서비스 주체 인증 수행
2. Azure RBAC 확인 인증된 주체에 대해 Azure 리소스 권한 확인
3. Azure RBAC와 Kubernetes RBAC 통합 AKS에 설정된 역할이 Entra ID 사용자에게 매핑, Kubernetes API 접근 권한 결정
4. Kubernetes API 요청 Kubernetes API 서버가 RBAC 정책에 따라 요청자 권한을 확인 후, 리소스 접근 허용 또는 거부
5. Pod Workload 권한 부여 Pod가 Azure 리소스에 접근하는 경우, 연동된 Service Account 및 Managed Identity 토큰 사용

 

7. 주요 차이점 요약

구분 Microsoft Entra ID (Azure AD) Kubernetes Service Account Azure Service Principal / Managed Identity
주체 사용자, 그룹, 앱 신원 Kubernetes 내 Pod, 워크로드 ID Azure 애플리케이션/자동화 프로세스 ID
권한 대상 Azure 리소스 및 구독 권한 Kubernetes 네임스페이스 및 클러스터 리소스 Azure 리소스(스토리지, Key Vault 등) 액세스
인증 OAuth 2.0, OpenID Connect, SAML 프로토콜 지원 토큰 기반 인증 (JWT, 서비스 토큰) OAuth 토큰, Managed Identity 토큰 자동 관리
권한 부여 Azure RBAC 역할 관리 Kubernetes Role/ClusterRole / RoleBinding Azure RBAC 역할 할당 또는 Managed Identity 권한 부여
관리 중앙 통합 관리, 보안 정책 강화 쿠버네티스 네임스페이스별 세부 권한 관리 키 및 인증 정보 자동 갱신, 보안 강화 가능

 

8. AKS 권한 관리 방안

  • 최소 권한 원칙 준수: 필요한 최소 범위 권한만 부여
  • 역할 바인딩은 그룹에 우선 적용: 사용자 직접 할당을 지양
  • Managed Identity 활용 권장: 비밀번호/키 관리 부담 완화
  • 정기 권한 검토와 감사: Azure Monitor, Kubernetes Audit Log 활용
  • Azure AD PIM(Privileged Identity Management) 활용 가능: 권한 승격 및 접근 제어 강화
  • 핵심은 Entra ID 기반 RBAC로 계정을 관리하는 게 모범 사례임.(HR과 연동하여 운영/개발 계정 관리)
  • Azure Managed Identity 는 주로 CI/CD 자동화에 앱/pod 워크로드에 주로 활용됨
  • AKS는 Azure AD Workload Identity + User-assigned MI 조합이 표준.

 

9. 관련 문서

https://learn.microsoft.com/ko-kr/azure/aks/operator-best-practices-identity

https://learn.microsoft.com/ko-kr/azure/aks/manage-azure-rbac?tabs=azure-cli

https://learn.microsoft.com/ko-kr/entra/identity/managed-identities-azure-resources/overview

Azure Load Balancer 이해: 가용성, 분산처리 특징과 Coverage

1. 부하 분산(Load Balancing) 이란

  • 부하 분산은 네트워크나 컴퓨팅 리소스로 몰리는 과도한 트래픽 또는 작업량을 여러 서버나 자원에 고르게 분산해, 과부하와 단일 장애점을 제거하고 서비스의 연속성과 신뢰성을 보장하는 핵심  기술입니다. 애플리케이션 서비스에서 트래픽이 한 대 서버에 몰리거나 네트워크 병목 현상이 발생하면 응답 지연, 서비스 불가, 시스템 장애로 이어질 수 있으며, 부하 분산 장치를 통해 이를 방지합니다.

2.  Azure Load Balancer의 핵심 위치와 작동 원리

Azure Load Balancer는 클라우드 네트워크에서 OSI 4계층인 전송계층(TCP, UDP)에서 작동하는 관리형 L4 부하 분산 서비스입니다.

  • 클라이언트 요청이 단일 프런트엔드 IP (공용 혹은 사설)로 들어오면,
  • 설정된 부하 분산 규칙과 백엔드 풀 내 가상 머신, VM Scale Set, 컨테이너 인스턴스에
  • 헬스 프로브를 통한 상태 점검 결과를 바탕으로 자동으로 요청을 분산 배분합니다.

이는 네트워크의 TCP/UDP 헤더 정보(원본 IP/포트, 목적지 IP/포트, 프로토콜 번호) 등 5-tuple 해쉬 방식을 기반으로 합니다.

 

3.  Azure Load Balancer의 주요 구성 요소

구성 요소 역할 및 기능
프런트엔드 IP 클라이언트가 요청을 보내는 IP 주소 (Public 또는 Private)
백엔드 풀 트래픽이 분산되는 VM, VMSS, 컨테이너 등 자원들의 모임
로드 밸런싱 규칙 프런트엔드 IP의 포트와 프로토콜, 백엔드 풀 내 포트를 연결하는 규칙 설정
상태 프로브 백엔드 자원의 상태를 주기적으로 검사하여 비정상 인스턴스를 제외하는 역할
인바운드 NAT 규칙 특정 포트를 통해 특정 인스턴스로 트래픽을 직접 전달 (ex: SSH, RDP 연결 등)
아웃바운드 규칙 백엔드 자원에서 외부로 나가는 트래픽에 대해 NAT 처리를 수행하는 규칙

 

4. Azure Load Balancer의 핵심 기능

  • 고가용성 유지
    여러 가용성 영역에 분산해 폭넓은 페일오버 지원
  • 대용량 및 초저지연 트래픽 처리
    수백만 개 동시 TCP/UDP 세션을 안정적으로 처리
  • 유연한 IP·포트 매핑
    여러 Public/Private IP, 다수 포트에 대한 부하분산 규칙 설정 가능
  • 백엔드 상태 점검 및 장애 자동 복구
    건강하지 않은 백엔드는 자동으로 분배 대상에서 제외
  • 상세 로깅 및 모니터링
    Azure Monitor와 Log Analytics 통합을 통한 실시간 상태 감시

5. SKU별 특성 비교

  • Basic Load Balancer는 사실상 25-09-30 서비스 종료 예정으로 Standard load Balancer 위주로 구성
  • 가용영역 옵션은 ‘프런트엔드 IP’의 영역 설정으로 결정됩니다. 프런트엔드가 Zone‑redundant(다중 AZ) 이면 LB도 다중 AZ가 되고, Zonal(특정 AZ 고정) 이면 LB도 그 AZ에 고정됩니다. (Public LB는 할당한 Public IP의 영역 속성이 그대로 반영)
  • 리소스가 생성된 후에는 해당 리소스에 대한 영역을 변경, 업데이트 또는 생성할 수 없습니다.
  • 리소스는 생성 후 영역 중복에서 영역 내 중복으로 업데이트할 수 없으며, 그 반대로도 업데이트할 수 없습니다.
  • 지역 전체 장애를 대비하여 멀티 리전으로 구성할 경우에 글로벌 단일 LB에서 지역 LB로 분산/페일오버 구성, App계층이 L4일 경우 표준 모델임
기능 및 특성 Basic Load Balancer Standard Load Balancer
가용성 영역 지원 없음 다중 가용성 영역 완전 지원 (Zone Redundant)
SLA 미제공 99.99%
지원 프로토콜 TCP, HTTP TCP, UDP, HTTP, HTTPS
NAT 아웃바운드 지원 제한적 완전 지원
프런트엔드 IP 형식 Public IP만 Public 및 Private IP 모두 지원
백엔드 풀 지원 NIC만 NIC 및 IP 리소스 모두 지원
진단 및 모니터링 제한적 Azure Monitor, Log Analytics 지원
NSG, UDR 등 보안 정책 연동 제한적 완전 연동 및 보안 강화

 

6. Azure 주요 부하 분산 서비스 비교

서비스명 OSI 레이어 지원 대상 및 용도 특징 및 주요 기능
Azure Load Balancer 4 (TCP/UDP) VM, VMSS, 컨테이너 등 네트워크 패킷 레벨 부하 분산 고성능, 저지연, 다중 IP 및 포트 지원, AZ 간 자동 분산
Application Gateway 7 (HTTP/HTTPS) 웹 애플리케이션, API 라우팅, WAF 통합 URL 경로 기반 라우팅, SSL 종료, WAF, 세션 기반 부하 분산
Traffic Manager DNS 기반 다중 리전 글로벌 부하 분산 및 장애 조치 DNS 레벨에서 리전별 요청 분산, Failover, 글로벌 사용자 위치 기반 라우팅
Front Door 7 (HTTP/HTTPS) 글로벌 웹 애플리케이션 가속, 보안 강화 전세계 CDN, WAF, SSL Offload, 글로벌 부하 분산 및 최적화

 

7. Load Balancer 적용 구조 및 구성 흐름

  • Load Balancer 생성 → 프런트엔드 IP 구성(공용/사설) → 백엔드 풀 등록(VM, VMSS 등) → 부하 분산 규칙 설정 → 헬스 프로브 생성 → NAT 규칙 필요 시 추가
  • 서비스에 맞게 NSG, UDR, Firewall 연동되어 안전한 네트워크 구성을 보장

- Azure CLI 주요 명령 예시

bash
az network lb create --resource-group myResourceGroup --name myLB --sku Standard --frontend-ip-name myFrontEndPool --backend-pool-name myBackEndPool

az network lb probe create --resource-group myResourceGroup --lb-name myLB --name myHealthProbe --protocol tcp --port 80


az network lb rule create --resource-group myResourceGroup --lb-name myLB --name myLBRule --protocol tcp --frontend-port 80 --backend-port 80 --frontend-ip-name myFrontEndPool --backend-pool-name myBackEndPool --probe-name myHealthProbe


az network lb inbound-nat-rule create --resource-group myResourceGroup --lb-name myLB --name myNATRule --protocol tcp --frontend-port 5022 --backend-port 22 --frontend-ip-name myFrontEndPool

 

8. 영역별 LB 서비스 특징

 (1) 리전널(Regional) 서비스

  • 리전 내에서만 사용 가능하며, 같은 리전 내 여러 가용영역(존, AZ)에서 트래픽을 분산합니다.
  • 보통 규제 준수 또는 데이터 주권 등의 이유로 트래픽이 특정 리전에 머물러야 할 때 사용합니다.
  • TLS 종료 지점을 리전 단위로 제어할 수 있어 특정 리전에서만 암호화 통신을 처리합니다.
  • 리전 내 다중 AZ를 월등히 활용하여, AZ 장애 시에도 서비스 가용성은 유지할 수 있지만 리전 전체 장애에는 취약합니다.

 (2) 존너럴(Zonal) 서비스

  • 특정한 단일 가용영역(AZ) 내에서만 사용됩니다.
  • 주로 아주 세밀한 장애 도메인 관리가 필요하거나, AZ 단위로 로드밸런서를 세팅해야 할 때 사용합니다.
  • AZ 하나가 다운되면 로드밸런서도 영향을 받지만, 빠른 복구와 AZ별 리소스 격리가 가능합니다.

 (3) 글로벌(Global) 서비스

  • 여러 리전(Region)에 걸쳐 전 세계적으로 분산된 로드밸런서를 의미합니다.
  • 클라이언트 요청을 전 세계에 분산된 가장 가까운 리전의 백엔드로 라우팅하며, 장애 발생 시에는 다른 리전으로 트래픽을 자동 전환(페일오버)합니다.
  • 글로벌 anycast IP를 가지며, 전 지리적으로 최저 지연(latency)을 위한 TLS 종료도 전 세계 여러 지점에서 수행합니다.
  • 글로벌 서비스가 필요할 때는 지역별 리전널 로드밸런서들을 연동하여 글로벌 로드밸런서 계층을 구성합니다.
  • 예를 들어, Azure Standard Load Balancer의 글로벌 로드밸런서는 기존 리전 단위 로드밸런서와 연동하여 다중 리전 페일오버 및 부하분산을 지원합니다.
  • 글로벌 서비스 구성 시 참고 사항
    • 글로벌 로드밸런서는 일반적으로 외부(퍼블릭) 트래픽에 적용되며, 내부 로드밸런서는 보통 리전 단위로 작동합니다.
    • 글로벌 로드밸런서는 각 리전 로드밸런서의 상태(health probe)를 정기적으로 체크해 비정상 리전은 차단합니다.
    • 사용자 위치에 따른 지리적 거리 기반(geo-proximity) 라우팅 정책을 적용할 수 있어, 사용자별 가장 가까운 리전으로 트래픽을 유도합니다.
    • 글로벌 로드밸런서로 구성 후 각 리전 로드밸런서의 backend 및 포트 설정을 일치시켜야 연동에 문제가 없습니다.

8. 참고 문서

https://learn.microsoft.com/ko-kr/azure/load-balancer/load-balancer-overview

https://learn.microsoft.com/ko-kr/azure/load-balancer/components

https://learn.microsoft.com/ko-kr/azure/architecture/guide/technology-choices/load-balancing-overview

https://learn.microsoft.com/ko-kr/azure/architecture/guide/technology-choices/load-balancing-overview

 

Azure 관련AKS 설치 구성에 대한 이해: Ingress Controller, CNI, CSI

1. Ingress Controller란?

 (1)이론 및 개념

  • Ingress Controller는 Kubernetes 환경에서 L7(Application Layer) 프로토콜인 HTTP/HTTPS 트래픽을 클러스터 외부에서 내부 서비스로 라우팅하는 핵심 컴포넌트입니다.
  • Kubernetes의 Ingress 리소스는 경로, 호스트, TLS 인증서 등 트래픽 분배 규칙을 선언하는 API 오브젝트이며, 실제 요청 분배와 정책 적용은 Ingress Controller가 담당합니다. 따라서 이 둘은 명확히 개념적으로 분리됩니다.
  • Ingress Controller의 주요 역할은 다음과 같습니다
    - 다중 도메인 및 경로 기반 트래픽 라우팅
    - TLS/SSL 종료, 인증서 관리
    - 인증, HTTP 트래픽 재작성 및 리디렉션
    - 웹 애플리케이션 방화벽(WAF)과 통합하여 보안 강화
  • Kubernetes Ingress와 Ingress Controller 관계
    구성요소 역할
    Ingress 리소스 트래픽 흐름/분배 정책의 선언적 정의를 제공
    Ingress Controller 정책을 실시간으로 해석하여 트래픽을 백엔드 서비스로 라우팅, SSL 종료 수행
  • AKS의 주요 Ingress Controller 유형
    종류 특징
    애플리케이션 라우팅(Add-on) Azure 관리형 NGINX 기반, Azure DNS 자동 등록/갱신, Key Vault 인증서 연동, 쉽게 활성화 가능
    Application Gateway Ingress Controller (AGIC) Azure Application Gateway와 연동, WAF, SSO, SSL 종료, 대규모 엔터프라이즈 기능 포함
    기타(직접 설치 및 관리) Istio, Kong, Emissary, Traefik 등 원하는 솔루션 직접 구성 가능
  • 주요 옵션 및 상세 설명
    옵션명 값 예시 설명
    ingressClassName webapprouting.kubernetes.azure.com, nginx 여러 Ingress Controller 동시 사용 시 구분자
    spec.rules[].host myapp.example.com 트래픽 도메인 이름
    spec.rules[].http.paths[].path /, /api 요청 URI 경로
    spec.rules[].http.paths[].pathType Prefix, Exact, ImplementationSpecific 경로 매칭 방법
    spec.rules[].http.paths[].backend.service.name 서비스 이름 트래픽 전달 대상 내부 서비스
    spec.rules[].http.paths[].backend.service.port.number 서비스 포트 번호  
    spec.tls[].hosts[] [myapp.example.com] TLS가 적용되는 도메인 리스트
    spec.tls[].secretName my-tls-secret TLS 인증서 Secret 이름
    metadata.annotations["kubernetes.io/ingress.class"] nginx, webapprouting.kubernetes.azure.com (레거시) 특정 Ingress Controller 지정용
    metadata.annotations["nginx.ingress.kubernetes.io/rewrite-target"] / 재작성 대상 경로
    metadata.annotations["nginx.ingress.kubernetes.io/ssl-redirect"] "true", "false" HTTP → HTTPS 리디렉션 여부
    metadata.annotations["nginx.ingress.kubernetes.io/backend-protocol"] HTTP, HTTPS, GRPC 백엔드 통신 프로토콜 지정
  • Ingress 리소스 예시 (YAML)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    kubernetes.io/ingress.class: webapprouting.kubernetes.azure.com
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.example.com
    secretName: myapp-tls
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

 

2. CNI(Container Networking Interface)란?

 (1) 개념과 역할

  • 정의
    Container Networking Interface(CNI)는 Kubernetes 등 컨테이너 오케스트레이션 환경에서 Pod 네트워크 인터페이스를 구성하고, IP 할당, 라우팅, 네트워크 정책 설정을 위한 표준 플러그인 인터페이스입니다.
  • 역할
    Pod가 클러스터 내에서 네트워크에 연결될 때 필요한 네트워크 환경을 만들고, IP 주소를 부여하며 네트워크 트래픽이 올바르게 라우팅되도록 제어합니다.

 (2) Azure AKS 네트워킹 모델

  • AKS에서 지원하는 주요 CNI 모델로는 Azure CNI Overlay, Azure CNI Flat (Transparent), 그리고 kubenet이 있습니다.
네트워킹 모델 설명 특징
Azure CNI Overlay Pod마다 논리적 IP를 터널링(VXLAN 등) 통해 할당하는 모델 IP 주소 자원 효율적 사용, 대규모 확장, 네트워크 격리 가능
Azure CNI Flat Pod가 실제 VNet 서브넷 대역 내 실제 IP를 직접 할당받는 모델 온프레미스 연동 용이, 시나리오에 따라 IP 소모 많음
Kubenet 노드만 VNet에 실제 IP 할당, Pod는 별도 논리 네트워크 사용, NAT 적용 클러스터 크기 제한, 구성 복잡, Windows 미지원, 2028년 서비스 종료 예정

 

(3) 주요 CNI 옵션 및 파라미터

옵션명 예시값 설명
networkPlugin azure (Azure CNI), kubenet 네트워킹 플러그인 지정
networkPolicy calico, azure, none Pod 간 네트워크 정책 방식
networkPluginMode overlay (기본, 논리 IP 터널링), transparent (Flat) CNI 동작 모드 선택
podCidr 10.244.0.0/16 Pod IP를 할당할 논리 네트워크 CIDR (Overlay 모드)
vnetSubnetId 리소스 ID 문자열 (예: /subscriptions/.../subnets/mysubnet) 클러스터가 위치하는 실제 Azure VNet 서브넷
serviceCidr 10.0.0.0/16 Kubernetes 서비스 IP 풀 CIDR
dnsServiceIp 10.0.0.10 쿠버네티스 클러스터 DNS 서비스 IP
outboundType loadBalancer, managedNATGateway, userDefinedRouting 아웃바운드 트래픽 처리 방식 지정
nsgId NSG 리소스 ID 네트워크 보안 그룹 연결
routeTableId 사용자 정의 라우팅 테이블 ID 지정 라우팅 정책 충돌 방지 및 관리
privateClusterEnabled true/false 프라이빗 클러스터 활성화 여부

 

(4) 동작 원리

  • Overlay 모델:
    각 Pod에 PodCidr 내 논리적 IP 할당, Pod-Node간 VXLAN 등 터널링으로 패킷 전달. 다른 노드 Pod와 직접 통신 가능하며, 외부 통신 시 노드 IP를 통해 SNAT 수행. IP 주소의 재활용과 정책 격리가 가능해 대형 클러스터에 적합.
  • Flat (Transparent) 모델:
    각 Pod가 VNet 내 실제 IP를 직접 부여받아 네트워크상 완전한 1:1 매핑, 외부 시스템과 호환성이 뛰어남. 대규모 IP 자원의 사전 계획이 필수.
  • Kubenet 모델:
    노드에만 실제 VNet IP 할당, Pod는 별도의 사설 네트워크(IP Pool)에서 IP 할당, 노드가 NAT를 통해 통신 중계. 최대 클러스터 규모 400노드 제한 및 Windows Pod 미지원으로 2028년 서비스를 종료 예정.
특성 Azure CNI Overlay Azure CNI Flat Kubenet
클러스터 최대 노드 수 5,000+ VNet IP 범위에 제한 최대 400 노드
Pod IP 주소 할당 논리 Overlay 네트워크 VNet 내 실제 IP 별도 사설 네트워크, NAT 필수
Pod 간 통신 직접 통신 (터널링) 직접 통신 NAT 및 경로 테이블 의존
IP 주소 자원 효율 높음 중간 낮음
Windows Node 지원 예 예 아니오
고급 네트워크 정책 적용 Azure 네트워크 정책, Calico, Cilium 지원 거의 동일 Calico만 지원
Kubernetes Virtual Nodes 지원 가능 가능 미지원
관리 복잡도 중간 낮음 높음

 

 (5) 권장 사항 및 마이그레이션 가이드

  • 새로운 AKS 클러스터는 Azure CNI Overlay를 기본 권장하는 네트워크 모델로 채택
  • 기존 Kubenet 사용자 또는 IP 제한 문제 발생 시 Azure CNI Overlay로 점진적인 마이그레이션 검토
  • 온프레미스 또는 기존 VNet과의 긴밀한 네트워크 연동/보안 정책 필요 시 Azure CNI Flat 모델 활용 가능
  • Pod 수 및 클러스터 규모가 크고 네트워크 격리/모니터링이 중요한 경우 Overlay 모델이 최적

3. CSI(Container Storage Interface)란?

 (1) 개념 및 목적

  • CSI(Container Storage Interface)는 Kubernetes를 포함한 컨테이너 오케스트레이션 시스템에서 외부 스토리지 백엔드(블록, 파일, 오브젝트 스토리지 등)와 통신하기 위한 표준 인터페이스입니다.
  • 기존의 Kubernetes in-tree 스토리지 드라이버는 코어 Kubernetes 코드에 내장되어 업데이트와 확장이 어려운 반면, CSI는 플러그인 방식으로 설계되어 유지보수와 업그레이드가 유연합니다.
  • CSI를 사용함으로써, 다양한 스토리지 제공업체가 Kubernetes 생태계와 호환되는 드라이버를 독립적으로 개발, 배포할 수 있습니다.

 (2) 주요 기능

  • 동적 볼륨 프로비저닝 및 해제
  • 볼륨 마운트 및 언마운트
  • 볼륨 크기 조정 (Expansion)
  • 스냅샷 생성 및 삭제 지원 (CSI 2.0 이상)
  • 다중 접근 모드 및 여러 Pod 동시 마운트 지원

 (3) 구조 및 동작 메커니즘

  • CSI 드라이버는 크게 다음 네 가지 컴포넌트로 구성됩니다.
구성 요소 역할 및 설명
Controller Plugin PVC 생성시 백엔드 클라우드 스토리지에 실제 볼륨을 생성/삭제/관리
Node Plugin 노드에 볼륨을 attach/detach하고 Pod에 마운트/언마운트를 수행
Provisioner PVC 리소스를 감시해 동적으로 PV 생성 요청을 처리
Attacher Pod에 의한 볼륨 사용 시 마운트 과정을 책임, 다중 노드 연결 지원
  • Kubernetes 내에서는 PVC 생성 시 Provisioner가 이 이벤트를 포착하여 Controller Plugin에게 실제 스토리지 할당을 요청합니다. 이후 노드 단의 Node Plugin이 볼륨을 컨테이너에 마운트합니다.

 

 (4) Azure AKS에서 제공하는 주요 CSI 드라이버

드라이버 설명 및 특징 프로토콜 및 특성
Azure Disk CSI 고성능 블록 스토리지, 단일 Pod에 ReadWriteOnce(RWO) 모드 지원 Azure Managed Disk, SSD 및 HDD 지원
Azure Files CSI SMB/NFS 기반 공유 파일 시스템, 여러 Pod가 동시에 RWX 가능 SMB 3.0/NFS 지원, Premium/Standard 등 다양한 SKU
Azure Blob CSI 객체 기반 Blob Storage를 파일 시스템처럼 제공 비구조적 대용량 데이터 저장용, BlobFuse/NFS 지원

 

 (5) 주요 옵션 및 상세 설명 (Azure Files CSI 예시 중심)

옵션명 값 예시 설명
provisioner file.csi.azure.com Azure Files CSI 프로비저너 식별자
skuName Standard_LRS / Premium_LRS / Premium_ZRS 스토리지 성능 및 유형 선택 (표준, 프리미엄, 영역 중복 등)
protocol smb / nfs 파일 접근 프로토콜 설정 (Windows, Linux 용)
location Azure 리전 명 (예: eastus) 스토리지 리전 지정, 일관성/규제 준수를 위한 중요 설정
allowVolumeExpansion true / false PVC 용량 동적 확장 허용 여부
reclaimPolicy Delete / Retain PVC 삭제시 대응: 실제 볼륨 삭제 또는 보존
mountOptions dir_mode=0777, file_mode=0777 등 마운트 시 사용되는 POSIX 파일, 디렉터리 권한 설정
maxShares "10" 동시 접근 허용 Pod 수 (RWX에서 적용, 스토리지 SKU별 제한 가능)

 

 (6) StorageClass YAML

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-premium
provisioner: file.csi.azure.com
parameters:
  skuName: Premium_LRS
  protocol: smb
allowVolumeExpansion: true
reclaimPolicy: Delete
mountOptions:
  - dir_mode=0777
  - file_mode=0777

 

 (7) PersistentVolumeClaim YAML

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefiles-pvc
spec:
  storageClassName: azurefile-premium
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi

 

 (8) Azure Disk CSI 주요 사항

  • 블록 스토리지로, 고성능 DB나 워크로드에 적합하며 RWO (ReadWriteOnce) 지원
  • Managed Disks의 Premium SSD, Standard SSD, Standard HDD 모두 지원
  • 스냅샷 및 볼륨 확장 지원 (무중단 크기 변경 가능)
  • 노드당 디스크 최대 수용량 및 특정 VM SKU 제약 주의

 (9) 장애 및 관리 고려사항

  • PVC 상태가 Pending인 경우 StorageClass 파라미터 오류, 스토리지 할당 실패 가능성 확인
  • 볼륨 마운트 실패 시 K8S 이벤트 로그, Pod 로그, Storage Account 상태, 네트워크 연결(Private Endpoint 등) 순으로 점검
  • 스토리지 성능 이슈 발생 시 SKU 변경, 접속 프로토콜(NFS/SMB) 변경, 네트워크 대역폭 모니터링 및 조정 필요
  • 키 관리: KeyVault 또는 Azure AD Managed Identity 통합으로 보안 강화
  • 스냅샷과 백업 정책을 수립해 데이터 보호 및 복구 체계 갖출 것

4. 관련 문서

https://learn.microsoft.com/ko-kr/azure/aks/learn/quick-kubernetes-deploy-terraform?pivots=development-environment-azure-cli

https://learn.microsoft.com/ko-kr/azure/aks/concepts-network-cni-overview

https://learn.microsoft.com/ko-kr/azure/aks/concepts-network-ingress

https://learn.microsoft.com/ko-kr/azure/aks/concepts-storage

AKS Overlay Network 구성에 대한 이해: POD IP 할당과 특징

1. 오버레이 네트워크란?

  • 오버레이 네트워크는 물리적 네트워크 위에 논리적 가상 네트워크 계층을 추가로 만들고, 그 내부에서 Pod들에게 네트워크 주소(IP)를 할당하는 방식입니다.
  • 클러스터의 각 노드는 Azure Virtual Network (VNet)의 서브넷에 배포되며, 노드 자체는 실제 VNet IP를 갖습니다.
  • Pod들은 노드가 속한 VNet과는 논리적으로 분리된 별도의 프라이빗 CIDR(논리 IP Pool)에서 IP를 할당받습니다.
  • Pod 간 통신은 이 오버레이 네트워크 내부에서 가상 터널링(VXLAN, Geneve 등)을 통해 직접 연결됩니다.
  • 외부로 나가는 트래픽은 노드 IP로 NAT(Source NAT)되어 전송됩니다.
  • 외부(온프레미스, 인터넷)에서 Pod에 직접 접근은 불가능하며, 반드시 Service LoadBalancer 또는 Ingress Controller를 통해 서비스합니다.

2. AKS 오버레이 네트워크 동작 원리 및 구조

  • 클러스터 노드는 VNet 서브넷 내에서 CIDR /24(예: 10.0.0.0/24) 주소 공간을 할당받습니다.
  • 각 노드는 자신에게 할당된 논리 서브넷에서 Pod에게 IP(pool) 할당 (Pod CIDR, 예: 10.244.0.0/16 내 /24)
  • Pod간 트래픽은 TCP/UDP 패킷을 VXLAN 터널링으로 캡슐화하여 노드 간 전달
  • 기존 VNet 라우팅 테이블엔 Pod CIDR이 별도의 라우팅 도메인을 형성하여 독립적 라우팅 제공
  • 노드 IP를 통한 NAT로 클러스터 외부 통신 처리, Pod의 논리 IP는 외부에 노출되지 않음
  • Pod가 외부 리소스에 접근할 떄는 노드 IP로 라우팅되고, 반대로 외부에서 Pod로 직접 접근 불가

3. 주요 특징 및 장점

특징 설명
논리적 IP 주소 할당 물리적 VNet과 다른 프라이빗 CIDR 대역에서 논리 IP를 할당해 IP 주소 효율적 활용
Pod 간 직접 통신 VXLAN 기반 가상 터널로 노드 간 Pod간 직접 통신 가능
네트워크 격리 및 보안 강화 격리된 논리 IP 영역, 네트워크 정책 적용 가능
클러스터 IP 주소 확장성 제공 Pod IP 주소 공간 확장 용이, 대규모 클러스터 지원
외부 IP 고갈 문제 해소 VNet 내 IP 고갈 문제 없이 오버레이 IP Pool로 범위 확장
NAT 통한 외부네트워크 접근 지원 노드 IP를 통한 NAT로 아웃바운드 리소스 접근
외부에서 Pod 직접 접근 차단 보안성 강화, 외부 리소스는 클러스터 내 Service 또는 LB 통한 접근 필수

 

4. 운영 시 고려 사항 및 제한

  • Overlay 네트워크 설정 시, Pod IP 풀(CIDR)과 VNet 서브넷 CIDR의 충돌 방지 필요
  • NAT 포트 부족으로 인한 아웃바운드 병목 가능성 대비, 관리형 NAT Gateway 활용 권장
  • VXLAN 터널링 장애, 네트워크 정책(NSG), 사용자 정의 라우팅(UDR) 적용 시 경로 오류에 유의
  • 클러스터 스케일링 시 신규 노드에 대한 서브넷 자동 배분 관리 필요
  • 로깅 모니터링 툴을 통해 Overlay 터널 상태 및 트래픽 이상 조기 감지 체계 구현
  • IPv6 또는 Dual stack 환경에서는 지원 제한 사항 및 구성 제한 확인 필요

5. AKS Overlay 네트워크 주요 설정 옵션

옵션명 예시 설명
networkPlugin azure (Azure CNI) Azure CNI 플러그인 지정
networkPluginMode overlay Overlay 네트워크 모드 활성화
podCidr 10.244.0.0/16 Pod에 할당할 논리 IP 대역 사이즈
vnetSubnetId 전체 서브넷 리소스 ID (URI) 클러스터가 속한 Azure VNet 서브넷 리소스 ID
serviceCidr 10.0.0.0/16 Kubernetes 서비스 IP 풀 CIDR
dnsServiceIp 10.0.0.10 Kubernetes 내부 DNS 서비스 IP
outboundType loadBalancer, managedNATGateway 아웃바운드 NAT 트래픽 처리 방식 지정
nsgId NSG(네트워크 보안 그룹) 리소스 ID Azure 네트워크 보안 규칙 연동
routeTableId 라우팅 테이블 ID 사용자 정의 라우팅 테이블 관리
privateClusterEnabled true/false 제어 플레인 프라이빗 클러스터 활성화 여부

 

- AKS Overlay 네트워크 구성 예시 (Azure CLI)

bash
az aks create \
  --resource-group myResourceGroup \
  --name myOverlayCluster \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 10.244.0.0/16 \
  --service-cidr 10.0.0.0/16 \
  --dns-service-ip 10.0.0.10 \
  --outbound-type managedNATGateway \
  --vnet-subnet-id /subscriptions/xxx/resourceGroups/yyy/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/mySubnet \
  --nsg-resource-id /subscriptions/xxx/resourceGroups/yyy/providers/Microsoft.Network/networkSecurityGroups/myNSG \
  --route-table-id /subscriptions/xxx/resourceGroups/yyy/providers/Microsoft.Network/routeTables/myUDR \
  --enable-private-cluster false

 

6. 관련 링크

AKS PV/PVC 사용법 및 CSI 구성에 따른 Azure Files 특성 이해

1. PersistentVolume (PV) 와 PersistentVolumeClaim (PVC) 개념

  • PersistentVolume (PV)
    Kubernetes 클러스터 내에서 가능한 스토리지(디스크, 파일공유 등)를 추상화한 리소스입니다.
    사용자(개발자, Pod)가 직접 PV를 부르지 않고, PVC를 통해 필요한 스토리지 용량과 속성만 요청하면 클러스터가 처리합니다.
  • PersistentVolumeClaim (PVC)
    Pod가 요구하는 스토리지 용량, 접근 모드(ReadWriteOnce, ReadWriteMany 등) 등을 명시하는 저장소 청구서 역할입니다.
    PVC가 클러스터 내 적합한 PV와 바인딩되어 해당 스토리지를 Pod에 연결합니다.

 

2. Azure Files CSI 드라이버와 특징

  • Azure Files는 SMB와 NFS 프로토콜 지원, 여러 Pod에서 동시에 읽고쓸 수 있는 ReadWriteMany(RWX) 권한을 가진 공유 파일 스토리지입니다.
  • Azure Files CSI 드라이버는 Kubernetes에서 CSI 표준을 통해 Azure Files를 동적으로 프로비저닝 및 관리할 수 있습니다.
  • 지원되는 StorageClass 옵션으로 Premium_LRS, Standard_LRS, Zone Redundant Storage 등 다양한 성능과 내구성 옵션 선택 가능.
  • Azure Key Vault 연동을 통한 인증서 및 접근 키 관리, 보안 강화가 가능하며, 동적 프로비저닝, PVC 확장, 스냅샷 기능 등 최신 CSI 기능을 완벽 지원합니다.
  • Private 구성 시 Azure Files를 프라이빗 엔드포인트(Private Endpoint)를 통해 네트워크 격리하여 AKS 클러스터와 안전하게 연결할 수 있으며, 이를 통해 퍼블릭 인터넷 노출 없이 보안이 강화

 

3. 주요 StorageClass 및 PVC 옵션 상세

옵션명 값 예시 설명
provisioner file.csi.azure.com Azure Files CSI 드라이버 식별자
skuName Premium_LRS / Standard_LRS / Premium_ZRS 스토리지 계층 및 성능 옵션
protocol smb / nfs 사용할 프로토콜(SMB:윈도우 및 Linux, NFS:Linux 전용)
allowVolumeExpansion true / false Dynamic Volume Expansion 지원 여부
reclaimPolicy Delete / Retain PVC Delete시 볼륨의 삭제 또는 보존 정책
mountOptions dir_mode=0777, file_mode=0777, actimeo=30 마운트 시 적용할 파일 권한 및 캐시 관련 옵션
maxShares "10" RWX 모드에서 동시 접속 가능한 Pod 최대 수
storageClassName Custom 명명 PVC와 연결된 StorageClass 이름 지정
accessModes ReadWriteMany, ReadWriteOnce, ReadOnlyMany 접속 모드 - RWX, RWO, ROX 중 선택

 

- StorageClass 예시 YAML

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-premium
provisioner: file.csi.azure.com
parameters:
  skuName: Premium_LRS
  protocol: smb
allowVolumeExpansion: true
reclaimPolicy: Delete
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - actimeo=30

 

- PersistentVolumeClaim 예시 YAML

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefiles-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-premium
  resources:
    requests:
      storage: 100Gi

 

- Pod에서 PVC 연결하는 예시

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: app-container
    image: nginx
    volumeMounts:
    - name: azurefile
      mountPath: /mnt/azure
  volumes:
  - name: azurefile
    persistentVolumeClaim:
      claimName: azurefiles-pvc

 

4. 운영 시 주의사항 및 장애 대응

5. 관련 링크

Dockerfile 기본 개념 및 레이어 구성 원리

. 개념

  • 도커 이미지(Docker Image)를 자동으로 만드는 설계도(스크립트)
  • Dockerfile은 텍스트 파일로, 어떤 베이스 이미지를 쓰고, 어떤 패키지/파일/설정을 넣을지, 마지막에 어떻게 실행할지를 단계별로 적어놓은 문서입니다.
  • Docker는 이 파일을 읽어 위에서 아래로 순차 실행하면서 이미지를 빌드합니다.

2. 기본 명령

  • 실제 파일 변화를 만드는 명령: RUN, COPY, ADD → 읽기 전용 FS 레이어가 생성
  • 메타데이터/구성 변경 중심: ENV, WORKDIR, USER, EXPOSE, VOLUME, LABEL, ENTRYPOINT, CMD, ARG 등
  • 파일 내용을 늘리지는 않지만 이미지 구성(메타데이터) 는 바뀌고, 빌드 캐시 키에도 영향을 줍니다.
  • FROM 은 새 빌드 단계(stage) 를 시작합니다(멀티 스테이지에서 중요). 따라서 어떤 단계에서든 그 단계가 바뀌면 그 뒤의 모든 단계 캐시가 무효화되고 다시 빌드됩니다(계단식 무효화).

3. 빌드 캐쉬가 동작하는 방식

  • Docker/BuildKit은 “명령 + 입력(컨텍스트, 이전 레이어 해시 등)” 으로 캐시 키를 만들고, 같으면 재실행 없이 이전 레이어를 재사용합니다.
  • 파일 복사(COPY/ADD) 는 복사되는 파일의 내용 해시가 바뀌면 캐시 무효.
  • ARG/ENV 값 변경 도 이후 단계 캐시를 깨뜨립니다.
  • 네트워크 의존 RUN(예: apt-get) 결과도 캐싱되지만, 베이스 이미지 업데이트 등은 --pull(베이스 최신화) 또는 --no-cache(모든 캐시 무시) 같은 옵션으로 제어합니다.

4.  Best Practice

    • 변동이 적은 것 → 위로, 자주 바뀌는 것 → 아래로
      - 의존성 설치(자주 안 바뀜) 레이어를 먼저 만들고, 소스 코드 COPY 등 자주 바뀌는 단계는 뒤로 배치 → 캐시 적중률↑
    • RUN 묶기 vs 가독성
      -       불필요한 레이어를 줄이려고 RUN 을 과도하게 한 줄로 합치기보다, 의미 단위로 적절히 묶되 레이어 수를 관리하세요.- - 패키지 매니저는 한 레이어에서 갱신/설치를 끝내고 캐시 파일 삭제까지 마무리
    • .dockerignore 적극 사용
      - node_modules, .git, 빌드 산출물 등 캐시를 자주 깨뜨리는 불필요 파일을 빌드 컨텍스트에서 제외.
    • ADD 대신 COPY
      - URL 자동 다운로드/압축 해제 등 암묵적 동작이 있는 ADD 대신, 예측 가능한 COPY 를 기본으로.
    • 멀티 스테이지 빌드 로 최종 이미지 슬림화
      - 빌드 도구·헤더 등 개발용 레이어는 중간 단계에 남기고, 최종 스테이지는 실행 파일만 가져갑니다.
    • BuildKit 고급 마운트
      - 캐시가 이미지에 포함되지 않도록
    • 버전 고정 & 재현성
      - 패키지 버전을 고정(pinning)해 캐시 안정성을 높이고 “어제와 오늘 빌드가 다른” 상황을 줄입니다.
    • VOLUME 주의
      - VOLUME /data 를 선언하면 해당 경로의 이후 변경은 컨테이너 볼륨에 매핑됩니다. VOLUME 선언 이전에 넣은 파일은 런타임에 보이지 않을 수 있으니 순서를 신중히.
    • 베이스 이미지 최신화
      - 태그가 같은데 내용이 바뀐 경우를 대비해 정기적으로 --pull 로 베이스를 갱신하거나, digest(sha256:...) 고정을 검토하세요.
    • 레이어/캐시 청소
      - 개발 환경 용량이 불어나면 docker system df, docker system prune, (BuildKit) docker builder prune 로 캐시/중간 레이어를 정리.

5. 레이어 구성 원리

  • Dockerfile의 각 RUN, COPY, ADD 명령은 새로운 레이어(layer) 를 만듭니다.
  • 레이어는 캐시로 재사용 가능하고, 불변이라서 한 번 만들어지면 바뀌지 않습니다.
  • 레이어를 많이 나누게 되면 얻는 이점/단점
    - 캐시 효율 증대
    - 문제 원인 추적이 쉬움
    - 이미지 레이어 수가 늘어나면 저장/전송할 때 관리해야 할 블롭(blob)이 많아져서 오버헤드가 조금 생김.
    - 불필요한 파일 누적 위험
  • 레이어를 적게 묶어서 만드는 이점/단점
    - 이미지 크기 최적화
    - 전송/저장 효율 증대 : 레이어 수가 적어서 속도 저장 효율 올라감
    - 캐시 효율이 떨어짐
    - 가독성이 낮음

6. Dockerfile 주요 명령어 개념 및 예시

  • `FROM`: 베이스 이미지 지정 (ex: `FROM ubuntu:20.04`)
  • `RUN`: 이미지 빌드 시 실행할 커맨드 (ex: `RUN apt update && apt install -y nginx`)
  • `COPY`, `ADD`: 로컬 파일을 이미지 안으로 복사
  • `ENV`: 환경 변수 설정
  • `EXPOSE`: 컨테이너에서 서비스할 포트 명시
  • `CMD` 또는 `ENTRYPOINT`: 컨테이너 시작 시 실행할 명령어
  • RUN 명령어에서 여러 명령 병합 방법
    - 여러 개 명령을 한 줄에서 실행할 때는 `&&`로 체이닝하여 이전 명령 성공 시 다음 명령 실행
       예) `RUN apt update && apt install -y nginx`
    - `\` (백슬래시) 사용해 여러 줄로 나눠 가독성 개선 가능
  • 컨테이너 실행 흐름
    1. Dockerfile 작성 (설치 및 설정 명령어 포함)
    2. `docker build` 명령으로 이미지 생성 (Dockerfile대로 순차적 실행)
    3. `docker run` 명령으로 이미지를 실행해 컨테이너 상태 시작
    4. 컨테이너 안에서 앱 또는 서비스 동작

7. 결론

  • Dockerfile은 컨테이너 이미지 만드는 레시피
  • `RUN`은 이미지 만드는 동안 실행할 명령어 입력 (명령어 묶는 기법은 `&&`가 일반적)
  • 빌드하면 `RUN` 명령어 순서대로 실행되며 이미지가 만들어짐
  • 이미지를 기반으로 컨테이너를 실행해 서비스 구동하는 구조입니다.

8. 참고 문서

Support VM OS SKU 및 Migration 방법

1. Azure Migrate 이란?

  • Azure Migrate는 Azure로의 마이그레이션을 결정, 계획 및 실행하는 데 도움이 되는 서비스입니다. Azure Migrate를 사용하면 최상의 마이그레이션 방법을 찾고, Azure 준비 상태 및 Azure에서 워크로드를 호스트하는 비용을 평가하고, 가동 중지 시간 및 위험을 최소화하여 마이그레이션을 수행할 수 있습니다. Azure Migrate는 Azure Data Box를 사용하여 서버, 데이터베이스, 웹앱, 가상 데스크톱 및 대규모 오프라인 마이그레이션을 지원합니다.

2. VMware To Azure Migration 방식

  • Agentless (권장/기본, VMware 전용)

    • vCenter + VMware 스냅샷/CBT로 증분 복제. 게스트 OS에 설치 없음. 대규모(최대 300~500대 동시)까지 스케일아웃 어플라이언스로 확장. 일부 제한(예: VMDK 이름에 비-ASCII 문자가 있으면 미지원)

  • Agent (대안)

    • 각 서버에 Mobility Service를 설치해 블록 단위로 거의 연속 복제. 온프레미스 VMware는 물론 물리 서버·타 클라우드(AWS/GCP) 이전에도 사용. 포트/구성요소(복제 어플라이언스/프로세스 서버/443·9443 등) 요건이 있음.

3. 제약 사항

설정 Agentless Agent
Azure 권한 Azure Migrate 프로젝트를 만들고, Azure Migrate 어플라이언스를 배포할 때 만든 Microsoft Entra 앱을 등록하기 위한 권한이 필요합니다. Azure 구독에 대한 기여자 권한이 필요합니다.
복제 스케일 아웃 어플라이언스를 사용하여 여러 vCenter Server(하나의 어플라이언스에서 검색됨)에서 최대 500개의 VM을 동시에 복제할 수 있습니다. 포털에서 복제할 머신을 한 번에 10대까지 선택할 수 있습니다. 더 많은 머신을 복제하려면 10대 일괄 처리를 추가합니다. 복제 어플라이언스의 크기를 스케일링하면 복제 용량을 늘릴 수 있습니다.
어플라이언스 배포 Azure Migrate 어플라이언스는 온-프레미스에 배포됩니다. Azure Migrate복제 어플라이언스는 온-프레미스에 배포됩니다.
Site Recovery 호환성 호환 가능합니다. Site Recovery를 사용하여 머신 복제를 설정한 경우 마이그레이션 및 현대화 도구로 복제할 수 없습니다.
대상 디스크 관리 디스크 관리 디스크
디스크 제한 OS 디스크: 2TB
데이터 디스크: 32TB
최대 디스크: 60		 OS 디스크: 2TB
데이터 디스크: 32TB
최대 디스크: 63
통과 디스크 지원되지 않음 지원됨
UEFI 부팅 지원 지원
연결 공용 인터넷
개인 피어링을 사용하는 ExpressRoute
Microsoft 피어링을 사용하는 ExpressRoute
사이트 간 VPN		 공용 인터넷
개인 피어링을 사용하는 ExpressRoute
Microsoft 피어링을 사용하는 ExpressRoute
사이트 간 VPN

 

4. 배포 단계

과업 세부 정보 Agentless Agent
Azure Migrate 어플라이언스 배포 VMware VM에서 실행되는 경량 어플라이언스입니다.

해당 어플라이언스는 머신을 검색 및 평가하고 에이전트 없는 마이그레이션을 사용하여 머신을 마이그레이션하는 데 사용됩니다.		 필수.
평가를 위해 어플라이언스를 이미 설정한 경우 에이전트 없는 마이그레이션에 동일한 어플라이언스를 사용할 수 있습니다.		 필수 아님.
평가를 위해 어플라이언스를 설정한 경우 해당 어플라이언스를 그대로 두거나 평가가 완료된 경우 제거할 수 있습니다.
서버 평가 도구 사용 Azure Migrate: 서버 평가 도구를 사용하여 머신을 평가합니다. 평가는 선택 사항입니다. 평가는 선택 사항입니다.
마이그레이션 도구 사용 Azure Migrate 프로젝트에 마이그레이션 및 현대화 도구를 추가합니다. 필수 필수
마이그레이션을 위해 VMware 준비 VMware 서버 및 VM에 대한 설정을 구성합니다. 필수 필수
VM에 Mobility Service 설치 Mobility Service는 복제하려는 각 VM에서 실행됩니다. 필요하지 않음 필수
복제 어플라이언스 배포 복제 어플라이언스는 에이전트 기반 마이그레이션에 사용되며 VM에서 실행되는 Mobility Service와 마이그레이션 및 현대화 도구 간에 연결됩니다. 필요하지 않음 필수
VM 복제. VM 복제를 사용하도록 설정. 복제 설정을 구성하고 복제할 VM을 선택 필수 필수
테스트 마이그레이션 실행 테스트 마이그레이션을 실행하여 모든 것이 예상대로 작동하는지 확인합니다. 필수 필수
전체 마이그레이션 실행 VM 마이그레이션. 필수 필수

 

5. Agentless 추가 특징

  • vCenter에 연결해 게스트 OS에 에이전트 설치 없이 VMware VM을 Azure로 복제/마이그레이션하는 방식

  • 전용 복제 어플라이언스(어플라이언스/게이트웨이) 를 배포 → vCenter와 스토리지에서 스냅샷 기반 증분 복제 수집 → Azure로 전송 → 테스트 마이그레이션 후 컷오버

  • 검색이 완료되면 검색된 서버를 그룹으로 수집하고 그룹별로 평가를 실행

6. Agentless 동작 흐름

  1. 발견(Discovery): vCenter 등록 → 인벤토리/성능 수집

  2. 평가(Assessment): 목표 Azure VM Size/SKU·디스크·비용 산정

  3. 복제(Replication): 초기 전체 → 이후 증분 복제(CBT)

  4. 테스트 마이그레이션: 다운타임 없이 검증 환경 부팅

  5. 마이그레이션(컷오버): 짧은 정지 후 전환, 최종 동기화

7. Agent 방식 제약 사항 상세 내용

 (1) 지원 운영체제 (Windows + Linux)

  Azure Migrate의 agent 기반(Migration and Modernization 툴) 마이그레이션 방식은 다양한 OS를 지원합니다.

  • Windows: Azure Migrate는 UEFI 기반 머신을 Azure Generation 2 VM으로 마이그레이션하며, BIOS 기반 머신은 Generation 1 VM으로 마이그레이션됩니다 TECHCOMMUNITY.MICROSOFT.COM+6Microsoft Learn+6Reddit+6Reddit+9Microsoft Learn+9Microsoft Learn+9.
  • 지원되는 OS 목록:
    • Windows Server: 2025, 2022, 2019, 2016, 2012, 2012 R2 (단, EOS 버전은 안정성 보장 안 됨)
    • Windows 10 / 11 (Pro, Enterprise)
    • Linux 분포:
      • SUSE: Enterprise Server 15 SP1–SP6, 12 SP4
      • Ubuntu Server: 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS
      • RHEL: 6.x, 7.x (7.0–7.8), 8.0–8.1, 9.x
      • CentOS Stream
      • Oracle Linux: 6, 7.7, 7.7‑CI, 8, 9
    • 모든 경우에 대해 agentless/agent 기반 VMware 및 agentless Hyper‑V 방식 모두 지원 

주의: Windows Server 2003, 2008, 2012, 2012 R2와 같이 EOS(End of Support)된 운영체제는 Azure Migrate가 일관되고 안정적인 결과를 보장하지 않으며, 마이그레이션 전 업그레이드를 강력히 권고합니다 


 (2) 물리 서버 (또는 OS-불특정 머신) 마이그레이션에서의 OS 제약

  agent 기반 방식은 물리 서버 마이그레이션에도 활용되는데, 이 경우 다음과 같은 OS 및 스토리지 관련 제약사항이 존재합니다:

  • 파일 시스템 및 파티션:
    • Windows: NTFS만 지원
    • Linux: ext4, xfs, btrfs 지원
      — ZFS, UFS, ReiserFS, DazukoFS 등은 지원하지 않거나 특별 마운트 절차 필요 
    • 예: ReiserFS는 명시적으로 “지원되지 않음”으로 언급됨
  • 디스크/볼륨 제약:
    • UEFI Secure Boot: 지원되지 않음
    • OS 디스크 크기: Gen 1 VM 최대 2 TB / Gen 2 VM 최대 4 TB. 데이터 디스크는 최대 32 TB까지 지원 
    • 디스크 수: 최대 63개까지
    • 암호화된 디스크/볼륨: 마이그레이션 대상에서 제외됨
    • 공유 디스크 클러스터: 지원되지 않음
    • NFS, iSCSI, 페어링 NIC, IPv6, PV 드라이버 등: 여러 항목에서 제약 눈에 띔
      • 예: iSCSI 대상 머신은 agentless 마이그레이션에선 지원되지 않음.
      • 멀티패스 IO는 Windows 서버에서 특정 조건 하에서만 지원 
  • VM 설정 제한:
    • BitLocker 활성화된 경우 복제 체크 실패 → BitLocker 비활성화 필요
    • VM 이름 조건: 1~63자, 영문·숫자·하이픈만 허용

8. WAAgent (WALinuxAgent)란?

  • 정식 이름: Microsoft Azure Linux Agent (WALinuxAgent, 줄여서 waagent)
  • 역할: Linux VM이 Azure 플랫폼과 통신할 수 있도록 해주는 핵심 에이전트, Azure 위에서 Linux VM이 정상적으로 동작하고 관리될 수 있도록 해주는 에이전트
  • 기능:
    1. VM 초기화: Azure Fabric에서 VM을 부팅할 때, 호스트에서 전달된 구성(Hostname, SSH 키, 사용자 계정 등)을 OS에 적용
    2. 네트워킹: DHCP 클라이언트 역할을 하여 VM 네트워크 설정 관리
    3. 스토리지 관리: Azure에서 제공하는 리소스 디스크를 자동으로 마운트하고 스왑 공간 구성
    4. 확장(Extensions) 관리: Azure Backup, Monitoring, Security 확장 에이전트 등을 설치하고 관리
    5. 상태 보고: VM의 상태/헬스 정보를 Azure Control Plane에 전달
    6. 마이그레이션 시 필수 역할: 복제/스냅샷/에이전트 기반 마이그레이션에서 VM이 Azure와 통신하기 위해 필요
    7. Azure Migrate (agent 기반)일 경우 Linux VM을 온프레미스 → Azure로 옮길 때, 마이그레이션 후 VM이 Azure 환경에 맞게 네트워킹/스토리지/헬스 리포팅 가능하도록 구성하며, 마이그레이션 전 해당 Linux VM에 waagent가 설치되어 있어야, 복제 후 부팅이 정상적으로 됨
    8. Azure VM 운영 VM Insights, Log Analytics, Security Extensions 같은 관리 도구들이 모두 waagent를 통해 배포·실행되며, 없으면 VM이 Azure Portal에서 “Provisioning failed” 상태가 되거나, IP/디스크 설정이 안 잡히는 문제 발생 가능.

9. 참고 문서

Azure Native 보안과 네트워크 보안 서비스 이해

1.  Azure Native 보안이란?

  • Azure에서 기본적으로 제공하는 보안 관련 기능 및 서비스를 의미
  • NSG → Firewall → WAF/DDoS → Private Link/Bastion 같은 네트워크 계층 보안과, Defender for Cloud, Sentinel 같은 운영/모니터링 서비스가 유기적으로 맞물려 클라우드에서 기본적으로 제공되는 End-to-End 보안 프레임워크

2. Azure 보안의 핵심 사상

  • 클라우드 내장 보안(Platform-level Security)
    Azure 인프라 전반에 걸쳐 MS가 기본 제공하는 보안 기능 (네트워크, 데이터, ID, 애플리케이션 보안 포함).
  • Zero Trust 기반
    “아무도 신뢰하지 않는다(never trust, always verify)” 원칙으로, 네트워크 경계뿐 아니라 사용자·디바이스·애플리케이션 모두 지속적으로 검증.
  • 통합 관리
    Azure Security Center(현재는 Microsoft Defender for Cloud) 같은 서비스로 보안 posture를 모니터링하고 권고사항 제공.
  • 자동화 & 위협 인텔리전스
    Microsoft의 글로벌 위협 인텔리전스 기반으로 보안 로그/이벤트를 자동 분석해 대응.

3. 네트워크 서비스 종류와 특징

(1) 네트워크 보안 그룹 (NSG, Network Security Group)

  • VM, Subnet 수준에서 인바운드/아웃바운드 트래픽을 제어하는 방화벽 룰.
  • L3/L4 기반 (IP, 포트, 프로토콜).
  • 기본적인 "보안 그룹"으로 AWS의 SG와 유사.

(2) Azure Firewall

  • Fully managed 방화벽 서비스 (stateful firewall).
  • L3~L7 트래픽 필터링 가능.
  • FQDN 필터링, Application rule, Threat Intelligence 기반 차단 지원.
  • 고가용성 및 확장 자동 제공.
  • 아웃바운드·인바운드 트래픽 필터링

(3) Web Application Firewall (WAF)

  • Application Gateway WAF: L7 로드밸런서 + WAF 기능 (OWASP Top 10 공격 방어).
  • Azure Front Door WAF: 글로벌 CDN + WAF (전 세계 트래픽 보호).
  • SQL Injection, XSS 등 웹 공격 방어.

(4) DDoS Protection

  • 기본 제공(Free) + 표준(Advanced) 버전.
  • L3/L4 네트워크 공격 자동 완화.
  • Standard 버전은 Adaptive Tuning, 공격 분석 리포트, SLA 제공.
  • 대규모 분산 서비스 거부 공격(DDOS) 방어

(5) Private Link & Service Endpoints

  • Azure 서비스에 대한 비공개 연결 제공.
  • 인터넷 노출 없이 VNet 내부에서만 서비스 접근 가능.

(6) Azure Bastion

  • Public IP 없이도 포털 기반으로 안전하게 VM에 RDP/SSH 접속 가능.
  • Jump server 없이도 관리 가능 → 원격 접속 보안 강화.

(7) Azure DDoS + Threat Intelligence + Sentinel

  • Azure Sentinel: 클라우드 기반 SIEM/SOAR → 로그 수집, 위협 탐지, 자동화 대응.
  • Threat Intelligence 통합: 글로벌 위협 데이터로 정책 강화.

(8) Azure Sentinel

  • SIEM(Security Information and Event Management) + SOAR(Security Orchestration, Automation and Response) 기능 제공
  • 온·오프프레미스, 멀티클라우드, SaaS 애플리케이션의 보안 이벤트를 수집·분석
  • 머신러닝 기반 위협 감지, 자동 대응

(9) Microsoft Defender for Identity

  • 온프레미스 AD 환경과 Azure AD 간 계정·인증 위협 탐지
  • 의심스러운 로그인 패턴, 권한 상승 시도 감지

(10) Microsoft Defender for Endpoint

  • 엔드포인트 보안 → 악성코드, 랜섬웨어, 취약점 보호
  • 침입 방지, 위협 사냥(Threat Hunting) 가능

(11) Azure Key Vault

  • 비밀 값(Secrets), 암호화 키(Keys), 인증서(Certificates) 안전 저장
  • CMK(Customer Managed Key) 사용 가능

(12) Microsoft Entra ID (Azure AD) 보안 기능

  • 조건부 액세스(Conditional Access)
  • MFA(Multi-Factor Authentication)
  • ID 보호(ID Protection)

(13) Azure Policy + Blueprints

  • 조직 전체 리소스에 보안 규칙 강제 적용
    • 예: 특정 지역에만 리소스 생성 허용, 암호화 필수화

(14) Azure DDoS + Threat Intelligence + Sentinel

  • Azure Sentinel: 클라우드 기반 SIEM/SOAR → 로그 수집, 위협 탐지, 자동화 대응.
  • Threat Intelligence 통합: 글로벌 위협 데이터로 정책 강화.

4. 참고링크

Azure Monitoring 활용시 LogData 효율적 관리에 대해

1. Azure Monitor 및 기본 개념 정리

(1) Azure Monitor
• Azure 전반의 리소스 상태, 성능, 보안 이벤트를 수집·분석하는 플랫폼 서비스
• 메트릭과 로그 두 가지 데이터 형식 지원

(2) Log Analytics
• Azure Monitor 로그 데이터를 저장하고 Kusto Query Language(KQL)로 분석하는 서비스
• 데이터 수집, 저장, 쿼리에 따라 비용 부과

(3) Diagnostic Settings
• 어떤 리소스에서 어떤 종류의 로그를 어디로 보낼지 설정하는 기능
• 예: Log Analytics, Storage Account, Event Hub

(4) Retention Policy (보존 정책)
• 로그 데이터를 저장하는 기간을 지정
• 저장기간이 길수록 비용 증가, 짧게 하면 비용 절감

(5) Sampling (샘플링)
• Application Insights에서 모든 요청·트랜잭션 로그를 수집하지 않고 일부만 수집하는 기능
• 트래픽이 많은 서비스에서 비용 절감에 효과적

(6) Basic Logs vs Analytic Logs
• Basic Logs: 장기간 저장, 검색 빈도가 낮은 로그 (저렴)
• Analytic Logs: 쿼리·분석이 많은 로그 (비쌈)

(7) Archive Tier
• 장기간 사용하지 않는 로그를 저비용 저장소에 보관하는 방식
• 검색 시 복원 시간이 필요

2. 최적화 개요

(1) 수집 단계에서 절감
• Diagnostic Settings에서 불필요한 로그 카테고리 제외
• Application Insights에서 Sampling 설정 적용 (예: 100% → 20%)

(2) 저장 단계에서 절감
• Retention Policy로 저장기간 단축 (예: 90일 → 30일)
• 자주 쓰지 않는 데이터는 Archive Tier로 이동

(3) 분석 단계에서 절감
• 쿼리 실행 횟수 최소화
• 동일한 쿼리를 반복 실행 시 쿼리 결과 캐싱 또는 Export 기능 활용

(4) 로그 형식 구분
• 자주 분석하는 데이터: Analytic Logs
• 거의 조회하지 않는 데이터: Basic Logs로 설정

(5) 외부 저장소 연계
• 장기 보관 필요 시 Log Analytics가 아닌 Azure Storage에 보관 → 저렴한 저장 비용 + 규제 준수 가능

 

3. 세부 내용 설명

 (1) 수집할 로그 데이터량 최적화

  • 필요한 데이터만 수집하세요. 수집 대상 및 조건을 신중히 설정해 불필요한 로그를 줄여야 합니다.
    → 예: 진단 설정(Diagnostic setting), 데이터 수집 규칙(Data Collection Rule, DCR)을 통해 특정 이벤트/로그 수준만 수집하도록 제한
  • 테이블별 Basic Logs 플랜 활용
    디버깅 또는 드문 쿼리에만 필요한 테이블은 Basic Logs 플랜으로 설정해 데이터 수집 비용을 낮출 수 있습니다. 단, 일부 기능 제한이 있습니다. 

 (2) 가격 모델 및 티어 활용

  • **Commitment 티어 (예약량 기반 요금제)**로 전환 시, 데이터 수집량이 많을 때 단가를 낮출 수 있습니다. 기본은 페이-애즈-유-고(Pay-as-you-go)
  • 데이터 보관 기간 최적화
    기본 보존 기간 이후 장기 보존이 필요하지 않다면 데이터를 자동으로 삭제해 저장 공간과 비용을 줄이세요 

 (3) 모니터링 및 알림 기반 관리

  • Log Analytics Workspace Insights를 통해 로그 수집량 트렌드를 시각화하고, 어떤 솔루션이나 테이블이 과다 수집의 주범인지를 파악할 수 있습니다 
  • Alert (알림) 설정으로 이상 전송량 대응
    예시: 하루 50GB 이상 로그가 수집되면 알림을 받도록 설정하여 비용 예측력을 높이고, 필요 시 즉시 대응할 수 있습니다 
  • Azure Advisor 비용 최적화 권장사항 적용
    Advisor가 자동으로 제안하는 ‘Basic Logs 사용’, ‘프리미엄 요금제 전환’ 등 권고사항을 알림으로 설정해 놓으면, 실시간으로 비용 절감 기회를 놓치지 않을 수 있습니다 

 (4) 데이터 분석 기반 원인 탐지

  • Usage 테이블
    워크스페이스별, 솔루션별, 테이블별 수집된 청구 대상(billable) 데이터 양을 분석할 수 있습니다. 예시 쿼리도 제공되어 있습니다 
  • _IsBillable, _BilledSize 컬럼 활용
    실제 과금이 발생하는 개별 로그 항목 및 사이즈를 상세 분석해, 어떤 이벤트가 비용을 유발하는지 구체적으로 확인할 수 있습니다 
  • 자원, 리소스 그룹, 컴퓨터 단위 분석
    어느 리소스나 VM이 로그를 많이 생성하고 있는지 단위별 분석해 수집 전략을 세울 수 있어요 

 (5) 쿼리 최적화 및 성능 관리

  • 쿼리 최적화는 직접적인 수집 사이징보다는 간접적인 비용 절감에 도움이 됩니다.효율적인 쿼리는 CPU, 멀티스레드 활용, 메모리 등 자원 소비를 줄여 전체 처리 비용을 절감시키고, 쿼리 지연이나 스로틀링도 방지합니다 

4. 요약

전략 영역 수행 지침 요약
수집량 최적화 필요한 데이터만 수집, Basic Logs 플랜 적용(빠른 분석 필요시 Analytic)
가격 모델 활용 및 티어 조정 Commitment 이용, 불필요 보존기간 줄임(보유 정책 조정)
모니터링 및 알림 설정 Workspace 인사이트, 데이터 사용량 알림
원인 분석 기반 개선 Usage 테이블, 상세 쿼리 분석(저/고빈도 조회 로그 분석), 리소스별 검토
쿼리 최적화 효율적인 KQL 작성으로 처리 비용 절감, 샘플링 기법으로 일부 로그 수집
외부 저장소 Export 규제 준수 및 비용 절감을 위해 외부 저장 방법도 추가 고려 사항

5. 참고 문서

Azure Storage 암호화

. Azure Storage 암호화 개요

  • Azure는 저장 데이터(At Rest)와 전송 데이터(In Transit) 모두에 대해 암호화를 제공합니다. 이 암호화는 서버측에서 자동으로 적용되거나, 필요에 따라 사용자가 클라이언트측에서 직접 수행할 수도 있습니다. 또한 ES-256 같은 강력한 암호화 알고리즘과 Key Vault를 통한 중앙 집중형 키 관리 기능을 제공해 기업이 보안과 규정 준수를 동시에 달성할 수 있습니다.

2. 미사용 데이터 암호화

  • 미사용 데이터 암호화는 디스크, Blob, File, Table, SQL Database, Cosmos DB 등 다양한 스토리지 서비스에 적용됩니다.
    - 서버측 암호화(SSE): Azure가 저장 전에 자동으로 암호화하고, 읽을 때 자동 복호화
    - 클라이언트측 암호화: 업로드 전에 사용자가 직접 암호화
  • 서비스별 주요 특징

3. 전송 중 데이터 암호화

  • TLS(전송 계층 보안): 클라이언트와 서버 간 및 모든 클라우드-클라이언트 통신 보호. PFS 지원.
    ex> Azure Storage와 REST API를 사용할 때 HTTPS만 허용하도록 설정하면 중간자 공격을 방지할 수 있습니다.
  • PFS(Perfect Forward Secrecy): 세션 키 보호
  • MACsec: 데이터센터 간 네트워크 링크 암호화
  • SMB 3.0: 파일 공유 전송 암호화 (Windows Server 2012+). 
  • VPN Gateway(IPsec/IKE, 사이트 간/지점 연결 암호화) / SSH(비대칭키) / RDP(TLS): 안전한 원격 접속 및 데이터 전송
  • 데이터 링크 계층: MACsec(IEEE 802.1AE)로 데이터센터 간 링크 암호화, 기본 적용.
  • Azure Storage 접근 시 HTTPS 필수 설정 및 SAS 토큰 사용시 HTTPS 강제 기능

4. 키 관리 전략

  • Azure Key Vault는 암호화 키, 비밀, 인증서를 안전하게 저장하고 접근을 제어합니다.
    - 서비스 관리 키(SMK): Azure에서 자동 관리
    - 고객 관리 키(CMK): BYOK(Bring Your Own Key) 지원
    - HYOK(Host Your Own Key): 고객의 하드웨어에서 완전 관리
  • Key Vault를 활용하면 키를 주기적으로 순환하고, HSM(Hardware Security Module)에서 안전하게 생성 및 저장할 수 있습니다.

5. 보안 모범 사례

  • 보안 전송 강제 적용
    - 스토리지 계정에서 ‘Secure Transfer Required’를 켜고 HTTPS만 허용하세요.
  • BYOK 적용 시 주기적 키 순환
    - 데이터 보호와 규정 준수를 위해 키를 주기적으로 변경해야 합니다.
  • 모니터링 및 감사 활성화
    -     Azure Monitor와 함께 Key Vault 진입 시도를 로깅하면 보안 위협을 신속히 탐지할 수 있습니다.

6. 미사용 데이터 암호화 (At Rest Encryption)

  • 대상: 디스크, Blob, Table Storage, SQL DB, Cosmos DB, Data Lake 등 저장된 모든 데이터.
  • 기술: 기본적으로 AES-256 사용.
  • 암호화 모델
    1. 서비스 관리 키 (Microsoft 관리) – 편리하지만 고객 제어 낮음.
    2. 고객 관리 키 (BYOK) – Key Vault로 직접 관리.
    3. 고객 제어 하드웨어 키 (HYOK) – 자체 하드웨어에서 관리, 제한적 지원.
    • 클라이언트 쪽 암호화: Azure 외부에서 암호화 후 업로드. 키는 고객이 완전 제어.
    • 서버 쪽 암호화: Azure가 데이터 저장 시 자동 암호화·해독.
    • 서비스별 특징
      - Disk Encryption: 관리 디스크·스냅샷 모두 암호화.
      - Storage Service Encryption(SSE): Blob·File 저장 전 자동 암호화.
      - Azure SQL:
        * TDE(투명 데이터 암호화) – 서버 쪽, 기본 활성화.
        * Always Encrypted – 클라이언트 쪽, 민감 데이터 보호.
        * CLE(셀·열 수준 암호화) – 더 세밀한 단위 암호화.
      - Cosmos DB: 기본 암호화 + 선택적 CMK 이중 암호화.
      - Data Lake: 기본 자동 암호화, 키 직접 관리 가능.

7. 키 관리 (Azure Key Vault)

  • 역할: 암호화 키 보관·관리·액세스 제어.
  • 특징
    - HSM 기반, Microsoft는 키 열람 불가.
    - 고객이 키 생성·가져오기·순환 가능.
    - Microsoft Entra 계정 기반 권한 부여.
    - 장점: 하드웨어·패치·운영 부담 제거, 보안성·관리 편의성 향상.

8. 참고 문서

PV/PVC with Azure File 구성시 필요한 Network 설정

. Azure File + PV/PVC 구성 개요

  • Kubernetes 환경에서 **Persistent Volume(PV)**과 **Persistent Volume Claim(PVC)**를 Azure File 스토리지로 구성하려면,
    단순히 YAML로 PV/PVC를 정의하는 것뿐만 아니라 네트워크 설정이 반드시 뒷받침되어야 합니다.
    Azure File은 SMB(서버 메시지 블록) 프로토콜을 사용하므로, 네트워크 라우팅, DNS, 방화벽(NSG) 규칙 등이 제대로 설정되어 있어야 정상적으로 마운트됩니다.
  • PV (Persistent Volume)
    클러스터 관리자가 프로비저닝한 스토리지 리소스로, 스토리지의 실제 물리적/클라우드 리소스에 대한 추상화 레이어.
  • PVC (Persistent Volume Claim)
    개발자/애플리케이션이 요청하는 스토리지 요구사항. PV에 매칭되어 바인딩됨.
  • Azure File
    Azure Storage 계정에서 제공하는 SMB 3.0 기반 네트워크 파일 공유 서비스. Kubernetes에서는 csi.azure.com 드라이버를 통해 접근.

2. 네트워크 설정의 핵심 포인트

(1) 접근 경로

  • Azure File은 퍼블릭 엔드포인트 또는 **프라이빗 엔드포인트(Private Endpoint)**로 접근 가능.
  • 보안 강화를 위해 AKS 클러스터와 같은 VNet 내부에 Private Endpoint 구성 권장.

(2) DNS 해석

  • Private Endpoint 사용 시, Azure Storage의 FQDN({storageaccount}.file.core.windows.net)이 Private IP로 해석되도록 Azure Private DNS Zone 설정 필요.
  • Private DNS Zone 링크: privatelink.file.core.windows.net
  • AKS VNet과 DNS Zone을 연결(VNet Link)해야 함.

(3) 네트워크 라우팅

  • AKS 노드 → Azure File Storage까지의 경로 확인.
  • VNet이 피어링된 경우, PEERING 설정에서 "Allow forwarded traffic" 및 "Allow gateway transit" 활성화 필요.
  • On-prem과 연결 시 ExpressRoute 또는 VPN Gateway 사용 가능.

(4) 방화벽(NSG) 규칙

  • SMB 포트(445/TCP) 허용.
  • Azure File에 접근하는 서브넷에서 Outbound 445/TCP가 막혀 있으면 마운트 불가.
  • Private Endpoint 사용 시에도 해당 포트 허용 필요.

(5) 스토리지 방화벽

  • Storage Account의 "방화벽 및 가상 네트워크" 설정에서 AKS 서브넷 허용.
  • Private Endpoint 사용 시 Public Access 차단 가능.

(6) 인증

  • Azure File PV/PVC는 Storage Account Key 또는 Azure AD 기반 SMB 인증 지원.
  • Storage Account Key를 Secret로 저장 후 PV/PVC YAML에 참조.
  • Azure AD 인증 시, AKS 노드가 Azure File 리소스에 접근 가능한 Managed Identity 권한 필요.

3. PV/PVC + Azure File 네트워크 구성 절차 (Private Endpoint 기준)

  1. Storage Account 생성
    • Performance: Standard (HDD) 또는 Premium (SSD)
    • Account kind: StorageV2
    • File shares 기능 활성화.
  2. Private Endpoint 생성
    • Target sub-resource: file
    • 연결할 VNet/Subnet 지정.
    • Private DNS Zone(privatelink.file.core.windows.net)에 자동 등록되도록 설정.
  3. Private DNS Zone 구성
    • privatelink.file.core.windows.net Zone 생성.
    • Private Endpoint의 Private IP가 A 레코드로 등록되어야 함.
    • AKS VNet과 DNS Zone을 링크.
  4. NSG 설정
    • AKS 노드 서브넷에 Outbound 445/TCP 허용.
    • 필요 시 Inbound SMB 규칙도 설정(특정 상황에서만).
  5. 스토리지 방화벽 설정
    • Public access 차단.
    • Private Endpoint 서브넷만 허용.
  6. 인증 구성
    • Storage Account Key를 Kubernetes Secret에 저장.
    • 또는 Managed Identity에 Azure File Data SMB Share Contributor 권한 부여.

4. 주요 용어 정리

PV (Persistent Volume) 클러스터에서 사용할 수 있는 스토리지 리소스의 추상화 객체
PVC (Persistent Volume Claim) 사용자가 요청하는 스토리지 요구사항, PV에 바인딩
Azure File SMB 기반 클라우드 파일 공유 서비스
Private Endpoint VNet 내부에서 Azure 서비스에 Private IP로 연결
Private DNS Zone Private Endpoint 연결 시 서비스 FQDN을 Private IP로 해석하는 DNS Zone
NSG (Network Security Group) Azure 네트워크의 방화벽 역할
SMB (Server Message Block) 파일 공유를 위한 네트워크 프로토콜
Storage Account Key Storage Account 인증을 위한 키
Managed Identity Azure 리소스에 부여되는 인증 아이덴티티
Azure CSI Driver Kubernetes에서 Azure 스토리지를 사용하기 위한 Container Storage Interface 드라이버

 

5. 관련 문서

Azure Virtual Network 암호화

1. 의미

  • Azure Virtual Networks의 기능으로 가상 네트워크 암호화를 사용하면 DTLS 터널을 만들어 Azure Virtual Machines 간에 트래픽을 원활하게 암호화 및 암호 해독할 수 있음.
  • 가상 네트워크 암호화를 사용하면 동일한 가상 네트워크 내에서 Virtual Machines와 Virtual Machine Scale Sets 간의 트래픽을 암호화할 수 있습니다. 가상 네트워크 암호화는 지역적으로 피어링된 가상 네트워크와 전역적으로 피어링된 가상 네트워크 간의 트래픽을 암호화

2. 주요 제약사항

  • 암호화는 가상 네트워크의 가상 머신 간의 트래픽에만 적용됩니다. 트래픽은 개인 IP 주소에서 개인 IP 주소로 암호화
  • 가상 네트워크에서 암호화를 사용하도록 설정한 후에는 기존 가상 머신의 시작/중지가 필요
  • 내부 부하 분산 장치의 경우, 부하 분산 장치 뒤에 있는 모든 가상 머신은 지원되는 가상 머신 SKU에 있어야 합니다
  • AllowUnencrypted는 일반 공급에서 유일하게 지원되는 적용입니다. DropUnencrypted 적용은 향후 지원될 예정
  • 암호화가 사용하도록 설정된 가상 네트워크는 Azure DNS Private Resolver, Application Gateway 및 Azure Firewall을 지원하지 않습니다
  • Azure ExpressRoute 게이트웨이가 있는 가상 네트워크에서는 가상 네트워크 암호화를 사용하도록 설정해서는 안 됩니다.
  • Azure Private Link 서비스로 구성된 가상 네트워크는 Virtual Network 암호화를 지원하지 않으므로 이러한 Virtual Network에서는 Virtual Network 암호화를 사용하도록 설정해서는 안 됨.
  • 부하 분산 장치에 대한 연결 실패를 방지하기 위해 내부 부하 분산 장치의 백 엔드 풀에는 네트워크 인터페이스 보조 IPv4 구성이 포함되어서는 안 됨.
  • Azure 기밀 컴퓨팅 VM SKU가 있는 가상 네트워크에서는 Virtual Network 암호화를 사용하도록 설정하면 안 됩니다.
  • 지역 피어링, 글로벌 피어링을 통한 가상 머신 간 트래픽에서 지원됩니다.
  • Azure CNI(일반 또는 오버레이 모드), Kubenet 또는 BYOCNI를 사용하는 AKS에서 지원됩니다. 노드 및 Pod 트래픽이 암호화됩니다.
  • Azure CNI 동적 Pod IP 할당(podSubnetId 지정)을 사용하여 AKS에서 부분적으로 지원됩니다. 노드 트래픽은 암호화되지만 Pod 트래픽은 암호화되지 않습니다.
  • AKS 관리 컨트롤 플레인에 대한 트래픽이 가상 네트워크에서 송신되므로 가상 네트워크 암호화 범위에 포함되지 않습니다. 그러나 이 트래픽은 항상 TLS를 통해 암호화됩니다.

3. 추가 암호화 설계

  • 외부 인터넷 -> WAF 구간 : mTLS 및 SSL/TLS 1.2버전 이상 통신 암호화 적용
  • WAF -> F/W 구간 : SSL/TLS 1.2버전 이상 통신 암호화 적용
  • MSA Service <-> 타 시스템 호출 구간 : SSL/TLS 1.2버전 이상 통신 암호화 적용
  • Application : Always Encrypted + Dynamic Data Masking 동시 사용
  • DBMS - SQL Management Instance : TDE(Transparent data encryption)을 이용한 스토리지 암호화
  • Azure Files : CMK 기반의 SSE 지원 설정 혹은 Key Vault + MI 권한 설정 관리를 통한 암호화 
  • Azure Blob Storage : Azure Key Vault에 저장된 CMK를 사용하여 암호화

4. 네트워크 암호화

  • Azure VPN Gateway는 IPsec/IKE 기반 암호화 터널을 사용하며, 내부적으로 AES256/SHA2/PFS 같은 알고리즘을 조합한다
  • ExpressRoute → 기본은 암호화 없음. 필요 시
    - MACsec(L2) : ExpressRoute Direct서 포트 단 암호화(BYOK, Key Vault 보관).
    - IPsec over ER : VPN over ExpressRoute(끝단 간 L3 암호화) 조합 가능.
  • Virtual Network Encryption (VNE) → 동일 VNet/피어링 간 VM↔VM 트래픽을 DTLS로 암호화. 특정 VM SKU/Accelerated Networking 요구, 일부 네트워크 리소스와 비호환.
  • Azure Files: 기본적으로 SMB 3.x + 암호화 필수(암호화 미지원 클라이언트 연결 거부)

5. 참고 문서

AKS의 이슈상황 원인과 대응방안 + Pod Lifecycle

1. POD FAILED 현상

  • OOMKilled / Memory cgroup 초과
  • Evicted(DiskPressure/EphemeralStorage/MemoryPressure)
  • DeadlineExceeded (Job activeDeadlineSeconds 초과)
  • Exit code ≠ 0 (프로세스 조기 종료, entrypoint 오타, 권한 문제)

2. POD FAILED 해결 방안

  • OOMKilled: 🧭 resources.requests/limits 합리화, 메모리 leak 점검, VPA/HPA 도입, GC/힙 옵션 조정
  • Evicted: 노드 DiskPressure해소(이미지/컨테이너/워킹디렉 정리), ephemeral-storage requests/limits 및 emptyDir.sizeLimit 설정, 노드풀 디스크/사이즈 증설
  • Job 실패: backoffLimit, activeDeadlineSeconds, 재시도 간격 재설계. 반복 실패면 InitContainer로 프리체크, 종속 서비스 준비(health/endpoint) 확인
  • Exit code ≠ 0 : 권한·엔트리포인트: securityContext, command/args 검증, 실행 비사용자(shell) 문제 해결

3. BackOff 계열(CrashLoopBackOff, ImagePullBackOff, ErrImagePull 등등..)

  1. CrashLoopBackOff
    a. 원인 : 어플리케이션 예외/의존 미준비/잘못된 CMD, liveness probe 오탐 등
    b. 대응방법 : 
      - Startup, Readness, Liveness Probe 분리
      - InitContainer로 의존 리소스(DB 등) 준비 확인
      - 애플리케이션 종료 신호 처리(SIGTERM)와 graceful shutdown 구성
  2. ImagePullBackOff / ErrImagePull
    a. 원인 : 레지스트리 인증, 네트워크 혹은 이미지 태그 오타
    b. 대응방법 : 
      - A    CR 사용 시 AKS-ACR 연결(Managed Identity attach-acr), 또는 imagePullSecrets 설정
      - 프록시/NSG/DNS 확인, 사설 레지스트리면 프라이빗 엔드포인트/방화벽 예외
      - 태그 고정(immutable), imagePullPolicy: IfNotPresent 적절히 사용
  3. CreateContainerConfigError / CreateContainerError
    a.  pod pending과 동일한 대응을 통해 예방 가능

4. (추가) Nodegroup Scale-in시 고려할 Pod Lifecycle 설정

  • Scale-in 시 연결 드레이닝, 데이터 무결성 보장이 중요합니다.
  • 핵심 체크리스트는 아래와 같습니다.
    - Pod Disruption Budget(PDB): 과도한 동시 축출 방지Copy
    -     preStop hook + terminationGracePeriodSecondsCopy
      ->     preStop에서 LB 등록 헤제/세션 종료/큐 flush
      -> SIGTERM 후 readiness가 자동 false되지만, 어플리케이션 자체 graceful 필요
  • readinessProbe 엄격화: 종료 직전 트래픽 유입 차단 속도를 높이고 정상 동작 중에만 Ready 유지
  • PDB + HPA 조합: 축출 가능한 파드 수와 자동 확장 균형 맞추기
  • safe-to-evict 어노테이션: 스케일인 시 지우면 안되는 파드에 다음과 같이 safe-to-evict 어노테이션 추가
  • 빈약한 스테이트풀 방지: StatefulSet은 PodManagementPolicy=Parallel와 PodAntiAffinity로 분산, 스토리지는 RWO/PV 바인딩 존 일치.

5. 참고 문서

AKS 장애 대응 - Node Not Ready, POD Pending 등 이슈 원인 파악 및 해결방안

1. 개요

  • AKS는 작업자 노드의 상태를 지속적으로 모니터링하고 비정상상태가 되면 노드를 자동 복구하며 두 가지 이중화된 방법으로 상태를 체크합니다..
  • status 업데이트: kubelet이 주기적으로 Node의 리소스 상태를 API 서버에 업데이트
  • Lease 객체: kubelet이 10초마다 Lease 객체를 갱

2. 자동 복구 방법

  • AKS가 5분 이상 비정상으로 유지되는 노드를 식별하는 경우 다음 작업을 수행
    - AKS가 노드를 다시 부팅
    - 부팅 후 노드가 비정상이라면 AKS는 노드를 이미지로 다시 설치
    - 이미지 설치 후 노드가 비정상이고 Linux 노드인 경우 AKS가 노드를 다시 배포
    - 위 과정은 최대 3회 다시 시도

3. 자동 복구가 수행되지 않는 경우

  • 네트워크 구성 오류로 노드 상태가 들어오지 않을 때
  • 노드가 처음에 정상 노드로 등록하지 못한 경우
  • 노드에 다음 taint중 하나가 있는 경우 : node.cloudprovider.kubernetes.io/shutdownToBeDeletedByClusterAutoscaler
  • 노드가 업그레이드 중인 경우

4. Node Not Ready 원인 및 대응 방법

  • 상황 :
    - kubectl get nodes 에 NotReady 표기
    - kubectl describe node 의 Conditions에서 Ready=False, NetworkUnavailable=True, MemoryPressure=True, DiskPressure=True, PIDPressure=True 등 확인
  • 원인 및 대응 방법
A. kubelet/컨테이너 런타임 장애
1.    ssh를 통해 해당 node에 접속
2.    아래 명령어들을 이용해 kubelet, 컨테이너 런타임 장애여부 확인
journalctl -u kubelet -n 200 --no-pager
journalctl -u containerd -n 200 --no-pager
sudo systemctl status kubelet containerd
3.    컨테이너 런타임 프로세스 재시작
sudo systemctl restart containerd kubelet

B. 리소스 부족
1.    kubectl describe node의 Pressure=True 확인 Memory/PID Pressure: 과소요 파드 제한/리소스쿼터 도입, 문제 파드 축출. 필요 시 노드풀 스케일아웃.
2.    DiskPressure: 이미지/컨테이너 정리
sudo crictl images
sudo crictl rmi --prune
sudo du -sh /var/lib/containerd/* /var/lib/kubelet/* 2>/dev/null

C. 네트워크/CNI 문제
1.    NetworkUnavailable=True, kubelet이 API 서버로 Heartbeat 실패
2.    아래 명령어(CoreDNS, konnectivity 예시)를 이용해 장애 여부 확인
kubectl -n kube-system get pods -l k8s-app=kube-dns
kubectl -n kube-system get pods | grep konnectivity
3.    CNI/시스템 파드 재시작, 노드 재부팅, 노드 교체, UDR/NSG 변경 여부 점검

D. 시간 동기화/인증 토큰 문제
1.    노드 시간이 크게 틀어진 경우 API 인증 실패 가능성이 존재, node에 접속 후
2.    아래 명령어를 이용해 시간 확인
timedatectl status
3.    NTP 동기화 복구, kubelet 재시작

E. 노드가 cordon/drain 상태로 방치
1.    NotReady,SchedulingDisabled 또는 kubectl get nodes에 SchedulingDisabled
2.    아래 명령어를 통해 node를 uncordon으로 설정 혹은 필요시 drain
 kubectl uncordon <NODE>
 kubectl drain <NODE> --ignore-daemonsets --delete-emptydir-data

 

5. POD Pending 원인 및 대응 방법

  • 상황 : 
    - 스케줄러가 아직 파드를 어떤 노드에도 배치하지 못한 상태. (이미 스케줄된 뒤 컨테이너 풀/이미지 문제는 보통 ContainerCreating/ImagePullBackOff로 보입니다.)
A. 리소스 부족
1.    아래 명령어로 리소스 부족 확인
kubectl describe pod
2.    진단 결과에 따른 대응
o   스케일 아웃: 노드 풀 증가
o   리소스 요청 조정: requests/limits 현실화, 우선순위 검토
o   pod 수 제한(kubelet의 maxPods)에 걸리면 노드 타임/설정 변경

B. 스케줄링 제약 불일치
1.    nodeSelector/nodeAffinity/topologySpreadConstraints/podAntiAffinity가 현실과 안 맞음, 또는 taint/toleration 미스매치
2.    아래 명령어로 진단
kubectl describe pod <POD> | sed -n '/Events:/,$p'
3.    진단 결과에 따른 대응
o   label/taint 정합성 수정
o   제약 완화 또는 노드풀에 해당 특성 라벨 부여/증설

C. 스토리지 대기(PVC Pending)
1.    파드가 Pending, PVC가 Bound되지 않음
2.    아래 명령어로 진단
kubectl get pvc
kubectl describe pvc <PVC>
3.    진단 결과에 따른 대응
o   StorageClass 오타
o   존 불일치
o   용량, I/O 제한
o   디스크/SCI 문제
o   리소스 쿼터 부족

 

6. Pod Pending 해결 방안 풀이

  • AKS 클러스터 내에서 Pod가 Pending 상태가 되는 것은 일반적으로 스케줄러가 해당 Pod를 적절한 노드에 할당하지 못하는 것을 의미합니다. 특히 노드가 준비되지 않은 상태일 때, Pod Pending이 자주 발생하는데, 이는 클러스터 운영에 심각한 영향을 줄 수 있으므로 원인 분석과 신속한 대응이 필요합니다.
  • 첫째, 노드 자체가 정상적으로 준비되지 않아서 스케줄러가 Pod를 할당하지 못하는 경우입니다. 이때 노드가 `NotReady` 상태이거나, 클러스터 노드 그룹에서 노드 생성 지연, OS 또는 에이전트 문제 등으로 초기화가 완료되지 않은 상황일 수 있습니다. 이에 대한 대응으로는 해당 노드의 상태를 `kubectl get nodes` 등으로 확인하고, AKS 노드 풀 상태를 모니터링하며 필요하면 노드를 재시작하거나, 문제가 지속 시 노드 풀을 재구성하거나 교체하는 조치가 필요합니다.
  • 둘째, 리소스 부족 문제입니다. 클러스터 내 가용 노드가 있지만, CPU, 메모리, GPU 등 자원 부족으로 인해 스케줄링이 불가능하여 Pod가 Pending 상태에 머무는 경우입니다. 특히 제한된 리소스를 가진 노드 풀에서 고리소스 요구 Pod가 다수 배포될 때 흔하게 발생합니다. 대응 방법으로는 리소스 요청(Request)과 제한(Limit)을 적절히 설계하고, 필요 시 노드 풀에 노드를 추가하거나 HPA(Horizontal Pod Autoscaler), Cluster Autoscaler를 활용해 클러스터 확장 정책을 적용하는 것이 효과적입니다.
  • 셋째, 스케줄링 제약 조건(Scheduling Constraints)으로 인해 노드에 Pod가 할당되지 못하는 경우입니다. 예를 들어, Pod에 설정된 노드 셀렉터(NodeSelector), 노드 친화성(Node Affinity), taint 및 toleration 정책과 같은 배치 제한 조건들이 노드와 맞지 않으면 스케줄러가 매칭을 못해 Pending 상태가 됩니다. 이 경우 Pod 및 노드의 라벨(Label), taint, toleration 설정을 점검하고 불필요하거나 잘못된 제약 조건을 제거하거나 수정해야 합니다.
  • 넷째, 네트워크 또는 스토리지 등의 외부 종속성 문제로 인해 Pod가 정상적으로 스케줄링되지 못하는 경우입니다. 예를 들어, Azure Disk, Azure Files와 같이 외부 볼륨 프로비저닝이 지연되거나 실패하면 Pod가 Pending 상태에 머무르게 됩니다. 이런 상황에선 PersistentVolume, PersistentVolumeClaim 상태를 점검하고, 적절한 스토리지 클래스와 프로비저닝 정책을 확인하는 것이 필요합니다.
  • 마지막으로, 클러스터 구성 또는 제어 평면(Control Plane) 문제로 노드 상태 갱신이 늦거나, API 서버와 노드 에이전트 간 통신 장애가 발생하는 경우도 있습니다. 이 경우에는 클러스터 상태 대시보드 확인, Azure 모니터링 로그 및 이벤트 분석, 필요한 경우 Azure 지원팀과 협력하여 문제 원인을 규명하고 해결해야 합니다.
  • 따라서, AKS에서 노드 준비 실패로 인한 Pod Pending 문제에 대응하기 위해서는 먼저 노드 상태 및 클러스터 리소스 현황을 정확히 파악하고, 스케줄링 제약 조건을 점검하며, 외부 종속성과 클러스터 상태까지 종합적으로 분석하는 체계적인 접근이 필요합니다. 이러한 과정을 통해 적절한 노드 재구성, 클러스터 확장, 배치 제약 완화, 외부 리소스 문제 해결 조치를 시행하여 안정적인 AKS 운영을 유지할 수 있습니다.

7. 참고 문서

AKS GPU Sharing에 관한 고찰

1. 개요

  • Azure에서 GPU를 활용하기 위해서는 기본적으로 VM 1대에 GPU 1개를 매칭하여 사용하며, 하나의 GPU를 여러대의 VM이 사용할 수 없다.
  • 다만, 컨테이너 환경에서는 GPU 자원을 쉐어링 할 수 있는데, AKS에서 GPU 사용 요건과 사용 방식에 대해 알아 보자.

2. AKS에서 GPU 활용 조건

  • GPU 지원 VM 노드풀 사용
  • NVIDIA Device Plugin for Kubernetes
    - 쿠버네티스에서 GPU 리소스를 스케줄링하려면 반드시 nvidia-device-plugin DaemonSet을 배포해야 함.
    - 이 플러그인이 GPU 리소스를 nvidia.com/gpu라는 형태로 노출시켜, Pod이 요청할 수 있도록 해줌
  • NVIDIA 드라이버 및 CUDA 라이브러리
    - GPU 노드풀에는 NVIDIA 드라이버가 설치되어야 하며, CUDA/cuDNN 버전은 컨테이너 이미지 내부와 호환되어야 함.
    - 즉, 컨테이너 내부 CUDA 버전과 VM에 설치된 드라이버 버전이 호환되어야 여러 컨테이너에서 GPU 활용이 가능
    - AKS는 NVIDIA GPU Operator 또는 VM 확장 기능을 통해 자동 설치 가능.
  • QoS 설정은 반드시 Guaranteed(requests == limits).

3. 하드웨어적 Sharing 기법 - Multi Instance GPU(MIG)

  • NVIDIA Multi-Instance GPU(MIG)는 최신 NVIDIA GPU(A100, H100 등)에서 제공하는 하드웨어 기반 가상화 기술입니다. MIG는 단일 물리 GPU를 최대 7개의 완전 격리된 독립 GPU 인스턴스로 분할할 수 있습니다. 각 인스턴스는 자체 메모리, 컴퓨팅 코어, 캐시를 포함하며, 서로 간의 작업 간섭 없이 독립적으로 동작합니다. 이를 통해 여러 워크로드를 동시에 운영하면서도 예측 가능한 서비스 품질(QoS)을 보장할 수 있습니다. 또한, GPU 인스턴스 단위의 성능 모니터링과 관리가 가능해 GPU 자원의 효율적 배분과 안정성 확보에 탁월합니다.
  • MIG는 Ampere 이상(A100, A30)과 Hopper 이상(H100/H200 등)에서 지원됩니다. 드라이버 요구사항은 대략 A100/A30 = CUDA 11 / R450+, H100 = CUDA 12 / R525+ 
  • MIG는 한 개의 물리 GPU를 여러 개의 독립 인스턴스(MIG slice) 로 하드웨어 분할하는 기술임 따라서 같은 노드 안의 단일 GPU를 여러 Pod/컨테이너가 나눠 쓰게 해주지만, 여러 노드가 한 GPU를 공유하는 건 아님. NVIDIA 공식 가이드도 “단일 물리 GPU에서 여러 GPU 인스턴스가 병렬 실행”이라고 명시
  • MIG 자원을 쿠버네티스에 노출하는 방식은 두 가지 전략 중 하나를 선택
    - single: 모든 MIG 인스턴스를 nvidia.com/gpu 로 노출
    - mixed: 프로파일별 자원명으로 노출(예: nvidia.com/mig-1g.5gb)
  • AKS는 MIG 호환 VM 사이즈(예: A100 계열 NDv4, H100 Standard_NC40ads_H100_v5 등)로 MIG 노드풀을 만들 수 있고, 만들 때 GPU instance profile(예: MIG1g, MIG2g 등)을 지정합니다. 단, 적용한 profile은 노드풀 생성 후 변경 불가이고, Azure Linux 노드이미지에선 현재 미지원
  • GPU는 limits에만 지정해도 되고, 그러면 request = limit 으로 간주되며 requests를 지정하려면 limits와 반드시 동일해야 함
  • QOS 관점에서 GPU만 limits를 걸어도 CPU/메모리를 지정하지 않으면 BestEffort가 됩니다. 안정적인 스케줄/축출 회피가 필요하면 CPU/메모리도 requests=limits로 맞춰 Guaranteed를 권장
  • GPU Operator를 쓰면 드라이버/디바이스 플러그인/GFD 등을 자동 배포하며 MIG Manager가 노드의 MIG 구성을 관리합니다. 다만 AKS에서는 MIG 프로파일은 노드풀 생성 시 고정(런타임 변경 불가) 제한이 있으니 설계 시에 결정

4. 소프트웨어적 Shareing 기법 - NVIDIA Multi-Process Service(MPS)

  • NVIDIA Multi-Process Service(MPS)는 소프트웨어 레벨에서 여러 CUDA 프로세스를 동시에 실행시켜 GPU 이용률을 높이는 기술입니다. MPS는 단일 GPU 내에서 다중 프로세스의 작업을 병렬 처리할 수 있도록 하여 GPU의 자원 활용을 극대화하지만, 하드웨어 자원 격리 측면에서는 MIG에 비해 제한적입니다. 따라서 격리가 엄격히 요구되는 환경보다는 GPU 활용률 향상이 목표인 경우 적합하며, GPU idle 시간을 줄여 효율 극대화, latency 줄일 수 있음
  • 다만, 하드웨어 자원 분리는 없기 때문에 (메모리·SM 등 격리 X, soft sharing임)  워크로드 간 간섭이 발생할 수 있어 안정성이 중요한 멀티 테넌트 환경에는 부적합
  • MIG에 비해 Pod 및 워크로드 수의 제한이 없으며, 대부분 (Kepler 이후 Tesla, T4, V100 포함) GPU 사용이 가능한 VM에서 활용 가능함.

 

5. 활용 방법

  • 먼저 MIG로 GPU를 하드웨어 분할(예: A100 한 장을 1g.5gb × 7로 쪼갬) 후 그 안에서 다시 MPS를 켜면, 해당 MIG slice를 여러 프로세스가 소프트웨어 레벨로 공유할 수 있음
  • 즉  GPU를 다중 사용자 또는 다중 워크로드 환경에서 효율적으로 운영하기 위해서는 하드웨어 기반의 MIG, 소프트웨어 병렬 처리용 MPS, 그리고 Kubernetes 자원 정책을 함께 고려하는 통합적 접근이 필수
  • (참고) Time‑slicing: 디바이스 플러그인 옵션으로 시간 분할 공유(오버서브스크립션) 가능. MIG 프로파일 자원에도 적용 가능. 격리는 MIG보다 약하지만 활용도는 높음

6. 참고 문서

저작자표시 비영리 변경금지 (새창열림)

'카테고리 없음'의 다른글

  • 현재글성덕이의 티티티2
댓글

티스토리툴바