Istio의 Dark 출시: 비밀 서비스

국제적인 미스터리 인물인 오스틴 파워스는 “위험이 나의 중간 이름이다”라고 말하곤 했습니다. 그러나 슈퍼 에이전트와 정보 기관이 높이 평가하는 것은 지루함이 위험보다 훨씬 나은 컴퓨터 서비스에는 전혀 적합하지 않습니다.

그리고 Istio는 OpenShift 및 Kubernetes와 함께 마이크로서비스 배포를 정말 지루하고 예측 가능하게 만듭니다. 정말 좋습니다. Istio 시리즈의 네 번째이자 마지막 게시물에서 이에 대해 더 자세히 이야기하겠습니다.

지루함이 맞을 때

우리의 경우 지루함은 마지막 단계에서만 발생합니다. 남은 것은 앉아서 과정을 지켜보는 것뿐입니다. 하지만 이를 위해서는 먼저 모든 것을 구성해야 하며 여기서는 많은 흥미로운 것들이 여러분을 기다리고 있습니다.

새 버전의 소프트웨어를 배포할 때는 위험을 최소화하기 위한 모든 옵션을 고려해 볼 가치가 있습니다. 병렬 실행은 매우 강력하고 입증된 테스트 방법이며, Istio를 사용하면 "비밀 서비스"(마이크로서비스의 숨겨진 버전)를 사용하여 프로덕션 시스템을 방해하지 않고 이를 수행할 수 있습니다. 이에 대한 특별한 용어인 "Dark Launch"도 있는데, 이는 동일한 스파이 이름인 "트래픽 미러링"을 가진 기능에 의해 활성화됩니다.

이전 단락의 첫 번째 문장에서는 "릴리스" 대신 "배포"라는 용어를 사용하고 있습니다. 원하는 만큼 자주 마이크로서비스를 배포하고 사용할 수 있어야 합니다. 이 서비스는 트래픽을 수신 및 처리하고, 결과를 생성하고, 로그에 기록하고 모니터링할 수 있어야 합니다. 그러나 동시에 이 서비스 자체가 반드시 프로덕션 환경으로 출시될 필요는 없습니다. 소프트웨어 배포와 출시가 항상 같은 것은 아닙니다. 원할 때마다 배포할 수 있지만 준비가 되었을 때만 릴리스하세요.

지루함을 정리하는 것은 흥미롭다

모든 HTTP 요청을 마이크로서비스 권장사항 v1로 라우팅하는 다음 Istio 라우팅 규칙을 살펴보세요(모든 예는 다음에서 가져옴). Istio 튜토리얼 GitHub 저장소) 동시에 권장사항 v2 마이크로서비스에 미러링합니다.

라벨에 주의하세요 mirror: 화면 하단 - 트래픽 미러링을 설정하는 것입니다. 예, 정말 간단합니다!

이 규칙의 결과는 프로덕션 시스템(v1)이 들어오는 요청을 계속 처리하지만 요청 자체는 v2에 비동기식으로 미러링되는 것입니다. 즉, 완전한 복제본이 v2로 이동하게 됩니다. 이렇게 하면 프로덕션 시스템의 작동을 어떤 식으로든 방해하지 않고 실제 조건(실제 데이터 및 트래픽)에서 vXNUMX를 테스트할 수 있습니다. 이로 인해 테스트 구성이 지루해 집니까? 네, 물론이죠. 그러나 그것은 흥미로운 방식으로 이루어졌습니다.

드라마를 추가하자

v2 코드에서는 들어오는 요청으로 인해 데이터가 변경될 수 있는 상황을 제공해야 합니다. 요청 자체는 쉽고 투명하게 미러링되지만 테스트에서 처리 방법을 선택하는 것은 귀하에게 달려 있으며 이는 약간 걱정스럽습니다.

중요한 점을 다시 말씀드리겠습니다

트래픽 미러링(Dark Launch/Request Mirroring)을 사용한 비밀 실행은 어떤 방식으로든 코드에 영향을 주지 않고 수행할 수 있습니다.

생각할 거리

요청이 미러링되는 곳에서 요청 중 일부를 v1이 아닌 v2로 보내면 어떻게 되나요? 예를 들어 전체 요청의 2% 또는 특정 사용자 그룹의 요청만 해당됩니다. 그런 다음 v1의 작동 방식을 이미 살펴보고 점차적으로 모든 요청을 새 버전으로 전송합니다. 또는 그 반대로 v2에 문제가 있으면 모든 것을 vXNUMX로 되돌립니다. 카나리아 배포라고 하는 것 같아요. 다시 채굴하러 갑니다, 그리고 그것이 러시아 출신이라면 아마도 다음에 대한 언급이 포함될 것입니다. 고양이), 이제 이에 대해 더 자세히 살펴 보겠습니다.

Istio의 Canary 배포: 커미셔닝 단순화

조심스럽게 차근차근

Canary 배포 배포 모델의 본질은 매우 간단합니다. 소프트웨어의 새 버전(이 경우 마이크로서비스)을 시작할 때 먼저 소규모 사용자 그룹에게 해당 버전에 대한 액세스 권한을 부여합니다. 모든 것이 순조롭게 진행되면 새 버전이 작동하기 시작할 때까지 이 그룹을 천천히 늘리거나, 그렇지 않은 경우 결국 모든 사용자를 해당 그룹으로 마이그레이션합니다. 신중하고 점진적으로 새 버전을 도입하고 통제된 방식으로 사용자를 해당 버전으로 전환하면 위험을 줄이고 피드백을 극대화할 수 있습니다.

물론 Istio는 지능형 요청 라우팅을 위한 몇 가지 좋은 옵션을 제공하여 Canary 배포를 단순화합니다. 그렇습니다. 이 모든 작업은 어떤 방식으로든 소스 코드를 건드리지 않고도 수행할 수 있습니다.

브라우저 필터링

가장 간단한 라우팅 기준 중 하나는 브라우저 기반 리디렉션입니다. Safari 브라우저의 요청만 v2로 이동하려고 한다고 가정해 보겠습니다. 수행 방법은 다음과 같습니다.

이 라우팅 규칙을 적용한 후 다음 명령을 사용해 보겠습니다. curl 루프에서 마이크로서비스에 대한 실제 요청을 시뮬레이션합니다. 스크린샷에서 볼 수 있듯이 모두 v1로 이동합니다.

v2의 트래픽은 어디에 있나요? 이 예에서는 모든 요청이 자체 명령줄에서만 왔기 때문에 단순히 존재하지 않습니다. 하지만 위 화면의 결론에 주의하세요. 이는 Safari 브라우저에서 요청을 실행했다는 사실에 대한 반응이며 결과적으로 다음과 같습니다.

무제한의 힘

우리는 정규식이 요청 라우팅을 위한 매우 강력한 기능을 제공한다고 이미 작성했습니다. 다음 예를 살펴보십시오(무슨 일을 하는지 이해하실 것입니다).

이제 당신은 아마도 정규 표현식이 무엇을 할 수 있는지에 대해 알게 될 것입니다.

현명하게 행동하라

특히 정규식을 사용하여 패킷 헤더를 처리하는 스마트 라우팅을 사용하면 원하는 방식으로 트래픽을 조정할 수 있습니다. 이는 새 코드의 구현을 크게 단순화합니다. 간단하고 코드 자체를 변경할 필요가 없으며 필요한 경우 모든 것을 원래대로 신속하게 반환할 수 있습니다.

관심이 있으십니까?

컴퓨터에서 Istio, Kubernetes 및 OpenShift를 실험하고 싶으십니까? 팀 Red Hat 개발자 팀 훌륭하게 준비했다 교과서 이 주제에 대해 설명하고 모든 관련 파일을 공개적으로 사용할 수 있도록 했습니다. 그러니 계속해서 자신을 부인하지 마십시오.
 

Istio Egress: 기념품 가게를 통해 출구

Istio를 Red Hat OpenShift 및 Kubernetes와 함께 사용하면 마이크로서비스를 훨씬 쉽게 사용할 수 있습니다. Istio의 서비스 메시는 Kubernetes 포드 내부에 숨겨져 있으며 코드는 (대부분) 격리된 상태로 실행됩니다. 성능, 변경 용이성, 추적 등 - 사이드카 컨테이너를 사용하면 이 모든 기능을 쉽게 사용할 수 있습니다. 하지만 마이크로서비스가 OpenShift-Kubernetes 시스템 외부에 있는 다른 서비스와 통신해야 한다면 어떻게 될까요?

이것이 바로 Istio Egress가 구출되는 곳입니다. 간단히 말해서, Kubernetes 포드 시스템의 일부가 아닌 리소스("서비스" 읽기)에 액세스할 수 있게 해줍니다. 추가 구성을 수행하지 않으면 Istio Egress 환경에서 트래픽은 Pod 클러스터 내에서만 내부 IP 테이블을 기반으로 하는 클러스터 간에 라우팅됩니다. 그리고 이러한 번데기는 외부 서비스에 액세스할 필요가 없는 한 훌륭하게 작동합니다.

송신을 사용하면 송신 규칙이나 IP 주소 범위를 기반으로 위의 IP 테이블을 우회할 수 있습니다.

httpbin.org/headers에 GET 요청을 보내는 Java 프로그램이 있다고 가정해 보겠습니다.

(httpbin.org는 나가는 서비스 요청을 테스트하기 위한 편리한 리소스일 뿐입니다.)

명령줄에 입력하면 curl http://httpbin.org/headers, 다음 내용을 볼 수 있습니다.

또는 브라우저에서 동일한 주소를 열 수 있습니다.

보시다시피, 해당 서비스는 단순히 전달된 헤더를 반환합니다.

수입대체 정면승부

이제 시스템 외부에 있는 이 서비스의 Java 코드를 가져와 Istio가 설치된 자체적으로 실행해 보겠습니다. (이 작업은 직접 문의하여 수행할 수 있습니다. Istio 튜토리얼.) 적절한 이미지를 구축하고 OpenShift 플랫폼에서 실행한 후 다음 명령을 사용하여 이 서비스를 호출합니다. curl egresshttpbin-istioegress.$(minishift ip).nip.io, 그 후에 화면에 다음이 표시됩니다.

이런, 무슨 일이 일어났나요? 모든 것이 잘 작동했습니다. 찾을 수 없음은 무엇을 의미하나요? 우리가 그 사람을 위해 그랬을 뿐이야 curl.

IP 테이블을 전체 인터넷으로 확장

이에 대해 Istio를 비난(또는 감사)해야 합니다. 결국 Istio는 탐지 및 라우팅(그리고 앞서 이야기한 다른 많은 사항)을 담당하는 사이드카 컨테이너일 뿐입니다. 이러한 이유로 IP 테이블은 클러스터 시스템 내부의 내용만 알고 있습니다. 그리고 httpbin.org는 외부에 있으므로 접근이 불가능합니다. 그리고 이것이 소스 코드를 조금도 변경하지 않고 Istio Egress가 구출되는 곳입니다.

아래 Egress 규칙은 Istio가 필요한 서비스(이 경우 httpbin.org)를 검색하도록 강제합니다(필요한 경우 전체 인터넷을 통해). 이 파일(egress_httpbin.yml)에서 볼 수 있듯이 여기의 기능은 매우 간단합니다.

남은 것은 이 규칙을 적용하는 것뿐입니다.

istioctl create -f egress_httpbin.yml -n istioegress

다음 명령어를 사용하여 이그레스 규칙을 볼 수 있습니다. istioctl get egressrules:

마지막으로 명령을 다시 실행합니다. 컬 – 그리고 우리는 모든 것이 작동하는 것을 봅니다:

우리는 공개적으로 생각합니다

보시다시피 Istio를 사용하면 외부 세계와의 상호 작용을 구성할 수 있습니다. 즉, 여전히 OpenShift 서비스를 생성하고 Kubernetes를 통해 관리할 수 있으며 필요에 따라 확장 및 축소되는 모든 것을 포드에 유지할 수 있습니다. 동시에 환경 외부의 서비스에도 안전하게 액세스할 수 있습니다. 그렇습니다. 이 모든 작업은 어떤 방식으로든 코드를 건드리지 않고도 수행할 수 있다는 점을 다시 한 번 반복합니다.

이것은 Istio 시리즈의 마지막 게시물이었습니다. 계속 지켜봐 주시기 바랍니다. 앞으로 흥미로운 일이 많이 있을 것입니다!

출처 : habr.com