Who and Why am I here?
제 소개와 연락처입니다. 각 페이지 맨 아래에 또는 댓글 한마디 남겨주심 그저 좋아라~ 합니다.
My Cluster & its assets
2011년산 노트북(Intel Core i5, 16M) 내에서 동작하는 (Home) Kubernetes Cluster 및 여기서 운용 중인 서비스 링크, 그리고 설명(w/ git repo)입니다. 이 블로그 글에서 다루는 서비스 대부분을 여기서 테스트합니다.
최근 글
Search
LG SDC 2024 발표 내용
그간 여기서 한참이나 다루었던 Service Mesh와 OpenTelemetry에 대해 LG SDC(Software Developer Conference) 2024에서 발표한 내용이다.
LG SDC 2024
https://www.lgsdc.com/
LG SDC 2024 홈페이지
제목은 Platform Engineering for ThinQ Cloud이지만 이는 실제 주제인 Service Mesh, OpenTelemetry, Internal Developer Portal에 대한 context에 해당한다. Internal Developer Portal은 동료 팀원이자 다음 블로그의 주인장이 담당했다.
SEOWOO THOUGHTS
개인적인 생각과 공부, 그리고 업무에서 배우는 것들을 정리하여 남기고 있습니다.
https://www.gomgomshrimp.com/
공동 발표한 공서우님의 블로그. Kubernetes에 대해 특히 심도있게 논한다. 이 notion 기반 블로깅 아이디어를 내게 전하기도.
사실 제목이 context가 되어버린 사연이 있다. 원래 Platform Engineering for ThinQ Cloud, Service Mesh/OpenTelemetry, Internal Developer Portal 각각을 각기 다른 세션으로 각기 다른 발표자가 발표하기를 기획했지만, 주최측에서 Platform Engineering for ThinQ Cloud만을 선정한 것이다. 해당 발표자는 아래 블로그 주인장이자 내가 속한 조직의 팀장님.
근데 이 발표를 우리 둘에게 양보했기에 결국 3개 주제가 하나의 발표로 묶이게 된 것이다. 시간에 쫓기는 통에 발표 시 감사 인사 전달을 잊었는데, 대신 이 블로그 글을 통해서나마 감사 인사를 전하고자 한다.
reshout's blog
승부는 거의 출발점에서 정해진다.
http://blog.reshout.com/
발표를 양보해주신 김건우님의 블로그. Web 상의 개인 log란 blog의 탄생 시 목적에 정확히 부합한다.
발표 내용은 공서우님이 담당한 Internal Developer Portal과 극히 일부를 제외하고는 모두 본 블로그에서 다룬 것들이다.
참고로 전체 30분 발표에 둘이서 나누는 그 짧은 시간 대비, 다루는 주제 범위가 너무 컸음을 부인하기 어렵다. 따라서 청자에게 많은 부담을 지우게 된 것이 사실이다. 이러한 컨퍼런스는 지식의 전달 보다는 일종의 ‘장기자랑’ 속성이 강하다는 것을 감안하자면 그럴 수도 있겠다 싶지만 찝질한 마음은 지우기 어렵다.
이 땜시 발표 자료에 이 블로그 소개도 할 겸 참조 문서에 상세 내용 링크를 잔득 달아놨는데, 정작 홈페이지에서 발표 자료가 공유 안되고 있는 점은 안습. 2022, 2023년도 자료를 공유하기는 하기에 언젠간 2024의 것도 공유하긴 할 듯 하지만, 근데 정작 볼만한 사람들이 관심 가질 시점에 없으면 그게 무슨 소용인가. 해서 발표 자료는 아래에 남겨둔다.
•
발표자료
LG SDC 2024 발표: Service Mesh, OpenTelemetry
自省(Introspect) / 세상살이
Service Mesh
OpenTelemetry
Observability
LG SDC 2024
2024/09/18
Open source 기반 Observability architecture. 에서 자세히 설명한다.
Introduction
Open source를 기반으로 한 Observability 환경 구축에 대한 논의이다. 본 논의 중심에는 OpenTelemetry 뿐 아니라 Service Mesh(Istio), Prometheus, Grafana가 위치한다.
Motivation
일반적으로 Observability의 vendor 제품 운용 비용은 상당하며, 이로 인한 제약은 커지기 마련이다. 다음은 Hacker news에 올라온 Coinbase의 Datadog 비용 이슈(연간 $65M, 약 867억원)에 대한 논의인데, 성토가 어마어마하다.
상기 논의의 주요 comment 모음(한글 자동 번역)
위 Coinbase는 결국 전담 팀을 꾸려 Open Source 기반으로 전환 중에 Datadog이 ‘거부할 수 없는 거래’를 제시해 Datadog으로 유지했다고. Observability는 사실 상 infra level의 서비스로 app 전반의 영역에 걸쳐 분포하기 마련이라 타 솔루션으로의 전환이 어려울 것은 자명하다.
이런 상황에, OpenTelemetry로의 data export를 못하도록 OTel Datadog receiver PR을 방해한 흔적마저 보인다. 이를 딛고 감행한 해당 PR 작성자로의 응원이 엄청나다.
Summary
•
Open source 기반 Observability는 vendor의 그것을 대체 가능하다.
•
본 Open source 기반 Observability Architecture에는 OpenTelemetry 및 Istio, Prometheus, Grafana가 중심이다. 이들 모두 각자의 영역에서 오랜 시간 검증 받은 제품이다.
Open Source 기반 Observability via OpenTelemetry, Service mesh
S/W 엔지니어
Observability
Istio
Service Mesh
OpenTelemetry
OpenMetrics
Prometheus
Grafana
2024/09/12
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자의 테스트 결과로, 특히 메모리 사용량 개선은 극적이다.
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에 해당한다.
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. 로 이어 진다).
참조한 문서는 글 내부 및 에 달았다.
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
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 부하 감소
S/W 엔지니어
Istio
DNS
DNS Proxy
Kubernetes
DNS cache
Nodelocal DNSCache
2024/05/25
Load more
카테고리 별 글
Search
음악인
13
Load more
S/W 엔지니어
121
Load more
예술/인문 소감
70
Load more
自省(Introspect) / 세상살이
70
Load more
프로젝트s
92
Load more
방명록 백업