Istio 시작하기
Istio는 마이크로서비스의 복잡성을 해결하며, Sidecar 패턴으로 통신 관리를 최적화합니다. Ambient 모드로 자원 사용을 효율화합니다.
개요
Istio는 급격히 성장하는 마이크로서비스 아키텍처의 복잡성을 해결하기 위해 등장했습니다.
마이크로서비스의 확산으로 인한 문제였습니다. 모놀리식 애플리케이션을 작은 서비스들로 분해하면서 서비스 간 통신, 보안, 모니터링이 매우 복잡해졌습니다. 개발자들은 이러한 인프라 문제를 해결하느라 비즈니스 로직에 집중하기 어려웠습니다.
이러한 배경에서 Istio는 서비스 메시의 복잡성을 추상화하고, 개발자들이 비즈니스 로직에 집중할 수 있도록 하는 통합 솔루션으로 등장하게 되었습니다. 특히 Sidecar를 활용한 Proxy 패턴은 애플리케이션 코드를 수정하지 않고도 서비스 메시의 기능을 활용할 수 있게 도와주었습니다.
Sidecar proxy라는 개념은 Pod마다 하나씩 배치되며 기존 애플리케이션의 트래픽을 가로채며 네트워킹을 대신 수행합니다. 이러한 특징으로 인해 istio는 기존 kube-proxy 중심의 트래픽 관리를 완전히 대체하며 동작할 수 있게 지원합니다.

Sidecar
각 Pod에 Envoy 프록시가 사이드카로 주입되어 함께 실행됩니다. 모든 트래픽이 이 사이드카를 통해 라우팅되는 방식입니다. 이로 인해 사이드카 proxy의 업데이트나 재시작이 필요할 때 애플리케이션도 함께 재시작해야하며, 각 Pod마다 사이드카 proxy가 실행되므로 메모리와 CPU 리소스가 중복해서 소비됩니다.
특히 대규모 클러스터에서 수백, 수천 개의 사이드카가 실행될 경우 전체 리소스 사용량이 크게 증가하며, 작은 마이크로서비스라도 사이드카로 인해 최소 리소스 요구사항이 증가하게 됩니다. 또한 실제 트래픽이나 부하 관계없이 동일한 리소스를 예약/점유하고 있으며 사이드카로 인한 디버깅, 트러블 슈팅이 어려워지므로 운영상의 어려움을 초래합니다.
Ambient
노드 레벨의 ztunnel과 독립적인 waypoint proxy를 사용하여 애플리케이션과 메시 컴포넌트의 lifecycle을 완전히 분리한 구조로 Sidecar-less한 방식입니다. 노드 단위로 공유되는 컴포넌트를 통해 중복 리소스 사용 최소화되어있지만 아직 Istio에서는 베타 기능으로 출시되었으며 Ambient Mesh에 대해 지속적으로 업데이트 되고 있습니다.
Minikube istio 테스트
테스트 환경 설정
<1. minikube start>
minikube delete
minikube start --memory 4096
minikube start --driver=virtualbox --memory 4096
<2. istio / istioctl 설치>
demo
프로파일 관련:
- 테스트 목적으로 좋은 기본 설정들이 포함된
demo
프로파일을 사용됩니다 - 이 외에도 프로덕션용, 성능 테스트용, OpenShift용 등 다른 프로파일들도 존재합니다.
- Gateway 관련 중요한 차이점:
- Kubernetes Gateway를 만들면 자동으로 gateway 프록시 서버도 함께 배포되지만 Istio Gateway는 다르게 동작합니다.
- 설정 변경사항:
demo
프로파일에는 기본적으로 Istio gateway 서비스들이 설치됩니다.- 하지만 이 서비스들이 사용되지 않을 것이므로 테스트 과정 중 Istio Gateway는 비활성 됩니다.
$ curl -L https://istio.io/downloadIstio | sh -
$ cd istio-1.24.2
$ export PATH=$PWD/bin:$PATH
$ export NAMESPACE=istio
$ k create ns $NAMESPACE
$ k apply -f samples/addons
<3. k8s CRD 설치>
- CRD(Custom Resource Definition)란?
- Kubernetes의 기능을 확장할 수 있게 해주는 사용자 정의 리소스입니다
- 기본적으로 제공되지 않는 새로운 유형의 리소스를 정의할 수 있습니다
- 마치 네이티브 Kubernetes 리소스처럼 사용할 수 있게 됩니다
- Gateway API CRD의 역할:
- 트래픽 라우팅을 위한 새로운 리소스 타입을 정의합니다
- Ingress보다 더 풍부한 기능을 제공합니다
- L4/L7 라우팅, TLS 설정, 가중치 기반 트래픽 분배 등을 지원합니다
- 명령어:
💡 Istio는 Kubernetes Gateway API를 지원하며 , 향후 트래픽 관리를 위한 기본 API로 만들 계획입니다. 다음 지침에 따라 메시에서 트래픽 관리를 구성할 때 Gateway API 또는 Istio 구성 API를 사용하도록 선택할 수 있습니다. 선호도에 따라Gateway API
또는Istio APIs
탭 아래의 지침을 따르세요.
Kubernetes Gateway API CRD는 대부분의 Kubernetes 클러스터에 기본적으로 설치되지 않으므로 Gateway API를 사용하기 전에 설치되었는지 확인하세요.
kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \\
{ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.2.0" | kubectl apply -f -; }
이 CRD가 설치되어야 Gateway API 관련 리소스들(Gateway, HTTPRoute 등)을 사용할 수 있습니다.
테스트 환경을 설정하기 전 istio가 envoy 사이드카 프록시를 자동으로 주입하기 위해선 namespace에 레이블을 추가해야합니다.
kubectl label namespace default istio-injection=enabled
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.24/samples/bookinfo/platform/kube/bookinfo.yaml
생성시 자동으로 Sidecar 컨테이너가 붙는 것을 확인
➜ istio-1.24.2 git:(main) ✗ k get pods
NAMESPACE NAME READY STATUS RESTARTS AGE
default details-v1-6cd6d9df6b-v4p6q 0/2 Init:0/1 0 7s
default productpage-v1-57ffb6658c-jtgg9 0/2 Init:0/1 0 7s
default ratings-v1-794744f5fd-9hjkx 0/2 Init:0/1 0 7s
default reviews-v1-67896867f4-gdbn5 0/2 Init:0/1 0 7s
default reviews-v2-86d5db4bd6-nbx7p 0/2 Init:0/1 0 7s
default reviews-v3-77947c4c78-qgr55 0/2 Init:0/1 0 7s
애플리케이션 외부 트래픽 열기
<1. k8s Gateway를 사용합니다.>
kubectl apply -f samples/bookinfo/gateway-api/bookinfo-gateway.yaml
- Gateway API란?linktopage
Istio는 게이트웨이를 설정할 때 기본적으로 LoadBalancer 타입의 서비스를 생성합니다. 이는 외부에서 들어오는 트래픽을 클러스터 내의 서비스로 분산시키기 위한 것입니다. LoadBalancer 서비스는 클라우드 제공업체에서 외부 IP 주소를 할당받아, 외부 요청을 클러스터의 여러 인스턴스로 라우팅합니다.
하지만 테스트 환경에서는 터널을 통해 엑세스하므로 로드밸런서를 사용하지않으며 로드 밸런서가 외부 IP 주소에 대해서는 인그레스 게이트웨이 설명서를 읽어보세요.
<2. 생성된 Gateway와 서비스 연결>
kubectl annotate gateway bookinfo-gateway networking.istio.io/service-type=ClusterIP --namespace=default
<3. 연결 확인>
kubectl get gateway
NAME CLASS ADDRESS PROGRAMMED AGE
bookinfo-gateway istio bookinfo-gateway-istio.default.svc.cluster.local True 4m55s
Application 접속
http://localhost:8080/productpage
내부 포워딩 시킨 후 /productpage
로 접근합니다.
kubectl port-forward svc/bookinfo-gateway-istio 8080:80
Istio는 여러 가지 다른 원격 측정 애플리케이션 과 통합됩니다 . 이를 통해 서비스 메시의 구조를 이해하고, 메시의 토폴로지를 표시하고, 메시의 상태를 분석하는 데 도움이 될 수 있습니다.
다음 지침에 따라 Prometheus , Grafana , Jaeger 와 함께 Kiali 대시보드를 배포하세요 .
Jaeger
Jaeger는 Uber Technologies에서 오픈 소스로 개발한 분산 추적 시스템입니다. 주로 마이크로서비스 기반의 분산 시스템을 모니터링하고 문제를 해결하는 데 사용됩니다.
Jaeger는 다음과 같은 기능을 제공합니다:
- 분산 컨텍스트 전파: 서비스 간의 요청을 추적하여 전체적인 흐름을 이해할 수 있도록 합니다.
- 분산 트랜잭션 모니터링: 여러 서비스에 걸쳐 발생하는 트랜잭션을 모니터링하여 성능을 분석합니다.
- 근본 원인 분석: 문제 발생 시 원인을 파악하는 데 도움을 줍니다.
- 서비스 의존성 분석: 서비스 간의 의존성을 시각화하여 시스템 구조를 이해하는 데 도움을 줍니다.
- 성능 및 지연 최적화: 성능 병목 현상을 찾아내고 최적화할 수 있는 정보를 제공합니다.
Jaeger는 OpenTracing 표준을 지원하며, 다양한 프로그래밍 언어에 대한 클라이언트 라이브러리를 제공합니다. 또한, Cassandra, Elasticsearch와 같은 여러 저장소 백엔드를 지원하여 추적 데이터를 저장할 수 있습니다.
Jaeger의 주요 구성 요소는 다음과 같습니다:
- Agent: 클라이언트 라이브러리에서 수집한 추적 데이터를 수신하고, 이를 수집기로 전송합니다.
- Collector: Agent로부터 데이터를 수집하고, 저장소에 저장합니다.
- Query Service: 저장된 데이터를 쿼리하고, 웹 UI를 통해 시각화합니다.
Kiali
Kiali는 Istio와 같은 서비스 메쉬를 모니터링하고 관리하기 위한 오픈 소스 도구입니다. Kiali는 다음과 같은 주요 기능을 제공합니다:
- 서비스 맵 시각화: Kiali는 서비스 간의 관계를 시각적으로 표현하여, 마이크로서비스 아키텍처의 구조를 쉽게 이해할 수 있도록 도와줍니다. 이를 통해 서비스 간의 의존성을 파악할 수 있습니다.
- 트래픽 모니터링: Kiali는 서비스 간의 트래픽 흐름을 모니터링하고, 요청 수, 응답 시간, 오류율 등의 메트릭을 제공합니다. 이를 통해 성능 문제를 조기에 발견하고 해결할 수 있습니다.
- 정책 관리: Kiali는 Istio의 정책을 관리하고, 서비스 간의 통신을 제어하는 데 필요한 설정을 쉽게 적용할 수 있도록 도와줍니다.
- 문서화 및 헬스 체크: Kiali는 서비스의 상태를 모니터링하고, 문제가 발생할 경우 경고를 제공합니다. 또한, 서비스의 문서화 기능을 통해 팀원들이 시스템을 이해하는 데 도움을 줍니다.
- 통합 기능: Kiali는 Jaeger와 같은 다른 모니터링 도구와 통합되어, 분산 추적 및 성능 분석을 지원합니다.
Kiali는 Kubernetes 환경에서 쉽게 배포할 수 있으며, Istio와 함께 사용하여 서비스 메쉬의 가시성을 높이고 관리 효율성을 향상시킬 수 있습니다. 더 자세한 정보는 Kiali 공식 문서를 참조하세요.
Dashboard 통합
<1. Kiali와 다른 애드온을 설치 하고 배포될 때까지 기다립니다.>
kubectl apply -f samples/addons
kubectl rollout status deployment/kiali -n istio-system
<2. Kiali 대시보드에 엑세스합니다>
생성되었다면 kiali 대시보드가 생성됩니다.
istioctl dashboard kiali

<3. 그래프로 보기>
추적 데이터를 보려면 서비스에 요청을 보내야 합니다. 요청 수는 Istio의 샘플링 속도에 따라 달라지며 Telemetry API를 사용하여 구성할 수 있습니다 . 기본 샘플링 속도가 1%인 경우 첫 번째 추적이 표시되기 전에 최소 100개의 요청을 보내야 합니다. 서비스에 100개의 요청을 보내려면 productpage
다음 명령을 사용합니다.
이때 Gateway는 local이므로 localhost:8080을 사용합니다.
export GATEWAY_URL=localhost:8080
for i in $(seq 1 100); do
response=$(curl -s -w "%{http_code}" -o /dev/null "http://$GATEWAY_URL/productpage")
if [ $response -eq 200 ]; then
echo "요청 $i: 성공 (상태 코드: $response)"
else
echo "요청 $i: 실패 (상태 코드: $response)"
fi
done
트래픽을 확인합니다.

설정한 bookinfo-gateway를 통해 트래픽이 전달되고 있는 것을 확인할 수 있습니다.
