Istio란 무엇인가요?

현재 시점에서 Istio는 Kubernetes와만 기본적으로 작동하지만, 오픈 소스 특성 덕분에 누구나 Istio가 다른 클러스터 소프트웨어에서도 실행될 수 있도록 확장 기능을 작성할 수 있습니다. 오늘은 가장 많이 사용되는 사용 사례인 Kubernetes와 함께 ISTIO 을 사용하는 방법에 대해 집중적으로 설명합니다.

Kubernetes는 컨테이너 오케스트레이션 툴이며, Kubernetes의 핵심 단위 중 하나는 노드입니다. 노드는 하나 이상의 컨테이너와 파일 시스템 또는 기타 구성 요소로 구성됩니다. 마이크로서비스 아키텍처는 서로 다른 마이크로서비스를 나타내는 여러 노드를 가질 수 있습니다. Kubernetes는 노드의 가용성과 리소스 소비를 관리하고 Pod Autoscaler를 통해 수요가 증가함에 따라 파드를 추가합니다. Istio는 보안, 관리 및 모니터링 기능을 추가하기 위해 파드에 더 많은 컨테이너를 주입합니다.

오픈 소스이기 때문에 Istio는 이를 지원하는 모든 퍼블릭 클라우드 제공업체와 관리자가 있는 모든 프라이빗 클라우드에서 실행할 수 있습니다.

다음 영상에서는 Istio의 기본 사항에 대해 더 자세히 설명합니다:

조직이 마이크로서비스로 전환하면 수십 또는 수백 개의 특정 애플리케이션을 지원해야 합니다. 이러한 엔드포인트를 개별적으로 관리하려면 많은 가상 머신(VM)을 지원해야 하며, 수요에 따라 확장해야 합니다. Kubernetes와 같은 클러스터 소프트웨어는 파드를 생성하고 확장할 수 있지만 라우팅, 트래픽 규칙, 강력한 모니터링 또는 디버깅 툴은 제공하지 않습니다.

서비스 메시를 입력합니다.

서비스 수가 증가함에 따라 잠재적인 통신 방법의 수가 기하급수적으로 증가합니다. 두 서비스에는 통신 경로가 두 개뿐입니다. 3개 서비스에는 6개, 10개 서비스에는 90개가 있습니다. 서비스 메시는 통신에 대한 정책을 만들어 이러한 통신 경로를 구성하는 단일 방법을 제공합니다.

서비스 메시는 서비스를 계측하고 사전 정의된 구성에 따라 통신 트래픽을 지시합니다. 이는 실행 중인 컨테이너를 직접 구성하거나 코드를 작성하는 대신 관리자가 서비스 메시에 구성을 제공하여 작업을 완료할 수 있다는 것을 의미합니다. 이는 이전에는 웹 서버 및 서비스 간 통신에서 항상 수동으로 처리해야 했던 작업입니다.

클러스터에서 이 작업을 수행하는 가장 일반적인 방법은 사이드카 패턴을 사용하는 것입니다. 사이드카는 서비스와 컨테이너 간의 통신 트래픽을 라우팅하고 관찰하는 파드 내부의 새로운 컨테이너입니다.

앞서 언급했듯이 Istio는 Kubernetes 위에 계층으로 추가되며, 프로그래머와 관리자에게는 보이지 않는 컨테이너를 추가합니다. 이러한 컨테이너는 사이드카 컨테이너라고 하며, 구성 요소 간의 트래픽을 제어하고 상호 작용을 모니터링하는 중간자 역할을 합니다. 이 두 가지는 구성, 모니터링 및 관리라는 세 가지 방식으로 결합하여 작동합니다.

Kubernetes에서 구성을 설정하는 기본 방법은 kubectl 명령어이며, 일반적으로 "kubectl -f " 형식으로 사용하며 파일은 YAML 파일입니다. Istio 사용자는 kubectl로 새롭고 다양한 유형의 YAML 파일을 실행하거나 새로운 옵션 명령인 ioctl을 사용할 수 있습니다.

Istio를 사용하면 Kubernetes에서 실행 중인 애플리케이션의 상태를 쉽게 모니터링할 수 있습니다. Istio의 계측 툴은 애플리케이션의 상태를 관리하고 시각화하여 Kubernetes가 제공하는 일반적인 클러스터 및 노드 모니터링보다 더 많은 인사이트를 제공합니다.

Istio의 인터페이스는 본질적으로 Kubernetes와 동일하기 때문에 별도의 추가 작업 없이 관리할 수 있습니다. 실제로 Istio는 사용자가 전체 Kubernetes 클러스터에 영향을 미치고 관리할 수 있는 정책을 생성할 수 있도록 하여, 각 클러스터를 관리하는 데 걸리는 시간을 줄이고 사용자 지정 관리 코드를 작성할 필요를 없애줍니다.

서비스 메시의 주요 이점으로는 디버깅, 모니터링, 라우팅, 보안 및 사용성 개선 기능이 있습니다. 즉, Istio를 사용하면 더 많은 서비스 그룹을 보다 쉽게 관리할 수 있습니다.

예를 들어 서비스에 여러 종속성이 있다고 가정해 보겠습니다. 보험 회사의 pay_claim 서비스가 deductible_amt 서비스를 호출하고, 그 서비스가 다시 is_member_covered 서비스를 호출하는 식입니다. 복잡한 종속성 체인은 10개 또는 12개의 서비스 호출로 구성될 수 있습니다. 이 12개 중 하나라도 실패하면 연쇄적인 실패가 발생하여 500 오류, 400 오류 또는 전혀 응답이 없는 상태로 이어질 수 있습니다.

이러한 호출 세트를 디버깅하기 위해 스택 트레이스와 같은 툴을 사용할 수 있습니다. 프런트엔드에서는 클라이언트 측 개발자가 웹 서버에서 어떤 요소가 어떤 순서로 반환되는지 확인하고 이를 검사할 수 있습니다. 프런트엔드 프로그래머는 디버깅을 돕기 위해 워터폴 다이어그램을 얻을 수 있습니다.

하지만 이 예제는 데이터 센터 내부에서 발생하는 일, 예를 들어 callback=parselLotamaAudiences가 다른 4개의 웹 서비스를 호출하고 그 중 어떤 서비스가 더 느리게 응답하는지까지는 보여주지 않습니다. 이후에 우리는 Istio가 이러한 호출을 추적할 수 있는 툴을 어떻게 제공하는지 확인하게 됩니다.

DevOps 팀과 IT 관리자는 트래픽을 관찰하여 지연 시간, 서비스 처리 시간, 오류 비율 등을 확인하고 싶어할 수 있습니다. 이들은 종종 대시보드를 통해 이를 확인하길 원합니다. 대시보드는 이러한 지표의 총합 또는 평균을 시각화하며, 특정 노드, 서비스 또는 파드까지 드릴다운하여 확인할 수 있는 기능을 제공합니다. Kubernetes는 이러한 기능을 기본적으로 제공하지 않습니다.

기본적으로 Kubernetes는 모든 파드가 다른 모든 파드로 트래픽을 전송할 수 있도록 허용합니다. Istio는 관리자가 어떤 서비스가 서로 통신할 수 있는지 제한하는 정책을 생성할 수 있도록 합니다. 예를 들어, 서비스는 실제로 종속된 다른 서비스만 호출하도록 제한할 수 있습니다. 서비스를 안정적으로 유지하기 위한 또 다른 정책으로는 속도 제한이 있으며, 이는 과도한 트래픽으로 서비스가 마비되는 것을 방지하고 서비스 거부(DoS) 공격을 차단합니다.

기본적으로 Kubernetes는 라운드 로빈 방식의 로드 밸런싱을 제공합니다.만약 특정 마이크로서비스를 제공하는 파드가 6개 있다면, Kubernetes는 각 파드에 순차적으로 요청을 보내는 로드 밸런서 또는 서비스를 제공합니다. 그러나 때때로 회사는 프로덕션 환경에 동일 서비스의 서로 다른 버전을 배포하기도 합니다.

가장 간단한 예는 블루-그린 배포입니다. 이 경우, 소프트웨어는 프로덕션 환경에 완전히 새로운 버전을 구축하지만, 프로덕션 사용자에게는 해당 버전을 아직 노출하지 않습니다. 새 버전을 프로모션한 후에는 장애 발생 시 빠르게 롤백할 수 있도록 기존 서버를 유지할 수 있습니다.

Istio에서는 구성 파일에서 태그를 사용하는 것만으로 이러한 처리가 가능합니다. 관리자는 라벨을 사용하여 어떤 유형의 서비스에 연결할지 지정하고, 헤더 기반의 규칙도 만들 수 있습니다. 예를 들어, 베타 사용자는 최신 빌드가 적용된 카나리아 파드로 라우팅하고, 일반 사용자는 안정적인 프로덕션 빌드로 라우팅하도록 구성할 수 있습니다.

서비스가 과부하되거나 다운되면 더 많은 요청이 실패하면서 시스템을 계속 과부하되게 만듭니다. Istio는 오류와 지연을 추적하기 때문에 정책으로 설정한 특정 요청 횟수 이후에 일시 중지를 강제 적용하여 서비스가 복구할 수 있도록 합니다. 작은 텍스트 파일을 생성하고 Istio가 이를 새로운 정책으로 사용하도록 지정하면 클러스터 전체에 이 정책을 적용할 수 있습니다.

Istio는 기본적으로 신원, 정책, 암호화를 제공하며, 인증, 권한 부여, 감사(AAA) 기능도 지원합니다. Istio로 관리되는 모든 파드는 서로 통신 시 암호화된 트래픽을 사용하여 외부의 관찰을 방지합니다. 암호화와 결합된 신원 서비스는 승인되지 않은 사용자가 서비스 호출을 위조(스푸핑)하지 못하도록 보장합니다. AAA는 보안 및 운영 담당자에게 낮은 오버헤드로 모니터링할 수 있는 툴을 제공합니다.

전통적인 애플리케이션도 여전히 Istio가 제공하는 신원, 정책, 보안 기능이 필요합니다. 이는 프로그래머와 관리자가 잘못된 추상화 수준에서 작업하게 하며, 각 서비스마다 동일한 보안 규칙을 반복해서 구현하게 만듭니다. Istio는 단일 제어판을 통해 클러스터 전체에 대한 정책을 설정할 수 있도록 하여 올바른 추상화 수준에서 작업할 수 있게 해줍니다.