Work/개발 노트

[Istio 스터디] 2주차 - Envoy, Istio Gateway

★용호★ 2025. 4. 19. 16:40

Envoy의 중요성

  • Envoy는 Istio 서비스 메시(Service Mesh)의 데이터 플레인으로서 핵심적인 역할을 담당
  • Kubernetes가 컨테이너 오케스트레이션 플랫폼이듯이, Istio 서비스 메시를 제대로 이해하고 운영하기 위해서는 Envoy에 대한 깊은 이해가 필수적
  • Istio가 제공하는 다양한 기능(트래픽 라우팅, TLS 터미네이션 등)은 모두 Envoy의 기능을 기반으로 함
  • Istio 컨트롤 플레인은 단지 Envoy의 설정을 관리하는 역할만 수행하며, 실제 모든 프록시 기능은 Envoy가 담당

Envoy 프록시 소개와 핵심 원칙

Envoy 프록시 배경

  • 2016년 9월에 오픈 소스로 공개
  • CNCF(Cloud Native Computing Foundation)에 빠르게 합류
  • C++로 작성되어 높은 성능 제공
  • 높은 부하 상황에서도 안정적인 대응이 가능한 프록시

Envoy의 두 가지 중요 원칙

  1. 네트워크의 투명성
    • 네트워크에서 발생하는 문제와 애플리케이션 문제를 명확히 구분할 수 있게 함
    • 네트워크는 다양한 문제 상황(트래픽 폭주, 사용자 접속 폭주, 서버 장애, 유지보수 등)이 발생할 확률이 높음
    • 이러한 문제의 원인 파악을 쉽게 하기 위해 네트워크 계층을 투명하게 관리
  2. 텔레메트리 제공
    • 운영 최적화 및 문제 해결을 위해 다양한 메트릭과 로깅 기능 제공
    • 네트워크 상태를 실시간으로 모니터링할 수 있는 기능 지원

Envoy의 핵심 기능

중계 프록시 역할

  • 클라이언트와 서버 사이에서 중개자 역할을 수행
  • 클라이언트 사이드 로드 밸런싱 기능 제공
  • 백엔드 서버 보호 기능:
    • DDoS 공격으로부터 서버 보호
      • 서버 패닉 상황 방지
    • Rate limit(요청 속도 제한) 설정 가능
      • 커넥션 제한을 통한 백엔드 보호

다양한 프로토콜 지원

  • HTTP/HTTPS 프로토콜
  • gRPC 프로토콜
  • TCP 프로토콜
  • 데이터베이스 프로토콜
  • 비동기 프로토콜 등 다양한 통신 방식 지원

텔레메트리 제공

  • 모든 애플리케이션 트래픽이 Envoy를 경유하므로 중앙집중식 모니터링 가능
  • 메트릭 수집을 통한 운영 최적화 및 문제 원인 분석 지원
  • 개발자가 네트워크 문제를 깊게 고려하지 않아도 되도록 지원

Envoy의 핵심 구성 요소(Core Components)

1. 리스너(Listener)

  • 클라이언트의 요청을 수신하는 첫 번째 구성 요소
  • 특정 포트와 IP에 바인딩되어 다운스트림 트래픽을 수신
  • 수신한 트래픽을 필터 체인을 통해 처리

2. 라우트(Route)

  • 수신된 요청을 어디로 보낼지 결정하는 규칙 모음
  • URL 경로, 헤더, 쿼리 파라미터 등을 기반으로 라우팅 결정
  • 리스너가 수신한 트래픽을 적절한 클러스터로 전달

3. 클러스터(Cluster)

  • 업스트림 서비스의 엔드포인트 집합
  • 클러스터는 여러 서브셋으로 구성 가능
    • 서브셋은 업스트림 클러스터 내의 호스트들을 메타데이터를 기반으로 그룹화하는 로드밸런싱 기능
    • 특정 조건에 맞는 호스트들로만 라우팅 할 수 있음 (EC2 타겟그룹과 유사)
  • 각 서브셋은 개별 엔드포인트(실제 서비스 인스턴스)로 구성됨

(참고) 트래픽 흐름 용어

  • 다운스트림(Downstream): 클라이언트에서 Envoy로 들어오는 트래픽 방향
  • 업스트림(Upstream): Envoy에서 백엔드 서버로 나가는 트래픽 방향

Envoy가 제공하는 주요 기능

서비스 디스커버리

  • 클라이언트 측 서비스 디스커버리 기능 제공
  • 개발팀이 별도로 서비스 디스커버리 로직을 구현할 필요가 없음
  • 동적으로 엔드포인트 목록을 확인하고 관리
  • Istio는 이러한 Envoy의 서비스 디스커버리 메커니즘을 고수준 리소스로 추상화하여 제공

https://hackjsp.tistory.com/85

로드 밸런싱

  • 다양한 로드 밸런싱 알고리즘 제공:
    • 랜덤(Random) : 무작위 선택
    • 가중치 기반 라운드 로빈(Weighted Round Robin) : 가중치에 따라 순차적으로 분배
    • 최소 요청(Least Request) : 현재 처리 중인 요청이 가장 적은 엔드포인트 선택
    • 해싱(Hashing) : 특정 키를 기준으로 동일한 엔드포인트로 라우팅
  • 로컬리티 어웨어 로드 밸런싱(Locality-aware Load Balancing) 지원
    • 약 2년 전부터 유행하기 시작한 로드 밸런싱 전략
    • 지역(region, zone)을 고려하여 가까운 인스턴스에 우선 라우팅
  • 정교한 라우팅
    • URL 경로, 헤더, 쿼리 파라미터 등 다양한 조건에 따른 라우팅 규칙 설정 가능
    • 트래픽 분할을 통한 A/B 테스트, 카나리 배포 지원
      • 트래픽을 특정 비율로 나누어 다양한 버전의 서비스로 분배할 수 있음
      • 이러한 기능은 CD(Continuous Deployment) 과정에서 활용되어, CD 툴과 Istio를 연계한 배포 기술이 많이 개발되고 있음
    • Envoy는 다양한 조건에 따른 세분화된 라우팅 규칙을 지원

트래픽 미러링

  • 실제 트래픽의 복사본을 다른 서비스로 전송하는 기능
  • 프로덕션 환경의 실제 트래픽을 테스트 시스템으로 복제하여 분석 가능
  • 보안 검사, 성능 테스트 등 다양한 목적으로 활용 가능

복원력(Resilience) 제공

  • 재시도(Retry) 메커니즘
  • 타임아웃(Timeout) 설정
  • 서킷 브레이커(Circuit Breaker) 구현
  • 장애 감지 및 이상 탐지
  • 단, 중요한 점은 Envoy가 제공하는 복원력 기능이 애플리케이션 자체의 복원력 설계를 대체할 수는 없음
    • 중간에서 대응은 가능하지만, 궁극적으로는 애플리케이션 자체에서 타임아웃이나 복원력 설정이 적절히 이루어져야함

HTTP/2 및 gRPC 지원

  • 최신 웹 프로토콜 지원
  • gRPC 통신을 위한 특화된 기능 제공

메트릭 수집

  • 다양한 메트릭 유형 제공:
    • 다운스트림 연결 관련 메트릭(예: 총 연결 수, 활성 HTTP/1.1 연결 수)
    • HTTP/2 관련 메트릭(총 요청 수 등)
    • 클러스터 관련 메트릭(서킷 브레이커 발동 횟수, 재시도 횟수, 500 에러로 인한 퇴출 횟수 등)
  • 다양한 통계 어댑터 지원(프로메테우스, OTEL 등)

분산 트레이싱

  • 요청 추적을 위한 트레이싱 헤더 생성
  • 기본적인 트레이스 헤더 구성은 애플리케이션에서 해야 함
    • OpenTelemetry 자동 계측(Auto-instrumentation)을 사용하면 이 작업이 간소화됨
    • 최신 Istio 설정은 OpenTelemetry 기반으로 되어 있어 트레이싱 헤더가 변경됨
  • Envoy는 서비스 호출 연관 목적으로 X-Request-ID 헤더를 생성
  • 트레이싱 시작 시 B3 트레이스 스펙 등의 전파 헤더(propagation headers) 사용

TLS 터미네이션

  • 클라이언트로부터 TLS 연결을 종료하고 백엔드 서비스와 통신 시 별도의 TLS 연결 설정 가능
  • 인증서 키 갱신 등을 자동 관리하여 개발자가 신경 쓸 필요가 없음
  • Istio 내에서 이러한 TLS 관련 기능을 자동으로 처리

레이트 리미팅(Rate Limiting)

  • 과도한 요청으로부터 시스템 보호
  • 특정 엔드포인트나 사용자에 대한 요청 빈도 제한

확장성

  • L7(애플리케이션 계층) 필터 체인을 통한 고급 기능 확장
  • 커스텀 필터 개발을 통한 특수 요구사항 구현 가능

Envoy 설정 방식

1. 정적(Static) 설정

  • 설정 파일(JSON 또는 YAML 형식)을 통한 직접 구성
  • Envoy 시작 시 로드되며, 변경 시 재시작 필요
  • 리스너, 라우트, 클러스터 등을 모두 파일 내에서 정의

2. 동적(Dynamic) 설정

  • xDS API를 통한 동적 구성
  • 실행 중에 설정 변경 가능(재시작 불필요)
  • 다음과 같은 API 종류 제공:
    • LDS (Listener Discovery Service)
      • 기본적인 리스너 정보를 관리
      • 트래픽을 수신하는 진입점 역할
    • RDS (Route Discovery Service)
      • LDS의 부분집합
      • 수신된 트래픽의 라우팅 규칙을 정의
      • 리스너로 받은 트래픽을 어디로 전달할지 결정
    • CDS (Cluster Discovery Service)
      • 백엔드 서비스 그룹을 정의
      • 클러스터 단위로 서비스를 관리
    • EDS (Endpoint Discovery Service)
      • CDS의 부분집합
      • 실제 서비스 엔드포인트 정보를 관리
      • 클러스터 내 개별 서비스 인스턴스 정보 포함
    • SDS (Secret Discovery Service)
      • 인증서 관련 정보를 관리
    • ADS (Aggregated Discovery Service)
      • 위의 모든 API를 통합 관리
      • 일관성 강화를 위해 도입
      • 개별 API를 묶어서 스트림으로 한 번에 전달
      • ADS는 설정의 일관성을 유지하는데 중요한 역할 수행
        • 예를 들어, EDS(엔드포인트 정보)가 전달되었으나 아직 CDS(클러스터 정보)가 전달되지 않은 상황에서 발생할 수 있는 불일치 문제를 방지

Envoy와 Istio의 관계

Istio는 Envoy를 데이터 플레인으로 사용하며, 그 설정을 관리함 -> 이런 구조를 통해 사용자는 Envoy의 복잡한 설정을 직접 관리할 필요 없이 높은 수준의 추상화된 Istio API만 사용하면 됨

  1. 사용자가 Istio API(VirtualService, Gateway 등)로 선언적 설정 작성
  2. Istio 컨트롤 플레인이 이 설정을 Envoy 설정으로 변환
  3. 변환된 설정이 xDS API를 통해 Envoy에 적용
  4. Envoy가 실제 프록시 기능 수행

Envoy의 다른 프록시와의 비교

  1. API 기반 설정 적용: 설정 변경 시 재시작이 필요 없음
  2. 높은 성능과 확장성
    • C++ 기반이며 가비지 수집 없음
  3. 서비스 메시에 최적화된 기능 제공
  4. 다양한 모니터링 및 관찰성(Observability) 기능
    • 심층 프로토콜 메트릭 수집

(참고) 선언형 설정의 이점:

  • Istio API(예: VirtualService)를 통해 선언형 설정만 작성하면 됨
  • 이 설정은 Envoy 설정으로 자동 변환됨
  • Istio 프록시(Envoy)에 부트스트랩 과정에서 적용됨
  • 이는 고수준에서 한 단계 추상화된 설정 방식으로, Envoy의 모든 복잡한 설정을 직접 관리할 필요가 없음
  • Istio가 Envoy 설정으로 자동 변환 및 동기화 수행

Envoy Proxy 기본 실습

# 예제 코드 clone
git clone https://github.com/AcornPublishing/istio-in-action
cd istio-in-action
docker run --name proxy --link httpbin envoyproxy/envoy:v1.19.0 --config-yaml "$(cat ch3/simple.yaml)"

# 다른 터미널에서 로그 확인 (15000번 포트로 리스닝)
docker logs proxy

# envoy proxy에 연결 테스트 (--link 옵션을 주면 해당 컨테이너에 별칭으로 접근 가능)
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/headers

  • 정적 설정을 통한 Envoy 동작 확인
    • 현재 통신 흐름은 curl 컨테이너 -> proxy 컨테이너 -> httpbin 컨테이너로 전송됨
    • curl 컨테이너에서 proxy로 요청을 전송했음에도 httpbin 컨테이너에 정상적으로 전달됨
    • 이 때 헤더에 Envoy 관련 설정들이 포함됨
  • 요청 타임아웃 설정 (기본 15초, 1초로 변경 테스트)

 

docker rm -f proxy
docker run --name proxy --link httpbin envoyproxy/envoy:v1.19.0 --config-yaml "$(cat ch3/simple_change_timeout.yaml)"
docker ps

# 타임아웃 설정 변경 확인
docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/headers

docker run -it --rm --link proxy curlimages/curl curl -X GET http://proxy:15001/delay/2
# 출력 내용 : upstream request timeout

  • Listener(15001 포트)와 HTTP Connection Manager(HCM) 설정
  • 라우팅 규칙을 통한 upstream 서비스 연결

Envoy Admin API 활용

  • 15000 포트를 통한 관리 API 접근
  • 로깅 레벨 조정 (HTTP debug 등)
  • 통계 정보 확인 (Prometheus 형식 지원)
  • 재시도(retry) 정책 설정 및 모니터링

Envoy의 Istio 적합성

  • 중앙 집중식 설정 관리 (xDS API 활용)
  • HTTP 고급 기능 제공
  • 메트릭/텔레메트리 지원
  • TLS 인증서 관리

Istio 서비스 메시의 진입점: 게이트웨이(Gateway)

게이트웨이의 개념과 역할

  • Istio 서비스 메시는 마이크로서비스 간의 통신을 관리하는 인프라 레이어
  • 서비스 메시에 진입하기 위해서는 게이트웨이(Gateway)라는 리소스가 필요함
    • 서비스 메시망에 외부 트래픽이 들어오는 진입점 역할을 하며, 그 중에서도 인그레스 게이트웨이(Ingress Gateway)는 외부에서 내부로 들어오는 트래픽을 처리
  • 인그레스 게이트웨이는 일반적으로 네트워크 용어에서의 '진입점' 또는 '관문'과 유사한 개념으로, 일반적으로 이 지점 뒤에는 방화벽이나 API 게이트웨이 등이 위치함
  • Istio 게이트웨이는 다음과 같은 기능을 제공
    • 가상 IP(Virtual IP) 개념을 통한 로드 밸런싱
    • 도메인 이름 기반의 라우팅
    • 엔드포인트 직접 대응 방지를 통한 보안 강화
  • 게이트웨이는 실제로 Envoy 프록시 기반으로 구현되어 있으며, 리버스 프록시로서 클라이언트에서 들어오는 트래픽을 적절한 백엔드 서비스로 라우팅

가상 호스팅(Virtual Hosting)

  • 가상 호스팅은 단일 접근 지점에서 여러 서비스를 제공하는 기술
  • 인그레스 게이트웨이는 이러한 가상 호스팅 기능을 지원하여 하나의 게이트웨이에서 여러 도메인에 대한 요청을 처리할 수 있음
    • 예를 들어, bar.example.com과 foo.example.com 두 개의 도메인에 대한 요청이 인그레스 게이트웨이에 도달하면, 게이트웨이는 각각의 요청을 적절한 백엔드 서비스로 라우팅
    • 각각의 도메인은 하나의 가상 호스트(Virtual Host)로 취급됨

호스트 결정 메커니즘

  • 가상 호스트를 식별하기 위해 게이트웨이는 다음과 같은 HTTP 헤더를 활용
    • HTTP/1.1: Host 헤더 필드
    • HTTP/2: :authority 헤더 필드
  • TLS 연결의 경우 SNI(Server Name Indication) 확장을 사용하여 호스트를 식별할 수 있음
    • SNI는 TLS 핸드셰이크 과정에서 클라이언트가 접속하려는 서버의 호스트명을 서버에 알려주는 확장 기능

Istio 인그레스 게이트웨이의 구현과 기능

  • Istio 인그레스 게이트웨이는 서비스 메시의 진입점 역할을 하며, 다음과 같은 기능을 제공
    • 가상 호스팅 및 라우팅
    • 보안 및 트래픽 제어
    • 메시 트래픽 인바운드/아웃바운드 관리

Istio 인그레스 게이트웨이의 구조 및 동작 방식

  • Istio를 설치하면 istio-system 네임스페이스에 인그레스 게이트웨이 파드(istio-ingressgateway)가 배포되며 이 파드는 다음과 같은 구성 요소로 이루어져 있음
    • 파일럿 에이전트(Pilot Agent): Envoy 프록시를 부트스트랩하고 관리
    • Envoy 프록시: 실제 요청을 처리하는 프록시 서버
    • 위 구성 요소는 Istio의 컨트롤 플레인과 xDS API(Listener Discovery Service, Route Discovery Service, Cluster Discovery Service, Endpoint Discovery Service 등)를 통해 통신하며, 설정을 동적으로 업데이트함
  • 게이트웨이는 아래 포트 사용
    • HTTP: 80, HTTPS: 443, 상태 체크: 15021
  • 외부 접근을 위해 NodePort를 사용하는 경우는 아래 포트 사용
    • HTTP: 30000, HTTPS: 30005

Istio 인그레스 게이트웨이 프록시 상태 확인

  • istioctl proxy-status 명령을 사용하여 인그레스 게이트웨이의 상태를 확인할 수 있음
    • CDS(Cluster Discovery Service), LDS(Listener Discovery Service), EDS(Endpoint Discovery Service), RDS(Route Discovery Service)의 상태를 보여줌
    • 참고로 처음 게이트웨이를 배포했을 때는 아직 라우팅 규칙이 설정되지 않았기 때문에 RDS가 "NOT SENT"(전송되지 않음) 상태일 수 있음
  • istioctl proxy-config 명령을 사용하여 다양한 설정(리스너, 라우트, 클러스터 등) 확인 가능

Gateway 및 VirtualService 리소스 설정

Gateway 리소스 구성

# 기본적인 Gateway 리소스 구성 예시
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookstore-gateway
spec:
  selector:
    istio: ingressgateway # Istio 기본 컨트롤러 사용
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "webapp.istio-in-action.io" # 처리할 호스트 이름
  • Gateway 리소스는 인그레스 게이트웨이가 어떤 포트, 프로토콜, 호스트 이름을 리스닝할지 정의
  • 위 구성 예시는 인그레스 게이트웨이가 80번 포트에서 webapp.istio-in-action.io 호스트에 대한 HTTP 요청을 처리하도록 지시

VirtualService 리소스 구성

# Virtual Service 설정 예시
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookstore-virtual-service
spec:
  hosts:
  - "webapp.istio-in-action.io"
  gateways:
  - bookstore-gateway
  http:
  - route:
    - destination:
        host: webapp
        port:
          number: 80

 

  • Gateway 리소스만으로는 트래픽을 어디로 라우팅할지 정의하지 못하기 때문에 VirtualService 리소스는 게이트웨이로 들어온 트래픽을 서비스 메시 내의 특정 서비스로 라우팅하는 규칙을 정의
  • 위 설정은 bookstore-gateway로 들어오는 webapp.istio-in-action.io 호스트에 대한 요청을 webapp 서비스의 80번 포트로 라우팅

Gateway와 VirtualService의 관계

  • Gateway: 트래픽을 받아들이는 방법(포트, 프로토콜, 호스트) 정의
  • VirtualService: 받아들인 트래픽을 어디로 보낼지(목적지) 정의
  • 두 리소스를 함께 사용해야 완전한 트래픽 라우팅 경로가 구성됨

TLS 및 보안 구성

TLS 종료(Termination)

  • Istio 인그레스 게이트웨이는 TLS 트래픽을 종료하고 서비스 메시 내부로 전달할 수 있는데 이를 위해 인증서와 개인 키가 필요함

TLS 구성을 위한 기본 단계:

# Gateway 리소스에서 이 Secret을 참조하게 됨
apiVersion: v1
kind: Secret
metadata:
  name: test-certs
  namespace: istio-system
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-key>
# Gateway 리소스에서 이 Secret을 사용
servers:
- port:
    number: 443
    name: https
    protocol: HTTPS
  tls:
    mode: SIMPLE
    credentialName: test-certs
  hosts:
  - "webapp.istio-in-action.io"

HTTP에서 HTTPS로 리다이렉션

- port:
    number: 80
    name: http
    protocol: HTTP
  tls:
    httpsRedirect: true
  hosts:
  - "webapp.istio-in-action.io"
  • 보안을 강화하기 위해 HTTP 요청을 HTTPS로 자동 리다이렉션하도록 구성할 수 있음
  • 위 예시는 클라이언트가 HTTP로 접근할 경우 301 응답과 함께 HTTPS로 리다이렉션

상호 TLS(mTLS)

tls:
  mode: MUTUAL
  credentialName: server-certs
  clientCertificate: client-ca-cert
  • 상호 TLS(mutual TLS, mTLS)는 서버뿐만 아니라 클라이언트도 인증서를 제출하여 양방향 인증을 수행하는 방식
  • 이 설정을 적용하고 나면 서버 인증서와 함께 클라이언트 CA 인증서를 요구하여 클라이언트가 유효한 인증서를 제시해야만 접근을 허용함

다중 가상 호스트와 인증서

servers:
- port:
    number: 443
    name: https
    protocol: HTTPS
  tls:
    mode: SIMPLE
    credentialName: webapp-certs
  hosts:
  - "webapp.istio-in-action.io"
- port:
    number: 443
    name: https
    protocol: HTTPS
  tls:
    mode: SIMPLE
    credentialName: catalog-certs
  hosts:
  - "catalog.istio-in-action.io"
  • 여러 도메인을 서비스할 때 각 도메인마다 다른 인증서를 사용할 수 있음
  • 위 예시에서는 SNI(Server Name Indication)를 통해 클라이언트가 요청하는 도메인에 따라 적절한 인증서를 선택하여 제공함

TCP 트래픽 라우팅

TCP 트래픽 처리

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: tcp-echo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 31400
      name: tcp
      protocol: TCP
    hosts:
    - "*"
  • Istio는 HTTP/HTTPS 외에도 일반 TCP 트래픽을 처리할 수 있음
  • MongoDB, Redis, PostgreSQL 등의 데이터베이스 프로토콜과 같이 HTTP가 아닌 트래픽에 유용
 
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tcp-echo-vs
spec:
  hosts:
  - "*"
  gateways:
  - tcp-echo-gateway
  tcp:
  - route:
    - destination:
        host: tcp-echo
        port:
          number: 31400
  • 위와 같이 VirtualService도 TCP 트래픽에 대한 라우팅 규칙을 정의할 수 있음
  • 단, 단순 TCP로 처리할 경우 Istio의 고급 기능(요청 추적, 트래픽 관리 등)을 활용하기 어렵다는 제한이 있음

SNI 패스스루(Passthrough)

tls:
  mode: PASSTHROUGH
hosts:
- "secure-app.example.com"
  • TLS 트래픽을 게이트웨이에서 종료하지 않고 백엔드 서비스로 그대로 전달하는 방식
  • 이 경우 게이트웨이는 SNI 정보만을 확인하여 라우팅을 수행함
  • 이 모드에서는 게이트웨이가 TLS 트래픽을 해독하지 않고, 백엔드 서비스가 직접 TLS 종료 처리

다중 게이트웨이 및 운영 최적화

다중 게이트웨이 설정

  • 단일 인그레스 게이트웨이만 사용할 필요는 없으며, 다음과 같은 이유로 여러 게이트웨이를 배포할 수 있음
    • 보안 분리
    • 부하 분산
    • 팀별 분리
    • 컴플라이언스 요구사항
    • 고가용성
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: default
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: false
      - name: my-user-gateway
        namespace: istio-in-action
        enabled: true
        k8s:
          service:
            ports:
              - port: 31400
                targetPort: 31400
                name: tcp
  • IstioOperator를 사용하여 커스텀 게이트웨이를 생성할 수 있음
  • 또는 애노테이션을 사용하여 디플로이먼트에 게이트웨이를 주입하는 방식도 있음

로깅 및 모니터링 최적화

  • Istio의 로깅 설정은 성능에 영향을 줄 수 있음
  • 특히 액세스 로그는 디버깅에 유용하지만 부하가 큰 환경에서는 부담이 될 수 있음
  • 기본적으로 Demo 프로필에서는 로그가 활성화되어 있지만, Default 프로필에서는 비활성화되어 있음
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  accessLogging:
    - providers:
      - name: envoy
  metrics:
    - providers:
      - name: prometheus
    overrides:
    - match:
        metric: REQUEST_COUNT
      disabled: true
  • 필요한 경우에만 특정 워크로드에 대해 로깅을 활성화하는 것이 좋고, 이 때는 위와 같이 Telemetry API를 사용할 수 있음

게이트웨이 설정 최적화

  • 게이트웨이는 기본적으로 모든 서비스에 대한 클러스터 정보를 로드함
  • 서비스 수가 많을 경우 메모리 사용량과 성능에 영향을 줌
  • 아래 설정을 활성화하면 게이트웨이는 VirtualService에서 매핑된 서비스만 클러스터 설정에 포함시켜 효율성을 높임
PILOT_FILTER_GATEWAY_CLUSTER_CONFIG=true

실습 진행 방법 및 문제 해결

Gateway 및 VirtualService 배포 및 테스트

웹 애플리케이션과 카탈로그 애플리케이션을 배포하고, Gateway와 VirtualService를 설정하여 외부에서 접근할 수 있게 함

접근 테스트는 curl 명령어를 사용하여 수행

curl -k -H "Host: webapp.istio-in-action.io" https://localhost:30005

로컬에서 테스트할 때는 호스트 이름 확인을 위해 /etc/hosts 파일에 항목을 추가

127.0.0.1 webapp.istio-in-action.io
127.0.0.1 catalog.istio-in-action.io

TLS 설정 및 테스트

TLS 설정을 위해 인증서와 개인 키를 Secret으로 생성하고, Gateway 설정을 업데이트

HTTPS 요청으로 테스트:

curl -k -H "Host: webapp.istio-in-action.io" https://localhost:30005

자체 서명 인증서를 사용하기 때문에 -k 옵션으로 인증서 검증을 건너뛰도록 설정

문제 해결 방법

Istio 환경에서 문제가 발생할 경우 다음과 같은 명령어로 디버깅할 수 있음:

  1. istioctl proxy-status: 프록시의 동기화 상태 확인
  2. istioctl proxy-config listeners <pod-name>: 리스너 설정 확인
  3. istioctl proxy-config routes <pod-name>: 라우팅 설정 확인
  4. istioctl proxy-config clusters <pod-name>: 클러스터 설정 확인
  5. istioctl logs <pod-name>: 로그 확인
  6. kubectl logs -n istio-system -l app=istiod: Istiod 로그 확인