![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](https://image.slidesharecdn.com/servicemeshistiomonitoring-190426001231/85/Service-mesh-istio-monitoring-10-320.jpg)
![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 ]](https://image.slidesharecdn.com/servicemeshistiomonitoring-190426001231/85/Service-mesh-istio-monitoring-12-320.jpg)
![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](https://image.slidesharecdn.com/servicemeshistiomonitoring-190426001231/85/Service-mesh-istio-monitoring-17-320.jpg)
![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])](https://image.slidesharecdn.com/servicemeshistiomonitoring-190426001231/85/Service-mesh-istio-monitoring-18-320.jpg)
![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"'](https://image.slidesharecdn.com/servicemeshistiomonitoring-190426001231/85/Service-mesh-istio-monitoring-25-320.jpg)
Service mesh(istio) monitoring
- 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
- 8. Mixer § Mixer는 Telemetry 연동 및 수집, Policy 관리하는 Istio 컴포넌트
- 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
- 29. EFK Logging Demo § Log Entry를 Fluentd로 전달하여 EFK에서 Logging이 될 수 있도록 설정
- 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/
- 36. Visualizing (Kiali) Dashboard § Kiali는 Service Mesh 및 Istio 컴포넌트의 트래픽 데이터들을 Visualizing(시각화)하여 제공 Graph
- 37. Kiali 구성요소 1 서비스 요소(Application, Workload, Service) 목록 트래픽 Metric
- 38. Kiali 구성요소 2 Istio Config(Policy) 목록 Istio Config(Policy) 코드
- 39. Kiali API § Kiali API를 사용하여 그래프 및 기타 Metric, 상태값 등 구성 정보를 JSON 형태로 접근, 제어 가능 • 웹 브라우저에서 $KIALI_URL/kiali/api/namespaces/hipster-shop/apps를 주소창에 입력하여 Application 목록 을 JSON 형태로 출력 https://www.kiali.io/api/• Kiali API 참고 링크 :
- 40. Q & A