CloudNet 가시다님이 진행하시는 KANS 스터디 7주차 정리입니다.
[ 실습 환경 구성 ]
구성 : VPC 1개(퍼블릭 서브넷 2개), EC2 인스턴스 3대(Ubuntu 22.04 LTS, t3.xlarge - vCPU 4, Mem 16), testpc 1대는 t3.small
[ 1. Istio 소개 ]
▶ 서비스 메시(Service Mesh)
- 등장 배경 : 마이크로서비스 아키텍처 환경의 시스템 전체 모니터링의 어려움, 운영 시 시스템 장애나 문제 발생할 때 원인과 병목 구간 찾기 어려움
- 서비스 메시란?
: 애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층. 이 계층은 컨테이너화된 마이크로서비스로 구성된다. 애플리케이션이 확장되고 마이크로서비스의 수가 증가함에 따라 서비스의 성능을 몬터링하기가 점점 어려워지고 있다. 서비스 메시는 서비스 간 연결을 관리하기 위해 모니터링, 추적, 로깅, 트래픽 제어와 같은 기능을 제공한다. - 서비스 메시가 필요한 이유?
: 현대적 애플리케이션 아키텍처에서는 독립적으로 배포 가능한 소규모 마이크로서비스 모음으로 애플리케이션을 구축할 수 있다. 애플리케이션 성능은 서비스 간 통신의 속도와 탄력성에 따라 좌우된다. 개발자는 서비스 전반에서 애플리케이션을 모니터링하고 최적화해야 하지만, 시스템의 분산된 특성 때문에 가시성을 확보하기 어렵다. - 서비스 메시를 사용 시 이점
1) 서비스 검색 에 자동화된 서비스 검색을 제공하여 서비스 엔드포인트 관리의 운영 부하를 줄인다. 서비스 레지스트리를 사용하여 메시 내의 모든 서비스를 동적으로 검색하고 추적한다.
2) 로드 밸런싱 : 서비스 메시는 라운드 로빈, 최소 연결 또는 가중치 로드 밸런싱과 같은 다양한 알고리즘을 사용하여 요청을 여러 서비스 인스턴스에 지능적으로 분산한다. 로드 밸런싱은 리소스 활용도를 높이고 고가용성 및 확장성을 보장한다.
3) 트래픽 관리 : 요청 라우팅 및 트래픽 동작을 세밀하게 제어할 수 있는 고급 트래픽 관리 기능을 제공한다.
4) 트래픽 분할 : 들어오는 트래픽을 서로 다른 서비스 버전 또는 구성 간에 분할할 수 있다. 메시는 일부 트래픽을 업데이트된 버전에 전달하므로 변경 사항을 제어하고 점진적으로 적용할 수 있다.
5) 미러링 요청 : 기본 요청 흐름에 영향을 주지 않으면서 분석을 위해 테스트 또는 모니터링 서비스에 트래픽을 복제할 수 있다. 요청을 미러링하면 서비스가 프로덕션 트래픽에 영향을 미치지 않으면서 특정 요청을 처리하는 방법을 파악할 수 있다.
6) 카나리 배포 : 대부분의 사용자가 기존의 안정적인 버전을 계속 사용하면서 일부 사용자 또는 트래픽을 새 서비스 버전에 전달할 수 있다.
7) 보안 : 서비스 메시는 상호 TLS(mTLS) 암호화, 인증 및 권한 부여와 같은 보안 통신 기능을 제공한다. 상호 TLS를 사용하면 서비스 간 통신에서 ID를 검증할 수 있다. 트래픽을 암호화하여 데이터 기밀성과 무결성을 보장하는 데 도움이 된다.
8) 모니터링 : 서비스 메시는 포괄적인 모니터링 및 관찰성 기능을 제공하여 서비스의 상태, 성능 및 행동에 대한 인사이트를 도출할 수 있다.
- 지연 시간, 오류율, 리소스 사용률과 같은 지표를 수집하여 전체 시스템 성능을 분석
- 분산 추적을 수행하여 여러 서비스 전반에서 요청의 전체 경로와 시간을 확인
- 감사, 디버깅 및 규정 준수를 위해 로그에 서비스 이벤트 캡처
- 기본 동작 : 파드 간 통신 경로에 프록시를 놓고 트래픽 모니터링이나 트래픽 컨트롤 -> 기존 애플리케이션 코드에 수정 없이 구성 가능
1. 기존 통신 환경
2. 애플리케이션 수정 없이, 모든 애플리케이션 통신 사이에 Proxy를 두고 통신 해보자
- 파드 내에 사이드카 컨테이너로 주입되어서 동작
- Proxy 컨테이너가 Application 트래픽을 가로채야됨 -> iptables rule 구현
3. Proxy는 결국 DataPlane이니, 이를 중앙에서 관리하는 ControlPlane을 두고 중앙에서 관리하자
- Proxy는 중앙에서 설정 관리가 잘되는 툴을 선택. 즉, 원격에서 동적인 설정 관리가 유연해야함 -> 풍부한 API 지원이 필요 => Envoy
- '구글 IBM 리프트(lyft)'가 중심이 되어 개발하고 있는 오픈 소스 소프트웨어이며, C++로 구현된 고성능 Proxy인 엔보이(Envoy)
- 네트워크의 투명성을 목표, 다양한 필터체인 지원(L3/L4, HTTP L7), 동적 configuration API 제공, api 기반 host reload 제공
- 트래픽 모니터링 : 요청의 '에러율, 레이턴시, 커넥션 개수, 요청 개수' 등 메트릭 모니터링, 특정 서비스간 혹은 특정 요청 경로로 필터링
- 트래픽 컨트롤 : 트래픽 시프팅(Traffic shifting), 서킷 브레이커(Circuit Breaker), 폴트 인젝션(Fault Injection), 속도 제한(Rate Limit)
- 트래픽 시프팅(Traffic shifting) : 예시) 99% 기존앱 + 1% 신규앱, 특정 단말/사용자는 신규앱에 전달하여 단계적으로 적용하는 카나리 배포 가능
- 서킷 브레이커(Circuit Breaker) : 목적지 마이크로서비스에 문제가 있을 시 접속을 차단하고 출발지 마이크로서비스에 요청 에러를 반환 (연쇄 장애, 시스템 전체 장애 예방)
- 폴트 인젝션(Fault Injection) : 의도적으로 요청을 지연 혹은 실패를 구현
- 속도 제한(Rate Limit) : 요청 개수를 제한
▶ 이스티오(Istio) 소개
- Istion 구성요소와 envoy : 컨트롤 플레인(istiod), 데이터 플레인(istio-proxy -> envoy)
- istiod : Pilot(데이터 플레인과 통시낳면서 라우팅 규칙을 동기화, ADS), Gally(Istio와 K8s 연동, Endpoint 갱신 등), Citadel(연결 암호화, 인증서 관리 등)
- Istion proxy : Golang으로 작성되었고 envoy 래핑한 Proxy, istiod와 통신하고 서비스 트래픽을 통제, 옵저버빌리티를 위한 메트릭 제공
- 이스티오는 각 파드 안에 사이드카로 엔보이 프록시가 들어가 있는 형태
- 모든 마이크로서비스간 통신은 엔보이를 통과하여, 메트릭을 수집하거나 트래픽 컨트롤을 할 수 있음
- 트래픽 컨트롤을 하기위해 엔보이 프록시에 전송 룰을 설정 -> 컨트롤 플레인의 이스티오가 정의된 정보를 기반으로 엔보이 설정을 하게 함
- 마이크로서비스 간의 통신을 mutual TLS인증(mTLS)으로 서로 TLS 인증으로 암호화 할 수 있음
- 각 애플리케이션은 파드 내의 엔보이 프록시에 접속하기 위해 localhost에 TCP 접속을 함
[ 2. Envoy ]
▶ 소개 : L4/7 Proxy, Istio의 Sidecar proxy로 사용
- Istio 구성요소와 envoy : 컨트롤 플레인(istiod) - ADS를 이용한 Configuration 동기화 - 데이터 플레인(istio-proxy -> envoy)
- Cluster : envoy가 트래픽을 포워드할 수 있는 논리적인 서비스(엔드포인트 세트), 실제 요청이 처리되는 IP 또는 엔드포인트의 묶음을 의미
- Endpoint : IP주소, 네트워크 노드로 클러스터를 그룹핑됨, 실제 접근이 가능한 엔드포인트를 의미. 엔드포인트가 모여서 하나의 Cluster가 된다
- Listener : 무엇을 받을지 그리고 어떻게 처리할지 IP/Port 를 바인딩하고, 요청 처리 측면에서 다운스트림을 조정하는 역할
- Route : Listener로 들어온 요청을 어디로 라우팅할 것인지를 정의. 라우팅 대상은 일반적으로 Cluster라는 것에 대해 이뤄지게 된다.
- Filter : Listener로부터 서비스에 트래픽을 전달하기까지 요청 처리 파이프라인
- UpStream : envoy 요청을 포워딩해서 연결하는 백엔드 네트워크 노드 - 사이드카일때 application app, 아닐때 원격 백엔드
- DownStream : An entity connecting to envoy, In non-sidecar models this is a remote client
Envoy는 구성을 동적으로 관리하기 위한 강력한 API를 제공이 중요합니다.
(Listeners -> Routes -> Clusters -> Endpoints)
- Service Mesh 솔루션이나, Gateway API 구현체들을 Envoy를 내부적으로 사용하고 있으며, Envoy가 제공하는 동적 구성을 위한 API (xDS Sync API)를 이용하여 다양한 네트워크 정책을 구성하게 됩니다.
- Envoy의 xDS Sync API는 아래와 같은 레이어에서 동작하게 됩니다.
- LDS - Listener Discovery Service
- RDS - Route Discovery Service
- CDS - Cluster Discovery Service
- EDS - Endpoint Discovery Service
▶ testpc에 Envoy 설치
▶ Envoy proxy 실습
certs - print certs on machine
clusters - upstream cluster status
config_dump - dump current Envoy configs (experimental)
contention - dump current Envoy mutex connection stats (if enabled)
cpuprofiler - enalbe/disable the CPu profiler
drain_listeners - drain listeners
healthcheck/fail - cause the server to fail health checks
healthcheck/ok - cause the server to pass health checks
heapprofiler - enable/disable the heap profiler
3. Istio 설치 (Sidecar mode)
▶ Istio Sidecar mode 설치 : v1.23.2
- Auto Injection with namespace label : 해당 네임스페이스에 생성되는 모든 파드들은 istio 사이드카가 자동으로 injection 됨
▶ Istio 접속 테스트를 위한 변수 지정
- testpc
- 자신 PC
4. Istio 통한 외부 노출
▶ Nginx 디플로이먼트와 서비스 배포
▶ Istio Gateway/VirtualService 설정 - Host 기반 트래픽 라우팅 설정
- 클라이언트 PC -> (Service:NodePort) Istio ingressgateway 파드 -> (Gateway, VirtualService, Service는 Bypass) -> Endpoint(파드 : 사이드카 - Nginx)
- Gateway : 지정한 인그레스 게이트웨이로부터 트래픽이 인입, 프로토콜 및 포트, HOSTS, Proxy 등 설정 가능
- VirtualService : 인입 처리할 hosts 설정, L7 PATH 별 라우팅, 목적지에 대한 정책 설정 가능(envoy route config)
- Introducing Istio v1 APIs
▶ Istio를 통한 Nginx 파드 접속 테스트
- pilot : istio-proxy 내 uds로 envoy와 grpc 통신, istiod 받아온 dynamic config를 envoy에 전달
▶ debug : 파드 디버깅
▶ Istio - Envoy xDS(x Discovery Service, Dynamic API Configuration)
- 동적으로 각 영역의 설정을 로드하는 방법
- Management 서비스(Istiod)와 통신하면서 configuration을 갱신 : Istod - [Istop-proxy <-> envoy]
- gRPC, REST 방식 모드 지원
- CSD(Clusters), LDS(Listeners), EDS(Endpoints), RDS(Routes)-> Discovery Service => ADS(Aggregation Discovery Service) <-> Istiod
- Incremental xDS ( 참고 : https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol#incremental-xds)
- Delta xDS now on by default (참고 : https://istio.io/latest/news/releases/1.22.x/announcing-1.22/#delta-xds-now-on-by-default)
▶ Istio - Istio proxy와 Envoy 프로세스간 '유닉스 도메인 소켓 통신' 환경을 실습으로 확인
5. Bookinfo 실습 & Istio 기능
5.1 Bookinfo
▶ Bookinfo 애플리케이션 소개 : 4개의 마이크로서비스로 구성 : Productpage, reviews, ratings, details
- ProductPage 페이지에서 요청을 받으면, 도서 리뷰를 보여주는 Revies 서비스와 도서 상세 정보를 보여주는 Details 서비스에 접속하고
- ProductPage는 Reviews와 Details 결과를 사용자에게 응답한다
- Reviews 서비스는 v1, v2, v3 세 개의 버전이 있고 v2, v3 버전의 경우 Ratings 서비스에 접속하여 도서에 대한 5단계 평가를 가져옴
- Reviews 서비스의 차이는 v1은 Rating이 없고, v2는 검은색 별로 Ratings가 표시되며, v3는 색깔이 있는 별로 Ratings가 표시됨
▶ Bookinfo 애플리케이션 배포
5.2 Istio를 통한 인입 기본 설정
▶ Istio Gateway/VirtualService 설정
▶ Istio를 통한 productpage 접속(반복) 테스트 & 웹 브라우저 접속 테스트
- k3s-s NodePort 접속 확인
- 자신의 PC에서 접속 확인
5.3 모니터링
▶ Kiali (키알리) 소개 : 주 데이터 소스(Prometheus, Jaeger)
- Kiali is an observability console for Istio with service mesh configuration and validation capabilities.
Kiali provides detailed metrics and a basic Grafana integration, which can be used for advanced queries.
Distributed tracing is provided by integration with Jaeger.
- Jaeger 와 연동을 통해서 분산 트레이싱을 제공할 수 있다
- Monitoring port of the IstioD pod : Kiali connects directly to the IstioD pod (not the Service) to check for its health.
By default, the connection is done to port 15014 which is the default monitoring port of the IstioD pod.
- 파드의 헬스체크는 Kiali가 직접 IstioD 파드에 TCP Port 15014를 통해서 체크한다
- Prometheus, Jaeger and Grafana
Prometheus and Jaeger are primary data sources for kiali.
This page describes how to configure Kiali to communicate with these dependecies.
A minimalistic Grafana integration is also available.- 주 데이터 소스는 Prometheus and Jaeger이며, 최소 수준의 Grafana와 연동할 수 있다
▶ Addon 설치 : Kiali(키알리) 대시보드 along with Promethues, Grafana, and Jaeger
- Istion integrates with several different telemetry applications. These can help you gain an understanding of the structure of your service mesh, display the topology of the mesh, and analyze the health of your mesh.
- Use the following instructions to deploy the Kiali dashboard, along with Prometheus, Grafana, and jaeger.
