Kubernetes/Istio

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는 여러 클러스터 환경에서 서비스 메시를 구성하는..

들어가며Istio는 서비스 메시의 강력한 기능을 제공하지만, 기본 설정만으로는 모든 환경에서 최적의 성능을 보장하지 않는다. 특히 대규모 트래픽, 빠르게 변화하는 마이크로서비스 환경, 복잡한 리소스 구조에서는 컨트롤 플레인과 데이터 플레인 모두에서 성능 병목이 발생할 수 있다. Istio의 성능을 튜닝한다는 것은 단순히 리소스를 늘리는 것이 아니라, 어떤 설정이 불필요하게 부하를 주고 있는지, 어디서 병목이 생기고 있는지를 정확히 진단하고, 이에 맞는 전략을 적용해야 한다. Istio 성능 저하의 주요 원인은 다음과 같다:컨트롤 플레인의 설정 생성 및 푸시 처리 병목모든 프록시에 과도하게 전달되는 설정필요 없는 네임스페이스나 워크로드까지 감지하는 디스커버리 범위짧은 간격으로 반복되는 설정 이벤트에 의한 ..

0. 들어가며Istio는 강력한 서비스 메시 기능을 제공하지만, 그만큼 구조가 복잡해 문제가 발생했을 때 원인을 파악하기 어렵다. 특히 네트워크 지연, 응답 실패, 잘못된 라우팅과 같은 문제들은 컨트롤 플레인과 데이터 플레인, 애플리케이션 간의 상호작용 속에서 발생하기 때문에 단순한 로그 확인만으로는 실마리를 찾기 어렵다. 이번 포스팅에서는 Istio에서 자주 발생하는 문제 상황을 재현하고, 이를 디버깅하고 해결하는 과정을 다룬다. VirtualService, DestinationRule 설정 오류부터, Envoy Proxy의 헬스 체크, 지연 응답, 그리고 Prometheus 쿼리 분석까지 운영에서 에서 마주칠 수 있는 다양한 트러블슈팅 방법을 단계별로 정리해 본다.실습 환경 구성: 설정 누락으로 50..

0. 들어가며서비스 메시가 왜 필요한가? 기존 마이크로서비스 환경에서 발생할 수 있는 인증/인가/암호화 문제들을 소개하고, Istio가 이를 어떻게 해결하는지 개요를 다룬다. 애플리케이션 네트워크 보안의 필요성애플리케이션 보안은 인증되지 않은 사용자가 애플리케이션 데이터를 훔치거나 오염시키거나 무단 접근하지 못하도록 방지하는 모든 활동을 포함한다. 즉, 민감한 데이터를 안전하게 보호하려면 다음 요소가 반드시 필요하다.리소스 접근 이전에 사용자 인증과 인가 수행클라이언트와 서버 간 요청이 오가는 동안 전송 중 데이터 암호화로 도청 방지인증(Authentication)은 클라이언트 또는 서버가 자신의 신원을 증명하는 과정을 의미한다. 일반적으로 비밀번호(아는 것), 디바이스나 인증서(가지고 있는 것), 지문..

이번 포스팅에서는 Istio의 Observability(관찰 가능성) 기능을 깊이 있게 살펴보자. 기존에 addon으로 간단히 구성했던 모니터링 도구들은 주로 샘플 실습용 manifest에 불과하며, 실제 운영 환경에서는 별도의 도구 설치와 세부적인 설정이 필요하다. 이번에는 Prometheus, Grafana, Jaeger, Kiali 같은 도구들을 Istio와 연동해 운영 환경에서 어떻게 Observability를 구축할 수 있는지 단계별로 알아본다.1. Istio에서의 observability란?Istio에서의 Observability는 마이크로서비스 환경에서 특히 강력한 역할을 한다. Istio는 각 서비스에 Envoy 프록시를 사이드카로 주입하여, 애플리케이션 코드를 수정하지 않고도 네트워크 트..