istio

Service Mesh(서비스 메시)

: 서비스간의 통신을 제어, 관리할 수 있도록 하는데 특화된 마이크로서비스를 위한 인프라계층

: API(Application Programming Interface)를 사용하여 애플리케이션 인프라 서비스 간에 대량의 네트워크 기반 프로세스 간 통신을 처리하도록 설계된 구성이 가능하고 대기 시간이 짧은 인프라 계층

• 기존의 서비스 아키텍처 호출이 직접 호출방식 → 서비스메시에서의 호출은 자체 인프라계층의 proxy통해 이루어짐.
• 서비스메시를 구성하는 개별 proxy는 서비스 내부가 아니라 각 서비스와 함께 실행되므로 sidecar라고도 함. 각 서비스에서 분리된 sidecar proxy들이 모여 Mesh network 형성

클라우드/컨테이너 환경과 어우러지면서 api-g/w와는 또 다른 분산 책임 형태로 해당 문제들을 품.

api gateway / service mesh

• api gateway : 외부 요청을 내부 서비스로 전달하는 역할, 비즈니스 로직을 포함한 어플리케이션에 직접 연결 → 네트워크 변경 → 어플리케이션에 영향 있음
• service mesh : api gateway를 통해 들어온 내부 네트워크 관리하는데 초점, 기존 어플리케이션 영역(비즈니스 로직)과 네트워크 영역을 분리(sidecar)해 네트워크 변경 및 적용을 분리된 영역에서 처리 → 어플리케이션에 영향 없음

---

*MSA 구조는 장점도 많지만, 단점도 명확하다. 각각의 마이크로서비스가 늘어날수록 추적이 힘들고 네트워크와 어플리케이션 이슈 등으로 장애 여파가 커지게 된다.

Istio

: MSA아키텍쳐의 분산 네트워크 환경에서 각 어플리케이션들간의 네트워크 연결을 쉽게 설정할 수 있도록 지원하는 기술

 

아키텍처

Istio Sidecar Proxy : OSI Layer 7계층(L7) 처리도 할 수 있음 (Kube-proxy는 L4에서만 작동)

• Data plane(네트워크 연결을 통해 데이터 전달 및 biz logic의 추가 가능) : pilot, citadel, galley, istio-auth로 구성 
  • 각 서비스를 Envoy proxy와 함께 배포(사이드카 패턴 방식)
  • 서비스를 오가는 모든 네트워크 패킷을 변환, 전달 및 모니터링
  • 1. Envoy 프록시: Istio는 Envoy 프록시를 Data plane의 사이드카 프록시로 사용합니다. 데이터 플레인의 Envoy는 장애 처리, 상태 확인, 서비스 검색 및 로드 밸런싱과 같은 기능을 담당합니다. Envoy 프록시는 각 서비스 요청에 대한 자세한 정보를 제공합니다.
    2. Mixer: 컨트롤 플레인의 믹서는 Istio의 텔레메트리 허브 역할을 하며 메시의 Envoy 프록시에서 서비스 요청에 대한 속성을 수집합니다. Mixer는 모니터링 및 로깅 목적으로 이러한 속성을 가져오는 API를 제공합니다.
    3. Pilot: Istio는 컨트롤 플레인에서 파일럿을 사용하여 서비스 메시를 기반으로 트래픽 제어 및 로드 밸런싱을 제공합니다. 모든 트래픽 규칙은 Istio에서 지정할 수 있으며 내부의 파일럿은 트래픽에 영향을 미치는 배포 변경 사항에 대해 Kubernetes 인프라와 통신할 수 있습니다. 또한 Istio는 파일럿을 사용하여 모든 Envoy 프록시에 보안 정책(예: 인증 및 권한 부여 정책)을 배포합니다.
    4. Citadel: Istio는 Citadel을 사용하여 Envoy 프록시 간에 정책 중심의 보안 통신을 제공합니다. 사이드카 프록시 간의 모든 인증 및 키 기반 자격 증명 관리는 Citadel에서 관리합니다.
    5. Galley: Istio 컨트롤 플레인에는 사용자 정의 Kubernetes YAML 파일을 Istio가 이해하는 형식으로 해석하는 역할을 하는 Galley도 포함되어 있습니다. Galley는 사용자 구성을 저장하고 유효성을 검사한 다음 추가 작업을 위해 Pilot에 보냅니다.
  *Envoy는 HAProxy, nginx처럼 단순한 프록시처럼 사용할 수도 있다. HAProxy, nginx로 서비스메시를 구현할 수도 있지만, 실제 사용에는 여러가지 한꼐점이 존재한다고 한다.
•  Control plane(네트워크 관련된 로깅 및 제어 가능) : istio의 proxy를 담당하는 envoy가 있음.
  • 회로 차단, 로드밸런싱, 타임아웃 등의 기본 구성 정보 저장
  • 기본 구성 정보에 맞게 각 서비스의 프록시 동작시킴

istio 아키텍처의 트래픽 흐름

1. K8S Cluster 앞에 LoadBalancer가 존재. 클라이언트가 bar.test.com이라는 도메인에 접근했을때 LoadBalancer의 Public IP 및 Private IP의 응답을 받게됩니다.

2. LoadBalancer에는 istio Ingress Gateway Service의 포트를 맵핑해주게됩니다.

3. Virtual Service에 라우팅 룰을 적절하게 지정하게됩니다. ex) host가 gimup.test.com으로 요청이 들어오게 된다면 특정 K8S svc를 목적지로 지정합니다.

4. 목적지로 지정하는 부분은 DestinationRule에 정의하게되며 DestinationRule에서 정의한 서비스로 라우팅을 하게 됩니다.

 

 

 

*사이드카 방식의 한계

• 기존 사이드카 방식은, 사이드카를 설치하거나 업그레이드하려면 애플리케이션 파드를 다시 시작해야 하며 이는 워크로드에 지장을 줄 수 있다
• 사이드카 프록시는 각 워크로드 전용이므로 CPU 및 메모리 리소스는 각 개별 파드의 최악의 사용에 대비하여 프로비저닝되어야함
• 이로 인해 클러스터 전체에서 리소스 활용률이 저하될 수 있고, 워크로드의 고정비용이 항상 발생