Cloud Native Computing Foundation / KCD Korea 2021

분산 추적(distributed tracing)은 요청이 마이크로서비스 및 서버리스 애플리케이션과 같은 다양한 서비스 아키텍처를 통해 트래픽이 이동하는 경로를 기록합니다. 또한 수백 개의 구성 요소 간의 종속성과 관계를 측정하는 형식으로 마이크로 서비스 아키텍처의 observability 에서 매우 중요합니다. 분산 시스템에는 다양한 언어, 프레임워크 및 인프라 구성 요소가 포함되기 때문에 일반적인 접근 방식 없이는 수행하기 어렵습니다. OpenTelemetry는 API, SDK 등을 제공함으로써 마이크로 서비스간 종단 간 분산 추적 remote tracing을 위한 표준을 제공합니다. OpenTelemetry에 대한 소개와 예시를 통해 어떻게 애플리케이션의 tracing 을 측정하고 기록할수 있는지 설명합니다.

2021년 초부터 쿠버네티스 코리아 그룹에서 진행했던 k8s 101, Istio 그리고 cluster-api 스터디에 대한 회고를 해보려고 합니다.
회고 뿐만이 아니라 앞으로의 계획도 공유를 드리려고하니 많은 관심 부탁드립니다~

쿠버네티스의 창시자 조 베다(Joe Beda)와 크레이그 맥러키(Craig McLuckie)가 VMware에 근무하고 있다는 사실을 알고 계시나요? 사실 VMware는 오픈소스 쿠버네티스 생태계에 굉장히 많은 기여를 하고 있답니다. 쿠버네티스를 사용하고 계시는 분들이라면 누구나, 관련된 여러 오픈소스와도 함께 사용하는 것이 필연적이지요. 이번 키노트에서는 쿠버네티스의 방향을 이끄는 오픈소스의 생태계의 최신 기술에 대해서 알아봅니다.

무신사는 단순히 옷을 판매하는 온라인 쇼핑몰이 아닌, 옷에 대한 모든 서비스를 고객에게 제공하는 패션 플랫폼입니다.

날카롭고 예민한 트래픽과 고객 유입량을 효율적으로 소화하기 위하여 노력했던 무신사 인프라 변화 모습에 대해 소개합니다.
IDC에서 클라우드로 전환 과정과 쿠버네티스까지 왜 사용하게 되었는지, 클라우드에서 쿠버네티스를 어떻게 운영하고 있는지, 클라우드에서 제공하고 있는 쿠버네티스 에코시스템 기능을 왜 사용하게 되었는지에 대해서 공유하려고 합니다.

2년간 DPDK Application을 Kubernetes에서 구동하기 위해 Kubelet의 Hugepage, Topology Manager Feature를 확장하고, Memory Manager란 신규 Feature를 제안하여 기여하였습니다. 이 과정에서 Kubelet과 Container Runtime간에 사용되는 CRI Spec을 확장하고, Docker, ContainerD, CRIO와 같은 Container Runtime에도 기여를 하며 Kubernetes Internals와 Container을 구성하는 근간 기술들에 대해 학습 할 수 있었습니다. 그리고 컨트리뷰션 과정에서 Intel, Redhat, Nvidia, Google, 등 다양한 회사들의 개발자들과 교류 하며 Power of community에 대해서도 많은점을 배웠습니다. 이러한 2년간의 Contribution 과정과 이 과정에서 개발자로써 얻을수 있었던 Lesson Learned에 대해 공유하고 Community에서 논의 되는 최신 변경사항도 간단하게 공유드리고자 합니다.

리눅스 기반의 Kubernetes 클러스터를 구축하고 있는 상황에 난감하게 Windows OS 기반의 서비스가 등장했습니다. 해당 서비스를 위해 별도의 VM을 구성하거나 Windows Node를 만들어서 클러스터 조인을 하는 것은 너무 힘들고 복잡한 것 같습니다. 그래서 준비했습니다.
Kubevirt 기반의 Linux Kubernetes 에서 Windows OS를 Pod형태로 배포를 했습니다.
리눅스 기반의 Kubernetes 클러스터에 Windows OS기반으 서비스를 올리는 것에 난감했던 지난 날을 잊고 이번기회에 Kubevirt를 이용해서 Kubernetes 에 Pod 기반으로 Windows를 설치해 보시는건 어떠신지요?
어렵지 않고, 복잡하지 않고 간단하게 테스트 경험을 공유해 드립니다. 😊

발표자료: https://docs.google.com/presentation/d/1OPrJjwzByGkUa6KgY5JVrUr-39t-w8GU/edit?usp=sharing&ouid=104128282621057166215&rtpof=true&sd=true

사물인터넷(IoT) 환경이 상용화되면서 점차 다양한 기기들이 인터넷에 연결되고 그로 인해 생성되는 데이터가 엄청난 속도로 증가하고 있으며 이렇게 다양한 경로를 통해 수집된 데이터들은 데이터 분석을 위해 데이터센터로 모이게 됩니다. 2025년이 되면 전 세계에서 생성되는 데이터가 175제타바이트(175조 기가바이트)가 될 것이며 이 중 Edge 장치에서 생성되는 데이터는 90제타바이트 이상이 될 것입니다(-IDC Data Age 2025 보고서 – 세계의 디지털화: Edge에서 코어까지)
엣지 컴퓨팅은 다양한 단말기기에서 발생하는 데이터를 클라우드와 같은 중앙 집중식 데이터센터로 보내지 않고 데이터가 발생하는 현장 혹은 근거리에서 실시간 처리하는 방식으로 데이터 흐름 가속화를 지원하는 컴퓨팅 아키텍처이며 4차 산업혁명으로 더욱더 주목받고 있습니다. K3s는 엣지 컴퓨팅을 대비하여 만든 Lightweight Kubernetes로 현재 많은 주목을 받고 있기 때문에 K3s 소개및 구축방법을 소개해 드리며, K3s 환경에서 서비스 어플리케이션 개발방법 예제 및 K3s의 모니터링및 관리 방안을 소개해 드립니다

발표자료: https://docs.google.com/presentation/d/1HeSK_YsMgFWAzjK87GwzsICXPIEYwc3I/edit?usp=sharing&ouid=104128282621057166215&rtpof=true&sd=true

기업환경에서는 다양한 니즈에 의해 용도별 혹은 지역별로 다수의 클러스터를 구성하면서 멀티 클러스터에 대한 관리의 용이성이 필요하다. SKT는 TKS (Taco Kubernetes Service)를 public cloud에서 서비스할 예정이며 이 과정에서 멀티 클러스터의 지원은 필수적인 요소였고 이러한 환경에서 단순하고 통일된 가시성 구조가 필요했다. 이 세션에서는 TKS를 준비하면서 기존 prometheus federation model에서 thanos 체계로 전환하여 멀티 클러스터 환경에서의 가시성을 확보한 방법을 공유하고, 이 과정에서 마주친 문제와 해결 방법을 공유한다.

이 세션은 kubernetes에 대해 익숙한 운영자/개발자를 대상으로 하며 다음의 내용을 포함한다.

- Prometheus 소개
- Thanos 컴포넌트 별 소개
- 멀티 클러스터 모니터링 구조

본 세션에서는 SKT의 어플리케이션 배포 기술인 Decapod의 진화된 버전인 v2 버전을 소개합니다. Decapod는 declarative application orchestration & delivery 를 위한 tool-chain으로서 직관적인 yaml document 작성과 application 배포 체계를 제공합니다. 이번 v2 버전은 Argo-cd와 argo-workflow 를 조합하여 app-of-apps 패턴으로 group of application 을 효과적으로 배포하고, 결과를 UI 상에서 가시적으로 보여주며, 소스 코드 상의 변화 발생시 gitops 방식으로 즉각적인 업데이트를 수행합니다. 또한, 최초 설치시에도 역시 app of apps 패턴을 사용하여 스스로 bootstrap하는 기능을 포함하고 있습니다.

후반부에는, SKT에서 현재 사용하고 있는 사례들, 예를 들면 kubernetes cluster-api, helm, decapod를 조합하여 gitops방식으로 kuberenetes cluster를 배포/관리하고, 그 위에 thanos, prometheus등 여러 개의 서로 관련된 app들을 LMA라는 하나의 논리적 group으로 배포하는 사례를 소개합니다

모든 decapod 관련 코드들은 GitHub 상에서 오픈소스로 관리되고 있습니다.

발표자료: https://drive.google.com/file/d/1phjKwPQp7fSqyDeHRQFAbGn5D0_H_U9G/view?usp=sharing
잘 짜여진 모놀리스는 효율적이고 직관적이며 운용하기 편리한 합리적인 아키텍처입니다. 대부분의 작은 규모의 회사는 모놀리스로 서비스를 시작하지만 이 중 대부분은 서비스의 규모와 인력이 점차 늘어남에 따라 효율적인 아키텍처를 장기적으로 유지하는데 실패합니다. 오히려 모놀리스라는 이름의 수년간 쌓아온 프랑켄슈타인에 세번째 팔과 다섯번째 다리를 용접하고 있는 자신을 문득 깨닫게 되는 일도 드물지 않습니다. 뒤늦게 개발도 운용도 정상적으로 진행 할 수 없는 하향 나선의 상황에 직면에 있음을 깨닫게 되어도, 이미 하루에도 수만명이 이용하는 서비스를 근본적으로 손 대는 것 또한 좀처럼 엄두가 나지 않습니다. 우리는 수년간 쌓아 온 모놀리스 서비스를 해체하고 클라우드의 쿠버네티스로 옮길 수 있을까요? 어떻게하면 서비스를 사용하는 수 많은 유저들이 알아차리지 못하는 사이에 우리의 서비스를 안전하게 이전 할 수 있을까요? 클라우드 네이티브로의 이전은 과연 우리들의 Velocity에 큰 영향을 줄까요? 이 세션을 통해 데이터센터의 모놀리스를 클라우드의 쿠버네티스로 성공적으로 이전하기 위한 전략과 클라우드 네이티브 서비스의 장점, 그리고 주의점들을 짚어보려 합니다.

카카오페이는 고객의 돈을 다루는 전자금융 서비스입니다.
모든 서비스들은 안정성이 중요하겠지만 금융을 다루는 환경에서는 서비스 안정성과 영속성은 더욱 중요한 키워드 입니다.

카카오페이는 2018년부터 거대한 1개의 Kubernetes 클러스터에서 Istio를 도입해서 사용해왔습니다.

카카오페이 DevOps 팀에서는 SPOF(Single point of failure)가 발생할 수 있는 아키텍처라고 판단 하고,
더 단단하고 회복가능한 DR(Disaster recovery) 구조의 Multi Kubernetes 환경으로 개선하고 있습니다.

Multi Kubernetes 환경에서 사용자인 엔지니어들이 동일한 사용 경험을 유지할 수 있고,
클러스터를 운영하는 엔지니어 관점에서도 필요한 다양한 플랫폼(K8S API Proxy/Event, Logging System/Cluster State manager)들을 개발하고 제공하기 위해 노력하고 있습니다.

기술력과 안정성이라는 양립하는 가치를 모두 지키기 위해서 카카오페이 DevOps 팀에서 노력했던 몇가지 사례들을 공유하려고 합니다.

쿠버네티스는 클라우드 환경에서 가장 성공한 컨테이너 관리 시스템입니다. 쿠버네티스는 다양한 오픈소스를 제치고 어떻게 성공할 수 있었을까요? 다양한 이유가 있지만 쿠버네티스가 클라우드에 적합한 디자인을 가지고 있기 때문입니다. 각 컴포넌트는 약결합을 가지며 낙관적 동시성과 캐싱을 통해 성능을 극대화 하였습니다. 이 발표에서는 쿠버네티스가 어떤 좋은 디자인을 가지고 있는지 공유합니다. 특히 쿠버네티스의 핵심 구성요소인 kube-apiserver와 client-go를 코드 레벨로 분석해봅니다. 이를 통해 쿠버네티스의 디자인 원칙을 이해하고 클라우드 환경에서 성공할 수 있었던 이유를 알아봅니다.

쿠버네티스 환경에서 실행되는 애플리케이션과 데이터를 보호하고, 다른 클러스터로 워크로드와 데이터를 이동하거나 재해복구를 적용하는 방안을 소개합니다.

발표자료: https://drive.google.com/file/d/1-hCYj09Cw0mhFs8KtYrCXHf2rVQGz7IZ/view?usp=sharing

어떻게 해서 AI.Node 에서 쿠버네티스를 사용하게 되었고, 이후 첫번째로 경험해본 대회에서 어떠한 일들을 겪었는지, 그리고 이후 수많은 시도 끝에 어떻게 실패를 하였고, 이후에 실패를 바탕으로 어떻게 극복하여 실패를 실패로만 끝내지 않았는지에 대하여 발표해보려고 합니다.

체커에서 만들고 있는 쿼리파이는 데이터 거버넌스를 위한 솔루션으로써 고객의 환경에 설치되어야하는 특성을 지니고 있습니다. 이 세션에서 쿼리파이를 고객에게 전달하기 위해서 쿠버네티스를 비롯한 다양한 오픈소스를 제품에 녹여낸 경험을 공유하고자 합니다. 예를 들어서, 쿠버네티스에 배포할 컨테이너 이미지를 만드는 법(docker, buildpack)이나, 쿠버네티스 생태계에 빠르게 배포하기 위해 헬름(helm, helmfile)을 작성하고 배포하는 과정을 비롯해서, 내부에서 사용하는 CI/CD 파이프라인 구성을 통해 어떻게 여러번 해야하는 작업을 자동화 했는지 이야기합니다. 마지막으로 운영에서 쿠버네티스에서 로그를 확인하거나, 클러스터의 컨텍스트 및 네임스페이스를 변경하는데 사용하는 도구들인 kubectx, kubens 같은 도구를 소개합니다. 마지막으로 쿠버네티스 환경이 아닌 곳에서도 쿼리파이를 배포하기 위해 어떤 방식을 채택하고 구현하고 있는지 공유하고자 합니다.