🌼

어쨌건간에 흘러가는 者

Who and Why am I here?

My Cluster & its assets

최근 글

카테고리 별 글

Who and Why am I here?

제 소개와 연락처입니다. 각 페이지 맨 아래에 또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.

•

Linkedin / Github

•

Youtube / Strava

•

anyflow@gmail·com

어쨌건간에

https://www.anyflow.net/introspective-life/anyway

My Cluster & its assets

2011년산 노트북(Intel Core i5, 16M) 내에서 동작하는 (Home) Kubernetes Cluster 및 여기서 운용 중인 서비스 링크, 그리고 설명(w/ git repo)입니다. 이 블로그 글에서 다루는 서비스 대부분을 여기서 테스트합니다.

•

Dockebi OPENAPI Spec. 

•

Grafana / Prometheus

•

Kiali / Jaeger

My Cluster - Home k8s cluster

단일 host에서 Kubernetes와 여기서 운용할 여러 app을 ‘빠르게’ 실행/삭제 가능함과 동시에 Home server/cluster로서의 운용을 위한 프로젝트

https://www.anyflow.net/sw-engineer/my-cluster

Introduction

Prometheus metric의 특성과 Istio metric의 interval에 대해 논한다. Prometheus는 일반적인 DB와는 달리 pull 방식으로 데이터를 수집함과 동시에, Grafana 등에서 마주치는 데이터에는 (interpolation, extrapolation에 의해 보정된) 가상의 데이터가 포함되다보니, Prometheus에 실제 어떻게 데이터가 저장되어 있는지를 유추하기가 생각보다 어렵다. 그리고 이는 데이터 정확성에 대한 파악 뿐 아니라 용량 산정/예측에도 영향을 미친다.

Summary

•

Prometheus는 Time series identifier 별로 time series를 생성한다. 즉, label value 갯수만큼 time series가 생성 즉, label 갯수에 따라 기하 급수로 time series 갯수가 증가하는 구조이다.

•

Query, 특히 range query에는 가상의 데이터가 포함된다. scrape_interval 보다 step이 작을 경우 특히 그러하다.

•

Istio에는 metric 생성 주기에 영향을 주는 ‘듯’한 여러 parameter가 있다. 그러나 타 metric과 마찬가지로 결국 scrape_interval 에 맞춰 metric sample의 timestamp가 생성된다.

Prometheus Data Model

Data model | Prometheus

An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.

https://prometheus.io/docs/concepts/data_model/

Prometheus의 모든 데이터는 time series로 이루어지며, Time series는 Time series identifier와 Samples로 구성되어, 각 Time series Identifier 마다 단일 time series 생성된다. 단, Query를 위해 임시 time series를 생성할 수도 있다.

이미지 출처: https://training.promlabs.com/training/introduction-to-prometheus/prometheus-an-overview/time-series-data-model/

Time series identifier

Metric name와 key/value 쌍으로 이루어진 Metric label의 집합.

•

notation: <metric name>{<label name>=<label value>, ...}

Prometheus metric에 관한 몇몇 특성 및 Istio의 metric interval에 관하여

S/W 엔지니어

Prometheus

Istio

2024/08/08

Ambient mode에서의 Istio 구조. 에서 자세히 논한다.

Introduction

Istio Ambient mode에 대한 요약이다. (비공식적으로) Sidecar-less mode로도 불리는 Istio Ambient mode는 최근에 와서야 베타 버전이 된 기능이지만, Istio 전반의 구조 변경과 함께 상당한 성능 향상을 이끄는 중요 업데이트이다.

참조한 문서는 글 내부 및 에 달았다.

Summary

•

Ambient mode는 Sidecar mode 하의 Istio 기능을 계승하면서, 더 빠르고 더 적은 리소스를 사용한다. 특히 메모리 사용량 개선은 극적이다.

•

Ambient mode에서는 DaemonSet 인 Ztunnel(L4 대응)과 Deployment 인 Waypoint (L7 대응)가 Istio-proxy sidecar를 대신한다.

•

Waypoint 는 Kubernetes Gateway API의 Gateway 를 통해 Namespace 단위로 생성하는 것이 기본이다. 이는 Waypoint 가 특정 workload 군에 대한 gateway 역할도 함께함을 의미한다.

Why Ambient mode? (over Sidecar mode)

Ambient mode의 목표는 Sidecar mode 하의 Istio 기능 계승과 함께(공식 문서의 두 번째 단락 참조. “mixed mode에 대한 seamless interoperation”은 이를 암시한다), 전체적 구조 변경을 통한 전반의 성능 개선으로 보인다.

왜 Ambient란 이름이 붙었는지는 모르겠는데 어쨌건 Sidecar-less란 비공식 명칭에서 이를 더 유추하기가 좋다. Sidecar mode의 단점(app과의 lifecycle coupling, 중복 및 사전 예약 resource 요구 등)을 제거한 무엇이겠다는 생각으로 자연스럽게 이어지기 때문이다.

아래 링크는 Sidecar mode에 비해 더 작은 duration, 더 적은 리소스로 동작한다는 제 3자의 테스트 결과로, 특히 메모리 사용량 개선은 극적이다.

LiveWyer | Service Meshes Decoded Part Two: Is Istio Ambient worth it?

Is Istio Ambient worth it? | Discovering the fastest service mesh and sharing our comparison experience

https://livewyer.io/blog/2024/06/06/comparison-of-service-meshes-part-two/

Istio Internals: Ambient mode

S/W 엔지니어

Istio

Service Mesh

Ambient mode

Ambient Mesh

Kubernetes Gateway API

API Gateway

Death Star Architecture

2024/06/11

TLS traffic에 대한 Envoy filter chain의 구조. 에서 자세히 논한다.

Introduction

대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.

, Istio overview: Observability 및 Istio overview: Security 에 이어, 마지막으로 Istio의 확장성과 타 Service Mesh 제품에 대해 논한다.

참조한 문서는 글 내부 및 에 달았다.

Summary

•

Istio/Envoy에는 다수의 filter의 연결로 이루어진 Filter chain이 있어, 각 filter를 사용하여 request / response에 대한 다양한 부가적 action을 추가할 수 있다.

•

Envoy에는 다수의 configurable Built-In filters가 있어 별도 프로그래밍 없이도 다양한 요구에 대응이 가능하다.

•

Lua와 WebAssembly(WASM)을 사용하여 Built-In filters 이외의 사용자 정의 기능을 삽입 가능하다.

•

Istio 이외에도 Cilium, Linkerd, Kuma, Consul 등 Service Mesh 제품은 다양하다.

Istio의 확장성에 관하여

Istio에서의 확장은 Istio Proxy에 대한 확장을 의미하는데, 대부분의 Istio proxy 타 기능과 마찬가지로 Envoy에 크게 의존한다. Istio의 역할은 사실 상 Envoy 기능에 대한 interfaces 제공으로, EnvoyFilter 및 WasmPlugin Istio resource가 이들 interface에 해당한다.

Envoy Filter

Customizing Envoy configuration generated by Istio.

https://istio.io/latest/docs/reference/config/networking/envoy-filter/

Istio overview: Extensibility, Etc.

S/W 엔지니어

Istio

Service Mesh

Envoy

EnvoyFIlter

WASM

WebAssembly

2024/06/04

Istio의 사용자, 서비스 보안 구조. Zero Trust Architecture 에서 자세히 논한다.

Introduction

대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.

, Istio overview: Observability 에 이어 Security feature에 대해 다룬다(이후 Istio overview: Extensibility, Etc. 로 이어 진다).

참조한 문서는 글 내부 및 에 달았다.

Summary

•

보안 관점에서 Istio는 ZTA(Zero Trust Architecture)를 추구하는 것으로 보인다.

•

Istio는 사용자 관점 보안으로 JWT/JWK 기반의 OIDC(OpenID Connect)를 지원한다.

•

Istio는 서비스 관점 보안으로 mTLS 및 SPIFFE(Secure Production Identity Framework for Everyone)를 지원한다.

•

AuthorizationPolicy 를 통해 L7 수준에서 access control이 가능하다.

Zero Trust Architecture

Security

Describes Istio's authorization and authentication functionality.

https://istio.io/latest/docs/concepts/security/

Istio는 ZTA(Zero Trust Architecture)를 추구하는 것으로 보이는데, 실제 위 공식 문서는 Zero Trust network를 언급한다. 이는 Istio가 multi clusters 및 외부 host가 포함된 환경도 지원함을 고려하면 충분히 이해되는 부분이다(이들 환경에서는 traffic이 보호되지 않거나 보안 정책이 상이한 구간을 지나기 마련이다).

Istio overview: Security

S/W 엔지니어

Istio

SPIFFE

mTLS

Service Mesh

OIDC

JWT

OAuth2

2024/06/02

Introduction

대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.

에 이어 Observability feature에 대해 다룬다(이후 Istio overview: Security, Istio overview: Extensibility, Etc. 로 이어 진다).

참조한 문서는 글 내부 및 에 달았다.

Summary

•

Istio는 Observability의 주요 signal인 MLT(Metrics, Logs, Traces) 모두를 지원한다.

•

Istio는 Logs와 Traces에 대해서 OpenTelemetry를 지원하고, Metrics는 Prometheus만을 지원한다.

•

Metrics, Logs와는 달리 Traces는 application 의존성이 존재하여, application에서 trace propagation을 위해 ingress request의 trace header를 egress request header에 넣어야 한다.

Overview

Observability 데이터(signal)는 일반적으로 metrics, logs, traces으로 나뉘는데, Service Mesh는 app에 대한 이들 데이터 모두를 수집하여 각 signal 별 backend로 전한다. 수집은 app과 별개의 process로 동작하는 이상, app이 노출하는 endpoint 수준에서 이루어진다.

위 그림은 Istio component 종류 별 수집 대상 Observability signal 및 각 signal backend로의 전달 방법을 나타낸다. Metrics는 Prometheus의 수집 방법(scraping; PULL 방식) 그대로를 사용하고, traces는 Istio가 직접 trace backend로 전달하며, Log는 stdout으로 보내어 이후 Fluent-bit 등이 log backend로 보내는 것이 일반적이다.

Metrics

Istio overview: Observability

S/W 엔지니어

Service Mesh

Istio

Observability

OpenTelemetry

Prometheus

2024/05/29

Introduction

Kubernetes 환경에서의 Istio DNS Proxy 사용에 대한 설명으로, 이를 사용하면 CoreDNS를 포함한 DNS server로의 호출이 대폭 줄어든다. 이는 DNS server로의 부하 감소 뿐 아니라 app의 응답 속도 개선으로 이어진다. 은 참조 문서다.

Motivation

Istio의 DNS Proxying을 눈여겨 보게된 동기는 Nodelocal DNSCache에 대한 대체 가능성 때문이다. 용도가 중복된다면 굳이 둘 모두를 운용할 필요가 없다.

Nodelocal DNSCache는 CoreDNS로의 부하 감소를 위한 DaemonSet로 동작하는 추가 패키지인데, 이 부하는 iptables 모드의 kube-proxy 환경에서 DNS lookup 실패를 유발한다. 은 이에 대한 상세이다.

Summary

•

Istio DNS Proxying은 DNS roundtrip을 제거함으로 응답 속도 개선을 이룰 뿐 아니라 CoreDNS에 대한 부하를 급격히 제거한다.

•

Istio proxy는 미리 sync한 Kubernetes Service, Pod  및 Istio ServiceEntry 내 주소를 통해 투명하게(즉, app 변경 없이) DNS 서비스를 이룬다. 나머지 주소에 대해서는 관여하지 않아 일반적 DNS lookup 경로를 그대로 따른다.

•

이외에도 DNS server 변경 없이 DNS를 추가 가능하거나, 자동으로 virtual IP를 할당함으로 외부 TCP 서비스(e.g. AWS RDS)를 이슈 없이 식별 가능해진다.

Istio DNS Proxying 구조

Istio DNS proxying의 기본 아이디어는 “Istio가 가진 주소 정보 활용”인 듯 보인다. Istio proxy에는 이미 DNS 서비스에 필요한 Domain Name과 VIP(virtual IP - service IP), RIP(real IP - pod IP)가 있기 때문이다.

이를 고려하면 적어도 in-cluster 연산에는 CoreDNS 호출 필요성이 아예 사라진다. 해당 호출이 사라지므로 성능 증대는 물론 CoreDNS에 대한 부하를 (공식 문서 표현에 따르면) ‘drastically’ 완화하여, 이는 pod가 많아질 수록 더욱 그렇다.

Istio DNS Proxying 구조

Istio DNS proxy: 지연 개선, DNS 부하 감소

Introduction

Istio의 distributed tracing 전반에 대해, 특히 OpenTelemetry 기반으로 논한다.

Summary

•

Istio는 distributed tracing의 핵심인 trace ID와 span ID를 생성 및 관리하여 header로 제공한다.

•

다만 Trace propagation은 application에서 수행해야 한다. 나머지는 Istio가 알아서 한다.

•

Istio는 OpenTelemetry가 채택한 W3C Trace Context를 지원한다. 그러나 default는 B3 propagation 이므로 별도 설정이 필요하다.

Istio 기반 distributed tracing 구조

Distributed tracing의 목적은 특정 request에 대한 관련 component 전체의 상태를 파악하는 것이다. 이를 Istio가 어떻게 이루는지 아래 3개의 components로 이루어진 transaction 예를 통해 설명한다.

gateway가 dockebi로 request 보내는 것으로 시작해 dockebi-storage를 거쳐 최종 response를 받는 간단한 구조이다. 화살표 번호는 traffic 순서를 나타내고 ingress, egress는 해당 component 관점에서의 Istio proxy를 의미한다. 참고로, dockebi component에는 마치 Istio proxy가 ingress / egress의 두 개인 양 오해하기 쉬운데 이는 설명 편의 상 나눈 것으로, 단일 Istio proxy가 ingress / egress traffic 모두를 처리한다.

아래는 위 구조 하에서의 특정 trace에 대한 Grafana distributed tracing 뷰로, tracing backend로는 Jaeger를 사용하였다.

Grafana에서의 distributed tracing 뷰. Jaeger도 완전히 동일한 구성의 뷰를 제공한다.

위 그림의 붉은색, 분홍색, 초록색 막대 각각은 component에 대한 각 ingress / egress traffic의 시작과 끝 시간 및 관련 정보, 즉 span을 의미한다. 위에서부터 아래로 gateway (egress) → dockebi (ingress) → dockebi (egress) → dockebi-storage (ingress) 가 나열되어 있다. 또한 span을 클릭하면 span 상세 정보가 나타나는데, 위에서는 gateway (egress) 의 상세 정보가 보인다.

Istio Distributed Tracing w/ OpenTelemetry

Introduction

Kubernetes 내 Metric, Logs, Traces(MLT) pipelines를 OpenTelemetry Collector로 교체하는 방법, 특히 각 signal 관점에서 어떻게 OpenTelemetry Collector workload를 나눌지에 대해 논한다.

, , 의 연장선 상에 위치한 OpenTelemetry Collector의 상세 검토 중 하나이다.

예제 코드는 버전으로 따지면 alpha 수준으로 글과 함께 지속 업데이트 예정이다. 완료 시 본 callout은 제거 예정이다.

Motivation

OpenTelemetry Collector는 일반적으로 보이는 아키텍처 그림과는 달리 다수의 workload로 나누어야 하는데, 이는 무엇보다 OTel receiver, 즉 signal 종류가 workload 형식, 즉 배포 패턴(e.g. Deployment, DaemonSet)을 사실 상 규정하기 때문이다. 그렇다고 receiver 종류 별로 workload를 나누기에는 그 종류가 너무도 많다. 결국에는 이들에 대한 분류가 요구된다.

조직 관점 분류 방법에 대하여

Collectors

다행히도 receiver 이외에 타 OpenTelemetry component는 workload 형식에 대한 제한이 없다. 또한 유지보수성을 고려하자면 workload는 적을 수록 좋다. 따라서 최소 workload 분류 단위인 workload 형식 별로 나누는 것을 고려한다. 참고로, OpenTelemetry Collector는 Deployment, DaemonSet, StatefulSet 이외에도 sidecar 형식의 배포 패턴으로 지원한다(공식 문서는 DaemonSet 과 sidecar를 Agent로, 이외를 Gateway로 표현하며 receiver 수준에서야 구체적인 형식을 논한다).

아래는 위 관점에 따라 분류한 결과(우측)와 각각에 해당하는 OpenTelemetry 사용 전의 MLT 수집기를 나타낸다. 실선은 OTel 적용 전에도 사용되는 signal에 대한 관계를, 점선은 OTel 적용 후에 추가 가능한 경우를 나타낸다. 참고로 trace의 경우 OTel 전에는 Trace backend로 signal을 직접 보내는 것이 일반적이라 예상된다.

OpenTelemetry Collector 적용 전 components와 적용 후의 collectors 간 관계. Collector 명칭은 직관성을 위해 workload 형식이 아닌 signal의 공통 속성에서 추출

보다시피 OpenTelemetry Collector의 사용 결과, MLT에 대한 일관된 관리의 장점 뿐 아니라 최소 7개의 workload를 4개로 줄일 수 있다(물론, workload 별 부하는 더욱 커질 것이므로 이에 대한 적절한 resource 추가 할당이 필요하겠다).

아래 각 Collector에 대한 설명과 예제 코드로, 해당 collector가 담당하는 각 signal의 종류를 log, metric, trace 로 표현했다. Signal backends로는 Prometheus, Elasticsearch, Jaeger를 상정했다.

OpenTelemetry Collector: workload 분류

S/W 엔지니어

OpenTelemetry

OpenTelemetry Collector

Prometheus

Elasticsearch

Jaeger

Istio

2024/05/15

Introduction

mockserver 예제을 통해 EnvoyFilter API를 요약한다. 예제는 EnvoyFilter 속성의 아주 일부만 다루지만, 전반의 구조를 다루고 있기에 나머지는 공식 문서를 통해 응용이 가능하리라 생각한다.

글 전반으로 아래 Istio 공식 문서의 것을 참고했다.

Envoy Filter

Customizing Envoy configuration generated by Istio.

https://istio.io/latest/docs/reference/config/networking/envoy-filter/

EnvoyFilter 란

istiod에 의해 생성된 Envoy configuration에 대해 customization을 가능하게 하는 Istio API. configuration의 특정 field 수정 뿐 아니라 Envoy의 새로운 Listener, Cluster마저 생성 가능하다고. 주로 traffic 전처리를 위한 Envoy network filter chain에 custom filter 삽입을 위한 용도로 사용될 듯. 이 글의 mock server가 딱 이 경우에 해당한다.

VirtualService 를 통한 mockserver 구현에 대해 단순 mockserver라면, 복잡한 EnvoyFilter를 쓸 필요 없이 VirtualService 의 directResponse 로도 가능하다.

EnvoyFilter 특징

•

sidecar 및 gateway 전체에 적용하려면 root namespace(e.g. istio-system)에 workloadSelector 지정 없이 생성한다. 이 말은 workload(e.g. pod)의  namespace 별로 적용이 가능하다는 뜻임과 동시에, 특정 workload 별로도 적용이 가능하다는 뜻이다.

•

타 Istio object와 달리 (override 가 아닌) 추가적인 방식으로 동작하여 여러 EnvoyFilter를 적용 가능하다.

•

여러 EnvoyFilter 적용 시 root namespace의 EnvoyFilter 가 workload namespace의 것보다 앞서 적용되며, 동일 namespace에서는 생성 시간 순서를 따른다.

•

EnvoyFilter 간 충돌을 일으키는 설정이 있을 경우 동작은 정의되지 않는다.

•

하위 호환을 지원하나, (그래도) Istio proxy version 업그레이드 시 deprecated field 확인이 필요하다.

Istio EnvoyFilter via mockserver

S/W 엔지니어

Istio

EnvoyFIlter

Lua

Kubernetes

Service Mesh

2024/05/06

Introduction

Istio의 dynamic configuration의 핵심인 xDS에 관한 요약으로, Istio in Action을 주로 참고한 글이다. 참고로 dynamic configuration는 Istio Envoy proxy에 동적으로 설정되는 데이터로, 여기에는 Istio Envoy proxy가 노출할 port 부터 routing 규칙 및 upstream 서비스까지 모두 포함된다.

Motivation

Istio의 Namespace isolation을 사용하지 않으면, pod가 많아질 수록 Istio sidecar가 사용하는 메모리 크기가 커진다. 이로 인해 OOMKilled나 connection drop 등 다양한 오류가 발생하는데, 알고보니 주된 범인은 xDS 데이터였다. xDS는 Istio/Envoy dynamic configuration의 핵심이다.

참고로, Namspace isolation은 사실상 필수 설정인데 이에 대해서는 를 참고한다.

xDS란

xDS는 eXtensible Discovery Services의 약자로 dynamic configuration 관리 서버, 즉 istiod 가 노출하는 API 및 이들 서비스를 가리킨다. Envoy는 istiod 를 ‘구독’하여 최종적 일관성(eventual consistency)에 기반하여 configuration을 상시 동기화한다(출처). 참고로 이 동기화에는 Istio의 경우 gRPC를 사용하는데, Envoy는 이외에도 HTTP long polling과 특정 filesystem watch 기법도 제공한다고.

xDS의 x에는 대표적으로 Listener(LDS), Route(RDS), Cluster(CDS), Endpoint(EDS)가 있는데, 이들 각각은 순서대로, Envoy가 노출할 port, 인입된 트래픽을 어떤 upstream 서비스로 보낼지 지정하는 규칙, upstream 서비스, 마지막으로 upstream 서비스의 주소를 가리킨다.