이번 포스팅은 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
첫번째. K8S API는 명령하는 방식이 아니라 서술하는 방식을 사용한다.
-
명령 방식(Imperative way)
이전에는 시스템에 명령어를 직접 입력해서 시스템을 desired state로 동작시켰다.
하지만 이러한 방식은 내가 시스템을 계속 모니터링 해야 하고 시스템에 문제가 생긴다면, 내가 직접 시스템으로 명령어를 전달해야한다는 것을 의미한다.
이렇게 시스템을 계속 모니터링하고 고치는 방식은 시스템 관리에 있어 비효율적이다.
-
서술 방식(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은 상태정보를 투명하게 써 놓는 것으로 끝내야 한다.
이는 kube-API 서버에 hidden internal API가 없다는 것을 의미하는데 쉽게 말하면 API 호출이 간단해야한다는 것이다.
왜 내부는 투명해야하고, API 호출이 간단해야 할까?
클러스터 내 모든 워커 노드의 Kubelet들은 마스터 노드의 API Server로 API 호출을 통해 desired state를 watch할 수 있다. 하지만 만약 control plane내에 hidden internal APIs들이 존재한다면 watch 하는데 복잡한 과정을 거쳐야 하고 이는 시스템의 복잡성을 야기할 것이다.
따라서 no hidden API 방식을 사용함으로써 시스템을 더 단순화 시키고 클러스터를 구성(composable)하고 확장(extensible)하기 쉽게 만들 수 있다.
예를 들자면, Hidden API가 없기 때문에 사용자가 원하는 custom component를 직접 만들고 클러스터 위에서 실행할 수 있는 것이다.
3. Meet the user where they are: Remote storage
리모트 스토리지를 사용함으로써 레거시 애플리케이션을 더 쉽게 수용할 수 있게 하자.
레거시 애플리케이션들을 클러스터 내에서 돌리기 위해서는 K8S내의 필요한 정보를 가지고 있어야 한다.
정보에는 다음과 같은 것들이 있다.
1) Secrets - KubeAPI에 저장된 민감한 정보들
2) Configmap - KubeAPI에 저장된 Configuration 정보들
3) DownardAPI - KubeAPI에 있는 pod 정보들
이러한 Info는 어떻게 가져오는걸까?
필요한 정보들을 API 서버에 둔다면, 레거시 애플리케이션들은 API를 통해 정보를 직접 가져와야 한다.
그리고 이는 레거시 애플리케이션의 수정이 필요하다는 것을 의미한다.
하지만 기존 레거시 애플레케이션을 일일이 수정하는 것은 좋은 방법이 아니다. 그래서 K8S는 API 서버에서 정보를 읽는 방법 대신, 볼륨을 이용한 방법을 사용한다.
리모트 스토리지를 이용해서 볼륨을 마운트하여 필요한 정보에 접근하도록 하는 것이다. 이러한 리모트 스토리지를 이용하여 pod에서 사용된 로그나 다른 정보들을 Persistent하게 사용할 수 있다.
4. Workload portability
워크로드의 이식성을 강화한다.
"이식성(Portability)이 있다"라는 것은 클라우드 네이티브의 특성에 맞게 어떤 환경에서도 시스템을 실행할 수 있다는 것이다.
예를 들면, 개인 온프레미스 서버에서도 시스템을 돌릴 수 있고, 벤더사의 시스템에 맞춰 시스템을 돌릴 수도 있다.
또한 K8S는 스토리지 측면에서도 Portability를 잘 해결하고 있다.
기존에 AWS를 이용하여 인프라를 구축하고, EFS를 사용하여 데이터를 보관하다가 온프레미스 환경으로 넘어오는 상황을 생각해보자. 온프레미스에서는 기존에 사용하던 EFS와 같은 네트워크 파일 시스템을 사용할 수 없게 되면서 이식성에 문제가 생기게 된다. 즉, 스토리지 측면에서 특정성을 두었기 때문이다. 하지만 K8S는 PV와 PVC를 이용하여 스토리지 측면의 이식성을 해결한다.
