Istio Service Mesh에 대한 일련의 게시물

우리는 Red Hat OpenShift 및 Kubernetes와 결합된 Istio Service Mesh의 다양한 기능 중 일부를 보여주는 일련의 게시물을 시작합니다.

오늘 XNUMX부:

• Kubernetes 사이드카 컨테이너의 개념을 설명하고 이 게시물 시리즈의 주요 주제를 공식화해 보겠습니다. "코드에서 아무것도 변경할 필요가 없습니다".
• Istio의 기본인 라우팅 규칙을 소개하겠습니다. 다른 모든 Istio 기능은 서비스 코드 외부의 YAML 파일을 사용하여 마이크로서비스로 트래픽을 전달할 수 있는 규칙이므로 이를 기반으로 구축되었습니다. Canary 배포 배포 방식도 고려하고 있습니다. 새해 보너스 – Istio에 대한 10개의 대화형 강의

곧 공개될 XNUMX부에서는 다음 내용을 알려드립니다.

• Istio가 회로 차단기와 함께 풀 배출을 구현하는 방법과 Istio를 사용하여 밸런싱 회로에서 작동하지 않거나 성능이 낮은 포드를 제거하는 방법을 보여줍니다.
• 또한 첫 번째 게시물의 Circuit Breaker 주제를 살펴보고 여기에서 Istio를 어떻게 사용할 수 있는지 살펴보겠습니다. 서비스 코드를 약간 변경하지 않고도 YAML 구성 파일과 터미널 명령을 사용하여 트래픽을 라우팅하고 네트워크 오류를 처리하는 방법을 보여 드리겠습니다.

XNUMX부:

• Istio에 이미 내장되어 있거나 쉽게 추가되는 추적 및 모니터링에 대한 이야기입니다. Prometheus, Jaeger, Grafana 등의 도구를 OpenShift 확장과 함께 사용하여 마이크로서비스 아키텍처를 손쉽게 관리하는 방법을 보여드리겠습니다.
• 우리는 오류를 모니터링하고 처리하는 것에서 의도적으로 오류를 시스템에 도입하는 것으로 이동합니다. 즉, 소스 코드를 변경하지 않고 오류 주입을 수행하는 방법을 배웁니다. 이는 테스트 관점에서 매우 중요합니다. 이를 위해 코드 자체를 변경하면 추가 오류가 발생할 위험이 있기 때문입니다.

마지막으로 Istio Service Mesh의 마지막 게시물에서는 다음과 같습니다.

• 다크사이드로 갑시다. 보다 정확하게는 코드가 프로덕션 데이터에 직접 배포되고 테스트되지만 시스템 작동에는 어떤 방식으로도 영향을 미치지 않는 Dark Launch 구성표를 사용하는 방법을 배웁니다. 이것이 Istio의 트래픽 분할 기능이 유용한 곳입니다. 그리고 어떤 방식으로든 전투 시스템의 작동에 영향을 주지 않고 실시간 생산 데이터를 테스트할 수 있는 능력이 가장 설득력 있는 검증 방법입니다.
• Dark Launch를 기반으로 Canary 배포 모델을 사용하여 위험을 줄이고 새 코드를 프로덕션에 더 쉽게 적용하는 방법을 보여 드리겠습니다. Canary 배포 자체는 새로운 것이 아니지만 Istio를 사용하면 간단한 YAML 파일만으로 이 체계를 구현할 수 있습니다.
• 마지막으로, 인터넷 작업 시 Istio의 기능을 사용할 수 있도록 Istio Egress를 사용하여 클러스터 외부에 있는 사용자에게 서비스에 대한 액세스 권한을 부여하는 방법을 보여 드리겠습니다.

자, 여기 갑니다...

Istio 모니터링 및 관리 도구 - 서비스 메시에서 마이크로서비스를 조율하는 데 필요한 모든 것 서비스 메시.

Istio 서비스 메시란 무엇입니까?

서비스 메시는 트래픽 모니터링, 액세스 제어, 검색, 보안, 내결함성 및 서비스 그룹에 대한 기타 유용한 기능과 같은 기능을 구현합니다. Istio를 사용하면 서비스 자체의 코드를 조금도 변경하지 않고도 이 모든 작업을 수행할 수 있습니다. 마술의 비결은 무엇입니까? Istio는 사이드카 컨테이너(사이드카는 오토바이 사이드카) 형태로 각 서비스에 자체 프록시를 연결한 후 이 서비스에 대한 모든 트래픽이 프록시를 통과하며, 프록시는 지정된 정책에 따라 이 트래픽의 방법, 시기 및 여부를 결정합니다. 서비스에 전혀 도달해야합니다. 또한 Istio를 사용하면 카나리아 배포, 회로 차단기, 결함 주입 등과 같은 고급 DevOps 기술을 구현할 수 있습니다.

Istio가 컨테이너 및 Kubernetes와 작동하는 방식

Istio 서비스 메시는 모니터링, 추적, 회로 차단기, 라우팅, 로드 밸런싱, 결함 주입, 재시도, 시간 초과, 미러링, 액세스 제어, 속도 제한 등 마이크로서비스를 생성하고 관리하는 데 필요한 모든 것을 사이드카로 구현한 것입니다. 오늘날 이러한 기능을 코드에서 직접 구현하는 수많은 라이브러리가 있지만 Istio를 사용하면 코드에서 아무것도 변경하지 않고도 동일한 기능을 모두 얻을 수 있습니다.

사이드카 모델에 따르면 Istio는 Linux 컨테이너에서 실행됩니다. Kubernetes-Pod는 제어된 서비스를 제공하며 주어진 구성에 따라 기능과 정보를 주입하고 추출합니다. 이는 사용자 고유의 구성이며 코드 외부에 존재한다는 점을 강조합니다. 따라서 코드가 훨씬 간단해지고 짧아집니다.

또한 중요한 점은 마이크로서비스의 운영 구성 요소가 코드 자체와 전혀 연결되어 있지 않다는 점입니다. 이는 해당 운영이 IT 전문가에게 안전하게 이전될 수 있음을 의미합니다. 실제로 개발자가 회로 차단기와 결함 주입을 담당해야 하는 이유는 무엇입니까? 예, 반응하지만 처리하고 생성하시겠습니까? 코드에서 이 모든 것을 제거하면 프로그래머는 애플리케이션 기능에 전적으로 집중할 수 있습니다. 그리고 코드 자체도 더 짧아지고 단순해질 것입니다.

서비스 메시

코드 외부에서 마이크로서비스 관리 기능을 구현하는 Istio는 Service Mesh의 개념입니다. 즉, 네트워크 기능의 메시를 형성하는 하나 이상의 바이너리로 구성된 그룹입니다.

Istio가 마이크로서비스와 작동하는 방식

사이드카 컨테이너의 작업은 다음과 같습니다. Kubernetes и 미니시프트 조감도: Minishift 인스턴스를 시작하고, Istio용 프로젝트("istio-system"이라고 함)를 생성하고, 모든 Istio 관련 구성 요소를 설치 및 실행합니다. 그런 다음 프로젝트와 포드를 생성할 때 배포에 구성 정보를 추가하면 포드에서 Istio를 사용하기 시작합니다. 단순화된 다이어그램은 다음과 같습니다.

이제 결함 주입, 지원 등을 구성하기 위해 Istio 설정을 변경할 수 있습니다. 카나리아 배포 또는 기타 Istio 기능 - 애플리케이션 자체의 코드를 건드리지 않고도 이 모든 기능을 수행할 수 있습니다. 가장 큰 클라이언트(Foo Corporation) 사용자의 모든 웹 트래픽을 사이트의 새 버전으로 리디렉션한다고 가정해 보겠습니다. 이렇게 하려면 사용자 ID에서 @foocorporation.com을 찾아 그에 따라 리디렉션하는 Istio 라우팅 규칙을 생성하면 됩니다. 다른 모든 사용자에게는 아무 것도 변경되지 않습니다. 그동안 귀하는 사이트의 새 버전을 침착하게 테스트하게 될 것입니다. 그리고 이를 위해 개발자를 전혀 참여시킬 필요가 없습니다.

그리고 그에 대한 대가를 치러야 합니까?

별말씀을요. Istio는 매우 빠르며 다음 언어로 작성되었습니다. Go 오버헤드가 거의 발생하지 않습니다. 또한 온라인 생산성 손실 가능성은 개발자 생산성 증가로 상쇄됩니다. 적어도 이론상으로는 개발자의 시간이 소중하다는 점을 잊지 마십시오. 소프트웨어 비용에 관해서는 Istio는 오픈 소스 소프트웨어이므로 무료로 다운로드하여 사용할 수 있습니다.

스스로 마스터하세요

Red Hat 개발자 경험 팀은 심층적인 실습을 개발했습니다. 지도력 Istio(영어)로. Linux, MacOS 및 Windows에서 실행되며 코드는 Java 및 Node.js로 제공됩니다.

Istio에 대한 10가지 대화형 강의

블록 1 - 초보자용

Istio 소개
30 분
Service Mesh에 대해 알아보고 OpenShift Kubernetes 클러스터에 Istio를 설치하는 방법을 알아보세요.
게시

Istio에 마이크로서비스 배포
30 분
우리는 Istio를 사용하여 Spring Boot 및 Vert.x와 함께 세 가지 마이크로서비스를 배포합니다.
게시

블록 2 – 중급 수준

Istio의 모니터링 및 추적
60 분
Istio의 기본 제공 모니터링 도구, 사용자 정의 측정항목, Prometheus 및 Grafana를 통한 OpenTracing을 살펴보겠습니다.
게시

Istio의 간단한 라우팅
60 분
간단한 규칙을 사용하여 Istio에서 라우팅을 관리하는 방법을 알아보세요.
게시

고급 라우팅 규칙
60 분
Istio의 스마트 라우팅, 액세스 제어, 로드 밸런싱 및 속도 제한을 살펴보겠습니다.
게시

블록 3 – 고급 사용자

Istio의 오류 주입
60 분
분산 애플리케이션의 오류 처리 시나리오, HTTP 오류 및 네트워크 지연 생성을 연구하고 카오스 엔지니어링을 사용하여 환경을 복원하는 방법을 배웁니다.
게시

Istio의 회로 차단기
30 분
스트레스 테스트 사이트를 위해 Siege를 설치하고 재생, 회로 차단기 및 풀 배출을 사용하여 백엔드 내결함성을 보장하는 방법을 배웁니다.
게시

송신 및 Istio
10 분
우리는 Egress 경로를 사용하여 내부 서비스와 외부 API 및 서비스의 상호 작용에 대한 규칙을 만듭니다.
게시

이스티오와 키알리
15 분
Kiali를 사용하여 서비스 메시 개요를 확인하고 요청 및 데이터 흐름을 탐색하는 방법을 알아보세요.
게시

Istio의 상호 TLS
15 분
Istio Gateway와 VirtualService를 만든 다음 상호 TLS(mTLS)와 해당 설정을 자세히 연구합니다.
게시

블록 3.1 - 심층 분석: 마이크로서비스용 Istio Service Mesh

그 책 무슨 내용이야:

• 서비스 메시란 무엇입니까?
• Istio 시스템과 마이크로서비스 아키텍처에서의 역할
• Istio를 사용하여 다음 문제를 해결합니다.
  • 결함 허용;
  • 라우팅;
  • 카오스 테스트;
  • 보안;
  • 추적, 측정항목 및 Grafana를 사용한 원격 분석 수집.

책 다운로드

서비스 메시 및 Istio에 관한 기사 시리즈

• Istio 라우팅 규칙: 서비스 요청이 필요한 곳으로 전달
• Isio의 회로 차단기: 풀 배출 처리
• Istio의 회로 차단기: 실패가 옵션인 경우
• Istio의 추적 및 모니터링: 모든 것이 이동하는 위치와 속도
• Istio의 카오스 엔지니어링: 이것이 의도된 방식입니다.
• Istio의 Dark 출시: 비밀 서비스
• Istio의 Canary 배포: 커미셔닝 단순화
• Istio Egress: 기념품 가게를 통해 출구

직접 해보기

이 게시물 시리즈는 Istio의 세계에 대한 심층적인 정보를 제공하기 위한 것이 아닙니다. 우리는 여러분에게 개념을 소개하고 Istio를 직접 사용해 보도록 영감을 주고 싶습니다. 완전히 무료이며 Red Hat은 다음을 포함하여 OpenShift, Kubernetes, Linux 컨테이너 및 Istio를 시작하는 데 필요한 모든 도구를 제공합니다. Red Hat 개발자 OpenShift 컨테이너 플랫폼, Istio 가이드 그리고 우리의 다른 자원 Service Mesh의 마이크로 사이트. 미루지 말고 오늘부터 시작하세요!

Istio 라우팅 규칙: 서비스 요청이 필요한 곳으로 전달

오픈시프트 и Kubernetes 연설을 훌륭하게 해내다 마이크로서비스 필요한 포드로 라우팅됩니다. 이것이 쿠버네티스의 존재 이유 중 하나인 라우팅과 로드 밸런싱입니다. 하지만 좀 더 미묘하고 정교한 라우팅이 필요하다면 어떨까요? 예를 들어 두 가지 버전의 마이크로서비스를 동시에 사용하려는 경우입니다. Istio 경로 규칙이 여기서 어떻게 도움이 될 수 있나요?

라우팅 규칙은 실제로 경로 선택을 결정하는 규칙입니다. 시스템 복잡성 수준에 관계없이 이러한 규칙의 일반적인 작동 원리는 간단합니다. 요청은 특정 매개변수 및 HTTP 헤더 값을 기반으로 라우팅됩니다.
예를 살펴보겠습니다:

Kubernetes 기본값: 사소한 "50/50"

이 예에서는 OpenShift에서 두 가지 버전의 마이크로서비스를 동시에 사용하는 방법을 보여줍니다. 이를 v1과 v2라고 하겠습니다. 각 버전은 자체 Kubernetes Pod에서 실행되며 기본적으로 균등하게 균형 잡힌 라운드 로빈 라우팅을 실행합니다. 각 포드는 마이크로서비스 인스턴스, 즉 복제본 수를 기반으로 요청 공유를 받습니다. Istio를 사용하면 이 잔액을 수동으로 변경할 수 있습니다.

OpenShift에 추천 서비스의 두 가지 버전인 Recommendation-v1과 Recommendation-v2를 배포했다고 가정해 보겠습니다.
그림에서. 그림 1은 각 서비스가 하나의 인스턴스에 표시될 때 요청이 서비스 간에 균등하게 번갈아 나타나는 것을 보여줍니다. 1-2-1-2-... 이는 기본적으로 Kubernetes 라우팅이 작동하는 방식입니다.

버전 간 가중치 분포

그림에서. 그림 2는 v2 서비스 복제본 수를 2에서 2로 늘리면 어떤 일이 발생하는지 보여줍니다(oc scale —replicas=1 development/recommendation-v2 명령을 사용하여 수행됨). 보시다시피, v1과 v2 사이의 요청은 이제 2:1 비율(2-2-XNUMX-XNUMX-XNUMX-XNUMX-…)로 나뉩니다.

Istio를 사용하여 버전 무시

Istio를 사용하면 필요한 방식으로 요청 배포를 쉽게 변경할 수 있습니다. 예를 들어 다음 Istio yaml 파일을 사용하여 Recommendation-v1에만 모든 트래픽을 보냅니다.

여기서 주의할 점은 라벨에 따라 포드가 선택된다는 것입니다. 이 예에서는 레이블 v1을 사용합니다. "weight: 100" 매개변수는 트래픽의 100%가 v1 레이블이 있는 모든 서비스 포드로 라우팅된다는 의미입니다.

버전 간 지시문 배포(Canary 배포)

다음으로, 가중치 매개변수를 사용하면 각 포드에서 실행 중인 마이크로서비스 인스턴스 수를 무시하고 두 포드 모두에 트래픽을 전달할 수 있습니다. 예를 들어 여기에서는 트래픽의 90%를 v1로 보내고 10%를 v2로 보냅니다.

모바일 사용자를 위한 별도의 라우팅

결론적으로 모바일 사용자 트래픽을 강제로 서비스 v2로 라우팅하고 다른 모든 사용자는 v1로 라우팅하는 방법을 보여 드리겠습니다. 이를 위해 정규식을 사용하여 요청 헤더의 사용자 에이전트 값을 분석합니다.

이제 너

헤더 구문 분석을 위한 정규 표현식의 예는 여러분이 Istio 라우팅 규칙을 자신만의 용도로 사용할 수 있는 동기를 부여할 것입니다. 게다가 헤더 값이 애플리케이션 소스 코드에서 형성될 수 있기 때문에 여기서 가능성은 매우 광범위합니다.

Dev가 아니라 Ops라는 점을 기억하세요.

위의 예에서 보여준 모든 것은 특별한 요청 헤더를 생성해야 하는 경우를 제외하고는 소스 코드를 조금도 변경하지 않고 수행됩니다. Istio는 예를 들어 테스트 단계에서 사용할 수 있는 개발자와 프로덕션에 큰 도움이 되는 IT 시스템 운영 전문가 모두에게 유용할 것입니다.

따라서 이 일련의 게시물의 주요 주제를 반복해 보겠습니다. 코드에서 아무것도 변경할 필요가 없습니다. 새 이미지를 빌드하거나 새 컨테이너를 시작할 필요가 없습니다. 이 모든 것은 코드 외부에서 구현됩니다.

너의 상상력을 사용해라

정규식을 사용한 헤더 분석의 가능성을 상상해 보십시오. 가장 큰 고객을 귀하의 특별 버전으로 리디렉션하고 싶습니다. 마이크로서비스? 용이하게! Chrome 브라우저용 별도 버전이 필요합니까? 괜찮아요! 거의 모든 특성에 따라 트래픽을 라우팅할 수 있습니다.

직접 해보기

Istio, Kubernetes 및 OpenShift에 대해 읽는 것도 중요하지만 모든 것을 직접 만져보는 것은 어떨까요? 팀 Red Hat 개발자 프로그램 이러한 기술을 최대한 빨리 익히는 데 도움이 되는 자세한 가이드(영문)를 준비했습니다. 매뉴얼 역시 100% 오픈소스이므로 퍼블릭 도메인에 게시되어 있습니다. 파일은 macOS, Linux 및 Windows에서 작동하며 소스 코드는 Java 및 node.js 버전에서 사용할 수 있습니다(다른 언어 버전도 곧 출시 예정). 브라우저에서 해당 Git 저장소를 엽니다. Red Hat 개발자 데모.

다음 포스트: 우리는 문제를 아름답게 해결합니다

오늘은 Istio 라우팅 규칙이 무엇을 할 수 있는지 살펴보았습니다. 이제 동일한 것을 상상해 보십시오. 단, 오류 처리와 관련된 경우에만 해당됩니다. 이것이 바로 다음 게시물에서 이야기할 내용입니다.

출처 : habr.com