[8주차] 가상 머신 워크로드를 Mesh 에 통합 : Istio의 VM 지원

구구달스 2025. 5. 26. 10:05

CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

🚀 Istio로 VM과 컨테이너를 연결하는 방법

🖥️ 왜 모든 워크로드를 Kubernetes로 옮기지 않을까?

Kubernetes 클러스터에서 모든 워크로드를 실행하는 것이 이상적이지만, 현실적으로는 몇 가지 제약 때문에 VM에서 실행해야 하는 경우가 있습니다.
- 규제 준수와 온프레미스 요구사항
  일부 기업은 데이터 보안이나 규제 준수 때문에 워크로드를 온프레미스 환경에서 실행해야 합니다. 하지만 Kubernetes 클러스터를 설정하고 운영할 전문 지식이 부족할 수 있습니다.
- 컨테이너화의 복잡성
  애플리케이션을 컨테이너화하려면 종종 재설계가 필요합니다. 일부 앱은 의존성 충돌(dependency hell)이나 업데이트가 어려운 레거시 의존성을 가지고 있어 컨테이너화가 쉽지 않습니다.
- VM에 특화된 의존성
  특정 워크로드는 VM 환경에 맞춰 설계되어 있어, 이를 컨테이너로 옮기면 성능이나 기능에 문제가 생길 수 있습니다.

모든 워크로드를 Kubernetes로 옮기는 것은 비용, 기술, 규제 등의 이유로
불가능하거나 비효율적일 수 있습니다.

🔗 Istio로 VM 워크로드를 서비스 메시에 통합하기

Istio는 VM 워크로드를 서비스 메시에 통합하기 위해 sidecar proxy를 설치하고 구성하는 방법을 제공합니다.
이를 통해 레거시 워크로드도 서비스 메시의 이점을 누릴 수 있습니다.
- 보안 강화: mTLS를 통한 안전한 통신
- 가용성 향상: 트래픽 관리와 장애 복구
- 관찰 가능성: 메트릭, 로그, 추적을 통한 모니터링

VM에 sidecar proxy를 설치하면
레거시 워크로드도 Istio 서비스 메시의 보안, 가용성, 관찰 가능성을 활용할 수 있습니다.

🌟 기업에 주는 이점

레거시 워크로드를 Istio 서비스 메시에 통합하면 기업은 다음과 같은 이점을 얻을 수 있습니다:
- 유연성: 컨테이너와 VM 워크로드를 동일한 네트워크에서 관리
- 비용 절감: 전체 시스템을 컨테이너화하지 않고도 현대화 가능
- 안정성: 트래픽 관리와 보안을 통해 서비스 안정성 향상
이 접근법은 특히 레거시 시스템이 많은 대기업에서 유용합니다. 기존 VM 워크로드를 유지하면서도 최신 네트워킹 기술을 도입할 수 있기 때문입니다.

Istio를 사용하면 레거시 워크로드를 현대화된 네트워크에 통합하여
비용과 안정성을 동시에 개선할 수 있습니다.

📌 핵심 요약

Istio 서비스 메시는 컨테이너뿐만 아니라 VM 워크로드도 통합할 수 있습니다.
규제, 의존성, 컨테이너화의 복잡성 때문에 모든 워크로드를 Kubernetes로 옮기기 어려운 경우가 있습니다.
VM에 sidecar proxy를 설치하면 보안, 가용성, 관찰 가능성을 강화할 수 있습니다.
이 접근법은 레거시 시스템을 유지하면서도 네트워크를 현대화하려는 기업에 유용합니다.

🚀 Istio의 VM 지원 기능 이해하기

🛠️ Istio VM 지원의 주요 기능

Istio 1.9.0에서는 VM을 서비스 메시에 통합하기 위한 세 가지 핵심 기능이 도입되었습니다:
- 간소화된 Sidecar Proxy 설치
  istioctl 명령어를 사용해 VM에 sidecar proxy를 쉽게 설치하고 구성할 수 있습니다.
- 고가용성 보장
  새로운 Istio 리소스인 WorkloadGroup과 WorkloadEntry를 통해 VM의 고가용성을 지원합니다.
- DNS Resolution
  VM에서 서비스 메시 내 서비스를 찾을 수 있도록 로컬 DNS proxy를 sidecar와 함께 설정합니다.
이 기능들은 VM 워크로드를 Kubernetes 워크로드처럼 서비스 메시에 자연스럽게 통합할 수 있게 해줍니다.

Istio는 sidecar proxy, WorkloadGroup, WorkloadEntry, DNS proxy를 통해
VM 통합을 간소화하고 고가용성을 제공합니다.

🔧 VM에서 Sidecar Proxy 설치 및 구성

VM을 서비스 메시에 통합하려면 VM이 메시의 일원이 되도록 설정해야 합니다. 이를 위해 다음 세 가지 단계가 필요합니다:
- Sidecar Proxy 설치
  VM에 Istio의 sidecar proxy를 설치하여 네트워크 트래픽을 관리합니다.
- Istiod와 연결 구성
  Sidecar proxy가 Istio의 control plane인 istiod와 통신하도록 설정합니다.
- Identity Token 제공
  VM에 인증을 위한 identity token을 제공하여 istiod와 안전하게 통신할 수 있도록 합니다.

설치 명령어 예시

# Istio sidecar proxy 설치
istioctl install --set profile=minimal
# VM 워크로드 등록
istioctl x workload entry configure -f workload.yaml

Kubernetes에서는 webhook이나 istioctl을 통해 sidecar proxy와 identity token이 자동으로 주입되지만, VM에서는 이를 수동으로 설정해야 합니다. 이 과정은 다소 번거로울 수 있지만, Istio의 VM 지원 기능 덕분에 훨씬 간단해졌습니다.

VM은 sidecar proxy 설치와 identity token을 통해 서비스 메시의 일원이 되며,
istioctl로 이 과정을 간소화할 수 있습니다.

🛡️ VM의 Identity Provisioning

Istio는 Kubernetes를 신뢰의 근원(source of trust)으로 사용하여 VM의 identity를 제공합니다. 이 과정은 다음과 같이 진행됩니다:
- Kubernetes에서 Token 생성
  Kubernetes에서 service account token을 생성합니다.
- Token을 VM으로 전달
  생성된 token을 VM으로 안전하게 전달합니다.
- Istio-Agent가 Token 사용
  VM에 설치된 istio-agent가 이 token을 사용하여 istiod에 인증하고, SPIFFE Verifiable Identity Document(SVID)를 발급받습니다.

Kubernetes와 VM의 차이점

Kubernetes 워크로드: Pod에 service account token이 자동으로 주입됩니다.

VM 워크로드: Service mesh 운영자가 token을 수동으로 생성하고 VM에 전달해야 합니다.

코드 예시: VM에 Token 전달

# Kubernetes에서 service account 생성
kubectl create sa vm-workload
# Token 생성 및 VM으로 전달 (예시)
kubectl create token vm-workload > vm-token.txt
# VM에서 istio-agent 실행
istio-agent --token-file vm-token.txt

이 과정은 수동으로 진행되므로, 특히 multi-cloud 환경에서는 추가적인 자동화가 필요할 수 있습니다.

VM은 Kubernetes에서 생성된 token을 통해 identity를 인증받으며,
이 과정은 수동으로 진행됩니다.

☁️ 향후 개선: Platform-Assigned Identity

Istio 커뮤니티는 VM의 identity provisioning을 자동화하기 위해 platform-assigned identity를 사용하는 솔루션을 개발 중입니다. 이 솔루션은 다음과 같이 동작할 예정입니다:
- VM의 클라우드 제공자에서 제공하는 identity를 신뢰의 근원으로 사용.
- istio-agent가 이 identity를 istiod에 전달하여 인증.
- Istio는 클라우드 제공자의 token 검증을 위한 API를 제공.
이 기능은 아직 개발 중이며, 자세한 내용은 Istio의 디자인 문서(http://mng.bz/zQGa)에서 확인할 수 있습니다.

Platform-assigned identity는 VM의 identity provisioning을 자동화하여
multi-cloud 환경에서의 관리를 간소화할 것입니다.

📌 핵심 요약

Istio 1.9.0부터 VM 지원이 beta로 졸업하며 sidecar proxy 설치, WorkloadGroup, WorkloadEntry, DNS proxy를 통해 VM 통합이 간소화되었습니다.
VM은 sidecar proxy 설치, istiod 연결, identity token을 통해 서비스 메시의 일원이 됩니다.
Kubernetes는 token을 자동 주입하지만, VM은 수동으로 token을 생성하고 전달해야 합니다.
향후 platform-assigned identity를 통해 VM의 identity provisioning이 자동화될 예정입니다.

🚀 Istio로 VM의 고가용성 보장하기

🛠️ Istio의 VM 고가용성 전략

Kubernetes는 Deployments와 Pods를 사용해 컨테이너 워크로드의 고가용성을 구현합니다.
Istio는 VM에 비슷한 개념을 적용하여 고가용성을 달성합니다:
- WorkloadGroup
  Kubernetes의 Deployments와 유사하며, 워크로드의 템플릿을 정의합니다.
  애플리케이션 포트, 라벨, service account, 건강 상태 프로브(health probe) 등의 속성을 지정합니다.
- WorkloadEntry
  Kubernetes의 Pods와 유사하며, 단일 VM을 나타냅니다.
  WorkloadGroup에서 정의한 공통 속성 외에 VM의 주소, 건강 상태 등의 고유 속성을 포함합니다.
이 리소스들은 VM을 서비스 메시의 일원으로 관리하며, 장애 발생 시 워크로드를 교체하거나 확장할 수 있게 합니다.

WorkloadGroup과 WorkloadEntry는
VM 워크로드를 Kubernetes처럼 관리하여 고가용성을 보장합니다.

🔄 Workload Auto-Registration 이해하기

VM을 수동으로 서비스 메시에 추가할 수도 있지만, Istio는 workload auto-registration을 통해 이 과정을 자동화합니다.
이 기능은 새로 프로비저닝된 VM이 자동으로 서비스 메시에 참여하도록 돕습니다.

Auto-Registration 과정

VM이 istiod(Istio control plane)에 연결합니다.
VM은 identity token을 사용해 WorkloadGroup의 일원임을 인증합니다.
인증이 완료되면 istiod가 VM을 나타내는 WorkloadEntry를 자동으로 생성합니다.

# WorkloadGroup 예시
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
  name: example-wg
  namespace: default
spec:
  template:
    ports:
      http: 8080
    serviceAccount: example-sa
  probe:
    httpGet:
      path: /health
      port: 8080

WorkloadEntry는 Kubernetes 서비스나 Istio ServiceEntry의 label selector를 통해 트래픽 라우팅의 백엔드로 사용됩니다. 이를 통해 VM의 실제 주소를 사용하지 않고 FQDN(fully qualified domain name)을 활용해 워크로드를 관리할 수 있습니다. 이는 워크로드 교체 또는 확장 시 클라이언트에 영향을 주지 않습니다.

Workload auto-registration은
VM을 자동으로 서비스 메시에 통합하여 관리와 확장을 간소화합니다.

🌐 서비스와 워크로드 통합

Istio는 Kubernetes 서비스를 통해 WorkloadEntry와 Pods를 통합적으로 관리할 수 있습니다. 이는 특히 레거시 VM 워크로드를 Kubernetes 기반의 현대화된 워크로드로 마이그레이션할 때 유용합니다.

트래픽 전환 예시

VM과 Kubernetes 워크로드를 병렬로 실행한 후, Istio의 traffic shifting 기능을 사용해 트래픽을 점진적으로 VM에서 Pod로 이동할 수 있습니다. 오류가 발생하면 트래픽을 VM으로 다시 전환할 수도 있습니다.

# VirtualService로 트래픽 전환 설정
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-service
spec:
  hosts:
  - example-service.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: example-service
        subset: vm
      weight: 20
    - destination:
        host: example-service
        subset: pod
      weight: 80

Istio는 VM과 Pod 간 트래픽을 유연하게 관리하여
마이그레이션의 안정성을 높입니다.

🩺 Istio의 Health Check

서비스 메시에서 워크로드는 트래픽을 받을 준비가 되었는지, 그리고 실행 중에 건강한지를 확인해야 합니다.
Istio는 두 가지 health check를 사용합니다:
- Readiness Probes
  워크로드가 트래픽을 받을 준비가 되었는지 확인합니다.
  WorkloadGroup에 정의된 설정에 따라 istio-agent가 주기적으로 체크합니다.
- Liveness Probes
  워크로드가 정상적으로 실행 중인지 확인합니다.
  이는 서비스 메시가 아니라 VM을 실행하는 플랫폼(예: 클라우드 제공자)의 역할입니다.

Readiness Probe 설정 예시

# WorkloadGroup에 readiness probe 설정
spec:
  probe:
    httpGet:
      path: /health
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10

클라우드 제공자의 Liveness Probe

Azure: VM scale sets의 자동 복구(http://mng.bz/0wrx)
AWS: Auto Scaling 그룹의 health check(http://mng.bz/KB4K)
Google Cloud: Managed instance groups의 auto-healing(http://mng.bz/9KNl)

Istio의 readiness probe는 적극적으로 설정하여 오류를 빠르게 감지하고, 클라우드 제공자의 liveness probe는 보수적으로 설정하여 VM이 복구할 시간을 확보하는 것이 좋습니다. 이를 통해 진행 중인 요청이 갑작스럽게 종료되는 것을 방지할 수 있습니다.

Readiness probe는 Istio가, liveness probe는 클라우드 플랫폼이 관리하며,
적절한 설정으로 안정성을 유지합니다.

📌 핵심 요약

Istio는 WorkloadGroup과 WorkloadEntry를 사용해 VM 워크로드의 고가용성을 보장합니다.
Workload auto-registration은 VM을 자동으로 서비스 메시에 통합하여 관리를 간소화합니다.
Kubernetes 서비스와 traffic shifting을 활용해 VM과 Pod 간 트래픽을 유연하게 관리할 수 있습니다.
Readiness probe는 Istio가, liveness probe는 클라우드 플랫폼이 관리하며, 적절한 설정으로 서비스 안정성을 높입니다.

🌐 Istio에서 VM의 DNS Resolution

❓ 왜 DNS Resolution이 필요한가?

서비스 메시에서 sidecar proxy(Envoy)는 트래픽 라우팅을 위한 모든 설정을 가지고 있습니다. 하지만 애플리케이션에서 트래픽이 proxy로 전달되려면 먼저 hostname이 IP 주소로 변환되어야 합니다.
VM에서 DNS resolution이 실패하면 트래픽이 애플리케이션을 떠나지 못하고 Envoy proxy에 도달하지 않습니다.
이 문제를 해결하기 위해 과거에는 private DNS 서버를 설정하고, Kubernetes 서비스를 동기화하는 방식이 사용되었습니다. 예를 들어, 오픈소스 프로젝트인 external-dns는 Kubernetes 컨트롤러를 통해 DNS 서버를 자동으로 업데이트합니다. 하지만 이는 워크어라운드일 뿐, 서비스 메시 사용자에게 통합된 솔루션이 아니었습니다.

DNS resolution이 없으면 VM의 트래픽이 Envoy proxy로 전달되지 않으며,
private DNS 서버는 임시 해결책에 불과합니다.

🔧 Istio의 Local DNS Proxy

Istio 1.8부터 VM의 DNS resolution 문제를 해결하기 위해 local DNS proxy가 istio-agent sidecar에 도입되었습니다. 이 DNS proxy는 Envoy proxy와 함께 실행되며, 애플리케이션의 DNS 쿼리를 처리합니다.

Local DNS Proxy 동작 방식

애플리케이션에서 DNS 쿼리가 발생하면, Iptable 규칙을 통해 DNS proxy로 리디렉션됩니다.
(Istio의 일반적인 트래픽 캡처 방식이며, istio-cni 사용 시 약간 다를 수 있습니다.)
DNS proxy는 istiod로부터 서비스 메시 내 모든 서비스 정보를 받아 쿼리를 처리합니다.
처리된 DNS 응답은 애플리케이션으로 반환되어 트래픽이 Envoy proxy로 전달됩니다.

설정 예시

DNS proxy는 별도의 구성 없이 istio-agent에 자동으로 포함됩니다.
다음은 VM에서 Istio sidecar를 설치하는 기본 명령어입니다:

# VM에 Istio sidecar 설치 (DNS proxy 포함)
istioctl install --set profile=minimal
# VM 워크로드 등록
istioctl x workload entry configure -f workload.yaml

Local DNS proxy는 VM에서 DNS 쿼리를 처리하여
애플리케이션 트래픽을 서비스 메시로 연결합니다.

🔄 Name Discovery Service (NDS)

DNS proxy가 최신 서비스 정보를 유지하려면 Kubernetes 서비스나 Istio ServiceEntry의 변경 사항을 실시간으로 반영해야 합니다. 이를 위해 Istio는 Name Discovery Service (NDS) API를 도입했습니다.

NDS의 역할

istiod는 NDS를 통해 DNS proxy에 새로운 DNS 항목을 동기화합니다.
Kubernetes 서비스나 ServiceEntry가 추가되거나 변경될 때 DNS proxy가 즉시 업데이트됩니다.
NDS는 VM뿐만 아니라 다른 기능도 지원합니다. 자세한 내용은 Istio 공식 블로그(https://istio.io/latest/blog/2020/dns-proxy)에서 확인할 수 있습니다.

NDS는 DNS proxy를 최신 상태로 유지하여
서비스 메시 내 서비스의 동적 변화를 반영합니다.

📌 핵심 요약

VM은 Kubernetes 클러스터 내부 DNS에 접근할 수 없으므로 DNS resolution이 필요합니다.
DNS resolution이 실패하면 애플리케이션 트래픽이 Envoy proxy로 전달되지 않습니다.
Istio 1.8부터 도입된 local DNS proxy는 VM에서 DNS 쿼리를 처리하며, Iptable을 통해 트래픽을 리디렉션합니다.
Name Discovery Service (NDS)는 DNS proxy를 최신 서비스 정보로 동기화하여 동적 환경을 지원합니다.

저작자표시 (새창열림)