Chapter 18. 서비스 메시를 사용해 관찰 가능성 및 관리 편의성 개선

[minkukjo]

끄적끄적

• 반가운 이스티오가 나와서 좋았다
• 이스티오의 모델은 경량 프록시 인보이와 컨트롤 플레인 그리고 데이터 플레인으로 이루어진 Architecture 였다.
• 이 모델이 어딘가 쿠버네티스의 마스터 노드와 워커 노드 구조와 비슷해서 "역시 구글이군" 이라는 생각이 절로 났다.
• 이스티오 프록시를 생성하는 방법은 생각보다 간단했다
• 이스티오 컴포넌트는 마치 오픈소스 종합 선물 상자 같았다
• 게이트웨이가 인그레스를 대체하고 버추얼 서비스로 라우팅 하는 구조가 신박했다
• kiali 오픈소스가 직관적이라 좋았다. 그러나 그 어떤 좋은 분산 추적 오픈소스도 jvm 계통이면 메소드 시간까지 측정하는 핀포인트를 이기긴 어려울 것 같다.
• mTLS 상호 인증을 통해 클러스터 내부에 파드들 간의 통신까지 보안을 신경쓴 것이 인상깊었다
• 아웃라이어 디텍션 기능을 서비스 매시에서 사용하기보다는 언어 고유 매커니즘을 사용 하는 게 더 좋다는 것이 인상깊었다
• 비즈니스로직과 오류 처리 로직을 함께 유지보수하는게 더 좋다고 하는데 다른 분들 생각은 어떤지 궁금하다
• 물론 서비스 메시에서 fault나 delay 이용해서 카오스 엔지니어링 환경을 구현하는 점은 굉장히 편리해 보인다
• istio를 활용한 카오스 엔지니어링 경험 사례가 혹시 있나하고 찾아봤더니 aws 윤석찬님 발표 자료도 나오더라. https://www.slideshare.net/Channy/chaos-engineering-in-action-for-kubernates
• 카나리 배포나 블루/그린 배포를 이용해서 기존 버전과 새 버전 간의 배포/롤백 기능을 편리하게 구현할 수 있는 것도 이스티오의 장점인것 같다

개인적인 결론

• 서비스 매시를 활용한 패턴은 분산 추적이나 카오스 엔지니어링, 로깅 환경 구축, 클러스터 모니터링, 배포등과 같이 비즈니스 로직과 무관한 기능들을 구현해야할 때 유효한패턴으로 보인다
• 결국은 코드와 인프라의 분리를 하기 위한 패턴으로 봐야하지 않나 싶음

[MinJunKweon]

느낀점

• Istio 듣기만 했지 실제로 사용해본 적이 없어서 몰랐는데 이번 기회에 개념과 역할을 알 수 있는 계기가 되었음.
• 모든 트래픽을 컨트롤 플레인을 거치게해서 관리한다는 개념은 참 좋은 것 같음
  • Istio를 별도로 사용하지 않고 쿠버네티스 내에서 제공하는 기능이었으면 참 좋았을 것 같음
• 의도적으로 오류나 지연을 삽입해서 장애에 대한 테스트를 쉽게 할 수 있는 점이 가장 큰 강점인듯.
  • 민국님이 공유해주신 카오스 엔지니어링 발표자료 보고 그 중요성을 체감
  • 하지만, Istio를 안쓰고도 테스트 가능한 방식이 있다는 점ㅎㅎ

정리

서비스 간의 통신을 제어하고 관찰하는 인프라 계층

모든 서비스에 사이드카(Sidecar)로 경량 프록시를 사용해서 프록시를 통해서 각 컴포넌트가 통신할 수 있게끔 구성. 이렇게하면 서비스 메시가 모든 트래픽을 제어하고 모니터링할 수 있음

• 구성
  • 컨트롤 플레인 - 런타임에 프록시 컴포넌트를 구성. 데이터를 수집하고 트래픽 흐름을 시각화
  • 데이터 플레인 - 서비스 메시에 속한 전체 컴포넌트와 외부에서 들어오는 트래픽, 나가는 트래픽을 처리하는 별도의 컴포넌트
• 대표적인 서비스 메시 : Linkerd, Istio
• k8s에서 istio를 배포하면 별도의 네임스페이스(istio-system)에 배포됨
• istioctl 명령어를 제공해서 이스티오 프록시를 삽입할 수 있음.
  • kubectl get deployment sample-deployment -o yaml | istioctl kube-inject -f - | kubectl apply -f -
    • 단순히 3개의 명령어를 파이프로 이어서 istio 서비스메시에 추가 가능
      1. 현재 k8s 클러스터에 배포된 sample-deployment 디플로이먼트를 yaml 형태로 추출해서
      2. istioctl을 통해 이스티오 프록시 컨테이너를 추가함. (기존 컨테이너의 수신, 발신 트래픽을 프록시를 통과하도록 강제하는 역할)
      3. 프록시 컨테이너가 추가된 구성을 k8s에 적용

Istio API (Kubenetes CRD)

• Gateway : 서비스 메시로 들어오고 나가는 트래픽의 처리방법을 구성하는 리소스. 아래 설명할 버추얼 서비스에 의존해서 트래픽을 라우팅함.
• VirtualService : 라우팅 규칙 정의. 안정성과 탄력성 테스트를 위해 오류나 지연을 삽입할 수 있음.
• DestinationRule : 버추얼 서비스에 의해 특정 서비스로 라우팅되는 트래픽에 대한 정책, 규칙을 정의함.
• Policy : 요청 인증 방법을 정의. JWT 기반의 OAuth 2.0/OIDC 접근 토큰을 사용해 인증 할 수 있음. 전체 서비스 메시에 적용되는 글로벌 룰은 MeshPolicy CRD를 사용함.

Istio 아키텍처

Istio 컨트롤 플레인에 구성될 런타임 컴포넌트들

• Pilot : 전체 사이드카로 업데이트된 서비스 메시 구성을 전달함.
• Mixer : 2개의 런타임 컴포넌트로 구성됨.
  • Policy : 인증, 권한 부여, 속도 제한, 할당량 제한 등의 네트워크 정책을 시행
  • Telemetry : 원격 측정 정보를 수집해서 프로메테우스 등으로 보냄.
• Gallery : 구성 정보를 수집, 검증하고 컨트롤 플레인의 다른 이스티오 컴포넌트에 배포
• Citadel : 내부에서 사용하는 인증서의 발급, 교체를 담당
• Kiali : 서비스 메시 진행 중인 작업을 시각화, 검증, 트러블슈팅을 도와주는 컴포넌트. (별도의 오픈소스 프로젝트, https://kiali.io/)
• Prometheus : 성능 메트릭 등등 시계열 기반 데이터를 수집해서 저장함. (별도의 오픈소스 프로젝트)
• Grafana : 프로메테우스에서 수집한 성능 메트릭 및 기타 시계열 관련 테이터를 시각화함
• Tracing : 분산 추적 정보를 처리하고 시각화함. (분산 추적을 위한 오픈 소스 프로젝트 Jaeger 기반)

Istio 데이터 플레인에 구성될 런타임 컴포넌트들

• Ingress Gateway : 서비스 메시로 들어오는 트래픽 처리
• Egress Gateway : 서비스 메시로 나가는 트래픽 처리
• +) 모든 Pod에 이스티오 프록시가 사이드카로 삽입됨.

[LOG-INFO]

끄적끄적

• 트래픽 관리를 해준다길래 어떻게 하나 봤더니 사이드카로 경량프록시를 구성하는 방식이었음. 이거 보고 '와 천재다' 라는 생각이 들었음
  • 생각해보니 nginx, apache 같은 웹서버들도 비슷하게 되어있었군
• 크게 컨트롤 플레인, 데이터 플레인으로 나뉨
  • 컨트롤 플레인에는 여러 유용한 런타임 컴포넌트가 있음
  • 데이터 플레인은 각 컴포넌트들(+프록시)과 InBound/OutBound 트래픽을 관리함
• 오 Kiali에서 각 요청 하나하나가 시각화되는거 쩐다...!
  • Jaeger도 Kiali에 내장되어있군
  • 핀포인트보다 얘네가 나을려나..?!