K8S 설계 개념(Kubernetes Design Concept)

 

틀린 내용이 있을 수도 있습니다! 

틀린 내용이 있다면 댓글로 달아주시면 감사하겠습니다!

 

 

 

이번 포스팅은 K8S가 어떤 설계 개념을 토대로 디자인 되었는지 알아본다.   

Saad Ali라는 구글 개발자는 다음 규칙을 바탕으로 K8S를 설계했다.

 

1. Kubernetes APIs are declarative rather the imperative 

2. No hidden internal APIs

3. Meet the user where they are: Remote storage 

4. Workload portability 

 

 

1. Kubernetes APIs are declarative rather the imperative 

1) Imperative way 

 

이전에는 시스템에 명령어를 직접 입력해서 시스템을 desired state로 동작시켰다. 

하지만 이러한 방식은 내가 시스템을 계속 모니터링 해야 하고 시스템에 문제가 생긴다면, 

내가 직접 시스템으로 명령어를 전달해야한다는 것을 의미한다. 

이렇게 시스템을 계속 모니터링하고 고치는 방식은 시스템 관리에 있어 비효율적이다. 

 

2) Declarative way 

 

Declarative way를 선택하면 시스템 관리자는 desired state을 정의 후,

시스템은 정해진 상태에 맞춰 동작한다. 

만약 시스템에 문제가 생기면, 시스템은 스스로 desired state에 맞춰 동작하려고 하기 때문에 

automatic recovery의 장점을 지닌다. 

 

 

 

2. The Kuberntes control plane is transparent. There are no hidden internal APIs

K8s control plane은 상태정보를 투명하게 써 놓는 것으로 끝내야 한다.

이는 hidden internal API가 없다는 것을 의미하는데 쉽게 말하면 API 호출이 간단해야한다는 것이다. 

 

예를 들자면, 클러스터 내 모든 워커 노드들은 마스터 노드의 API Server로 API 호출을 통해 desired state를 watch할 수 있다. 

하지만 만약 control plane내에 hidden internal APIs들이 존재한다면 watch를 하는데 더 복잡한 과정을 거쳐야할 것이다.   

 

또한 이러한 방식을 사용함으로써 시스템이 더 단순해지고 k8s를 구성(composable)하고 확장(extensible)하기 쉬워진다. 

Hidden API가 없기 때문에 사용자가 원하는 custom component를 직접 만들고 클러스터 위에서 실행할 수 있는 것이다.  

 

 

 

3. Meet the user where they are: Remote storage 

레거시 애플리케이션을 더 쉽게 수용할 수 있게 한다. 

레거시 애플리케이션들을 클러스터 내에서 돌리기 위해서는 K8S내의 필요한 Info를 가지고 있어야 한다. 

 

Kuberntes API has lots of data that is interesting to workloads

1)  Secrets - KubeAPI에 저장된 민감한 정보들 

2) Configmap - KubeAPI에 저장된 Configuration 정보들

3) DownardAPI - KubeAPI에 있는 po1) Imperative way d 정보들 

 

그런데 어떻게 레거시 애플리케이션의 수정 없이 이러한 info를 가져올까? 

K8S의 Info들을 API 서버에 두면 info를 직접 Read해야 한다.

즉, app을 수정해야하므로 이는 좋지 않다.  

 

그래서 K8S는 API 서버에서 info를 읽지 않고 볼륨을 이용해서 가져온다. 

remote storage를 이용해서 볼륨을 마운트해서 사용하며

remote storage를 이용하면 pod에서 사용된 로그나 다른 Info들을 Persistent하게 만들 수 있다. 

 

 

4. Workload portability 

워크로드의 이식성을 강화한다. 

이식성이 있다는 것은 클라우드 네이티브의 특성에 맞게 어떤 환경에서도 

시스템을 실행할 수 있다는 것이다.

예를 들면, 개인 온프레미스 서버에서도 시스템을 돌릴 수 있고,

벤더사의 시스템에 맞춰 시스템을 돌릴 수도 있다.

 

스토리지 측면에서도 마찬가지.