TechnicalArchitect merin

Kubernetes Gateway API에서 트래픽 정책은 어디에 붙는가

Policy Attachment와 GatewayClass 이해하기Kubernetes에서 Ingress를 오래 사용하다 보면 이런 Annotation에 익숙하다.metadata: annotations: nginx.ingress.kubernetes.io/proxy-read-timeout: "300" nginx.ingress.kubernetes.io/proxy-send-timeout: "300" nginx.ingress.kubernetes.io/proxy-body-size: "100m"Timeout 하나를 바꾸려 해도 Annotation을 추가하고, Controller가 달라지면 Annotation 이름도 달라진다.Gateway API를 처음 접했을 때 가장 기대했던 부분도 이 점이었다.이제..

Azure Application Gateway for Containers에서 Root Domain을 사용할 수 없는 이유

AKS 앞단에 Application Gateway for Containers(AGC) 를 구성하면서 Custom Domain을 연결하던 중, example.com과 같은 Root/Apex Domain을 사용할 수 없는 상황을 겪었다.처음에는 인증서 문제라고 생각했지만, 실제 원인은 AGC의 Frontend 구성 방식과 DNS의 CNAME 제약이었다.아래 내용은 2026년 8월 기준 Microsoft 문서를 기준으로 정리했다.1. AGC의 Frontend는 IP가 아니라 FQDN이다기존 Application Gateway(AGW)와 Application Gateway for Containers(AGC)의 가장 큰 차이 중 하나는 Frontend 구성 방식이다.AGC의 Frontend를 생성하면 Azure에..

AKS에서 Spegel로 노드풀 단위 P2P 이미지 미러 구축기

들어가며Kubernetes에서 오토스케일로 노드가 늘어날 때마다 같은 이미지를 사설 레지스트리(JFrog, Harbor 등)에서 반복 pull 하면 배포가 느려집니다.이번에 Spegel을 도입해, 노드풀 단위 P2P 레지스트리 미러를 구성하고 해피패스까지 검증했습니다.핵심은 다음과 같습니다.레지스트리 mirror + P2P로 이미 노드에 있는 이미지 레이어를 피어에서 받기노드풀별로 독립 배포 (워크로드 A / 워크로드 B 분리)GitOps(ArgoCD)가 아닌 수동 kubectl kustomize --enable-helm | kubectl applySpegel이란?Spegel은 Kubernetes 노드마다 DaemonSet으로 뜨는 P2P OCI 레지스트리 미러입니다.동작 흐름:containerd가 외부..

Kubernetes User Namespace 정리: 왜 필요하고, AKS에서 어디까지 가능한가

1. 왜 User Namespace가 필요한가컨테이너는 격리되어 있다고 하지만, 기본적으로 컨테이너 내부의 root 사용자는 host 관점에서도 위험한 의미를 가질 수 있다. 컨테이너 탈출 취약점이나 runtime 취약점이 발생했을 때, 컨테이너 내부 root가 host에서 높은 권한을 얻는 상황을 줄이기 위해 Linux는 user namespace라는 격리 기능을 제공한다.Kubernetes의 user namespace는 Kubernetes namespace와 다른 개념이다. Kubernetes namespace는 리소스를 논리적으로 나누는 Kubernetes 기능이고, Linux user namespace는 컨테이너 내부 UID/GID와 host UID/GID를 분리하는 Linux 커널 기능이다. K..

Ingress NGINX에서 AKS Istio Gateway API로의 전환

Kubernetes에서 외부 또는 내부 사용자 트래픽을 애플리케이션으로 전달할 때, 가장 익숙한 방식은 오랫동안 Ingress와 Ingress Controller였다. 나 역시 기존 환경에서는 ingress-nginx를 사용해 여러 서비스의 진입점을 운영하고 있었다.하지만 최근에는 단순히 “익숙하다”는 이유만으로 Ingress 구조를 계속 유지하기에는 고민할 지점이 많아졌다. Kubernetes 공식 문서에서도 Ingress는 기능 동결 상태로 안내되고 있고, 더 유연한 구조인 Gateway API 사용이 권장되고 있다. 여기에 더해 커뮤니티 ingress-nginx 프로젝트도 2026년 3월 retire 예정으로 발표되면서, 기존 구조를 계속 가져가는 것에 대한 운영 리스크도 분명해졌다.이번 작업의 목..

[AKS] “방화벽 때문인 것 같은데…”에서 멈추지 않기: AKS Outbound 장애를 증거로 쪼개서 푸는 방법 (feat. 회사 방화벽 이슈)

요즘 회사에서 AKS 운영을 하다 보면, 장애의 많은 부분이 결국 네트워크/방화벽으로 모입니다.특히 “나가는 트래픽(Outbound)”은 서비스 내부 코드가 멀쩡해도, 보안 정책 한 줄 때문에 갑자기 Connection reset by peer로 터지기도 하죠.문제는 여기서부터예요.개발자는 “쿠버네티스가 뭔가 잘못된 거 아니냐”보안/네트워크는 “우리 방화벽은 문제 없다(로그 없다)”운영자는 “어딘가에서 끊기는 건 확실한데… 어디지?”이 글은 딱 그 고민을 담아서, “방화벽 이슈 같다” → “증거 기반으로 레이어를 분해” → “해결 경로(누구에게 무엇을 요청할지)까지 정리한 기록입니다.⚠️ 보안상 도메인/리소스/구독ID/IP 등은 일부 마스킹하거나 샘플로 치환해서 작성하는 걸 권장합니다. (아래 예시는 실..

[AKS] Outbound(Egress) 경로 설계: outboundType부터 UDR(Azure Firewall)까지 (운영 체크리스트 + Test Command)

AKS를 운영하다 보면 인바운드(들어오는 트래픽)보다 아웃바운드(나가는 트래픽) 때문에 더 자주 막힙니다. 외부 API allowlist(고정 출구 IP), 보안팀의 방화벽 강제 경유, 프록시/SSL inspection, Private Endpoint 중심의 격리 전략까지… 전부 “AKS에서 밖으로 어떻게 나가느냐” 문제로 수렴하거든요. 이 글은 그 출발점인 networkProfile.outboundType(= outboundType) 을 기준으로, 각 타입이 의미하는 바와 설계 순서, 그리고 우리가 선택한 UDR(userDefinedRouting) 기준의 구현/테스트 템플릿까지 블로그용으로 정리한 글입니다.(공식 문서 기준: https://learn.microsoft.com/en-us/azure/aks..

AWS 기반 AI 플랫폼 아키텍처(Bedrock·RAG·GitOps 통합형 AI 에이전트) 설계

최근 AWS를 활용하여 엔터프라이즈급 AI 플랫폼을 설계하고 구축하는 기회가 있었습니다. 본 포스트에서는 다이어그램을 통해 설계한 아키텍처의 주요 구성 요소와 설계 의도를 공유하고자 합니다.1. 전체 아키텍처 개요1.1 멀티 계정 전략 (PRD/DEV 분리)이 아키텍처의 목표는 엔터프라이즈 금융권 환경에서 AI Agent 기반 서비스를 안정적으로 운영하는 것이었습니다.이를 위해 아래 네 가지 축을 중심으로 설계했습니다. 프로덕션과 개발 환경을 완전히 분리하여 운영의 안정성과 보안성을 확보했습니다. 멀티 계정 + 멀티 AZ 인프라 PRD / DEV 계정 분리, 각 계정 내에서 2개 AZ 활용 VPC, 서브넷, 보안 정책까지 환경별 완전 분리 EKS 기반 컨테이너 런타임 ..