[Kubernetes On-premises] why and why not

0. Intro

이 전 글에서 Kubeflow 에 대하여 열심히 적어봤다. 현재 진행되는 프로젝트 중 ML 툴들을 관리하는 파트에 Kubeflow 를 적용하고 싶었다. 그러나 Kubeflow 의 Cloud Native 라는 장점이 최대 난관이 되었다. 현 프로젝트는 보안 문제 때문에 클라우드를 전혀 사용하고 있지 않고 (클라이언트의 중요 요구사항) 그래서 로컬에서 인프라부터 모든걸 관리해야 한다는 뜻 이다. 지금은 DockerCompose 를 통하여 인프라를 관리하고 있지만 Kubernetes 같은 경우, vagrant, virtual machine ... 복잡하다. 그래서 이 문제를 해결할 수 있는 방법이 없을지 리서치 하면서 글을 적어보려 한다.

 

이전 글 보러가기...

[MLOpsKR 커뮤니티 발표 2021] Kubeflow + KRSH vs Airflow

 

1. Kubernetes

Is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation

컨테이너 작업을 자동화 하는 오픈소스 플랫폼. 신속한 확장을 요하는 클라우드 네이티브 애플리케이션을 호스팅하는데 이상적인 플랫폼

1-0. Background

container evolution from kubernetes.io/docs/concepts/overview/what-is-kubernetes/

• Traditional deployment era
  • 배포시, 여러 다른 환경이 필요할 경우 실제 하드웨어를 추가해야만 가능했다. 이것을 극복하기 위해 나온것이 가상머신이다.
• Virtualized deployment era
  • 여러 환경을 하나의 하드웨어 위에서 구동할 수 있게 되었다. 그러나 각 가상머신은 하나의 머신과 구조가 같기 때문에 OS 부터 가동해야 하는 등, 여전히 높은 사양의 하드웨어가 필요했다.
• Container deployment era
  • Virtual Machine 과 비슷하지만 다르다. (Virtual Environment 라고 하는 것 같기도...) 하나의 OS 위에 여러 다른 환경을 올린다. 가상머신보다 훨씬 가벼우면서 분리된 환경을 제공한다. ( its own filesystem, share of CPU, memory, process space ... )

1-1. what is it ?

Container deployment 는 굉장히 좋다. 바로 위에서 설명했듯, 가상머신과 비슷하게 작동하면서 훨씬 가볍다. 그러나, Production level 에서는 주의를 기울일 필요가 있다. 왜냐하면 container 가 실수로라도 down 되는 순간, 그 안에 실행중이던 Product 또한 종료되기 때문이다. 이것을 방지하고 관리를 쉽게 하기 위해 Kubernetes 가 개발되었다. (개발한 사람들의 목적이 그러했다는 뜻)

 

Kubernetes 로 할 수 있는 것들...

• Service discovery and load balancing
  • 컨테이너를 DNS name 혹은 IP address 로 찾고 만약 트래픽이 너무 많으면 로드밸런싱
• Storage orchestration
  • 자원관리
• Automated rollout and rollbacks
  • 백업같은 기능, 예를들어, 새로운 컨테이너를 만들고 옛 컨테이너를 지우고 그 옛 컨테이너의 리소스들을 전부 새 컨테이너로 복사
• Self-healing
  • Kubernetes restarts containers that fail, replaces containers, kills containers that don't repond to your user-defined heath-check.
• Secret and configuration management
  • deploy and update sensitive information/config without rebuilding container images and without exposing secrets

 1-2. what is cloud-native computing ?

Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model

클라우드에서 빌드되고 클라우드의 이점을 최대로 활용할 수 있도록 애플리케이션을 구축하고 실행하는 방식

2. Kubernetes on-premises

Kubernetes 가 cloud-native technology 라고는 하지만 그것이 결코 on-premises 가 불가능 하단 것은 아니다. 사실 cloud-like 환경만 만들어 준다면 얼마든지 가능하다. 실제 on-premises 로 인프라를 구축하여 사용하는 경우가 있었다. 그래서 정리해봤는데... 예상과 크게 다르지는 않았다.

2-1. why run kubernetes on-premises

• Compliance & Data Privacy
  • 회사 규정 및 보안문제 때문에. 회사 자체에서 public cloud를 사용하지 못하는 경우. => (현재. 나는 이런 경우다)
• Business Policy Reasons
  • 회사 규정 및 보안문제 - 위의 경우와 유사함
• Being Cloud Agnostic to Avoid Lock-in
  • 여러 클라우드를 통해서 application 을 배포하려고 하는 경우
• Cost
  • Public cloud 의 비용 부담 때문에 => (현재. AI training 을 돌려야 하는 프로젝트의 경우도 해당된다.)

2-2. challenges

• Etcd
• Load balancing
• Availability
• Auto-scaling
• Networking
• Persistent storage
• Upgrades
• Monitoring

내가 Kubeflow 에 대한 기술조사를 마치고 보고했을 때, "인프라 관리" 가 가장 큰 문제점이었다. 물론, 인프라 혹은 Kubernetes 를 담당할 인력이 충분했다면 문제가 되지 않았을 것이다.

2-3. best practices

왜 적으면 적을수록 암담해질까.

• Integrating with Existing Environment
• Staffing team
• Node configuration
• Etcd Configuration
• Repositories
• Storage and Networking
• Container registry
• UI
• Trouble shooting

3. 결론

Kubernetes 는 로컬에서 하지 말자. Kubeflow 또한 마찬가지. 

시간이 많고 내가 이걸 해보고 싶다 하면 하겠으나, 시간도 없고, 인력도 없고, 이것보다 더 중요한 것이 있고... 그렇다.

끝!

4.Reference

https://platform9.com/blog/kubernetes-on-premises-why-and-how/