Service Mesh
Service1 POD
ContainerSidecar Proxy
Service2 POD
Container Sidecar Proxy
Service3 POD
Container Sidecar Proxy
§ Microservice간 통신 및 트래픽을 제어하는 Mesh 형태의 Service Network
• Microservice간 통신은 추상적인 Service Network Layer의 Proxy를 통해 수행
• 개별 Proxy는 Service Workload의 내부가 아닌 Workload와 분리된 Sidecar 형태로 구성
• Sidecar Proxy는 연결된 Workload(Container) 대신 타 Service로의 통신 및 트래픽 제어
• Sidecar Proxy간 Mesh Network를 형성 → Service Mesh
Service4 POD
Container Sidecar Proxy
Service5 POD
Container Sidecar Proxy
4.
Istio
TelemetryTraffic Security
• mTLS(양방향 트래픽 암호화)
• Auth (서비스 접근 인증)
• RBAC (권한 제어)
– Namespace
– Service
– Method
• 서비스 Discovery
• Load Balancing
• 트래픽 라우팅
• Failure Handling
• Fault Injection
• HTTP/gRPC/TCP 트래픽 처리
• Monitoring (Metrics 기반)
• Logging
• Tracing
• Telemetry 항목 시각화
• Service Topology 제공
§ Service Mesh 구성 및 관리를 위한 Platform
5.
Istio Data Plane
IstioControl Plane
Istio 컴포넌트
§ Istio Control Plane : Service Mesh Controller 구성
§ Mixer : Telemetry 연동 및 수집, Policy 관리
§ Pilot : Envoy 제어를 통한 서비스 및 트래픽 관리
§ Galley : Istio의 구성 및 설정 검증, 배포 관리
§ Citadel : 보안 관리 및 트래픽 암호화(mTLS) 적용
§ Istio Data Plane : Service Mesh 구성
§ Envoy : 서비스 간 통신 및 트래픽 처리
6.
Service Mesh 테스트용오픈소스
Hipster Shop Microservice Demo
https://github.com/GoogleCloudPlatform/microservices-demo
7.
Service Mesh Architecture
CloudZ
Kubernetes (ZCP)
Users Internet Load Balancer
Istio Control Plane
Istio Data Plane
Pilot Mixer Citadel
Recommendation
Frontend
LoadGenerator Advertise
ProductCatalog
EmailCurrency
Payment
Shipping
Redis-Cart Cart
Checkout
Ingress
Gateway
Galley
Mixer Adapter
§ Adapter는Istio가 Metric/Log/Trace 관리를 위한 Infra Backend에 있는 Telemetry들을 쉽게 연동하기 위한
추상적인 Interface로, Provider별 Template을 제공
10.
Mixer Attribute
§ Attribute는Istio의 Telemetry 연동을 위한 특정 서비스의 Request 또는 Request 환경을 명시하는 속성 정보
(특정 Request의 크기, HTTP 응답 코드, Request Source의 IP 주소 등)
§ 각 Attribute는 Name과 Type이 있으며, Type은 Attribute가 보유하는 데이터의 종류를 정의
request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: [192 168 0 1]
destination.service.name: example
11.
Mixer - Attribute관계
§ Mixer는 본질적으로 Attribute 처리 시스템
§ Envoy Sidecar Proxy는 모든 요청에 대해 Mixer를 호출하여 Request와 연관된 서비스 정보 및 Request 자
체를 설명하는 Attribute를 Mixer에 전달
§ Attribute 정보 기반으로 Mixer는 Telemetry가 있는 다양한 Infra Backend에 대한 호출을 생성
12.
Mixer Config 요소
§Mixer의 Telemetry 기능을 설정하는 3가지 요소
요소 설명 코드 적용 형태
Instance Attribute를 Adapter에 Mapping 설정
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
name: requestduration
namespace: istio-system
spec:
compiledTemplate: metric
params:
value: response.duration | "0ms"
dimensions:
destination_service: destination.service.host | "unknown"
destination_version: destination.labels["version"] | "unknown"
response_code: response.code | 200
monitored_resource_type: '"UNSPECIFIED"'
Handler Adapter에 대한 연동 방식을 설정
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
name: staticversion
namespace: istio-system
spec:
compiledAdapter: listchecker
params:
providerUrl: http://white_list_registry/
blacklist: false
Rule
특정 Adapter로 반영되는 되는 시기 및
Handler에 반영될 Instance를 설정
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: promhttp
namespace: istio-system
spec:
match: destination.service.host == "service1.ns.svc.cluster.local" && request.headers["x-
user"] == "user1"
actions:
- handler: promhandler
instances: [ requestduration ]
13.
Monitoring
Metric 쿼리Metric 수집Metric 시각화
• Grafana를 사용하여 Service
Mesh 트래픽 모니터링 시각화
• Istio Metric 수집 및 처리방식
을 Mixer에서 설정
• Prometheus를 사용하여
저장된 Istio Metric을 쿼리
§ Service Mesh Monitoring을 위한 Istio의 Envoy Proxy Metric은 Mixer에서 수집 및 처리
14.
Metric 수집
§ IstioMixer가 Service Mesh에 대한 Monitoring 설정을 통해 자동으로 Metric을 수집 할 수 있도록 설정
§ Metric 수집이 끝나면 Mixer에서 관리되는 Metric을 Prometheus에 전달되어 조회 가능
15.
Monitoring을 위한 Mixer설정 1 - Instance
§ Instance : Envoy가 전달한 Attribute를 기반으로 생성되는 Metric Entry
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
name: quadruplerequestcount
namespace: istio-system
spec:
compiledTemplate: metric
params:
value: "4" # Envoy에서 수신된 request 마다 4씩 값이 카운트 된다.
dimensions:
# outbound, client, server중 속성 값과 일치한 정보를 출력
reporter: conditional((context.reporter.kind | "inbound") == "outbound", "client", "server")
source: source.workload.name | "unknown" # ~.workload.name에 속성값이 없을 경우 Unknown을 출력
destination: destination.workload.name | "unknown"
message: '"quadruple the fun!"' # 모든 Instance에 Message 출력
monitored_resource_type: '"UNSPECIFIED"'
16.
Monitoring을 위한 Mixer설정 2 - Handler
§ Handler : Prometheus Adapter가 받은 Metric Entry Instance를 Prometheus Backend에서 처리 할 수 있
는 Prometheus 형식의 값으로 변환하는 부분을 설정
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
name: quadruplehandler
namespace: istio-system
spec:
compiledAdapter: prometheus
params:
metrics:
- name: quadruple_request_count # Prometheus metric명
instance_name: quadruplerequestcount.instance.istio-system # Mixer instance명
kind: COUNTER
label_names: # Instance에 구성된 demension 항목과 동일하게 Label 명시
- reporter
- source
- destination
- message
17.
Monitoring을 위한 Mixer설정 3 – Rule
§ Rule : Mixer가 관리하는 Metric Entry Instance를 특정 Handler에서 사용할 수 있도록 설정
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: quadrupleprom
namespace: istio-system
spec:
actions:
- handler: quadruplehandler
instances: [ quadruplerequestcount ]
• Adapter는 istio_ 의 String을 모든 Metric명 앞에 추가하여 Backend에 있는 Telemetry로 전달
• 쿼리 : istio_quadruple_request_count
18.
Metric 쿼리 Demo(Prometheus)
2. Productcatalog 서비스의 모든 Metric Entry Instance에 대한 최근 5분 동안의 Request 비율
1. Productcatalog 서비스 버전 v1에 대한 모든 Request 수
• 쿼리 : istio_requests_total{destination_service="productcatalogservice.hipster-shop.svc.cluster.local", destination_version="v1"}
• 쿼리 : rate(istio_requests_total{destination_service=~"productcatalogservice.*", response_code="200"}[5m])
19.
Metric 시각화 (Grafana)
§Istio Mixer에서 관리하는 Metric을 시각화하여 모니터링 할 수 있는 Dashboard를 Grafana를 통해 제공
20.
Mesh Dashboard
§ MeshDashboard에서는 Service Mesh 모니터링 수행
§ Service Mesh내의 각 서비스에 대한 Request, Latency, Success Rate에 대한 값을 출력
21.
Service Dashboard
§ ServiceDashboard에서는 Mesh 내의 개별 Service 대상 Request/Response에 대한 Metric 제공
§ 특정 Service를 Request하는 Client Workload에 대한 Metric 제공
§ Service를 제공하는 Server Workload에 대한 Metric 제공
22.
Workload Dashboard
§ WorkloadDashboard에서는 Mesh 내의 개별 Workload Request/Response에 대한 Metric 제공
§ 특정 Workload로 Request하는 Inbound 서비스에 대한 Metric 제공
§ Workload가 타 Workload로 Request하는 Outbound 서비스에 대한 Metric 제공
23.
Logging
Envoy 접근 LogLog수집 Fluentd Logging
• Fluentd 연동 및 Logging 설정• Mixer에서 Istio Log 수집 및 처리 • Envoy Proxy 접근 Log 수집
§ Service Mesh Logging을 위한 Istio Mixer에서의 Log 설정 및 수집, 처리
24.
Log 수집 Demo
§Service Mesh에서 서비스 Request에 대한 Log를 자동으로 수집하도록 설정
• istio-telemetry POD의 mixer 컨테이너를 통한 Log 검색
• 명령어 : kubectl logs -n istio-system -l istio-mixer-type=telemetry -c mixer | grep "newlog" | grep -v
'"destination":"telemetry"' | grep -v '"destination":"pilot"' | grep -v '"destination":"policy"' | grep -v
'"destination":"unknown"'
25.
Logging을 위한 Mixer설정 1 - Instance
§ Instance : Envoy Sidecar Proxy에서 수집된 Attribute를 기반으로 생성된 Log Entry
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
name: newlog
namespace: istio-system
spec:
compiledTemplate: logentry
params:
severity: '"warning"' # Log 레벨
timestamp: request.time # Log에 Envoy가 제공하는 Request 기반으로 시간 출력
variables:
source: source.labels["app"] | source.workload.name | "unknown"
user: source.user | "unknown"
destination: destination.labels["app"] | destination.workload.name | "unknown"
responseCode: response.code | 0
responseSize: response.size | 0
latency: response.duration | "0ms" # Log 출력에 대한 대기시간 지정
monitored_resource_type: '"UNSPECIFIED"'
26.
Logging을 위한 Mixer설정 2 - Handler
§ Handler : Standard I/O Adapter에 전달될 Log Entry Instance 처리 방식을 설정
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
name: newloghandler
namespace: istio-system
spec:
compiledAdapter: stdio
params:
severity_levels: # Logging 레벨 설정
warning: 1
outputAsJson: true # JSON 형식으로 Log행 생성
27.
Logging을 위한 Mixer설정 3 – Rule
§ Rule : Log Entry Instance를 Handler로 전달되도록 Mixer에 적용
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: newlogstdio
namespace: istio-system
spec:
match: "true" # Rule은 모든 요청에 대해 실행, 정규표현식을 사용하여 변경 가능
actions:
- handler: newloghandler
instances:
- newlog
28.
Envoy 접근 LogDemo
§ Envoy Proxy는 접근 Log를 kubectl logs명령으로 출력 할 수 있음
• Productcatalog 서비스 Log
• 명령어 : kubectl logs -f <productcatalogservice의 POD명> -c istio-proxy
Fluentd 설정
§ Istio의Mixer는 Forward 로그를 Listen하는 Fluentd 데몬과 연결할 수 있음
§ Mixer가 실행중인 Fluentd 데몬에 연결하려면 Fluentd로 연동되는 Adapter 생성 및 Template 설정
kind: ConfigMap
apiVersion: v1
data:
forward.input.conf: |-
# TCP를 통한 Message 전송
<source>
type forward
</source>
output.conf: |-
<match **>
type elasticsearch
log_level info
include_tag_key true
host elasticsearch
port 9200
logstash_format true
# Chunk limits 설정
buffer_chunk_limit 2M
buffer_queue_limit 8
flush_interval 5s
# Retry 대기시간은 5분 이하로 지정
max_retry_wait 30
# 영구적으로 Retry 수행
disable_retry_limit
# 2개의 쓰레드로 처리
num_threads 2
</match>
metadata:
name: fluentd-es-config
namespace: logging
Forward 로그를 Listen하는 Fluentd 설정
31.
EFK Logging 설정
apiVersion:config.istio.io/v1alpha2
kind: handler
metadata:
name: handler
namespace: istio-system
spec:
compiledAdapter: fluentd
params:
address: "fluentd-es.logging:24224"
§ Logging을 위한 Mixer 설정 중 Handler의 일부 Spec을 변경
32.
Tracing (Zipkin)
Tracing Dashboard
§Istio는 기본적으로 모든 Request에 대한 Tracing 가능한 데이터를 생성
§ Zipkin을 사용하여 서비스 트래픽에 대한 Tracing 수행 가능
상세 Trace View
• Tracing은 서비스 간 연동정보의 집합인 Span별로 수행
• Tracing 가능한 데이터는 서비스 Request 실행중 발생한 값이나 Istio 컴포넌트 대상으로 수집
(istio-ingressgateway, istio-mixer, istio-policy)
Zipkin API
§ ZipkinAPI를 사용하여 서비스 트래픽 Tracing 정보를 JSON 형태로 접근, 제어 가능
• 웹 브라우저에서 $Zipkin_URL/api/v2/spans?serviceName=productcatalogservice.hipster-shop 를 주소창에
입력하여 Application 목록을 JSON 형태로 출력
• Zipkin API 참고 링크 : https://zipkin.io/zipkin-api/
Kiali API
§ KialiAPI를 사용하여 그래프 및 기타 Metric, 상태값 등 구성 정보를 JSON 형태로 접근, 제어 가능
• 웹 브라우저에서 $KIALI_URL/kiali/api/namespaces/hipster-shop/apps를 주소창에 입력하여 Application 목록
을 JSON 형태로 출력
https://www.kiali.io/api/• Kiali API 참고 링크 :