Anyflow Kubernetes 주요 assets
집에서 운영하는 k8s 클러스터 내 주요 서비스로 공부 겸 포트폴리오.. 머 그런거입니다(개발 서버인 관계로 종종 연결에 실패할 수 있습니다).
최근 글
Search
Introduction
아래는 한국어로 번역된 The Twelve-Factor App 방법론 링크이다. 여담으로, 번역을 누군가 해줘서 고맙기는 한데, 요즘엔 자동 번역 품질이 너무 좋다보니 그 고마움이 반감되고는 하는게 함정. 오히려 잘못된 의역의 위험이 줄기에 이를 더 선호하기도. 실제 아래 번역에서 그 위험성이 보인다. backing service를 백엔드 서비스라 번역을…
The Twelve-Factor App 방법론의 이점
Google Cloud 문서의 표현을 그대로 옮긴다.
Twelve-Factor 설계를 활용하면 앱 구성요소를 분리할 수 있으므로 각 구성요소를 쉽게 바꾸거나 원활하게 확장 또는 축소할 수 있습니다. 이러한 요소는 모든 프로그래밍 언어 또는 소프트웨어 스택과는 별개이므로 Twelve-Factor 설계를 다양한 앱에 적용할 수 있습니다.
The Twelve-Factor App
1. Codebase: 버전 제어로 추적되는 단일 코드베이스, 다수의 배포
The Twelve-Factor App 개인적 해석 1/2
S/W 엔지니어
The Twelve-Factor App
방법론
methodology
codebase
config
dependency
반의존성
2023/11/17
아직두 이런 일에 기뻐하는 내가 놀랍기도. 기뻐하는 이유 중 하나는 그간 (이젠 ‘이전’ drummer가 되어버린) Mangini의 연주에 그간 꽤나 불만이었기 때문인데, 그의 버클리 음대 교수, 속주(?) 등 여러 명성과는 달리 무언가 곡의 맛을 못 살린다는 느낌을 지속 받아왔기 때문이다.
실제로 Youtube에 깔린 여러 Portnoy와의 비교 영상을 보면 확연히 드러난다. 이게 Portnoy 시대의 곡이라 그럴 수도 있겠다 싶은데, 예컨데 Enemy Inside 등의 온전한 Mangini 시대의 곡만 해도 이를 카피한 다른 (무명?) 드러머의 것이 확연히 다채롭고 맛깔지다. 단순히 모습만 갖고 실력을 판단해선 안되겠지만 연주 모습을 보면 뭔 놈의 힘이 스틱에 (그리고 얼굴 표정에) 그리 많이 들어갔는지 보는 내가 힘들 지경. audition시 Mangini가 아닌 Marco Minnemann이 붙었으면 더 좋았을 걸.. 생각마저.
그간 LTE3 등을 통해 꾸준히 협업을 해왔던 Rudess나 Petrucci 뿐 아니라 Myung 역시 당연스럽게 격하게 반기는 반면, Portnoy가 탈퇴했을 때 매정하게 굴었던 Labrie는 Loudwire, Twitter 모두에서 무언가 표면적 수준에서의 반응이다. 부디 목 관리에나 좀 더 신경 써주길 바라는 마음.
앞서 Mangini를 까기는 했지만 그가 나가면서 하는 멘트가 무언가 좀 짠해오는 느낌인데, 그간 자신의 역할이 Portnoy의 역할 대체가 아닌 Dream Theater가 계속되도록 돕는 것이었다고. 인터뷰어는 겸손하게 답변한 것이라 덧붙였지만 그게 단순히 겸손이 아닌 실제 그런 것이 아닌가 싶기도. 필시 속 마음은 팀에 더 남고 싶어했을 듯하다. 그런 면에서 이 멤버 교체가 결코 쉽지만은 않았겠단 생각.
Portnoy가 그간 몸담았던 Sons of Apollo는 이로서 사실 상 끝인 듯 하다. 코로나 경부터 멤버 각기 따로 활동했던 듯 싶은데, 보컬 Soto의 인터뷰를 보니 Portnoy가 사전에 이를 알린 것은 아닌 듯. 아무리 각기 활동했다고는 하지만 이건 좀 너무한 것 아닌가 싶다. 개인적으로 Portnoy와 Sherinian의 사운드를 나름 좋아라해서리 종종 듣고는 했지만 머 어쩔 수 없지..란 마음.
요즘 옛 멤버 재결합이 추세라는데 재결합하고도 새 앨범은 못 내고 있는 Guns N’ Roses 와는 달리 바로 새 앨범 작업에 들어갔다는 데 역시나 모범생 그룹답다는 생각. 앗싸!
Mike Portnoy is Back!
예술/인문 소감
Dream Theater
Mike Portnoy
Mike Mangini
2023/11/01
Introduction
API Gateway와 Service Mesh의 통합을 위한 방안으로서의 k8s Gateway API에 대해 논한다.
Motivation
Service Mesh, 예컨데 istio의 경우, internet facing service에 대해 virtual service에 기반한 traffic 관리를 위해서는 istio ingress gateway가 필요하다. 이는 명칭에도 보듯 아키텍처 상 API Gateway와 또 다른 중복이다.
앞선 글인 Ingress + API Gateway = Kubernetes Gateway API에서 위와 같이 문제를 제기했지만 k8s Gateway API가 이를 어떻게 해결하는지에 대해서는 언급하지 않았다. 사실, API Gateway 앞단에 load balancer나 ingress를 위치시키는 것은 network topology 상 역할 중복임에도 여러 이유로 일반적일 것이라 예상한다(e.g. ingress/L4 load balancer vendor ≠ API Gateway vendor). 이러한 상황에 ingress gateway 추가는 결국 이중 중복을 유발한다. 불편한 마음이 몰려든다.
Ingress + API Gateway = Kubernetes Gateway API에서 위와 같이 문제를 제기했지만 k8s Gateway API가 이를 어떻게 해결하는지에 대해서는 언급하지 않았다. 사실, API Gateway 앞단에 load balancer나 ingress를 위치시키는 것은 network topology 상 역할 중복임에도 여러 이유로 일반적일 것이라 예상한다(e.g. ingress/L4 load balancer vendor ≠ API Gateway vendor). 이러한 상황에 ingress gateway 추가는 결국 이중 중복을 유발한다. 불편한 마음이 몰려든다.North-Sourth traffic과 East-West traffic
본 주제에 키가 되는 주요 용어 먼저 설명한다.
•
North-South traffic : 클러스터 내외로 발생하는 트래픽이다.
•
East-West traffic : 클러스터 내에서 각 workload 간에 흐르는 트래픽이다.
이들 두 용어 관점에서 보자면 API Gateway는 Noth-South traffic를 다루는 모듈이다. 이 traffic은 API Gateway를 이후로 끝나거나(API Gateway에 연결된 worload에서 처리가 끝나는 경우), East-West traffic으로 전환된다(API Gateway에 연결된 service가 타 worload를 호출하는 경우). Ingress + API Gateway = Kubernetes Gateway API 는 본 관점의 설명임과 동시에 아래 그림은 바로 이 상황을 나타낸다.
Ingress + API Gateway = Kubernetes Gateway API 는 본 관점의 설명임과 동시에 아래 그림은 바로 이 상황을 나타낸다.
North-South traffic과 East-West traffic의 차이 및 API Gateway 와의 관계
이미지 출처 : https://glasnostic.com/blog/what-is-an-api-gateway-aws-express-kong/
하지만 API Gateway가 cluster 내부, 타 workload와 동일 cluster 내에 위치한다면?
이러한 배치는 그다지 낯선 경우가 아니며, CSP 제공이 아닌 API Gateway를 사용할 경우 오히려 일반적이라 예상한다. 이 경우 API Gateway는 위의 용어 정의에 따라 East-West traffic 역시 처리 대상이 되어 버린다. 그리고 이 East-West traffic의 실체는 다름 아닌 North-South traffic으로, 동일 traffic을 관점에 따라 나뉜 것일 뿐이다. 이 경우 위 그림의 API Gateway는 아래와 표현 가능하다.
API Gateway + Service Mesh = Kubernetes Gateway API
S/W 엔지니어
k8s
Kubernetes
istio
api
API Gateway
Gateway API
Kubernetes Gateway API
2023/10/03
Gateway API 기반 k8s resources(Gateway, HTTPRoute)와 타 k8s resources(Service, Pod)와의 관계
이미지 출처 : https://gateway-api.sigs.k8s.io/api-types/httproute/
Introduction
k8s ingress의 superset에 해당하는 Kubernetes Gateway API에 대해 논한다. 사실 상 Kubernetes Gateway API 공식 문서인 https://gateway-api.sigs.k8s.io/를 주로 참조한 개념적 요약이다.
Motivation
•
Network topology 관점에서 보자면 ingress와 API Gateway 모두는 L7 load balancer에 해당한다(k8s 외부로의 단일 접점 제공, L7 기반 부하 분산). 따라서 이들 둘을 별도로 운용하는 것은 비효율적이다. (이로 인해, 일반적으로는 L4 Load balancer에 API Gateway를 붙여 사용하리라 예상한다).
•
Service Mesh, 예컨데 istio의 경우, internet facing service에 대해 virtual service에 기반한 traffic 관리를 위해서는 istio ingress gateway가 필요하다. 이는 명칭에도 보듯 아키텍처 상 API Gateway와 또 다른 중복이다.
k8s Gateway API는 이들 문제에 대한 해결안이다.
Kubernetes Gateway API는 23.09.24 현재 v0.8.1로 베타 버전이다. 그럼에도 istio ingress gateway를 포함한 많은 API Gateway 솔루션이 현재 본 API를 지원 중이다.
What is k8s Gateway API?
Gateway API는 SIG-NETWORK 커뮤니티 에서 관리하는 오픈 소스 프로젝트로서, Kubernetes에서 서비스 네트워킹을 모델링하는 API(리소스 모음)입니다… 이전 Ingress API 에 익숙하다면 Gateway API를 해당 API의 더욱 표현력이 풍부한 차세대 버전과 유사하다고 생각할 수 있습니다.
from k8s Gateway API 공식 site
위의 공식 site의 정의 중 둘째 문장이 중요한데, Gateway API는 ingress API를 사실 상 대체 가능한 superset임을 암시한다. 참고로, ingress와 API Gateway 모두는 Network 관점에서 보면 L7 Load balancer에 해당하지만, API Gateway는 ingress와는 달리 L7 protocol(e.g. HTTP)에 특화된 다양한 작업을 수행 가능하다.
한마디로 말해, k8s Gateway API란 ingress + API Gateway인 셈이다.
k8s Gateway API의 resources 및 이들 간 관계
Ingress + API Gateway = Kubernetes Gateway API
S/W 엔지니어
k8s
API Gateway
Kubernetes
Gateway API
ingress
istio
Kubernetes Gateway API
2023/09/24
Load more
카테고리 별 글
Search
음악인
13
Load more
S/W 엔지니어
61
Load more
예술/인문 소감
26
Load more
自省(Introspect) / 세상살이
33
Load more
프로젝트s
9
방명록 백업