쿠버네티스/앱 현대화 테크 세미나

Keynote - SKT Cloud R&D 안재석

복잡한 쿠버네티스의 설치 과정과 솔루션

목표와 세미나 개최

각자마다 복잡한 쿠버네티스에 대한 다양한 환경과 제약조건을 가지고 있어 다양한 해결 방법을 가지고 있어 Silver Bullet 을 가지고 있다고 생각

발표 인사와 진행자 소개

4가지 공통 문제 정의

• 첫번째 테크나 세미나, 쿠버네티스 설치하기
• Searching…

한국 쿠버네티스 커뮤니티 소개 - 데보션 김상기

커뮤니티가 하는 역할

CNCF가 커뮤니티와 행사를 지원하는데 한국에는 CNGF 커뮤니티(Kubernetes Korea Group)

KCD Seoul 2024

• 9월 24일 예정

CNCF K8s contributor card 나올 예정

데보션(SK 개발자 커뮤니티) 소개

데보션 소개

데보션 (DEVOCEAN) 기술 블로그

내부 개발자 → 데보션 → 외부 개발자

데보션은 개발자와 소통하는 테크 블로그 & 커뮤니티 플랫폼

DEVOCEAN 앱이 있음 다른 플랫폼과는 차별화

• 대내외 개발자 소통/공유 를 위한 플랫폼
  • 지식과 경험을 소통하고 공유하는 장
• 대보션 전문가 프로그램
  • 최신 트렌드 및 우수 발표 사례 영상 제공
• Tech 블로그 & 영상 제공
  • Tech 블로그 작성 및 기술 멘토링
• 데보션 영 프로그램
  • 예비 개발자로 데보션 홍보 및 공유 문화 확산
• 외부 스터디도 운영중

다양한 클라우드 환경에서 선언적으로 Kubernetes 서비스 제공하기 - SKT 엄주관

쿠버네티스를 사용할 때 사용자의 권한과 역할 어떻게 사용할 것인지 이것들을 만들어주는 솔루션

TkS 엔터 플라이즈 솔루션 - 클라우드 서비스

TKS 앱현대화 플랫폼 시연

Kubernetes as Service를 스택 설정

• 준비된 스택으로 설정 가능

설정 후 → 스택 생성

Template as a Service

사내 외 기업 고객들에게 쿠버네티스 기반 애플리케이션 현대화 솔루션 제공

• 쿠버네티스, 애드온, 멀티 클러스터 텅합 모니터링, CI/CD 세트로 제공 하는 것으로 목표
• 규모 : 클러스터 X대, 클러스터 하나 당 X~ XX 노드
• 구축과 운영이 제 3자에 의해 수행
• 온프레미스.프라이빗 클라우드, 퍼블릭 클라우드

다품종 소생산

• 요구 사항 분석 → 템플릿 제공
• 서비스 자체를 어떻게 구축할 것 인지에 관한 문제

지나온 길

Sk 에서 문제상황을 인식하고 해결하는 과정들

Kubespray를 중심으로 Ansible 플레이북을 추가하고 통합

• 필요한 소프트웨어들을 한 번에 설치, 제거, 확장할 수 있는 통합 playbook 제공
• 각 소프트웨어들 간의 통합

추가 어플리케이션들은 Armada를 활용해 Helm으로 설치

• 다 수의 Helm 차트 Value를 단일 YAML을 관리하고 차트 그룹 정의 및 그룹 별 의존성 지정 등 설치 방법을 제공

Armada 극복

Armada 문제점

• 너무나 큰 Armada YAML
• 각 Helm 차트 Value 마다 동일한 값이 반복 사용되는 경우 누락

Decapod (v1) : Kustomize Plugin + Atgo Workflow + Helm

• …

그러나..

설정된 파일의 내용과 실제 환경에 적용된 내역과의 비교.추적 및 조치의 어려움

• 플레이북 실행 시점에만 적용
• 운영 편의 ㄷ으의 이유로 수동으로 환경 수정한 부분과 플레이북 재 반영 시 충돌

클러스터에 대한 설정 Ansible 와 애플리케이션 설정 Helm 분리

퍼블릭 클라우드로 확장한더면

• 기존 방법을 재사용하는 것도 가능하지만 비효율저그 인프라 프로비저닝은?

NOW..

Decapod V2

Kustomize Plugin + Argo Workflow + Argo CD ( GitOps) + Helm + Raw YAMLs

• Git 저장소
  • 변경 이력 유지

여기까지가 어플리케이션 입장으로 설명..

Cluster API

Cluster API 구성 요소

사진

Cluster API 커스텀 리소스

Self-managed Admin.Management Cluster

BYOH 인프라 프로바이더

SK에서 템플릿화로 제공

현재의 고민

기술적인것 보다 얼마나 잘 팔릴 것인가에 대한 고민

Decapod / 백엔드 개선

모든 자원이 Git Ops 인것은 아님

• 기술 부채 : 일부 자원은 워크 플로우에서 Kubectl 명령어로 처리

모든 자원을 Decapod 로 구현할 필요가 있는가

• 단순 CR 자원을 생성해야 하는 경우라면
  • Namespace
  • Policy
  • Alert
• 워크롤로우는 기본적으로 배치/비동기 동작, 늦은 반응성 등으로 어떻게 개선할 것인지 고민중에 있다.

Cluster API

추상환느 잘 되어 있지만 인프라를 잘 알아야 Cluster API 를 잘 사용할 수 있다

• 다양한 환경 대응 : 모든 Cluster API 인프라 프로바이더를 이해하고 사용하는 것은 불가능

사용자의 요구 사항은 우리의 예상보다 훨씬 다양하고 인프라 프로바이더의 구현에는 제약이 존재

• 우리가 생각한 베스트 프랙티스와는 다른 구성

클러스터 업그레이드

매우 성공적인, 그러나 다른 고객에게는 기대하기 힘든 사례

• 물리적으로 독립된 2개의 서비스 클러스터
  • 각 50% 워크로드 부하 처리
  • 단일 클러스터로 100% 수용가능
• 신규 버전 클러스터를 구축할 자원 여융

Cluster API는 기본적으로 노드를 Immutable한 자원으로 간주

• 신규 노드 구성, 기존 노드 폐기

사용자 워크로드 이전을 자동화하는 관점으로 접근

카카오에서 Kubernetes를 서비스하는 방법 - 카카오 전민철

카카오에서 k8s를 서비스하는 방식

• k8s 프로비저닝을 어떻게 하고 있었을까

• 지금은 어떻게 하고 있을까

• Cluster API 는 왜 사용하지 않을까

• V3 : DKOS (Datacenter of Kakao Operating System) 웹으로 통제중

  • Cluster level
  • Managed

클러스트를 생성하고 노드를 직접 제어 가능

k8s 프로비저닝을 어떻게 하고 있었을까

1. VM 생성 ( Openstack 기반의 사내 IaaS)
2. kernerl . OS 파라미터 설정
3. 컨테이너 런타임 구축
4. 쿠버네티스 구축
5. managed pod 배포

Kubespray

넓은 범위의 자동화 + 다양한 선택지 제공

동작하는 방식 Release 버전을 찍어 동작

흐름도 사진 추가

Ansible 외부 remote 접근할 때 SSH의 키페어로 사용해 보안적인 이슈가 있어 접근할 때 토큰으로 하거나 중앙 집중식으로 보안을 풀 수 있음

시간이 오래 걸린다는 단점이 존재해 다른 방법을 찾아봄

• 내부 환경과의 적합성
• 클러스터 구저 설정
• 운영 규모
• 복잡도
• 자동화 범위
• 업그레이드 지원
• 노드 추가 속도

Porvisioning Tool을 위의 기준을 고려해 찾아봄

Kubeadm VS Cluster API

kubeadm - 설정 관리 → Kubespray 많은 Task를 가지고 있는데 kubeadm을 연동했더니 노드의 버그가 존재

Cluster API - 운영규모를 감당하기 힘듬

Provisioning Tool을 사용하지 않기로 결정

1. VM 생성 ( Openstack 기반의 사내 IaaS)
2. kernerl . OS 파라미터 설정
3. 컨테이너 런타임 구축 → 정적 데이터(Image) + 동적 데이터(Cloud-init)
4. 쿠버네티스 구축
5. managed pod 배포

Control Plane → 1 - 5 단계 진행, 노드 추가 정적

Data Plane → 1 - 4 단계 진행, 노드 추가 활발, 설치 시간에 민감

흐름도 사진 추가

Cluster API 는 왜 사용하지 않을까

차이점

CRD - operator pattern :

Declarative : 클라우드 네이티브하게 동작해

CRD - Operator

• 장점 : 개발 공수가 적음
• 다른 클러스터로 이식이 쉬움
• 단점 : declarative하게 구현하기 어려움
• single leader → scale down X
• 변경사항을 local cache로 저장해 → 서로 다른 Operator가 동작하며 선언적인 구조로 적용하는 것보다 구현하기 어려움

Declarative

• 장점 : 직관적인 이해
• 상태 보장
• 단점 : 상태 추적
• Operator가 선언적으로 구현하기가 어려운 이유 설명 필요

Pod와 컨테이너 - Kubelet

폴링 구조에서 이벤트 구조로 변경

사진 추가

Cluster API 를 적용하지 않는 이유

• 컨트롤러가 동작할 때 event driven으로 처리하지만 single cache하고 있는 전체적으로 수행하는 작업을 하는데
• 권고사항이 10분마다 cache에 들고있는 전체적으로 싱크를 맞춰주는 작업(Reconcile)을 해야하기 때문에..
• 오픈스택에서는 event driven을 지원하지 않아 권고사항인 10분을 따라야한다..

전체적으로 보여주는 사진 한 장 추가

• Single leader 구조
• openstack provider 성숙도
• 운영 노하우
• Debugging
• ETCD 부하
• Business logic 추가

이러한 단점들을 고려해 Cluster API 를 사용하지 않고 직접 하나씩 개발

Q&N