Istio 실전 스터디

Istio는 버전이 자주 바뀌고 구성요소가 많아 수동 설치보다 자동화된 설치/업데이트 관리 도구가 필요하다. 이번 실습에서는 Istio의 공식 Helm Chart인 Sail Operator를 사용해 Istio를 설치하고, 버전 업그레이드를 진행하며 트래픽 유실 여부를

기존에는 Istio의 Ingress Gateway와 VirtualService를 통해 외부 트래픽을 내부 서비스로 전달했다. 하지만 최근에는 Kubernetes의 표준 Gateway API를 활용해 VirtualService 없이도 외부 노출이 가능해졌다. 이번 실습에

Kubernetes는 1.28부터 Native Sidecar 컨테이너 개념을 정식 지원하기 시작했다.기존에는 Sidecar가 단순히 컨테이너 하나였지만, 이제는 lifecycle, 종료 순서, 재시작 정책 등을 분리하여 컨트롤할 수 있는 구조로 발전했다.이번 실습에서는

현대적인 마이크로서비스 아키텍처에서는 서비스 간 통신, 보안, 트래픽 제어, 관측 가능성(O11y)을 통합적으로 다루는 솔루션이 필요하다. Envoy는 이러한 요구사항을 만족시키는 고성능 L7 프록시이며, 서비스 메시 구조에서 데이터 플레인(Data Plane) 으로

Envoy는 마이크로서비스 환경에서 프록시 역할을 수행하는 강력한 데이터 플레인(data plane)이다. 필터 체인을 통한 유연한 요청 처리, 동적 구성, 다양한 통계 수집 기능 덕분에 서비스 메시(mesh) 혹은 API Gateway 계층에서 널리 사용된다. 그러나

Istio를 사용하면 단순히 트래픽을 라우팅하는 것 이상으로, 네트워크 흐름을 관찰하고 제어할 수 있습니다. 이번 실습은 Ingress Gateway와 Egress Gateway를 함께 사용하여, 외부에서 내부 애플리케이션을 호출하고, 해당 애플리케이션이 다시 외부로

Istio를 활용하면 Ingress와 Egress Gateway를 통해 내부 서비스 간 트래픽뿐만 아니라 외부로 나가는 트래픽까지 정밀하게 제어할 수 있다. 하지만 이렇게 구성한 트래픽 흐름이 실제로 의도대로 잘 흘러가고 있는지 확인하기란 쉽지 않다. 이를 눈으로 확인

– Gateway와 Sidecar를 활용한 TLS 종료 방식 구성 실습TLS(Transport Layer Security)는 서비스 메시 환경에서 통신 보안을 보장하기 위한 핵심 요소다. Istio를 활용하면 클러스터 내부뿐만 아니라 외부에서 들어오는 트래픽에 대해서

Istio Ingress Gateway는 단순히 외부 요청을 내부 서비스로 라우팅하는 기능을 넘어서, HTTPS를 통한 보안 통신(Transport Layer Security) 도 지원한다. 이번 실습에서는 self-signed 인증서를 생성하고 이를 Istio Ing

Istio에서는 Ingress Gateway를 활용하여 클라이언트와의 TLS 통신을 처리할 수 있다. 앞선 실습에서는 Gateway에서 TLS를 종료(Terminate)하고 내부 서비스는 HTTP로 처리했지만, 이번 실습에서는 TLS 요청을 그대로 서비스(Pod)까지

이번 실습에서는 Istio 공식 문서의 시나리오 중 하나인 Ingress Sidecar TLS Termination을 그대로 따라가면서, 사이드카(Envoy)가 TLS 종료를 수행하도록 설정하고 흐름을 검증해보았다. 기존의 Istio Ingress Gateway가 TL

1) Kubernetes 클러스터 minikube, kind 또는 EKS/GKE 등 관리형 Kubernetes 클러스터 준비2) Flagger 설치 Helm을 통해 Flagger 설치 (flagger-system 네임스페이스에 설치)3) Prometheus 설치 (

이번 글에서는 Flagger를 이용하여 Istio 환경에서 Canary 배포를 수행하는 방법을 단계별로 실습하고 정리한다. Istio 서비스 메시 환경에서 Flagger를 사용하면 점진적으로 트래픽을 새로운 버전의 애플리케이션으로 전환하면서 배포 안정성을 확인할 수 있

A/B 테스트는 두 개 이상의 버전(예: 기존 버전과 신규 버전)을 사용자 그룹에 나누어 제공하고, 반응을 비교하여 더 나은 버전을 선택하는 전략이다. Flagger를 사용하면 쿠키나 헤더를 기반으로 트래픽을 분리하여, 실제 서비스에 무리 없이 A/B 테스트를 수행할

이번 실습에서는 Istio Egress Gateway를 구성하여 클러스터 외부 서비스 접근을 제어하는 방법을 다룬다.이를 통해 Istio Mesh 내부 서비스가 직접 외부와 통신하는 것이 아니라, Egress Gateway를 통해 외부로 나가는 흐름을 중앙 집중적으로

Istio는 기본적으로 메시 내부 서비스들만 통신 허용을 기본 정책으로 삼는다. 만약 외부 서비스(예: httpbin.org, google.com)로 통신하고 싶다면, ServiceEntry를 추가해서 Mesh에 외부 서비스를 등록해줘야 한다.ServiceEntry

마이크로서비스 아키텍처에서는 시스템 장애를 피할 수 없다. 특히 네트워크를 통해 통신하는 분산 시스템에서는 작은 오류 하나가 전체 시스템에 연쇄적으로 영향을 미칠 위험이 있다. 따라서 우리는 장애가 발생했을 때에도 서비스가 정상에 가깝게 동작하도록 복원력(Resilie

DestinationRule을 생성하여 서비스 버전별로 트래픽을 분리하는 방법을 실습한다.v1과 v2 파드가 모두 떠 있는 것을 확인한다.destination-rule-helloworld.yaml 파일 생성:적용:virtual-service-helloworld.yaml

DestinationRule의 trafficPolicy 기능을 이용해 Connection Pool, Circuit Breaker를 설정하고 실제 적용을 확인한다.destination-rule-helloworld-trafficpolicy.yaml 파일 생성:적용:테스트용

DestinationRule을 통해 서비스 간 통신에 mTLS를 적용해 본다.peer-authentication-default.yaml 파일 생성:적용:기존 DestinationRule 수정하여 TLS 강제 적용:적용:서비스 간 호출이 정상적으로 진행되면, mTLS로

EnvoyFilter를 사용하여 Envoy Proxy가 처리하는 HTTP 요청에 커스텀 헤더를 삽입하는 방법을 실습한다.적용 전후 결과를 비교하여 EnvoyFilter 적용 효과를 검증한다.Kubernetes 클러스터 (Istio 1.17 이상 설치)샘플 애플리케이션(

이번 글에서는 Istio 공식 문서의 Telemetry API 가이드를 따라가며, 커스텀 메트릭을 수집하고 Prometheus에서 그 결과를 직접 확인하는 실습 과정을 정리한다. 실습 환경은 다음과 같다:Kubernetes: Minikube v1.35.0, K8s v1

Istio는 기본적으로 Envoy 프록시를 사이드카로 주입하여 서비스 간 통신을 제어한다. 이 Envoy는 트래픽을 처리하는 동안 수많은 통계 정보를 자동으로 수집해 Prometheus와 같은 모니터링 시스템으로 보낸다. 하지만 기본 설정에서는 너무 많은 메트릭이 생성

이번 실습은 Istio가 수집한 메트릭 데이터를 Prometheus에서 직접 확인해보는 과정을 다룬다. Istio 공식 문서 Operations > Integrations > Prometheus 항목을 바탕으로 실습을 진행한다.Istio가 수집한 메트릭이 실제 Prom

마이크로서비스 아키텍처에서는 하나의 사용자 요청이 수많은 서비스와 네트워크 레이어를 거치며 처리된다. 이러한 구조는 유연성과 확장성 측면에서는 장점을 가지지만, 요청이 어디서 지연되고 실패했는지를 추적하는 데는 큰 어려움을 준다.예를 들어, "사용자가 웹에서 주문 버튼

이번 글에서는 Istio의 Observability(관측 가능성)를 강화하는 두 핵심 도구인 Kiali와 Jaeger를 실습 기반으로 비교 분석합니다. Kubernetes: minikube (Docker 드라이버)Istio: 1.17.x 버전Kiali: Helm 설치