Who and Why am I here?
제 소개와 연락처입니다. 각 페이지 맨 아래에 
또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
My Cluster & its assets
2011년산 노트북(Intel Core i5, 16M) 내에서 동작하는 (Home) Kubernetes Cluster 및 여기서 운용 중인 서비스 링크, 그리고 설명(w/ git repo)입니다. 이 블로그 글에서 다루는 서비스 대부분을 여기서 테스트합니다.
최근 글
Search
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자의 테스트 결과로, 특히 메모리 사용량 개선은 극적이다.
이는 무엇보다 (sidecar로 인해) app pod 마다 운용되던 xDS config가, Istio 전용 components에서 각 namespace 별로만 운용되는 최적화 효과 때문으로 보인다. 아래 링크는 이에 대한 상세 설명이고, 는 관련 내용이다.
Istio Internals: Ambient mode
S/W 엔지니어
Istio
Service Mesh
Ambient mode
Ambient Mesh
Kubernetes Gateway API
API Gateway
Death Star Architecture
2024/06/11
Introduction
대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.
, Istio overview: Observability 및 Istio overview: Security 에 이어, 마지막으로 Istio의 확장성과 타 Service Mesh 제품에 대해 논한다.
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 chain
Istio overview: Extensibility, Etc.
S/W 엔지니어
Istio
Service Mesh
Envoy
EnvoyFIlter
WASM
WebAssembly
2024/06/04
Introduction
대표적 Service Mesh 제품인 Istio에 대한 overview로 Kubernetes를 배경으로 설명한다.
, Istio overview: Observability 에 이어 Security feature에 대해 다룬다(이후 Istio overview: Extensibility, Etc. 로 이어 진다).
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이 가능하다.
Security
Istio는 ZTA(Zero Trust Architecture)를 추구하는 것으로 보이는데, 실제 위 공식 문서는 Zero Trust network를 언급한다. 이는 Istio가 multi clusters 및 외부 host가 포함된 환경도 지원함을 고려하면 충분히 이해되는 부분이다(이들 환경에서는 traffic이 보호되지 않거나 보안 정책이 상이한 구간을 지나기 마련이다).
ZTA; Zero Trust Architecture란 (하기 링크 요약)
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. 로 이어 진다).
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에 넣어야 한다.
Observability
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
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 부하 감소
S/W 엔지니어
Istio
DNS
DNS Proxy
Kubernetes
DNS cache
Nodelocal DNSCache
2024/05/25
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
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 서비스의 주소를 가리킨다.
또한 위 그림에는 없지만 Istio가 사용하는 xDS에는 Secret(SDS), Aggregate(ADS), Name(NDS)도 있으며, 이 중 NDS는 Istio 전용으로 Envoy와 별도로 동작하는 Istio DNS Proxy를 위한 것이다.
아래는 Envoy xDS의 전체 목록이다.
xDS 상세
Istio Internals: xDS
S/W 엔지니어
Service Mesh
Istio
xDS
Envoy
Kubernetes
2024/05/04
Load more
카테고리 별 글
Search
음악인
13
Load more
S/W 엔지니어
118
Load more
예술/인문 소감
70
Load more
自省(Introspect) / 세상살이
69
Load more
프로젝트s
92
Load more
방명록 백업