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/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
'Azure 상식' 카테고리의 다른 글
| AKS PV/PVC 사용법 및 CSI 구성에 따른 Azure Files 특성 이해 (0) | 2025.08.23 |
|---|---|
| AKS Overlay Network 구성에 대한 이해: POD IP 할당과 특징 (0) | 2025.08.23 |
| Azure Load Balancer 이해: 가용성, 분산처리 특징과 Coverage (0) | 2025.08.22 |
| AKS권한 관리 방식: K8S의 IAM처리 방식의 이해 Entra ID, Service Account 등 이해와 차이점 (0) | 2025.08.22 |
| Azure Managed Disk 에 대한 이해 (0) | 2025.08.21 |