Istio - 태그 - lee's bloghttps://ken-0913.github.io/myblog/tags/istio/Istio - 태그 - lee's blogHugo -- gohugo.ioko-krhyeonjae0913@gmail.com (ken-0913)hyeonjae0913@gmail.com (ken-0913)Thu, 16 Jul 2026 08:40:00 +0900ICA 시험 정리 (5) Observability: Prometheus, Grafana, Jaeger, Kialihttps://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-05-observability/Thu, 16 Jul 2026 08:40:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-05-observability/

ICA 시험 정리 시리즈 마지막 편이다. Istio는 Data Plane의 Envoy proxy가 모든 트래픽을 관리하면서 서비스 간 통신마다 상세한 telemetry를 생성한다. 덕분에 observability 솔루션을 처음부터 구축하지 않고도 metrics, distributed tracing, 시각화를 얻는다.

Istio observability는 세 가지 도구로 구성된다. 각 도구의 역할 구분이 시험 포인트다.

도구 역할
Prometheus / Grafana metrics 수집 및 시각화
Jaeger distributed tracing
Kiali Mesh 토폴로지 및 동작 분석

이 도구들은 kubectl apply -f samples/addons로 함께 설치되며, 데모 용도이므로 프로덕션 성능·보안에는 튜닝되어 있지 않다.

]]>ICA 시험 정리 (4) Security: mTLS, 인증, 인가, 인증서 관리https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-04-security/Thu, 16 Jul 2026 08:30:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-04-security/

ICA 시험 정리 시리즈 네 번째 편이다. Istio Security는 Authentication(인증), Authorization(인가), mTLS, Certificate Management로 구성된다. 시험에서 리소스 종류와 정책 적용 범위, mTLS 모드가 특히 자주 출제된다.

핵심 컴포넌트는 Istiod 내부의 CA(Certification Authority)다. CA는 인증서 유효성을 검증하고 CSR(Certificate Signing Request)을 승인·서명한다. 워크로드가 시작되면 Envoy proxy가 Istio agent에게 인증서와 키를 요청하여 통신이 처음부터 암호화·인증된다.

Configuration API Server는 인증·인가·보안 명명 정책을 Mesh 전체에 배포한다. 정책은 Sidecar, Ingress, Egress proxy 모두에 적용된다. 모든 proxy에 계층적으로 정책을 적용하는 이 방식이 Defense-in-Depth(심층 방어) 전략이다.

]]>ICA 시험 정리 (3) Traffic Managementhttps://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-03-traffic-management/Thu, 16 Jul 2026 08:20:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-03-traffic-management/

ICA 시험 정리 시리즈 세 번째 편이다. Istio는 애플리케이션 코드를 수정하지 않고 트래픽을 제어한다. 이번 편은 핵심 컴포넌트인 Gateway, Virtual Service, Destination Rule과 고급 기법인 Timeout, Retry, Fault Injection, Circuit Breaking, A/B Testing을 정리한다.

세 리소스의 역할 구분이 시험의 핵심이다. Gateway는 트래픽을 받기만 하고, 실제 라우팅은 Virtual Service가 정의하며, 라우팅 이후 정책은 Destination Rule이 담당한다.

컴포넌트 역할 주요 필드
Gateway Mesh 가장자리에서 inbound/outbound 트래픽 수용 selector, servers.hosts, servers.port
Virtual Service 라우팅 규칙, 가중치, 헤더 매칭, Timeout, Retry, Fault hosts, gateways, http.match, http.route
Destination Rule 라우팅 이후 정책: Subset, LB, TLS, Circuit Breaking host, subsets, trafficPolicy

Istio Gateway는 Mesh 가장자리에서 동작하는 로드밸런서다. 전통적인 Kubernetes Ingress가 NGINX 같은 컨트롤러를 쓰는 것과 달리, Istio Ingress Gateway는 Envoy proxy로 inbound 트래픽을 가로챈다.

]]>ICA 시험 정리 (2) Istio 입문: 아키텍처와 설치https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-02-introduction/Thu, 16 Jul 2026 08:10:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-02-introduction/

ICA 시험 정리 시리즈 두 번째 편이다. 이번 편은 Monolith에서 Microservice로의 전환, Service Mesh, Istio 아키텍처, 설치 흐름, Kiali를 다룬다. 시험에서는 Control Plane 구성 요소와 Sidecar 주입 과정이 자주 등장한다.

Monolith는 모든 기능을 하나의 코드베이스에 통합하므로, 작은 변경에도 전체 재배포가 필요하다. Microservice로 전환하면 각 모듈을 독립적인 언어로 구현하고 독립적으로 배포·확장할 수 있다. 시험 예제로 자주 쓰이는 Bookinfo 애플리케이션은 Details, Reviews, Ratings, Product Page 4개 모듈로 구성된다.

전환에는 대가가 따른다. 인증, 인가, 로깅, 모니터링, 트래픽 관리 같은 **횡단 관심사(cross-cutting concerns)**가 각 서비스마다 중복 구현된다. 이 문제를 해결하는 전용 인프라 계층이 Service Mesh다.

]]>ICA 시험 정리 (1) 서비스 메시 기초: Kubernetes Service, Sidecar, Envoyhttps://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-01-prerequisites/Thu, 16 Jul 2026 08:00:00 +0900ken-0913https://ken-0913.github.io/myblog/posts/istio-ica/istio-ica-01-prerequisites/

ICA(Istio Certified Associate) 시험을 준비하기 위한 정리 시리즈의 첫 편이다. 이번 편은 Service Mesh를 이해하기 위한 전제 개념인 Kubernetes Service, Sidecar, Envoy를 다룬다. 세 개념은 결국 Istio 아키텍처로 이어지는 밑바탕이 된다.

Pod는 Kubernetes의 가장 작은 배포 단위이지만 **일시적(ephemeral)**이다. Deployment의 의도 상태를 유지하는 과정에서 Pod가 동적으로 생성·종료되며, 이때 Pod의 IP가 계속 변경된다. 그래서 프론트엔드가 개별 Pod IP를 직접 추적하는 방식은 현실적이지 않다.

Service는 **안정적인 IP(stable IP)**를 가지고 Pod 집합으로 트래픽을 라우팅하는 추상화 계층이다. 대상 Pod는 보통 label로 선택되므로, Pod에 올바른 label이 지정되어 있어야 Service가 정상 동작한다.

]]>