EKS에서 워크로드를 운영하려면 두 가지를 결정해야 한다. 어디서 실행할 것인가(컴퓨팅)와 얼마나 실행할 것인가(오토스케일링). 3주차에서는 관리형 노드 그룹으로 컴퓨팅 옵션을 살펴보고 HPA부터 Karpenter까지 여러 스케일링 방법을 실습한다.0. 실습 환경 구성Terraform으로 EKS 클러스터를 배포한다. 이번 실습 환경의 변경점은 k8s 1.35 버전 사용과 워커노드 Private Subnet 배치, SSM 접속 지원이다. add-on으로 metrics-server와 external-dns가 포함되어 있다.# 코드 다운로드git clone https://github.com/gasida/aews.gitcd aews/3w# IAM Policy 파일 작성curl -o aws_lb_controlle..
분류 전체보기
실습 환경이번 실습은 Terraform으로 배포한 EKS 클러스터에서 진행했다. 퍼블릭 서브넷 3개에 t3.medium 워커 노드 3대를 배치하고, VPC CNI의 다양한 IP 할당 모드와 로드밸런서 동작을 확인한다.클러스터myeks (EKS, Terraform 배포)리전ap-northeast-2VPC CIDR192.168.0.0/16서브넷퍼블릭 3개 + 프라이빗 3개노드 그룹t3.medium × 3대 (ENI 3개, ENI당 IP 6개)CNIAWS VPC CNI (기본 설치)노드 배포 상태는 아래 명령으로 확인할 수 있다:# 노드 확인aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,P..
1. EKS = AWS 리소스의 집합 Amazon EKS(Elastic Kubernetes Service)는 AWS의 완전관리형 Kubernetes 서비스다. 컨트롤 플레인을 AWS가 운영하므로 사용자는 워크로드에 집중하면 된다. 완전관리형이란? Kubernetes 컨트롤 플레인은 API 서버, etcd, 스케줄러, 컨트롤러 매니저로 구성된다. 직접 구축하면 etcd 클러스터링, API 서버 이중화, 인증서 로테이션 같은 운영 부담이 상당하다. EKS는 이를 대신 처리하고 99.95% SLA를 보장한다. 대신 시간당 $0.10의 클러스터 비용이 발생한다.직접 구축(kubeadm 등)과 비교하면 EKS가 대신하는 범위가 명확하다.etcd 3대 클러스터링 + 백업/복구3 AZ 분산, 자동 백업API 서버 이..
개요Claude Code로 작업하다 보면,공식 문서 참조할 때, MCP 서버 정보 확인할 때, 외부 레퍼런스 긁어올 때, WebFetch를 꽤 자주 쓰게 됩니다.그러다 이슈를 하나 발견했습니다. 분명히 존재하는 페이지인데 404 에러가 발생합니다.문제의 원인? URL 끝에 붙는 슬래시(/), 이른바 트레일링 슬래시(trailing slash)가 문제였습니다.URL결과https://example.com/path/404 에러https://example.com/path정상HTTP 스펙상 /path와 /path/는 서로 다른 리소스입니다. /path는 파일, /path/는 디렉터리를 가리킵니다.브라우저에서는 둘 다 잘 열리는데, 서버가 보내는 301 리다이렉트를 자동으로 따라가기 때문입니다.WebFetch는 이..
Ambient Mesh란Istio Ambient Mesh는 기존 사이드카 기반 구조를 대체하는 사이드카리스(Sidecar-less) 서비스 메시 아키텍처다. 사이드카를 파드마다 주입하는 대신, 클러스터의 노드와 네임스페이스 단위로 프록시 컴포넌트를 분리 배치하여 운영의 유연성, 리소스 효율성, 보안 격리를 크게 향상시킨다.이 새로운 방식은 두 가지 계층으로 구성된다. 첫 번째는 Secure Overlay로, ztunnel이라는 경량 프록시를 통해 L4 수준에서 트래픽을 암호화하고 인증하는 역할을 한다. 두 번째는 L7 Processing Layer로, HTTP 라우팅이나 인증, 로깅이 필요한 경우에만 waypoint proxy를 통해 고급 기능을 처리한다. 기존 사이드카 방식과 달리, Ambient Me..
이스티오의 가상머신 지원Istio는 원래 쿠버네티스(Kubernetes) 환경에서 동작하도록 설계된 서비스 메시 프레임워크다. 그러나 현실의 인프라는 쿠버네티스로만 구성되어 있지 않다. 온프레미스에 존재하는 레거시 서버, 클라우드 상의 EC2와 같은 VM 인스턴스, 때로는 물리 서버까지 다양한 형태의 워크로드가 함께 운영되는 경우가 많다. 이런 하이브리드 환경에서도 일관된 트래픽 제어, 인증, 관측 기능을 제공하기 위해 Istio는 가상머신(VM) 지원 기능을 제공한다. 이를 통해 쿠버네티스 밖에 있는 VM 워크로드도 쿠버네티스 내부 Pod와 동일한 방식으로 제어 및 관찰할 수 있다. 가상머신을 Istio 메시(mesh)에 연결하면 다음과 같은 이점이 생긴다:서비스 간 mTLS 기반의 보안 통신정책 기..
개요Istio는 기본적으로 뛰어난 트래픽 제어 기능을 제공하지만, 현실 세계의 다양한 요구사항을 모두 충족하긴 어렵다. 예를 들어, 특정 조건에 따라 헤더를 동적으로 추가하거나, 외부 서비스를 호출해 요청 정보를 추가해야 하는 경우도 있다. 이런 시나리오에서는 Istio 내부 API만으로는 한계가 존재한다. 이때 Istio의 내부 구성 요소인 Envoy 프록시의 필터 체인을 직접 확장하면 데이터 플레인의 동작을 더욱 유연하게 제어할 수 있다. 이를 위한 핵심 도구가 바로 EnvoyFilter 리소스다. 단, EnvoyFilter는 잘못 구성하면 서비스 메쉬 전체에 영향을 줄 수 있어 신중한 접근이 필요하다. 일부 전문가들은 운영 환경에서는 가급적 사용을 최소화할 것을 권장하기도 한다. Envoy 필터 체..
1. 개요현대적인 클라우드 아키텍처에서는 여러 개의 쿠버네티스 클러스터를 운영하는 것이 점점 더 일반적인 선택이 되고 있다. 단일 클러스터로 모든 워크로드를 처리하려는 접근은 초기에는 단순하고 빠르게 시작할 수 있지만, 시간이 지날수록 확장성, 장애 복원력, 규정 준수, 팀 간 책임 분리 등 다양한 한계에 부딪히게 된다. Istio는 이러한 상황에 대응할 수 있도록 여러 클러스터를 하나의 서비스 메시로 통합할 수 있는 기능을 제공한다. 이를 통해 클러스터가 분리되어 있더라도 트래픽 제어, 보안 정책, 관찰 가능성(mTLS, 로그, 메트릭) 등의 기능을 일관되게 적용할 수 있으며, 운영자는 단일 메시처럼 관리할 수 있다.1.1 서비스 메시 확장 방식Istio는 여러 클러스터 환경에서 서비스 메시를 구성하는..
