[웨비나] 팟캐스트 요약 : From Kafka to Kubernetes

다음 링크의 팟캐스트를 정리한 것이다.

---

• tanzu.vmware.com/content/blog/from-kafka...native-in-15-minutes

쿠버네티스의 목적

---

소프트 웨어의 배포 방법론에 대한 개편 - 많은 머신에 가능 한 많은 프로그램 수행할 때 발생하는 다양한 문제의 해결


컨테이너

---

컨테이너 - Packaged Artifact, 동적 요소로 이동/스케줄 가능


쿠버네티스의 역사

---

• 5년 전 구글에 의해 런칭됨
• 활성화된 커뮤니티/다양한 기여사/개인 유저들에 의해 발전
• Google/IBM/RedHat/Amazon/MS/스타트업 등 참여

어떻게 현재의 위상을 갖게 되었는가?

---

• Cloud Native/IoT/BigData/MSA 등 Digital Transformation 전 영역에 영향을 끼침
• 모든 산업 영역이 소프트웨어의 시대에 접어들었음 - ex)Tesla, 소프트웨어로 자동차의 새 시대를 열었음
• 헬스케어/금융 등의 영역에서도 소프트웨어를 통한 변화가 시작됨
• IT는 현재의 프로세스를 어떻게 클라우드를 통해 재탄생시킬 것인지 고민하는 과정에 이름 - 현대적 개발 방법론을 통해 쿠버네티스는 변화하는 산업세계에서 새로운 동력을 줄 수 있는 솔루션/도구

Cloud vs. Cloud Native

---

1. Cloud

• 클라우드는 다른 사람의 인프라 위에 서비스를 운영하는 것
• API를 통한 셀프 서비스 - 다른 사람과의 소통 과정에서의 마찰/에너지 소모 감소
• Infrastructure on Demand - 신기술을 계속해서 접목할 공간 확보

2. Cloud Native

• 클라우드의 이점을 최대로 살릴 수 있는 기술/아키텍처/도구는 무엇인지 고민하는 관점
• 생각/실행/운영하는 방법
• 클라우드의 도입이 가져올 새로운 역량은 어떠한 것인가?
• 현재의 조직/시스템에 어떻게 도입해야 할 것인가?

3. Cloud Native 관점에서 Kubernetes의 역할

• 큰 조직에서 Cloud를 도입했을 때 약간의 효율성 외에 극적 변화가 일어나지 않는 이유 - 예전의 시스템/프로세스를 있는 그대로 클라우드에서 사용하기 때문
• Kubernetes는 Cloud와 이전 프로세스를 분리
• Be Cloud: Cloud 위에서 시스템 운영
• Be Cloud Native: On-Premise에서 운영하더라도 Cloud Native 유지, 실행하는 위치와 관련 없는 cloud type 프로세스

Kubernetes는 어떤 사용자와 관련이 있는가?

---

1. 누가 클러스터를 실행하고 운영하는가?

• 클러스터와 클라우드 인프라 운영자
• 직접 클러스터 구성 또는 관리형 서비스 활용
• 더욱 작고 동적이며 특정적인 클러스터 운용

2. 사용자가 어디까지 관여할 것인가?
<고급 사용자>

• 직접 kubernetes의 모든 설정 활용

<일반 사용자>

• 구성된 도구 - kubernetes API 패턴을 활용
• knative와 같은 플랫폼 구성 킷 - kubernetes를 도구로 활용하여 다른 서비스들을 kubernetes 위에 구성 ex)Machine Learning
• PaaS의 제한된 영역 안에서 kubernetes 활용

Opensource Kubernetes vs. 벤더사가 제공하는 Kubernetes

---

1. 오픈소스

• 오픈소스 소프트웨어가 의미있게 사용되기 위해서 모든 아키텍처가 구성되어 있어야 함
• 다양한 의견/옵션이 존재 - 사용자가 선택해야 함
• 장애/문제 발생 시 서포트 받기 어려움

2. Heptio와 같은 벤더

• 의견/컨설팅 제공
• 커스터마이징
• 전체 시스템을 운영해주기도 함
• 여전히 벤더사가 새로운 가치를 창출 할 영역이 존재

3. 어떤 것을 선택 할 것인가?

• kubernetes는 이전의 프로세스/시스템과 양립 불가능하지 않음 - 기존 시스템과 타협 가능
• 각 사의 상황에 따라 알맞는 선택 필요

Kubernetes는 멀티 클라우드 아키텍처를 가능하게 하는가?

---

• Kubernetes의 목적은 사람들이 소프트웨어를 배포하는 방법론을 개편하는 것임 - 베어메탈과 클라우드 모든 영역에서 서비스가 구동되게 하는 것
• Google의 내부 프로젝트로 수행했을 때와 오픈소스로 공개된 현재, 거의 대부분의 영역에서 변화됨
• 소프트웨어를 런칭하고 관리/운영하는 방법론을 재정의
• 모든 플랫폼에 대해 완벽한 호환성을 제공하는 것은 아니지만, 어느 정도의 호환성 보장 가능

쿠버네티스 등장 배경

---

1. 기존 VM을 통한 아키텍처 구성방식 vs 쿠버네티스

• MSA가 단순 개념에서부터 발전하면서 서비스의 단위가 점점 작아졌다. 이에 1-2 코어로 운영 가능한 서비스가 등장함에 따라 각각마다 Guest OS상에서 실행되는 VM으로 운영하기에는 낭비가 발생하여, 이에 실제 물리적 서버 상에서 실행하고 자원을 필요한 만큼만 할당할 수 있는 컨테이너를 통해 효율적으로 운영함/li]
  
• 컨테이너 방식이 확산될 거라는 전망에는 대부분 이견이 없는 상황이나 컨테이너가 하이퍼바이저를 당장에 대체하기에는 어려울 것이라는 시각이 지배적으로, 컨테이너와 서버 가상화 기술이 서로의 약점을 보완하면서 공존할 것으로 전망하고 있으며, 현재 하이퍼바이저 진영에서 컨테이너 기술을 융합한 가상화 기법들을 시도하고 있어 하이브리드 형태의 새로운 기술이 등장할 수도 있을 것으로 전망

2. 솔루션의 발전

• 단순 애플리케이션 코드 업데이트 방식이 아닌 VM/Container를 단위 배포하는 디자인 패턴(피닉스 서버 패턴) 및 솔루션(Spinnaker)
• 지능형 라우팅 및 분산 트랜잭션 로그 추적하는 솔루션(Envoy)
• 위의 솔루션들을 중앙 통제하는 서비스 메시 솔루션(Istio.io)

3. 데브옵스 모델의 발전

• 전통적인 개발 방법론에서는 분석, 설계, 개발, 검증, 출시 각 단계별 철저한 산출물 관리를 통해 위험 요소를 최소화 하며 최종 결과물의 완성도를 높이려고 했다. 대형 공공 과제들이 이런 개발방법론에 의해 추진되었으며, 특히 고정된 예산 기반으로 움직이는 외주 소프트웨어 개발의 경우 주로 이런 전통적인 개발 프로세스를 기반으로 진행된다.
• 한편, 일반 사용자를 대상으로 하는 서비스는 개발 진행 중 수시로 사용자의 피드백을 반영하여 빠르게 진화하는 방식의 프로세스가 필요하다. 개발과 IT서비스 운영이 별도의 조직에 의해 이루어짐으로써 일관성 있고 안정적인 시스템 운영을 추구할 수 있다는 강점이 있는 반면, 수시로 변경사항이 적용되어야 하는 애자일 방법론에서의 ‘속도’를 따라오기는 힘들 수 있다.
• 이러한 연유로 개발팀이 개발 및 CI/CD에 대한 부분을 쉽게 운영할 수 있도록 플랫폼 및 자동화 관리에 대한 목표가 명확해짐에 따라 데브옵스, 즉, 개발과 운영 사이클을 동일한 조직/사람이 수행하는 것이 최근 서비스 개발의 추세이다.

쿠버네티스(컨테이너 오케스트레이션) 특징

---

1. 쿠버네티스 장점

• 벤더나 플랫폼에 종속되지 않기 떄문에 대부분의 퍼블릭 클라우드 사용이 가능하고 오픈 스택과 같은 프라이빗 클라우드 구축 환경이나 베어메탈(가상화 환경을 사용하지 않는 일반 서버 하드웨어)에도 배포가 가능한 이유로 하이브리드 클라우드 솔루션으로 각광받음
• 컨테이너 스케줄링/클러스터링/서비스 디스커버리/로깅 및 모니터링 지원
• 서비스 중단 없이 업데이트 가능
• 자가 회복(self-healing)을 통해 특정 컨테이너가 다운될 경우 즉시 그 컨테이너를 복제 생성하여 서비스를 유지

2. 쿠버네티스 단점

• 복잡하고 개념을 이해하기 어려운 점, 그리고 장기적으로는 개발자의 업무를 더 쉽게 해주지만 결과적으로 복잡성은 줄어들지 않는다.
• YAML 설정 파일 및 클러스터 구성 또한 쉽지 않음. (직접 구성하는 대신 CSP에서 제공하는 관리형 서비스를 사용한다면 쉽게 구성이 가능하다. Cloud Code 같은 플러그인을 이용하거나 helm 같은 패키지 매니저를 사용하면 비교적 편리하게 설정파일을 관리할 수도 있다.)
• 윈도우 서버에서는 쿠버네티스 실행이 가능하지만, 반대로 쿠버네티스에서 윈도우 컨테이너 사용은 원활하지 않다. (하지만 마이크로소프트가 CNCF의 최상위 등급 멤버로, 머지 않아 해결될 부분으로 예측된다.)
• 컨테이너는 호스트 OS의 통제된 영역을 사용한다 하더라도 많은 컨테이너들이 동일한 운영체제 커널을 공유하여 가상머신만큼 철저하게 분리되어 있지 않기 때문에 보안이나 안정성 측면에서 문제가 발생할 수 있음
• 호스트 OS를 공유하는 메커니즘에 대한 안정장치 또한 동일 호스트 위에서 이루어지기 때문에 잘못된 스케줄링이나 예기치 못한 컨테이너간의 충돌 등이 발생할 가능성이 존재한다.
• 컨테이너는 기본적으로 비 저장성을 갖는 이미지로부터 실행되는데, 이는 시스템을 간결하게 하는 장점으로 작용했지만 작업의 영속성 측면에서는 단점을 불러온다. 이를 위해서는 컨테이너와 연결된 별도의 데이터베이스나 독립적인 스토리지가 있어야 하므로, 자체 파일 시스템을 가지고 있어 기본적으로 세션에 대한 영속성을 가지고 있는 가상머신보다는 불리하다.