k8s - 이스티오(Istio) 정리 #2

k8s 이스티오 정리 두 번째

 

- 이전 글 : k8s - 이스티오(Istio) 정리 #1

 

컨트롤 플레인 (Control plane)

사이드카와 게이트웨이는 컨트롤 플레인에 의해 설정 및 조정된다. 컨트롤 플레인은 마이크로 서비스 세트였지만, Istio는 몇 년 전에 큰 아키텍처 변경을 경험했다. Istio 블로그 게시물에서 논의되었으며, 11월에 그 일에 대해 이야기할 예정이다. 이 재설계 이후 컨트롤 플레인은 is tio-system 네임스페이스에서 실행되는 단일 파드(istiod)가 된다.

 

확장성 (Extensibility)

주목할 점은 데이터 플레인 동작의 일부는 Configuration으로 프록시에 제공되는 것이 아니라 Emissor의 WASM 지원을 사용하여 동적으로 주입되는 코드로 제공된다는 것이다. 이것은 발생한 아키텍처 변경의 일부이다. 예를 들어 Mixer라고 하는 컨트롤 플레인 컴포넌트에서 행해지고 있던 액세스 컨트롤 정책에 관한 고도의 결정이다. 이 거동은 사이드카에 WASM을 주입함으로써 사이드카로 옮겨졌다.

WASM 플러그인에 의한 Emissor의 지원은 매우 강력한 기능이다. 이 기능을 이용할 수 있는 것은 Istio 자신만이 아니다. 사용자는 임의의 코드를 삽입할 수도 있다. Istio에서는 전용 커스텀 리소스 유형을 사용하여 WASM 모듈을 사이드카에 쉽게 삽입할 수 있다. 요청 헤더와 본문을 검증, 조작 및 보고하기 위해 임의의 강력한 코드를 작성할 수 있다.

 

디폴트 기능 (Default features)

컨트롤 플레인, 사이드카, 입력 게이트웨이 및 잠재적으로 출력 게이트웨이를 갖춘 Istio의 구조를 알았다. 이를 통해 바로 이용할 수 있는 것은 무엇일까? 메쉬를 전혀 설정하지 않아도 무료로 많은 장점을 얻을 수 있다.

 

사이드카는 워크로드에 출입하는 모든 트래픽을 대행 수신하여 처리하기 때문에 각 요청과 응답에 대한 로그를 생성하여 로그 서버로 전송할 수 있다. 또 메트릭 서버에 송신할 수 있는 트래픽 흐름 통계 정보나, 트레이스 서버에 송신할 수 있는 트레이스 스팬도 생성할 수 있다.

 

Istio 설치 프로그램은 이러한 관찰 가능성이 있는 각 서버의 데모 인스턴스를 전개할 수도 있다. 이를 통해 서비스 메쉬(특히 Elastic Search, Promethus, Zipkin)의 이점을 즉시 얻을 수 있다. 마이크로 서비스의 세계에서 이 관찰 가능성은 복잡한 분산 시스템을 이해하고 디버깅하는 데 매우 중요하다는 것이 증명된다.

 

또 하나의 무료 기능은 사이드카 간의 모든 트래픽을 자동적이고 투과적으로 암호화하는 것이다. 앱 개발자는 HTTP가 아닌 플레인 텍스트 HTTP 서버를 제공하여 플레인 HTTP 콜을 수행할 수 있는데, 이는 또 다른 훌륭한 개발자 경험이다.

 

구성

무료인 것 이외의 행동을 원한다면 어떻게 해야 할까? 기능에 대해서는 여러 번 설명했기 때문에 반복하지 않도록 하겠지만, 많은 기능이 기본적으로 켜져 있지 않고 켜져 있지 않다는 점에 주의해야 한다. 앱이 얼마나 걸릴지 모르기 때문에 메쉬는 자동으로 요청 마감을 강제할 수 없다. 마찬가지로 재시도해도 안전한 요구와 그렇지 않은 요구를 알 수 없기 때문에 재시도할 수 없다. 이러한 기능은 모두 설정해야 하며, 이는 Istio API를 통해 수행된다.

 

Istio는 해당 API를 gRPC 엔드포인트가 아닌 호스트 k8s 클러스터에 CRD를 설치함으로써 공개된다. Istio를 설정하려면 Istio의 리소스 유형 인스턴스도 클러스터에 전개한다.

 

관리자와 사용자가 YAML 파일을 만들어 Istio를 설정하는 것이 실제 결과이다. 이러한 YAML은 k8s 스타일(Group, Kind, Metadata, Spec, 때로는 Status)을 따른다. 다른 리소스와 마찬가지로 이러한 리소스도 kubectlapply를 사용하여 전개할 수 있다. 또한 CD 파이프라인에 의해 전개되고 GitOps와 동기화된 Helm 차트에 의해 템플릿화 된 보다 복잡한 옵션 중 하나로 전개될 수 있다.

현재 1.15 버전의 Istio에는 15가지 Istio 리소스 유형이 있다. 이들은 설정 API 상의 다른 엔드포인트 또는 다른 설정 파일 유형으로 간주된다. 리소스는 다양한 그룹으로 분할되며 다음과 같은 모든 그룹과 주요 구성 유형이 사용된다.

 

Install.istio.io

  - IstioOperator : Istio의 install-timeconfig (게이트웨이 등)

Networking.istio.io

  - Gateway : Istio에게 외부 입력 게이트웨이 포트를 열도록 지시

  - VirtualService : 특정 호스트, 경로, 헤더 등에 일치하는 트래픽 라우팅 및 조작 절차

  - DestinationRule : 타임아웃이나 재시도 등 특정 애플리케이션에 트래픽을 전송하는 방법을 Istio에 전달

Security.istio.io

  - 요청 인증 및 인가 정책

Extensions.istio.io

  - WasmPlugins : 사이드카에 주입하기 위한 커스텀 코드

Telemetry.istio.io

  - 관측 가능성 데이터 수집과 전송을 위한 구성 인증 및 인가 정책

 

Egress Stance

네트워킹 그룹에서 가끔 사용해야 하는 다른 리소스가 있다. (서비스 엔트리)

Virtual Services 및 Destination Rules에 수신처 호스트 이름이 기술되면 이러한 이름은 먼저 Istio의 서비스 레지스트리에서 체크됩니다. 그 안에 없는 경우 DNS로 검색된다.

 

k8s의 클러스터 내 DNS 서버에 의해 클러스터 내 서비스와 외부 인터넷 도메인 모두의 호스트 이름이 검출되기 때문에 DNS만으로 잠재적 목적지의 서비스 검출에 충분하다. 단, ServiceEntries를 사용하면 DNS 룩업을 덮어쓰고 호스트 이름에 추가 메타데이터를 제공할 수 있다. 보통은 문제의 서비스에 Istio 사이드카가 있다고 한다. (k8s 워크로드가 아니더라도) 이것은 기존 워크로드에 메쉬를 확장했음을 Istio에 알리기 위해서이다.

 

안타깝게도 이 레지스트리를 표시하는 간단한 방법은 없다. 이 레지스트리는 접속되어 있는 서비스 검출 시스템(예: 클러스터 내의 서비스 리소스)과 수동으로 정의한 일련의 서비스 엔트리에서 추측해야 한다.

글로벌 출력 설정도 있다. set의 경우 호스트 이름은 서비스 레지스트리에 있는 경우에만 사용할 수 있다. 다른 장소에서는 요청을 전송할 수 없다.

 

Istio는 서비스 리소스 목록에서 서비스 레지스트리를 k8s로 자동으로 가져오기 때문에 클러스터 내 통신은 자동으로 작동합니다. 단, 모든 비 k8s 워크로드와 통신하는 모든 인터넷 엔드포인트도 레지스트리에 있어야 합니다. ServiceEntry를 사용하면 수동으로 이러한 수신처를 추가할 수 있으며 실질적으로 출력처를 일람 표시할 수 있습니다. 이 허가 목록은 쉽게 눈으로 볼 수 있기 때문에, 이것은 메쉬 오퍼레이터에게 좋은 보안 스탠스와 좋은 경험이 될 수 있습니다.

 

사용자 경험

이 설정을 파일로 제공하여 여러 개의 다른 개발자 경험을 구축할 수 있다. 응용 프로그램의 Istio Configuration을 다른 Repo에 저장하거나 응용 프로그램의(k8s) 디플로이먼트 구성을 사용하거나 코드와 함께 작성한다.

 

보통 개발자들은 그것을 하나로 묶는 것을 좋아한다. 앱의 동작을 인코딩하는 프로그램부터 런타임 컴퓨팅 및 네트워킹 환경의 YAML 정의에 이르기까지 앱을 설명하는 모든 것은 우리가 눈을 돌릴 수 있는 한 장소에 있다. 기능(예를 들어 JWT 검증)을 뒤로 미루고 스스로 여러 번 쓸 필요가 없도록 하고 싶다고 가정해보자. k8s YAML를 쓰는 것은 앱의 구조를 k8s에 전달하는 것이라고 생각한다. 어떻게 확장할까? 살아있는 상태와 죽은 상태는 어떤 것일까?

 

다른 주목할 만한 기능

Istio의 모든 기능을 다루는 것은 아니지만, 더 흥미로운 기능을 몇 가지 꼽고 싶다.

 

1) 로케일 지원 라우팅

Istio는 k8s에 각 워크로드 측 차량 쌍이 어디에 있는지, 즉 어떤 클라우드 지역, 존 및 호스트에 도달했는지 궁금할 수 있다. 이러한 데이터를 사용하면 서비스의 가장 가까운 인스턴스에 요청을 라우팅하여 지연을 낮게 유지하고 존 간 클라우드 입출력 비용을 피할 수 있다. (Tetrate Cost Analyzer를 사용하여 현재 비용을 파악할 수 있다)

2) 멀티 클러스터

각 클러스터 내의 모든 서비스가 다른 모든 것에 도달할 수 있도록 여러 클러스터 내의 Istio 데이터 플레인을 조합할 수 있다. 이것을 설계하는 방법은 여러 가지가 있지만 베스트 프랙티스는 클러스터마다 Istio 컨트롤 플레인을 하나씩 갖는 것이라고 생각한다. 이것은 하나의 메쉬로 생각할 수는 있지만 장애와 성능 특성이 개선되고 있다. 모든 서비스가 다른 모든 서비스와 통신할 수 있도록 각 Istio 인스턴스를 설정하려면 많은 작업이 필요하다. 이것은 수동으로 가능하지만 자동 생성하는 Tetrate Service Bridge와 같은 중앙 관리 플레인이 매우 유용하다.

 

참고 : https://blog.container-solutions.com/wtf-is-istio