[Istio 스터디] 8주차 - VM Support & Istio Traffic Flow

레거시 워크로드의 정의와 통합 필요성

레거시 워크로드는 Kubernetes의 파드가 아닌, VM(가상 머신) 또는 베어메탈 서버에 올라가 있는 애플리케이션을 의미

레거시 워크로드를 Istio 서비스 메시에 통합 시 이점:

트래픽 라우팅 관리
인증 관련 기능(mTLS 통신)
세밀한 권한 정책(Authorization policies)
텔레메트리(Telemetry) 기능

많은 기업 환경에서는 모든 워크로드를 Kubernetes로 마이그레이션하기 어려운 상황이 존재함:

유지 관리하는 업체가 없어 히스토리가 불분명할 수 있음
컨테이너화하려면 새로운 설계가 필요함
다양한 추가 고려사항이 필요함

Istio VM 지원의 주요 기법

Istio의 VM 지원 기능을 통해 Kubernetes Pod와 VM 워크로드를 단일 서비스 메시로 통합할 수 있음
Istio VM을 통해 마이크로서비스 아키텍처의 이점을 기존 VM 기반 애플리케이션에도 확장할 수 있음
핵심 요소로는 Istio 에이전트 설치, 신원 인증, DNS 프록시, 워크로드 그룹 및 엔트리 등이 있으며, 이를 통해 일관된 보안, 트래픽 관리, 텔레메트리 기능을 VM 환경에서도 활용할 수 있음

가상 머신을 Istio 서비스 메시에 통합하기 위해서는 다음 조건들이 필요:

Istio 에이전트 설치: 사이드카 프록시 역할을 하는 Envoy를 VM에 직접 설치
신원 인증을 위한 프로비저닝: 인증서 발급 및 관리
서비스 메시 노출: 접속을 위한 설정
DNS 관련 도메인 질의 해석: 서비스 메시 내 서비스와의 통신을 위한 DNS 설정

네트워크 아키텍처 유형

1. 멀티 네트워크 아키텍처

멀티 네트워크 아키텍처에서는 Kubernetes 클러스터와 VM이 서로 다른 네트워크에 위치합니다. 이 경우:

VM은 완전히 다른 인터넷망에 있어도 괜찮습니다.
단, VM은 게이트웨이와 통신이 가능해야 하며 필요한 포트들이 오픈되어 있어야 합니다.
컨트롤 플레인이 VM을 직접 제어하지 않고, 중간에 게이트웨이를 두어 VM의 상태 확인 및 제어를 수행합니다.
데이터 통신 시에도 게이트웨이를 경유하여 전달됩니다.

2. 싱글 네트워크 아키텍처

싱글 네트워크 아키텍처에서는 Kubernetes 클러스터와 VM이 동일한 네트워크에 위치합니다:

같은 네트워크에 있지만, 컨트롤 플레인은 여전히 게이트웨이를 경유하여 VM을 관리해야 합니다.
데이터 플레인 통신은 직접 처리됩니다.
고속 통신이나 트래픽이 많은 경우 게이트웨이를 경유하지 않아 병목 현상을 방지할 수 있습니다.

신원 인증(Identity) 프로비저닝

Kubernetes 파드의 신원 인증 방식

Kubernetes 파드는 다음과 같은 방식으로 신원 인증을 수행합니다:

Kubernetes 서비스 어카운트 토큰을 주입받음
이 토큰을 기반으로 인증서를 istiod(Istio의 컨트롤 플레인)를 통해 발급받음
SPIFFE ID(Secure Production Identity Framework for Everyone)를 인증서에 포함

VM의 신원 인증 방식

VM은 Kubernetes 서비스 어카운트 토큰을 사용할 수 없기 때문에 대체 방안이 필요합니다:

퍼블릭 클라우드 제공자(AWS, Azure 등)가 제공하는 VM 신원 확인 정보를 활용하는 방안이 논의 중
각 클라우드 서비스가 EC2 인스턴스 배포 시 제공하는 신원 정보를 신뢰 기반으로 사용할 가능성 있음

워크로드 그룹과 워크로드 엔트리

VM을 Istio 서비스 메시에 통합하기 위해 Istio는 두 가지 새로운 API 리소스를 도입했습니다:

워크로드 그룹(WorkloadGroup)

Kubernetes의 Deployment와 유사한 고수준 리소스
여러 VM을 그룹화하여 관리
고가용성을 달성하기 위한 리소스

워크로드 엔트리(WorkloadEntry)

Kubernetes의 Pod와 유사한 개념
단일 VM을 나타냄
자동으로 생성되며 VM의 IP, 라벨 등의 정보를 포함

이러한 구조를 통해 Kubernetes의 Deployment와 Pod의 관계와 유사하게 VM을 관리할 수 있습니다.

자동 등록 메커니즘

VM이 자동으로 워크로드 그룹에 등록되는 과정은 다음과 같습니다:

VM이 API 서버를 통해 자신이 특정 워크로드 그룹의 일원임을 선언
Kubernetes API 서버를 통해 VM의 신원 확인
모든 절차가 완료되면 워크로드 엔트리(WorkloadEntry) 리소스가 자동 생성
워크로드 엔트리에는 VM의 IP, 관련 서비스 라벨 등이 포함

이를 통해 서비스의 라벨 셀렉터가 Pod 뿐만 아니라 VM의 워크로드 엔트리도 선택할 수 있게 됩니다. 이로써 다음과 같은 활용이 가능합니다:

서비스 부하 분산
트래픽 우선순위 설정
장애 발생 시 대체 경로 설정

헬스 체크

서비스 메시에서 VM 워크로드의 상태를 확인하는 것은 매우 중요합니다:

VM 워크로드에 대해 기본적으로 헬스 체크가 필수적으로 수행됨
Kubernetes의 Liveness/Readiness Probe 개념과 유사하지만, VM에서는 Readiness Probe만 사용
- Liveness Probe는 일반적으로 클라우드 제공자의 자동 확장 그룹(AWS Auto Scaling Group, Azure VM Scale Set 등)에서 관리

헬스 체크 작동 방식

VM에 설치된 Istio 에이전트(사이드카 프록시)가 로컬에서 애플리케이션 상태를 주기적으로 검사
헬스 체크 상태(Health 또는 Failed)를 업데이트
Failed 상태일 경우 서비스 엔드포인트 그룹에서 제외
Health 상태일 경우 트래픽 수신 가능 상태로 유지

DNS 해석(DNS Resolution)

https://istio.io/latest/blog/2020/dns-proxy/

VM에서의 DNS 문제

Kubernetes 환경에서는 Pod가 도메인 기반으로 서비스에 접근할 때 CoreDNS(이전 이름: KubeDNS)를 통해 도메인 질의를 처리합니다. 그러나 VM은 이러한 환경이 없기 때문에 다음과 같은 문제가 발생합니다:

VM이 Kubernetes 서비스(예: service.namespace.svc.cluster.local)에 접근하려고 할 때
VM은 기본적으로 외부 DNS 서버(예: KT, LG, SK의 DNS 서버)에 질의
외부 DNS 서버는 Kubernetes 내부 서비스를 알지 못함

DNS 프록시 기법

이 문제를 해결하기 위해 Istio는 DNS 프록시 기법을 도입했습니다:

VM에 설치된 Istio 에이전트 내부의 DNS 프록시가 도메인 질의를 가로챔
가로챈 질의를 istiod와 CoreDNS를 통해 처리
응답을 캐싱하여 성능 향상
IP 테이블 규칙을 추가하여 DNS 쿼리가 자동으로 프록시로 리디렉션되도록 설정

NDS(Name Discovery Service)

https://www.anyflow.net/sw-engineer/istio-dns-proxying

Istio는 DNS 항목의 동기화를 위해 새로운 API인 NDS(Name Discovery Service)를 도입했습니다:

NDS를 통해 컨트롤 플레인과 데이터 플레인 간의 DNS 항목 동기화
미리 동기화된 주소에 대해 투명하게 통신 가능
코드 변경 없이 원하는 도메인을 특정 위치로 라우팅 가능

DNS 프록시의 이점

DNS 라운드 트립 제거: 로컬 캐시를 활용해 CoreDNS에 대한 부하 감소
투명한 주소 해석: 사전에 동기화된 주소에 대해 투명하게 처리
등록되지 않은 도메인 추가: ServiceEntry를 통해 추가 DNS 항목 정의 가능

컨트롤 플레인 업데이트 및 가상 머신 통합 기능 활성화

Istio 기본 설치 환경에서는 가상 머신 통합 기능이 활성화되어 있지 않음
Istio 컨트롤 플레인에 가상 머신 통합 기능을 명시적으로 활성화해야 함
가상 머신 통합을 위한 핵심 기능으로는 워크로드 자동등록 설정, 헬스 체크 구성, DNS 쿼리 캡처 및 리다이렉션 기능 필요
이러한 기능들을 Istio 컨트롤 플레인에 업데이트하여 활성화함

가상 머신 통합을 위한 설정 파일에서 중요한 부분은 다음과 같습니다:

meshConfig.proxyMetadata.ISTIO_META_DNS_CAPTURE="true" - DNS 캡처 기능 활성화
values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION="true" - 워크로드 자동등록 활성화
values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_HEALTHCHECKS="true" - 워크로드 상태 체크 활성화

DNS 캡처 설정이 활성화되면 가상 머신에 IP 테이블 규칙이 추가되어 DNS 쿼리 트래픽을 Istio 에이전트의 DNS 프록시가 처리할 수 있게 됩니다.

Istio 컨트롤 플레인과 가상 머신 간의 통신 구성

가상 머신과 Istio 컨트롤 플레인 간의 통신 구성이 필요합니다. VM에 있는 워크로드가 Istio 컨트롤 플레인(istiod)과 통신해야 하지만, 가상 머신은 컨트롤 플레인에 직접 접근할 수 없습니다. 따라서 중간에 East-West 게이트웨이(이스트-웨스트 게이트웨이)를 구성하여 통신을 중계합니다.

East-West 게이트웨이는 다음 두 가지 유형의 트래픽을 처리합니다:

컨트롤 플레인 트래픽: 포트 15012, 15017 등을 통한 istiod와의 통신
데이터 플레인 트래픽: 포트 15443을 통한 mTLS 통신

East-West 게이트웨이는 컨트롤 플레인과 가상 머신 간의 통신을 중계하고, VM에서 서비스 메시 내부로의 트래픽과 서비스 메시에서 VM으로의 트래픽을 처리합니다. 이를 위해 East-West 게이트웨이 파드를 배포하고, 해당 서비스를 LoadBalancer 타입으로 노출시킵니다.

East-West 게이트웨이 설정에 필요한 주요 포트는 다음과 같습니다:

15012: XDS 통신용 (구성 정보 교환)
15017: Webhook 및 검증용
15443: mTLS 데이터 플레인 트래픽용

East-West 게이트웨이 배포 및 구성

East-West 게이트웨이를 배포하기 위해 다음과 같은 설정을 적용합니다:

프로파일: MTA 사용
네트워크: Kubernetes 네트워크는 west-network, VM 네트워크는 vm-network로 레이블링
라우트 모드: 중간 프록시 역할을 위한 설정

East-West 게이트웨이가 배포되면 LoadBalancer 타입의 서비스로 노출되어 고유 IP를 할당받습니다. 실습 환경에서는 K3s의 LoadBalancer 구현을 통해 IP가 할당됩니다.

추가적으로 East-West 게이트웨이를 통한 트래픽 처리를 위해 Gateway 리소스와 VirtualService 리소스를 생성하여 트래픽 라우팅을 구성합니다. 이 Gateway 리소스는 기존 Ingress 게이트웨이가 아닌 East-West 게이트웨이를 선택자로 지정합니다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istiod-gateway
spec:
  selector:
    istio: eastwestgateway
  servers:
  - port:
      number: 15012
      name: tcp-istiod
      protocol: TCP
    hosts:
    - "*"
  - port:
      number: 15017
      name: tcp-istiodwebhook
      protocol: TCP
    hosts:
    - "*"

워크로드 그룹 생성 및 구성

워크로드 그룹(WorkloadGroup)은 Kubernetes의 Deployment와 유사한 개념으로, 가상 머신의 공통 속성을 정의합니다. 동일한 애플리케이션이 실행되는 여러 가상 머신을 그룹화하는 데 사용됩니다.

워크로드 그룹의 주요 구성 요소는 다음과 같습니다:

네임스페이스
라벨: 서비스 선택에 사용
서비스 어카운트: 인증에 사용
네트워크: VM이 속한 네트워크
헬스 체크 설정: 경로, 포트 등

예시 워크로드 그룹 설정:

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
  name: forum
  namespace: forum
spec:
  metadata:
    labels:
      app: forum
  template:
    serviceAccount: forum-sa
    network: vm-network
    readinessProbe:
      httpGet:
        path: /api/healths
        port: 8080

워크로드 그룹을 생성하면, 가상 머신이 자동 등록될 수 있는 템플릿이 준비됩니다. 여기서 설정된 네트워크는 VM 네트워크로, Kubernetes 클러스터의 west-network와 구분됩니다.

VM에 대한 인증 및 구성 파일 생성

가상 머신이 서비스 메시에 참여하려면 적절한 인증서와 설정 파일이 필요합니다. Istio는 이러한 파일들을 자동으로 생성하는 istioctl x workload entry 명령어를 제공합니다.

istioctl x workload entry configure -f forum-workload-group.yaml --clusterID "Kubernetes" --autoregister --output temp/

이 명령어는 다음과 같은 파일들을 생성합니다:

root-cert.pem: 루트 인증서
istio-token: 서비스 어카운트 토큰(JWT 형식)
mesh.yaml: 메시 구성 파일
hosts: DNS 호스트 파일(초기 통신을 위한 호스트 매핑)

이 파일들은 가상 머신에 복사되어 Istio 에이전트 설정에 사용됩니다.

VM에 Istio 에이전트 설치 및 구성

가상 머신에서 Istio 에이전트를 설치하고 구성하는 과정은 다음과 같습니다:

Istio 에이전트 패키지 다운로드 및 설치
curl -LO https://storage.googleapis.com/istio-release/releases/1.17.8/deb/istio-sidecar.deb sudo dpkg -i istio-sidecar.deb
인증서 및 토큰을 위한 디렉토리 생성
sudo mkdir -p /etc/certs sudo mkdir -p /var/run/secrets/tokens
인증서, 토큰 및 설정 파일 복사
sudo cp root-cert.pem /etc/certs/ sudo cp istio-token /var/run/secrets/tokens/istio-token
초기 istiod 통신을 위한 호스트 파일 설정
sudo bash -c 'echo "192.168.10.10 istiod.istio-system.svc" >> /etc/hosts'
파일 권한 설정
sudo chown -R istio-proxy: /etc/certs /var/run/secrets
Istio 서비스 시작
sudo systemctl start istio

Istio 서비스가 시작되면 IP 테이블 규칙이 자동으로 추가되어 DNS 쿼리와 트래픽이 Istio 에이전트에 의해 처리됩니다. 서비스 시작 후에는 로그를 확인하여 정상 동작 여부를 확인할 수 있습니다.

자동 등록 확인 및 워크로드 엔트리 검증

VM에 Istio 에이전트가 설치되고 실행되면, 워크로드 엔트리(WorkloadEntry)가 자동으로 생성됩니다. 이는 다음 명령어로 확인할 수 있습니다:

kubectl get workloadentries -n forum

출력 결과에서 VM의 IP와 자동 생성된 워크로드 엔트리를 확인할 수 있습니다. 워크로드 엔트리에는 VM의 상태 정보도 포함됩니다. 이 때, 헬스 체크에 실패하면 상태는 False로 표시됩니다.

istioctl proxy-status

위 명령어를 실행하면 서비스 메시에 참여한 모든 워크로드(파드 및 VM)가 표시되어 VM 워크로드가 서비스 메시에 성공적으로 통합되었는지 확인할 수 있습니다.

DNS 해석 동작 검증

가상 머신에서 DNS 해석이 올바르게 작동하는지 확인하기 위해 다음과 같은 테스트를 수행할 수 있습니다:

패킷 캡처 도구를 이용한 DNS 트래픽 모니터링
sudo tcpdump -i any udp port 53 | tshark -i - -Y "dns"
서비스 메시 내부의 서비스에 대한 DNS 쿼리 시도
nslookup webapp.istio-injection.svc.cluster.local
결과 확인
쿼리 결과로 서비스의 클러스터 IP가 반환되는 것을 확인할 수 있습니다. 이는 Istio DNS 프록시가 쿼리를 가로채 istiod와 CoreDNS를 통해 올바른 응답을 제공했음을 의미합니다.

DNS 프록시가 동작하는 순서는 다음과 같습니다:

VM에서 발생한 DNS 쿼리를 IP 테이블 규칙이 가로챔
가로챈 쿼리를 istiod를 통해 CoreDNS로 전달
응답을 받아 VM에 전달하고 캐싱
이후 동일한 쿼리에 대해서는 캐시된 응답 제공

서비스 메시와 VM 간의 통신 검증

VM과 서비스 메시 간의 양방향 통신을 검증하는 두 가지 시나리오를 테스트합니다:

VM에서 서비스 메시 내부 서비스로의 접근

VM에서 curl 명령을 사용하여 webapp 서비스에 접근합니다:

curl webapp.istio-injection.svc.cluster.local

이 요청은 다음과 같은 경로로 처리됩니다:

VM의 Istio 에이전트(Envoy)가 요청을 가로챔
East-West 게이트웨이로 전달
East-West 게이트웨이가 webapp 서비스로 라우팅
응답이 역경로로 반환

Kiali 대시보드에서 이러한 트래픽 흐름을 시각적으로 확인할 수 있습니다.

서비스 메시에서 VM 서비스로의 접근

서비스 메시 내부에서 VM에 배포된 서비스에 접근하기 위해 Kubernetes 서비스를 생성합니다:

apiVersion: v1
kind: Service
metadata:
  name: forum
  namespace: forum
spec:
  ports:
  - port: 8080
    name: http
  selector:
    app: forum

이 서비스는 WorkloadEntry에서 정의된 라벨과 일치하는 선택자를 사용합니다. 서비스 메시 내부 애플리케이션(예: webapp)에서 이 서비스를 통해 VM의 포럼 애플리케이션에 접근할 수 있습니다.

그러나 처음에는 VM에서 포럼 서비스가 실행되지 않고 있어 헬스 체크에 실패하고 엔드포인트가 나타나지 않습니다. VM에서 포럼 서비스를 시작하면:

./forum

포럼 서비스가 시작되고 8080 포트에서 수신 대기하며, 헬스 체크 엔드포인트(/api/healths)가 정상 응답을 반환합니다. 이후 WorkloadEntry의 상태가 Healthy로 변경되고, 서비스 엔드포인트에 VM이 추가됩니다.

브라우저나 curl을 통해 webapp 서비스에 접근하면 webapp이 forum 서비스에 API 요청을 보내 사용자 정보를 가져오는 것을 확인할 수 있습니다.

보안 정책 적용

Istio 서비스 메시의 주요 이점 중 하나는 통합된 보안 정책을 VM 워크로드에도 적용할 수 있다는 점입니다. 예를 들어, mTLS 인증을 강제하는 PeerAuthentication 정책을 적용할 수 있습니다:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: forum
spec:
  mtls:
    mode: STRICT

이 정책이 적용되면 다음과 같은 결과가 나타납니다:

VM에 직접 접근하는 외부 요청은 mTLS 인증 없이 접근하므로 거부됨
서비스 메시 내부에서는 자동 mTLS를 통해 VM 서비스에 계속 접근 가능
외부에서 Ingress 게이트웨이를 통해 접근하는 경우 게이트웨이와 VM 사이에 mTLS가 적용되어 정상 접근 가능

이렇게 Istio의 보안 정책을 VM 워크로드까지 확장하여 일관된 보안 규칙을 적용할 수 있습니다.

DNS 질의 처리 과정 분석

가상 머신 내의 워크로드가 webapp.istio-injection 같은 도메인에 대해 질의할 때 처리 과정을 분석해보겠습니다:

클라이언트가 webapp.istio-injection 도메인의 IP를 알아내기 위해 DNS 쿼리를 생성합니다.
운영체제는 먼저 /etc/hosts 파일에서 해당 도메인이 있는지 확인합니다.
/etc/hosts에 없는 경우, 원래는 시스템 리졸버(resolver)에게 처리를 요청해야 하지만, IP 테이블 규칙에 의해 이 요청이 리다이렉션됩니다.
이 요청은 Istio 에이전트의 DNS 프록시로 가로채져 전달됩니다.
Istio 에이전트는 East-West 게이트웨이를 통해 Kubernetes 클러스터의 CoreDNS에 쿼리를 전달합니다.
응답이 캐시되고 클라이언트에게 반환됩니다.

DNS 쿼리 테스트 및 분석

dig 명령어를 사용하여 DNS 쿼리 동작 테스트:

$ dig @127.0.0.1 -p 15053 webapp.istio-injection.svc.cluster.local

정상적으로 응답을 반환하고, 이와 유사하게 catalog나 forum 같이 서비스 메시에 등록된 다른 서비스에 대한 쿼리도 응답을 받을 수 있습니다.

그러나 서비스 메시와 관련 없는 외부 도메인(예: daum.net, naver.com)에 대한 쿼리는 어떻게 처리될까? DNS 프록시는 이러한 도메인에 대해서는 관심이 없으므로 처리하지 않습니다. 대신, 운영체제에 설정된 기본 네임서버(예: AWS VPC가 제공하는 네임서버)로 쿼리를 전달합니다. 이를 "폴백(fallback)"이라고 합니다.

폴백 메커니즘은 DNS 프록시가 서비스 메시 내부 도메인만 처리하고 외부 도메인은 운영체제에 구성된 표준 DNS 리졸버가 처리하도록 합니다.

CoreDNS 로그 분석

CoreDNS의 로그를 확인하여 DNS 프록시가 어떤 쿼리를 전달하는지 볼 수 있습니다. CoreDNS 설정을 편집하여 로깅을 활성화할 수 있습니다:

$ kubectl -n kube-system edit configmap coredns

CoreDNS의 ConfigMap에 로그 지시문을 추가하고 변경사항이 적용될 때까지 기다립니다. 이제 서비스 메시 관련 도메인에 대한 DNS 쿼리가 CoreDNS 로그에 나타나는 것을 확인할 수 있습니다.

참고로, CoreDNS의 레이블이 여전히 k8s-app: kube-dns로 되어 있는데, 이는 이전 이름(KubeDNS)이 레이블에 유지되고 있기 때문입니다.

NDS(Name Discovery Service) 쿼리 확인

Istio는 DNS 프록시가 인식하는 호스트네임을 확인하기 위한 NDS(Name Discovery Service) API를 제공합니다. 이 정보는 디버그 엔드포인트를 통해 확인할 수 있습니다:

$ curl localhost:8080/debug/ndsz?proxyID=forum-vm

이 명령은 Forum VM에 대한 NDS 설정을 반환합니다. 결과에는 서비스 메시 내의 모든 서비스에 대한 도메인 정보가 포함됩니다. 여기에는 FQDN(Fully Qualified Domain Name), 짧은 이름, 네임스페이스를 포함한 이름, 서비스 클러스터 IP 등 다양한 형식의 도메인 이름이 포함됩니다.

라우터 설정에서도 이러한 도메인 변형을 확인할 수 있습니다:

$ istioctl proxy-config route <pod-name>.<namespace>

여기서는 FQDN, 짧은 이름, 네임스페이스를 포함한 이름, 서비스 클러스터 IP 이름 등 다양한 형식의 도메인 이름이 표시됩니다.

DNS 프록시 동작 커스터마이즈

DNS 프록시의 동작을 사용자 지정하려면 /var/lib/istio/envoy/sidecar.env 파일을 편집합니다. 기본적으로 이 파일은 모든 줄이 주석 처리되어 있습니다.

로깅 레벨을 변경하거나 인증서 수명을 조정하는 등의 설정을 추가할 수 있습니다:

ISTIO_META_DNS_CAPTURE_LOGGING=debug
CITADEL_SECRET_TTL=12h

변경 후 Istio 서비스를 재시작합니다:

$ sudo systemctl restart istio

이제 DNS 프록시가 디버그 로그를 생성합니다. DNS 쿼리를 시도하면 상세한 로그를 볼 수 있습니다. 예를 들어, 서비스 메시에 없는 도메인(abc.com)에 대한 쿼리는 DNS 프록시가 발견하지 못하고 업스트림(외부 DNS 서버)으로 전달했다는 로그 메시지가 표시됩니다.

워크로드 자동 제거

가상 머신이 종료되면 워크로드 엔트리(WorkloadEntry)가 자동으로 제거됩니다. 이를 테스트하기 위해 Forum VM을 강제로 종료해 볼 수 있습니다:

$ aws ec2 terminate-instances --instance-ids <instance-id>

VM이 종료된 후, 워크로드 엔트리 리소스를 모니터링하면 헬스 체크 실패 후 리소스가 자동으로 제거되는 것을 확인할 수 있습니다. 이는 클라우드 네이티브 환경에서 자동 등록뿐만 아니라 자동 해제도 중요하다는 것을 보여줍니다.

파드와 가상 머신 구현 비교

책에는 Istio 서비스 메시에서 Kubernetes 파드와 가상 머신의 구현 차이점에 대한 비교 내용도 포함되어 있습니다. 이 부분은 각자 읽어보시는 것이 좋습니다.

실제 운영 환경에서는 여기서 수동으로 수행한 가상 머신 설정 작업들을 Ansible, Terraform 등의 자동화 도구를 사용하여 자동화하는 것이 권장됩니다. 파일 복사, 설정 변경 등의 작업은 모두 자동화될 수 있습니다.

책에 언급된 내용과는 달리, 가상 머신 지원 기능이 이제 베타 단계에서 코어(정식) 버전으로 승격되었습니다. 따라서 이제 이 기능을 보다 안정적으로 사용할 수 있습니다.

Istio 사이드카 프록시 기반 트래픽 흐름

Istio의 통신 메커니즘은 복잡한 IP 테이블 규칙과 사이드카 프록시(Envoy)를 통해 이루어집니다. 워커노드에서 파드로 들어오는 트래픽과 파드에서 외부로 나가는 트래픽이 모두 Envoy 프록시를 경유하도록 합니다.

일반적인 Kubernetes 환경에서는 트래픽이 이더넷 인터페이스로 직접 애플리케이션 컨테이너에 도달하지만, Istio를 사용할 때는 다음과 같은 경로를 거칩니다:

외부 트래픽이 노드로 들어옴
IP 테이블 규칙에 의해 트래픽이 Envoy 프록시로 리다이렉션됨
Envoy가 트래픽을 처리한 후 애플리케이션 컨테이너로 전달
응답도 마찬가지로 Envoy를 거쳐 외부로 전달

외부에서 파드로 들어오는 트래픽 흐름

외부 클라이언트가 Ingress Gateway를 통해 서비스에 접근할 때 트래픽 흐름은 다음과 같습니다:

클라이언트(소스 IP: 192.168.10.254)가 외부 공개 IP로 HTTP 요청을 보냄
Ingress Gateway가 요청을 받고, 소스 IP를 변경하여 파드 IP(예: 172.16.43.11:8080)로 전달
IP 테이블 규칙에 의한 리다이렉션: 파드에 도달한 트래픽은 IP 테이블 규칙에 의해 대상 포트가 15006으로 변경되어 Envoy 프록시로 리다이렉션됨
소스 IP 변환: Envoy는 애플리케이션 컨테이너에 요청을 전달할 때 소스 IP를 127.0.0.1(루프백)으로 변경
- 이는 같은 파드 내에서 동일한 IP를 사용하는 문제를 방지하기 위함
- 원래 클라이언트 IP는 "X-Forwarded-For" HTTP 헤더에 보존됨
애플리케이션이 응답을 생성하면 대상 IP가 127.0.0.1인 응답이 다시 Envoy로 전달
Envoy는 이 응답을 처리하여 다시 클라이언트에게 전달

이 과정에서 IP 테이블의 다양한 체인(PREROUTING, ISTIO_INBOUND, ISTIO_IN_REDIRECT 등)이 단계별로 적용됩니다.

파드에서 외부로 나가는 트래픽 흐름

파드 내 애플리케이션이 외부 서비스(예: 보안 패치 다운로드)에 접근할 때 트래픽 흐름은 다음과 같습니다:

애플리케이션이 외부 서비스(예: IP 37.x.x.x:80)로 요청 시작
아웃바운드 리다이렉션: IP 테이블 규칙에 의해 목적지 IP와 포트가 127.0.0.1:15001로 변경됨
- 127.0.0.1:15006은 인바운드 트래픽용, 127.0.0.1:15001은 아웃바운드 트래픽용
Envoy가 요청을 가로채서 처리한 후 실제 외부 서비스로 전달
응답이 돌아오면 다시 Envoy를 통해 애플리케이션으로 전달

IP 테이블 체인과 사용자 ID 기반 트래픽 구분

파드 내에서 애플리케이션과 Envoy 프록시는 동일한 네트워크 네임스페이스를 공유하므로, 하나의 IP 테이블 규칙 세트만 사용할 수 있습니다. 이로 인해 복잡성이 증가합니다:

애플리케이션과 Envoy 모두 OUTPUT 체인을 사용해야 함
누가 패킷을 생성했는지 구분하기 위해 사용자 ID(UID)를 활용
- Envoy 프록시는 UID 1337을 사용
- 따라서 공식 문서에서는 애플리케이션이 UID 1337을 사용하지 말 것을 권장

예를 들어, 아웃바운드 트래픽에서:

애플리케이션이 생성한 패킷: OUTPUT 체인 → ISTIO_OUTPUT 체인 → 15001 포트로 리다이렉션
Envoy가 생성한 패킷: OUTPUT 체인 → UID 1337 매치 → 리다이렉션 없이 바로 외부로 전달

트래픽 경로 상세 분석

전체적인 트래픽 경로를 단계별로 분석하면:

인바운드(외부→파드) 트래픽:

PREROUTING 체인
ISTIO_INBOUND 체인
ISTIO_IN_REDIRECT 체인 (포트 15006으로 리다이렉션)
Envoy 프록시가 수신
OUTPUT 체인 (127.0.0.1 소스로 애플리케이션에 전달)
애플리케이션 처리
응답 생성 (대상 127.0.0.1)
다시 Envoy가 수신하여 처리
최종적으로 클라이언트에게 전달

아웃바운드(파드→외부) 트래픽:

OUTPUT 체인
ISTIO_OUTPUT 체인
127.0.0.1:15001로 리다이렉션
Envoy 프록시가 수신
Envoy가 실제 대상으로 포워딩 (이때 UID 1337로 패킷 생성)
다시 OUTPUT 체인을 타지만 UID 1337 확인으로 리다이렉션 없이 진행
외부로 패킷 전달
응답은 역순으로 진행

IP 테이블 규칙 예시

Istio의 초기화 컨테이너(Init Container)는 파드 생성 시 다음과 같은 IP 테이블 규칙을 설정합니다:

# 인바운드 트래픽 리다이렉션
iptables -t nat -A PREROUTING -p tcp -j ISTIO_INBOUND
iptables -t nat -A ISTIO_INBOUND -p tcp -j ISTIO_IN_REDIRECT
iptables -t nat -A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-port 15006

# 아웃바운드 트래픽 리다이렉션
iptables -t nat -A OUTPUT -p tcp -j ISTIO_OUTPUT
iptables -t nat -A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ISTIO_REDIRECT
iptables -t nat -A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN
iptables -t nat -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-port 15001

이러한 규칙을 통해 사이드카 프록시가 모든 트래픽을 가로채고 제어할 수 있게 됩니다.

테스트 및 디버깅 방법

IP 테이블 규칙과 트래픽 흐름을 확인하는 방법으로는 다음과 같은 도구와 명령어가 유용합니다:

iptables -t nat -L -v: IP 테이블 규칙 확인
tcpdump: 패킷 캡처 및 분석
ss 또는 netstat: 소켓 연결 정보 확인
ip link 및 ip addr: 네트워크 인터페이스 확인

이러한 도구들을 활용하여 트래픽이 어떤 경로로 흐르는지, IP 테이블 규칙이 어떻게 적용되는지 확인할 수 있습니다.

성능 영향 고려사항

Istio 사이드카 프록시를 통한 트래픽 리다이렉션은 추가적인 네트워크 홉과 처리 과정을 필요로 하므로, 일정 수준의 지연과 오버헤드가 발생합니다. 극한의 성능이 요구되는 환경에서는 이러한 오버헤드를 고려해야 합니다.

그러나 Istio가 제공하는 다양한 기능(트래픽 관리, 보안, 모니터링 등)의 이점이 이러한 오버헤드를 상쇄할 만큼 가치가 있는지 평가해야 합니다.

'Work > 개발 노트' 카테고리의 다른 글

[Istio 스터디] 9주차 - Ambient Mesh (3)	2025.06.08
[istio 스터디] 6주차 - 운영 및 트러블슈팅 (0)	2025.05.17
[istio 스터디] 5주차 - 마이크로서비스 통신 보안 (0)	2025.05.11
[istio study] 4주차 - Observability (0)	2025.05.03
[Istio 스터디] 2주차 - Envoy, Istio Gateway (0)	2025.04.19