Kubernetes 이야기

Kubernetes Cluster 설계 본문

Kubernetes/일반

Kubernetes Cluster 설계

kmaster 2022. 4. 10. 10:09
반응형

소수의 대규모 클러스터(각 클러스터에 많은 워크로드 포함) 또는 많은 클러스터(각 클러스터에 적은 워크로드 포함)에서 주어진 워크로드 세트를 실행할 수 있다.

 

클러스터 설계에 따른 장단점은 아래와 같다.

https://learnk8s.io/how-many-clusters

즉, 하나의 클러스터로 모든 application을 운영할때는 비용과 관리가 용이하나 회복력이나 보안에는 취약하다.

반대로 작은 여러개의 클러스터로 application을 운영하면 비용 (특히 마스터 3중화를 고려하는 경우 훨씬 많은 비용을 고려해야 한다.) 과 관리는 어려우나 회복력이나 보안에는 효과적으로 운영이 가능하다. 최근에는 멀티 클러스터를 운영가능하게 하는 솔루션들이 있기 때문에 이러한 솔루션으로 Kubernetes cluster를 운영한다면 좀 더 효과적인 운영이 가능할 것이다.

 

위의 사항은 아래와 같은 환경이 적용되는 경우를 고려한다.

https://learnk8s.io/how-many-clusters

1. 하나의 대규모 공유 클러스터

https://learnk8s.io/how-many-clusters

 

 

Kubernetes에서는 Namespace로 논리적인 업무 구분을 할 수 있다. 이렇게 앱 단위를 Namespace로 구분하여 하나의 클러스터를 운영하는 경우 장단점을 보자.

 

장점

  1. 효율적인 리소스 사용
  2. 비용절감
  3. 효율적인 관리

단점

  1. 마스터 장애나 CNI 장애인 경우 전체 업무가 중단될 수 있다.
  2. Container가 운영체제 및 네트워크를 공유하기 때문에 엄격한 보안 격리에 취약하다. Kubernetes에서는 PodSecurityPolicy나 NetworkPolicies 등 이러한 보안 격리를 위해 다양한 도구가 있기 때문에 잘 사용하면 어느정도 예방할 수 있다.
  3. 적절한 Request, Limit없이 앱을 운영시 특정 앱으로 인해 다른 앱들의 성능저하가 발생될 수 있다.

2. 환경별 클러스터

하나의 대규모 클러스터와 아주 작은 업무 단위 클러스터를 생성하는 것은 장단점이 뚜렷하다. 환경별 클러스터는 이 장단점을 효과적으로 운영할 수 있는 방법이라고 생각되고, 많은 곳에서 운영되는 방식이기도 하다.

 

https://learnk8s.io/how-many-clusters

장점

  1. 운영환경의 격리
  2. 클러스터 환경에 맞는 커스터마이징 가능 ( 예를 들어 개발기에는 디버깅 도구 설치, 운영기에는 엄격한 보안 도구 설치 등 )

단점

  1. 클러스터간 동일 앱 배포 문제 : 효율적인 CI/CD 프로세스가 필요함.

고려사항

  • 클러스터는 컨트롤 플레인에서 관리하는 쿠버네티스 에이전트를 실행하는 노드(물리 또는 가상 머신)의 집합이다. 쿠버네티스 v1.23는 노드 5,000개까지의 클러스터를 지원한다. 보다 정확하게는, 쿠버네티스는 다음 기준을 모두 만족하는 설정을 수용하도록 설계되었다.

    노드 당 파드 110 개 이하
    노드 5,000개 이하
    전체 파드 150,000개 이하
    전체 컨테이너 300,000개 이하
    노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은 클러스터 배포 방법에 따라 다르다.
  • apiserver 성능 등을 고려하면 노드는 500여개 미만이 적당하다.
  • 리소스를 많이 사용하는 애플리케이션이 많다면 큰 규모의 노드가 필요하다.
  • Worker 노드가 많을 수록 더 높은 성능의 마스터 노드가 필요하다.
  • 500개 이상의 Worker노드를 운영할 계획이라면 apiserver 튜닝 등 성능 병목 현상을 위해 노력이 필요하다.
  • DaemonSet 이 많이 운영되는 경우에는 Worker 노드가 증가할 수록 시스템 오버헤드가 증가할 수 있다.
  • 하나의 Node에 Pod 개수가 많아지면 kubelet 및 cAdvisor와 같이 노드에서 실행되는 Kubernetes 에이전트에 오버헤드가 발생한다.
  • 너무 작은 노드로 운영시에는 효과적인 복제수준이 제한될 수 있다. 예를 들어 5개의 복제본으로 구성된 고가용성 애플리케이션이 있지만 2개의 노드만 있는 경우 앱의 유효 복제 정도는 2로 줄어듭니다.

 

참고

https://learnk8s.io/how-many-clusters

https://learnk8s.io/kubernetes-node-sizehttps://learnk8s.io/kubernetes-node-size

https://platform9.com/blog/kubernetes-cluster-sizing-how-large-should-a-kubernetes-cluster-be/

https://kubernetes.io/ko/docs/setup/best-practices/cluster-large/

반응형
Comments