4. Service (2/2) - Istio

소개

Istio는 기존 분산 애플리케이션에 투명하게 계층화되는 오픈 소스 서비스 메시 이다. Istio는 서비스를 보호하고, 연결하고, 모니터링하는 효율적인 방법을 제공 해준다. Istio는 서비스 코드 변경이 거의 또는 전혀 없이 로드 밸런싱, 서비스 간 인증 및 모니터링을 위한 경로이며, 컨트롤 플레인은 다음과 같은 중요한 기능을 제공한다..

• TLS 암호화, 강력한 ID 기반 인증 및 권한 부여를 통해 클러스터에서 서비스 간 통신을 보호.
• HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 자동 부하 분산.
• 풍부한 라우팅 규칙, 재시도, 장애 조치 및 결함 주입을 통해 트래픽 동작을 세밀하게 제어.
• 액세스 제어, 속도 제한 및 할당량을 지원하는 플러그형 정책 레이어 및 구성 API.
• 클러스터 수신 및 송신을 포함하여 클러스터 내의 모든 트래픽에 대한 자동 지표, 로그 및 추적.

 

핵심 개념 3가지

• 트래픽 관리(Taffic Managemnet)
  Istio의 트래픽 라우팅 규칙을 사용하면 서비스 간 트래픽 흐름과 API 호출을 쉽게 제어할 수 있다. Istio는 통신 차단, 제한 시간 및 재시도와 같은 서비스 수준 속성의 구성을 단순화하고 A/B 테스트, 카나리아 출시, 백분율 기반 트래픽 분할을 통한 트래픽 노출을 단계적으로 설정할 수 있도록 해준다. 또한 종속 서비스 또는 네트워크 오류에 대해 애플리케이션의 탄력성을 높이는 데 도움이 되는 기능을 기본으로 제공한다.
  Istio의 트래픽 관리 모델은 서비스와 함께 배포되는 Envoy 프록시에 의존한다. 메시 서비스가 보내고 받는 모든 트래픽(data plain 트래픽)은 Envoy를 통해 프록시 처리되므로 서비스를 변경하지 않고도 메시 주변의 트래픽을 쉽게 지시하고 제어할 수 있다.
• 보안(Security)
  모놀리식 애플리케이션을 마이크로 서비스로 변환하면 민첩성 향상, 확장성 향상, 서비스 재사용 능력 향상 등 다양한 이점을 얻을 수 있다. 그러나 마이크로서비스에는 다음과 같은 특별한 보안 요구 사항도 있다.
  • 중간자 공격을 방어하려면 트래픽 암호화가 필요.
  • 유연한 서비스 접근 제어를 제공하려면 상호 TLS와 세분화된 접근 정책이 필요.
  • 누가 언제 무엇을 했는지 확인하려면 감사 도구가 필요.
  Istio Security는 이러한 문제를 해결하기 위한 포괄적인 보안 솔루션을 제공한다. 특히 Istio 보안은 데이터, 엔드포인트, 통신 및 플랫폼에 대한 내부 및 외부 위협에 모두 대응 가능합니다.
  

  

 

• 관찰가능성
  Istio는 메시 내의 모든 서비스 통신에 대한 자세한 원격 측정을 생성한다. 이 원격 측정은 서비스 동작에 대한 관찰 가능성을 제공하여 운영자가 서비스 개발자에게 추가적인 부담을 주지 않고 애플리케이션의 문제를 해결, 유지 관리 및 최적화할 수 있도록 해준다. Istio를 통해 운영자는 모니터링되는 서비스가 다른 서비스 및 Istio 구성 요소 자체와 어떻게 상호 작용하는지 철저히 이해할 수 있다.
  Istio는 전반적인 서비스 메시 관찰 가능성을 제공하기 위해 다음 유형의 Telemetry를 생성한다.
  
  
  1. 메트릭스. Istio는 모니터링의 4가지 "황금 신호"(지연 시간, 트래픽, 오류 및 포화도)를 기반으로 일련의 서비스 지표를 생성한다. Istio는 메시 컨트롤 플레인에 대한 자세한 측정항목도 제공하고, 이러한 지표를 기반으로 구축된 기본 메시 모니터링 대시보드 세트도 제공된다.
  2. 분산 추적 . Istio는 각 서비스에 대해 분산 추적 범위를 생성하여 운영자가 메시 내의 호출 흐름 및 서비스 종속성에 대한 자세한 이해를 제공한다.
  3. 액세스 로그 . 트래픽이 메시 내의 서비스로 유입되면 Istio는 소스 및 대상 메타데이터를 포함하여 각 요청에 대한 전체 기록을 생성할 수 있습니다. 이 정보를 통해 운영자는 개별 워크로드 인스턴스 수준 까지 서비스 동작을 감사할 수 있다.

 

서비스 메시란?

최신 애플리케이션은 일반적으로 마이크로서비스의 분산 컬렉션으로 설계되며, 각 마이크로서비스 컬렉션은 개별 비즈니스 기능을 수행한다. 서비스 메시는 애플리케이션에 추가할 수 있는 전용 인프라 계층이므로, 이를 통해 관찰 가능성, 트래픽 관리, 보안과 같은 기능을 자체 코드에 추가하지 않고도 투명하게 추가할 수 있다. "서비스 메시"라는 용어는 이 패턴을 구현하는 데 사용하는 소프트웨어 유형과 해당 소프트웨어를 사용할 때 생성되는 보안 또는 네트워크 도메인을 모두 설명한다.

Kubernetes 기반으로, 분산 서비스 배포의 규모와 복잡성이 증가함에 따라 이해하고 관리하기가 더 어려워질 수 있다. 요구 사항에는 검색, 로드 밸런싱, 오류 복구, 메트릭 및 모니터링이 포함될 수 있고,  서비스 메시는 A/B 테스트, 카나리아 배포, 속도 제한, 액세스 제어, 암호화, 엔드투엔드 인증과 같은 보다 복잡한 운영 요구 사항을 해결하는 경우도 많다.

서비스 간 통신은 분산 애플리케이션을 가능하게 만들어 준다. 애플리케이션 클러스터 내 및 애플리케이션 클러스터 간에 이러한 통신을 라우팅하는 것은 서비스 수가 증가함에 따라 점점 더 복잡해 질수 있는데,  Istio는 이러한 복잡성을 줄이는 데 필수다.

Istio 를 활용하기 전

istio 활용 후

 

이렇게 열일 하시는 이스티오를 다운받고, 게이트웨이를 설정하고, 서비스를 생성해보자.

 

다운로드 및 자동설치

Istio를 다루기 위해서 Istio cli 도구(istioctl)를 설치한다.

# 파일 다운로드 및 실행
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.19.3
# Path 등록
export PATH=$PWD/bin:$PATH

 

Istio 설치 시 선택 가능한 프로파일에는 아래와 같이 여러 옵션이 있다.

	deault	demo	minimal	remote	empty	preivew	ambient
Core components
istio-egressgateway		✔
istio-ingressgateway	✔	✔				✔
istiod	✔	✔	✔			✔	✔
CNI							✔
Ztunnel							✔

우리는 Istio 게이트웨이를 통한 서비스 생성이 목적이므로 가장 무난한 demo 프로파일을 생성한다.

istioctl install --set profile=demo -y

설치가 끝나고 나면 isitio-system 네임스페이스 밑에 많은 오브젝트들이 설치되어 있을 것이다. 확인해 보자

kubectl get all -n istio-system

위 그림에서 보면 istio-ingressgateway 에 IP-Pool 에서 받아온 아이피가 매핑되어 있다, 이전 글에서 metallb L4 로드밸런서에 140번 아이피를 쓰고, ingres-nginx 로드밸런서에 141번 아이피를 썼기 때문에 그 다음 아이피가 할당되었다. 아래 그림에서 세개의 로드밸런서를 확인 할 수 있다.

이제 istio-ingressgateway를 통해 게이트웨이를 설정하고 서비스를 연결해보자. 먼저 게이트웨이 설정을 하는데, 위 서비스 메시 개념도에서 Envoy Proxy 가 바로 게이트웨이 이다. 메니페스트를 생성하고 적용해보자. 파일명은 my-gateway.yaml로 하였다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-ingress-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*.gw.test"

kubectl apply -f my-gateway.yaml

"*.gw.test" 라는 사설 도메인을 만들었다. 이 게이트웨이를 통해 gw.test 의 하위도메인에 대해서 VirtualService 생성할 수 있다. 이제 VirtualService를 생성해보자, 레플리카 3개로 이미 돌고 있는 nginx-hello 에 붙여 보겠다.

매니페스트 파일명 은  my-vs.yaml 이다.

kind: VirtualService
metadata:
  name: webapp-vs-from-gw
spec:
  hosts:
  - "istio.gw.test"
  gateways:
  - istio-ingress-gateway
  http:
  - route:
    - destination:
        host: nginx-hello
        port:
          number: 80

kubectl apply -f my-vs.yaml

nginx-hello 파드로 잘연결되고, 로드 밸런스가 잘되는지 확인해 보자. 먼저 사설 도메인이기 때문에 hosts 파일에 도메인 등록이 필요하다.

# /etc/hosts 혹은 C:\Windows\System32\drivers\etc\hosts"

192.168.180.142 istio.gw.test

아주 단순한 설정으로 게이트웨이 및 VirtualService를 생성해보았다. 작은 규모의 클러스터에서는 ingress-nginx 정도의 로드밸런스로도 충분해 보이고, 좀 더 복잡한 네트워크 구조가 필요한 복잡한 클러스터에서는 istio 가 필수인 것같다.

"gw.test" 도메인의 서브도메인으로 VirtualSerivce를 하나 더 생성해 보았다. 매니페스트 파일명은 my-vs2.yaml 이다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp-vs-from-gw
spec:
  hosts:
  - "my.gw.test"
  gateways:
  - istio-ingress-gateway
  http:
  - route:
    - destination:
        host: nginx-hello
        port:
          number: 80

kubectl apply -f my-vs2.yaml

hosts 파일에 "my.gw.test" 를 등록한다.

# /etc/hosts 혹은 C:\Windows\System32\drivers\etc\hosts"

192.168.180.142 my.gw.test

브라우저에서 호출해보자.

새로 등록한 도메인에서도 서비스가 잘되고 있을 볼 수 있다.