chap13. 가상머신 워크로드를 메시에 통합하기

• 현실적인 워크로드 환경
  • 실제 워크로드는 자주 가상머신이나 물리 머신에서 실행됨
  • 컨테이너와 쿠버네티스는 기술 스택 현대화 노력의 일환으로 사용
• 가상머신 통합의 필요성
  • 레거시 워크로드를 단순히 쿠버네티스로 현대화하는 것이 항상 가능하지 않음
  • 비용을 고려했을 때 불가능에 가까운 경우 존재
• 쿠버네티스 현대화의 제약사항
  • 규제 준수로 인해 온프레미스에서 워크로드 실행 필요
  • 쿠버네티스 클러스터 설정 및 운영 전문 지식 부족
  • 애플리케이션 컨테이너화의 복잡성
• 애플리케이션 컨테이너화의 어려움
  • 애플리케이션 재설계 필요한 경우 존재
  • 의존성 충돌 문제 (의존성 지옥)
  • 실행 중인 가상머신에 고유한 의존성 존재
• 해결 방안
  • 사이드카 프록시 설치 및 설정을 통해 어떤 워크로드든 메시의 일부로 포함 가능
  • 레거시 워크로드를 복원력 있고 안전하고 고가용성적인 방식으로 메시 통합
• 엔터프라이즈에 제공하는 가치
  • 레거시 워크로드 보유 기업에게 흥미로운 기능 제공
  • 애플리케이션 네트워크 계층에서 이스티오로 두 세계 연결

이스티오의 가상머신 지원

• 가상머신 지원 발전 과정
  • 이스티오 초기부터 가상머신 메시 통합 지원
  • 제어 평면 외부에서 많은 해결책과 자동화 필요했음
  • 이스티오 1.9.0에서 베타로 승격
  • 핵심 기능 구현 및 적절한 API 접근법 결정
• 핵심 기능들
  • 가상머신에서 사이드카 프록시 설치 및 설정 (istioctl로 간소화)
  • 가상머신의 고가용성 (WorkloadGroup, WorkloadEntry 리소스 도입)
  • 가상머신에서 메시 내 서비스의 DNS 해석 (로컬 DNS 프록시 사용)
• 접근 방식
  • 새 기능들을 고수준에서 다루는 것부터 시작
  • 가상머신을 메시에 통합하는 구체적인 예제로 실습 진행

가상머신에서의 사이드카 프록시 설치 및 설정 단순화하기

• 가상머신이 메시 일부가 되기 위한 요구사항
  • 네트워크 트래픽 관리할 사이드카 프록시 설치
  • 프록시가 istiod에 연결해 메시 설정을 받도록 설정
  • istiod 인증용 ID 토큰을 가상머신에 제공
• 쿠버네티스 워크로드와의 비교
  • 쿠버네티스: 웹훅이나 istioctl로 사이드카 자동 설치/설정
  • 쿠버네티스: ID 토큰을 파드에 자동 주입
  • 가상머신: 이런 편의성이 확장되지 않음
• 가상머신 설정 과정
  • VM 소유자가 직접 프록시 설치 및 설정 필요
  • 워크로드 ID용 부트스트랩 토큰 제공 필요
  • 이후에야 워크로드가 메시의 일부가 될 수 있음
• Single-network 아키텍처
  • 쿠버네티스 클러스터와 VM 워크로드가 동일한 L3 네트워크 공간 공유
  • VM이 istiod와 다른 파드들에 IP로 직접 접근 가능
  • 게이트웨이를 통한 제어 평면 트래픽 라우팅 선택 가능 (필수 아님)
  • 자동 등록 시 VM이 시작 시 istiod에 연결하여 WorkloadEntry 리소스 자동 생성
• Multi-network 아키텍처
  • VM 워크로드가 쿠버네티스 클러스터와 다른 네트워크에 위치
  • 파드들이 VM의 IP 주소와 직접 통신 불가능
  • Istio east-west 게이트웨이가 네트워크 간 브리지 역할
  • 제어 평면 통신과 데이터 평면 트래픽 모두 게이트웨이를 통해 흘러감
  • VM이 게이트웨이 주소로 설정되어 istiod에 안전하게 연결

    가상머신의 프로비저닝 ID 자세히 살펴보기

• 이스티오의 가상머신 ID 제공 방식
  • 쿠버네티스를 신뢰의 원천으로 사용
  • 쿠버네티스에서 토큰 생성 후 머신에 전달
  • istio-agent가 토큰을 가져가 istiod 인증에 사용
• 클러스터 워크로드 vs 가상머신 워크로드 ID 제공 차이
  • 클러스터 워크로드: 서비스 어카운트 토큰을 파드에 자동 주입 → 토큰으로 인증하여 SVID 획득
  • 가상머신: 수작업 필요 → 서비스 어카운트 생성 → 토큰을 가상머신에 전달 → 토큰으로 인증하여 SVID 획득
• 접근법의 유사점과 차이점
  • 유사점: 기본 접근법은 동일
  • 차이점: 쿠버네티스는 토큰을 자동으로 파드에 주입
  • 가상머신: 서비스 메시 운영자가 수작업으로 토큰을 안전하게 전달 필요
• 인증 과정
  • istio-agent가 토큰을 사용해 istiod에 인증
  • istiod가 SVID 형태로 ID 발급
• 솔루션의 단점
  • 서비스 메시 운영자가 쿠버네티스에서 토큰 자동 생성 필요
  • 토큰을 VM으로 안전하게 전송하는 자동화 필요
  • 다중 클라우드 전략 채택 시 작업량이 급격히 증가
• 플랫폼이 할당한 ID (개발 중)
  • 이스티오 커뮤니티에서 개발 중인 해결책
  • 가상머신의 플랫폼 부여 ID를 신뢰의 근원으로 사용
  • istio-agent가 이를 사용해 istiod 인증
  • 이스티오가 클라우드 프로바이더에 토큰 검증 API 노출 예정
  • 아직 개발되지 않았지만 ID 공급자 설계 문서 참조 가능
• 예제에서의 접근법
  • 머신 ID 프로비저닝의 신뢰 원천으로 쿠버네티스 사용
  • 간결함을 위해 토큰을 수작업으로 가상머신에 전달

가상머신 고가용성

• 이스티오의 가상머신 고가용성 접근법
  • 쿠버네티스가 컨테이너화된 워크로드에서 사용하는 접근법과 매우 유사하게 모방
• 쿠버네티스의 고가용성 달성 리소스
  • 디플로이먼트(Deployment): 고수준 리소스로 복제본 생성 방법에 대한 설정 포함
  • 파드(Pod): 디플로이먼트 설정으로 만든 복제본
    • 파드에 고유한 부분이 없도록 보장
    • 비정상 시 폐기하고 교체 가능
    • 불필요 시 축소 가능
    • 서비스 가용성 유지
• 이스티오의 가상머신용 리소스
  • WorkloadGroup 리소스
    • 쿠버네티스의 디플로이먼트와 유사
    • 관리하는 워크로드 설정 방법에 대한 템플릿 정의
    • 공통 속성 지정:
      • 애플리케이션이 노출하는 포트
      • 그룹 인스턴스에 부여하는 레이블
      • 메시에서 워크로드 ID를 나타내는 서비스 어카운트
      • 애플리케이션 상태 프로브 방법
  • WorkloadEntry 리소스
    • 쿠버네티스의 파드와 유사
    • 최종 사용자 트래픽을 처리하는 개별 가상머신 표현
    • WorkloadGroup의 공통 속성 + 고유 속성 보유:
      • 인스턴스의 상태
      • 주소 등
  • WorkloadEntry 생성 방식
    • 수동 생성 가능
    • 권장 방식: 워크로드 자동 등록 이용
      • 새로 뜬 워크로드가 메시에 자동으로 참가

        워크로드 자동 등록 이해하기

• 워크로드 자동 등록 과정
  • 워크로드가 제공받은 설정을 사용해 컨트롤 플레인에 연결
  • ID 토큰으로 자신이 WorkloadGroup의 일원임을 인증
  • 성공 시 컨트롤 플레인이 메시에서 가상머신을 나타내는 WorkloadEntry 생성
• WorkloadEntry 표현의 중요성
  • 쿠버네티스 서비스나 이스티오 ServiceEntry 리소스가 레이블 셀렉터로 워크로드 선택 가능
  • 트래픽을 라우팅할 백엔드로 사용 가능
• 서비스 기반 워크로드 선택의 장점
  • 실제 주소 대신 쿠버네티스 서비스(클러스터 내 FQDN) 사용
  • 클라이언트 측 지식이나 영향 없이 운영 가능:
    • 비정상 워크로드 폐기
    • 수요 증가에 따른 새 워크로드 생성
• 서비스의 WorkloadEntry와 파드 타겟팅
  • 서비스를 통해 WorkloadEntry와 파드 모두 대상 지정 가능
• 마이그레이션 활용 사례
  • 가상머신의 레거시 워크로드를 쿠버네티스의 현대화 워크로드로 이전 시 위험 감소
  • 워크로드 병렬 실행 후 서비스 메시의 트래픽 전환 기능 활용
  • 가상머신에서 파드로 트래픽을 점진적 이동
  • 오류 증가 시 가상머신으로 트래픽 롤백 옵션 보유
• 리소스 관계
  • Deployment와 Pod 관계에 대비되는 WorkloadGroup과 WorkloadEntry 관계

    이스티오가 수행하는 헬스 체크 이해하기

• 헬스 체크의 필요성
  • 워크로드가 서비스 메시의 일부가 된 후 트래픽 수신 준비 상태 확인
  • 헬스 체크로 검사받아야 함
• 서비스 고가용성을 위한 두 가지 헬스 체크
  • 쿠버네티스의 헬스 체크 방식과 유사
• Readiness 프로브
  • 워크로드가 시작된 후 트래픽을 수신할 준비가 됐는지 확인
  • 서비스 메시의 관심사
• Liveness 프로브
  • 애플리케이션이 실행 중일 때 정상인지 확인
  • 비정상 시 재시작 필요
  • 서비스 메시의 관심사가 아님
• Liveness 프로브 책임
  • 워크로드가 실행되는 플랫폼의 기능
  • 플랫폼별 구현 방식:
    • 쿠버네티스: Deployment 설정에서 정의한 프로브로 liveness 검사
    • 클라우드 VM: 클라우드 기능을 사용해 liveness 프로브 구현
• 클라우드 프로바이더별 자동 복구
  • 프로브 실패 시 새 인스턴스 생성 등 수정 조치 필요
  • 주요 클라우드 프로바이더 지원:
    • Azure: VM 스케일 셋에 대한 자동 인스턴스 복구 구현
    • AWS: 오토 스케일 그룹 인스턴스에 대한 헬스 체크 구현
    • GCP: 관리형 인스턴스 그룹에 대한 헬스 체크 및 자동 복구 구현

      이스티오가 가상머신에서 readiness 프로브를 구현하는 방법

• Readiness 프로브 구현 방식
  • istio-agent가 WorkloadGroup 정의에 따라 주기적으로 검사
  • 애플리케이션이 트래픽을 받을 준비가 됐는지 확인
• 상태 보고 과정
  • 에이전트가 애플리케이션의 상태를 istiod에 보고
  • 상태 변화 시점에 보고 (정상↔비정상)
  • 사이드카 프록시가 istiod를 애플리케이션 상태 정보로 업데이트
• 컨트롤 플레인의 라우팅 결정
  • 상태를 사용해 워크로드로 라우팅할지 여부 결정
  • 애플리케이션 정상 시: 데이터 플레인에 VM 엔드포인트 설정
  • 애플리케이션 비정상 시: 데이터 플레인에서 엔드포인트 제거
• 서비스 메시 운영자의 책임
  • WorkloadGroup에 애플리케이션 readiness 검사 설정
  • 클라우드 프로바이더 권장 방법에 따라 인프라 계층에 liveness 검사 생성
• Liveness vs Readiness 프로브 설정 권장사항
  • 서로 다른 설정 사용 추천
• Readiness 프로브 특성
  • istio-agent가 수행
  • 공격적으로 설정해야 함
  • 오류 반환 인스턴스로 트래픽 라우팅 방지
• Liveness 프로브 특성
  • 클라우드 프로바이더가 수행
  • 보수적으로 설정해야 함
  • 가상머신에 복구 시간 제공
• 인스턴스 종료 시 주의사항
  • 인스턴스를 너무 성급하게 종료하지 않도록 주의
  • 유예 기간 없이 진행 중인 요청 종료 시 최종 사용자에게 실패 노출
  • 경험상 좋은 방법: readiness 프로브가 liveness 프로브보다 항상 먼저 실패하도록 설정

메시 내 서비스의 DNS 해석

• DNS 해석 문제
  • 가상머신은 쿠버네티스 클러스터 외부에 위치
  • 쿠버네티스 내부 DNS 서버에 접근할 수 없음
  • 클러스터 서비스의 호스트네임을 해석할 수 없음
  • 가상머신을 서비스 메시에 통합하기 위한 마지막 단계
• DNS 해석이 필요한 이유
  • 서비스 프록시는 트래픽 라우팅 설정을 갖고 있음
  • 문제는 트래픽을 애플리케이션에서 프록시로 가져오는 과정
  • 호스트네임 해석이 전제 조건
  • DNS 해석 실패 시 트래픽이 애플리케이션을 떠나지 않아 엔보이 프록시로 리다이렉트 불가능
• 기존 해결 방법 (차선책)
  • 모든 쿠버네티스 서비스가 설정된 프라이빗 DNS 서버 사용
  • 가상머신을 네임서버로 프라이빗 DNS 서버 사용하도록 설정
  • 동적 워크로드 특성으로 인해 자동화 필요
  • 쿠버네티스 컨트롤러가 변경 사항 수신하여 DNS 서버 동기화
  • external-dns 오픈소스 솔루션 활용 가능
  • 통합 솔루션이 아닌 차선책
• 이스티오의 통합 솔루션
  • 이스티오 1.8 이상에서 istio-agent 사이드카에 로컬 DNS 프록시 도입
  • istiod가 DNS 프록시에 메시 내 모든 서비스 설정
• DNS 프록시 동작 방식
  • 엔보이 프록시와 함께 이스티오 사이드카로 동작
  • 애플리케이션의 DNS 쿼리 처리
  • Iptable 규칙을 사용해 DNS 쿼리를 DNS 프록시로 리다이렉트
  • istio-cni 사용 시 과정이 약간 다름
• NDS (Name Discovery Service)
  • DNS 프록시 지속적 업데이트를 위한 새 API
  • 메시에 쿠버네티스 서비스나 이스티오 ServiceEntry 추가 시 컨트롤 플레인이 데이터 플레인에 새 DNS 항목 동기화
• DNS 프록시의 추가 기능
  • 가상머신에만 국한되지 않음
  • 여러 추가 기능 제공 가능
• 다음 단계
  • 고수준 개념과 목표 파악 완료
  • 가상머신을 서비스 메시에 통합하는 실제 실습 진행 예정

(작성중..)

인프라 준비하기

서비스 메시 준비하기

가상머신 프로비저닝

가상머신까지 메시 확장

istiod와 클러스터 서비스들을 가상머신에 노출하기

WorkloadGroup으로 워크로드 그룹 나타내기

가상머신의 사이드카용 설정 생성하기

생성된 파일을 가상머신으로 전송하기

가상머신에 istio-agent 설치 및 설정하기

에이전트 로그 확인하기

클러스터 서비스로 트래픽 라우팅하기

트래픽을 WorkloadEntry로 라우팅하기

forum 워크로드 상태 확인하기

가상머신에서 forum 애플리케이션 시작하기

컨트롤 플레인이 가상머신 설정: 상호 인증 강제

DNS 프록시 이해하기

DNS 프록시가 클러스터 호스트네임을 해석하는 방법

DNS 프록시가 인식하는 호스트네임은 무엇인가?

에이전트 동작 커스터마이징하기

메시에서 WorkloadEntry 제거하기