3. Service Mesh
Service1 POD
Container Sidecar 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
Istio Control 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
Cloud Z
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
9. 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 수집
§ Istio Mixer가 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
§ Mesh Dashboard에서는 Service Mesh 모니터링 수행
§ Service Mesh내의 각 서비스에 대한 Request, Latency, Success Rate에 대한 값을 출력
21. Service Dashboard
§ Service Dashboard에서는 Mesh 내의 개별 Service 대상 Request/Response에 대한 Metric 제공
§ 특정 Service를 Request하는 Client Workload에 대한 Metric 제공
§ Service를 제공하는 Server Workload에 대한 Metric 제공
22. Workload Dashboard
§ Workload Dashboard에서는 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 접근 Log Demo
§ Envoy Proxy는 접근 Log를 kubectl logs명령으로 출력 할 수 있음
• Productcatalog 서비스 Log
• 명령어 : kubectl logs -f <productcatalogservice의 POD명> -c istio-proxy
30. 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)
35. Zipkin API
§ Zipkin API를 사용하여 서비스 트래픽 Tracing 정보를 JSON 형태로 접근, 제어 가능
• 웹 브라우저에서 $Zipkin_URL/api/v2/spans?serviceName=productcatalogservice.hipster-shop 를 주소창에
입력하여 Application 목록을 JSON 형태로 출력
• Zipkin API 참고 링크 : https://zipkin.io/zipkin-api/
39. Kiali API
§ Kiali API를 사용하여 그래프 및 기타 Metric, 상태값 등 구성 정보를 JSON 형태로 접근, 제어 가능
• 웹 브라우저에서 $KIALI_URL/kiali/api/namespaces/hipster-shop/apps를 주소창에 입력하여 Application 목록
을 JSON 형태로 출력
https://www.kiali.io/api/• Kiali API 참고 링크 :