Who and Why am I here?
My Cluster & its assets
집에서 운영하는 Kubernetes 클러스터 및 여기서 운용되는 서비스로, 아이콘을 클릭하면 각 서비스에 접근 가능합니다. 참고로 개발 서버인 관계로 종종 접근에 실패할 수 있습니다.
최근 글
Search
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 by xDS
S/W 엔지니어
Service Mesh
Istio
xDS
Envoy
Kubernetes
2024/05/04
Introduction
Service Mesh에 대한 overview로, Service Mesh의 대표 제품인 Istio를 통해 Kubernetes를 배경으로 설명한다.
쓰다보니 내용이 길어져 두 편으로 나누어, 본 글 이외의 나머지 편에서는 Features의 Observability, Security, 그리고 Istio 이외의 Service Mesh 제품에 대해 논한다. 참고로, 본 글에 주로 참조한 문서는 에 달았다.
Service Mesh란
일단, 정의는 Wikipedia에서 가져왔다.
프록시를 사용하여 서비스 또는 마이크로서비스 간 서비스 간 통신을 촉진하는 전용 인프라 계층
- Wikipedia, https://en.wikipedia.org/wiki/Service_mesh
Service Mesh는 pod 수준의 L7 traffic 처리를 위한 일종의 overlay network이다. sidecar 등의 기법으로 각 pod에 붙은 proxy가 모든 pod에 대한 in/outbound traffic를 제어함으로, 각종 부가적 features를 추가한다. API Gateway를 cluster 전체에 대한 proxy라 한다면, Service Mesh는 pod에 대한 proxy, 그리고 이들 proxy 간의 연합이라 볼 수 있다.
Architecture
아래 그림은 앞선 구조 관점의 Istio의 정의를 나타내는데, Service A와 Service B 사이에서 각 Service에 해당하는 proxy가 traffic을 중계함과 동시에 Control Plane인 istiod는 이들 proxy를 제어하고 있다.
아래 그림에서는 pod 대신 Service라 표현되었다(실제로는 pod에 sidecar가 설치되지만, 개념 및 사용 시에는 Kubernetes Service 단위로 사용된다).
참고: sidecar-less Service Mesh
근래에 sidecar 없는 아키텍처의 Service Mesh가 부각되었는데, Istio는 Ambient Mesh라 하여 Daemon Set(ztunnel)과 Deployment(waypoint)로 envoy proxy의 역할을 나누고, Cilium은 eBPF 기반으로 Daemon Set만을 사용함과 동시에 Control Plane마저 없다. 하지만 sidecar만 없을 뿐 개념적으로는 기존과 동일하다.
타 아키텍처 대비 비교 우위점
Service Mesh overview: Istio 관점으로 1/2
S/W 엔지니어
Envoy
Istio
Service Mesh
Cilium
k8s
Kubernetes
2024/04/27
Introduction
OTel(OpenTelemetry) Collector로 Prometheus (scraper - agent mode)를 교체하는 방법에 대한 설명이다. OpenTelemetry의 사용자 관점 Overview 및 OpenTelemetry 설치 준비: OTel k8s Operator 설치 의 연장선 상에 위치한 OpenTelemetry Collector의 상세 검토 중 하나이다.
Summary
•
OTel Collector로 Kubernetes resource metric 스크래핑을 위한 Prometheus를 대체 가능하다.
•
다수의 scraping 대상으로 인한 특정 pod로의 부하 쏠림을 해결하기 위해 Target Allocator가 제공된다.
•
Prometheus로 직접 전달(push)하는 방식과 Prometheus와 동일하게 pull 방식 모두 가능하다.
Architecture
OpenTelemetry Collector 및 Target Allocator의 Kubernetes Metric scrapping 구조
위 는느penTelemetry Collector로 Prometheus (scraper)를 교체했을 때의 아키텍처를 나타낸다.
좌측 노란 박스는 scraping 대상 Kubernetes resources를, 푸른 박스는 OpenTelemetry components로 OpenTelemetry Collector와 Target Allocator를, 붉은 박스는 metric 저장소로서의 Prometheus 및 scraper(오직 OpenTelemetry Collector에서만 scrap)로서의 Prometheus를 나타낸다. 실선은 데이터의 흐름을, 점선은 관계를 나타낸다
각 components에 대한 설명은 아래부터 이어진다.
Components
Architecture 에서 식별된 각 components에 대한 설명이다.
OpenTelemetry Collector로 Prometheus (scraper) 교체하기
S/W 엔지니어
OpenTelemetry
OTel
OpenTelemetry Collector
Prometheus
2024/04/07
OpenTelemetry Operator를 통한 Collector, Target Allocator, Auto-Instrumentation 설치
Introduction
OpenTelemetry의 사용자 관점 Overview 에서 이어지는 글로, OpenTelemetry 설치를 위한 준비 단계이다.
Overview
OTel Collector를 설치 방법은 세 가지로, OTel Collector Kubernetes resource 직접 생성, Helm Chart 이용, 마지막으로 Kubernetes Operator 이용 방법이 있으나, Kubernetes Operator를 이용해야 OTel Collector뿐 아니라 Target Allocator, Auto-Instrumentation도 설치가 가능하다.
앞선 그림은 Otel Kubernetes Operator가 이들 및 OTel CR(Custom Resource)과 어떻게 상호작용하는지를 보여준다(전형적인 Kubernetes CR의 동작 구조 그대를 따른다). 이 Operator 설치 이후의 구체적 Collector, Auto-instrumentation 등의 설치에 대해서는 아래에 이어진다(지속 업데이트 예정).
설치 방법
순서는 다음과 같다.
1.
cert-manager 설치
2.
OTel Kubernetes Operator 설치
cert-manager 설치
설치 방법 출처는 다음과 같다.
OpenTelemetry 설치 준비: OTel k8s Operator 설치
S/W 엔지니어
OpenTelemetry
OTel
Kubernetes Operator
cert-manager
2024/04/06
Introduction
Kubernetes 환경에서의 Observability용 최적 component 조합 검토 중 OpenTelemetry가 수시로 언급됨을 발견. 뿐만 아니라 component 제품마다 이에 대한 지원을 항시 언급. 이즈음 되면 OpenTelemetry는 무시할 수 없는 무엇이 되어버렸다는 뜻.
이 글은 OpenTelemetry에 대한 사용자 관점의 overview이다. 이외에 추후 관련 구현 및 상세 검토를 위해 주요 내용에 대해서는 해당 참조 문서 링크를 달았다.
다음은 OpenTelemetry 공식 홈페이지이자 본문에서 주로 참조한 문서.
Why OpenTelemetry?
1.
MLT 통합 계측: Observability의 핵심인 signal, 즉 MLT(Metrics, Logs, Traces)를 통합 계측, 처리함으로 프로세스 및 아키텍처를 단순화할 뿐 아니라 이들 데이터간 correlation 기반 분석을 촉진한다.
2.
표준화 : MLT 데이터 수집에 대한 표준화된 방법 제공으로 다양한 관찰 도구 및 플랫폼과 더 쉽게 통합 가능하다. 이러한 표준화는 일관성과 호환성을 촉진한다.
3.
최상위권 CNCF 프로젝트 : Open source로서 2024.03.21 현재 CNCF incubating 프로젝트. datadog 등의 특정 업체에게 휘둘릴 일이 없을 뿐 아니라(No Vendor lock-in), 유연성, 상호운용성이 좋다는 뜻. 2023.10 현재 CNCF 프로젝트 중 velocity 2위(1위는 Kubernetes), Linux 재단 프로젝트에서는 3위(1위는 Linux, 2위는 Kubernetes)
4.
주요 Observability 제품 지원: Grafana, Prometheus, Istio 등 Observability (관련) 부문의 주요 Open source 제품 뿐 아니라 Elasticsearch, Datadog, Dynatrace 등 주요 영리 업체도 지원 중이다.
5.
이전 표준 병합: 이전 signal 표준인 OpenTracing과 OpenCensus를 병합. 이들 두 표준의 홈페이지(링크 참조)에 들어가면 모두 OpenTelemetry를 쓰라고 가이드한다.
이외에 아래 글을 읽어볼만 한다. 동일한 주제의 글로 글쓴이는 W3C Trace Context 관련 WG의 멤버이다. 실무의 경험에서 비롯한 듯한 vendor neutrality는 허상이란 주장과 논거가 특히 와닫는다.
OpenTelemetry의 사용자 관점 Overview
S/W 엔지니어
OpenTelemetry
Kubernetes
Jaeger
Elasticsearch
Prometheus
Observability
o11y
OTel
OTTL
OTLP
MLT
metric
trace
log
telemetry
2024/03/23
제목: 대칭화, 모듈화, 순서화. ChatGPT 생성 이미지
내 첫 번째 교주님으로 모시는 일론 머스크에 이어 두 번째 교주님이신 박문호 박사가 ‘하사’하신 공부 방법에 대한 썰이다. 참고로 내게 교주님이란 존경하다 못해 돈까지 바치게 만드는 자를 뜻한다. 테슬라 주식 및 ‘박문호 박사의 빅히스토리 공부’ 책은 내가 바친 돈의 예.
일론 머스크야 너무 유명하니 별도로 설명할 필요는 없겠고, 박문호 박사는 ETRI 연구원으로 정년 퇴임하여 현재는 공부 및 이에 대한 전파에 매진하시는 ‘매우 비범한’ 연구자님. 왜 ‘매우 비범한’이란 수식어를 붙였는지는 그의 이력 뿐 아니라 아래 동영상에서 뿜어나오는 지식의 아우라를 직접 느껴보면 안다.
저 유튜브 제목과 부제에서 느껴지는 쌈마이, 사이비스러움이 눈에 거슬리지만, 실상 이 양반이 전하는 무엇은 이들에 정 반대편에 위치한다. 대칭화, 모듈화, 순서화란 이 세 가지가 공부법의 핵심이라고. 맘에 특히나 와닫던 이유 중 하나는 논거가 뇌과학, 즉 인간의 본성에 미치는 데 있다. ‘뇌가 편안해지기 때문에’는 이에 대한 대표적 예.
아래는 이에 대한 요약이라기보다는 나의 이해 및 연상에 더 가깝다.
대칭화
(익힐 여러 대상을) 대칭화하면 기억해야할 정보가 줄어들어 뇌가 편안해지기 때문이고, 나아가 편안해지기에 아름다움까지 지느끼게 된다. - 박문호
대칭이란 어휘는 입자 물리학에서 가져왔다는데 무려 이를 다루는 노이터 정리까지 언급한다(사실 이건 삼천포인데, 난 그 삼천포가 넘 좋았다). 노이터 정리에 대해서는 아래에 따로 적었다.
대칭화란 말이 사실 잘 와닫지 않는데, 대칭화는 사실상 일반화와 동일 의미로 이해된다. 대칭은 불변성을 의미하는데, 일반화란 것이 이 불변성을 각 특수에서 찾는 과정이기 때문.
그가 이렇게 생각한 이유는 어쩌면 당연스러운데, 일반화는 귀납법의 핵심이고 귀납법은 과학에서 진실 획득의 최애 수단이며, 우리는, 특히나 그는 과학의 시대에 살고 있기 때문이다. 해서 귀납법의 선구자들에게 이 공을 돌려야 할지도. 여담으로, 그 선구자는 내 어릴적 맘에 꼳힌 말(진실은 혼돈보다는 과오에서 더 잘 드러난다)을 했던 Francis Bacon으로 보통 일컫는다.
공부법 핵심: 대칭화, 모듈화, 순서화
예술/인문 소감
대칭화
순서화
모듈화
노이터 정리
프란시스 베이컨
뇌과학
박문호
교주님
2024/02/25
근래의 Web 기술 트렌드라는 몇몇 컬럼을 읽다 보니 눈에 걸리는 용어가 보여 간단히 내가 이해한 수준에서 적어 둔다. 몇몇 용어는 새로운 가치를 담았다기에는 무리가 있어 보이기도. 이외 SSG, MDX, ZTA 등 일부는 이미 오랜 용어이지만 이제야 이해했기에 함께 적었다. MDX는 그렇다쳐도 SSG는 나타나 인기를 끈지 10년이 넘은 듯 한데, 뒤쳐진 내가 좀 부끄러워지기도.
아래는 용어 정리를 하게 만든 컬럼 중 일부이다.
PWA(Progressive Web App)
smartphone 초창기부터 계속 이어지던 web으로의 phone app 기술 단일화 - cross platform 개발의 또 다른 시도인 듯. 그나마 기대했고 성과를 내는 듯 했던 Reactive Native, Flutter 조차 어려워 보이던데… PWA는 그래봤자 browser를 그대로 쓰는 web app이라 이질적 UX나 늦은 반응성 문제를 얼마나 해결하는지 의문.
구조적으로 browser가 native 관련 지원을 해야 할 텐데 Android에서는 Google이 PWA tutorial까지 만든 상황이니 그렇다 쳐도, Apple의 경우 이에 대해 공식적인 지원에 대한 언급을 찾기 어려울 뿐 아니라 많은 부분이 지원 안되는 모습을 보이는 도표마저 보이는 중.
•
web 관점: web 기술 기반의 단일 codebase, web에서 직접 접근 가능
•
native 관점: home 화면 icon, app store 기반 설치, background mode / offline 동작, (OS 또는 server) push notification, (browser UI 없는) 전체 화면 동작
References
frontend 관련 트렌드 기술 용어 정리(2024.02)
S/W 엔지니어
SSR
SSG
Headless Architecture
Multi-runtime microservices
ZTA
Zero Trust Architecture
markdown
mdx
2024/02/10
Load more
카테고리 별 글
Search
음악인
13
Load more
S/W 엔지니어
111
Load more
예술/인문 소감
70
Load more
自省(Introspect) / 세상살이
69
Load more
프로젝트s
92
Load more
방명록 백업