쿠버네티스를 구성할때 쿠버네티스 클러스터 규모를 어떻게 구축할지에 대한 내용은 중요하게 생각해보아야 할 내용입니다.
초기 구축할 클러스터의 규모는 클러스터에 실행될 어플리케이션의 스펙과 관련이 높습니다.
어플리케이션의 성능을 분산처리를 통해 증가할 수 있다면, 작은 스펙의 다수의 replication으로 구성할 수 있습니다.
위와 같이 분리된 replication 구성이 어렵다면, 어플리케이션의 자체 스펙으로 구성하여야 합니다.
예를 들어 클러스터의 총 용량이 400 CPU, 800GB memory라고 가정하였을때,
작은 노드를 많이 가져간다면 2 core 4GB memory로 구성하여 총 200개의 노드를 생성할 수 있게 됩니다.
큰 노드를 적게 가져간다면 8 core 16GB memory로 구성하여 총 50개의 노드를 생성할 수 있게 됩니다.
큰 노드를 적게 가져갈 경우의 장점 (온프레미스 환경에서 구축했을 때의 case)
1. 실제로 관리할 수 있는 노드의 갯수가 적어지기 때문에 관리하기가 편리하다.
2. 장비에 대한 업데이트/트러블슈팅을 하게 될 확률이 낮다. (퍼블릭 클라우드를 사용하게 될 경우에는 문제가 발생할 경우 새로운 머신을 생성하면 되기 때문에 위의 내용과는 크게 관련이 없을 수 있음)
3. 평균적으로 용량이 큰 1개의 노드를 생성하는것이 용량이 작은 10개의 노드를 생성하는것보다 비용적인 면에서 저렴하다. (퍼블릭 클라우드의 경우 CSP 사마다 차이가 있을 수 있음)
- 큰 어플리케이션을 운영할 때 유용하다. (큰 리소스를 필요로 하는 어플리케이션보다 작은 노드만 있다면 이를 실행할 수 없음)
큰 노드를 적게 가져갈 경우의 단점
1. 하나의 노드에 많은 pods들이 생성된다. (노드가 큰 스팩을 가지고 있기 때문에 여러개의 pods 들이 실행될 수 있음)
2. 위와 같은 현상이 발생하게 될 경우 kubelet, container, runtime등에 부하가 발생할 수 있다.
3. Replication 효율이 떨어진다. ( Replica 갯수가 노드 갯수보다 크면 HA 의미가 없음)
4. 장애 발생 시, 장애 규모가 크고 다른 노드에 큰 부하가 발생할 수 있다.
5. 노드 확장 시 불필요한 지출이 발생한다. (한개의 노드만 확장해도 큰 리소스가 추가되고 그만큼 큰 비용이 지출될 수 있음)
6. 쿠버네티스는 노드당 최대 110개의 pods가 생성되는것을 권장하고 있다.
-> 관련 docs 문서 링크 : https://kubernetes.io/docs/setup/best-practices/cluster-large/
Considerations for large clusters
A cluster is a set of nodes (physical or virtual machines) running Kubernetes agents, managed by the control plane. Kubernetes v1.30 supports clusters with up to 5,000 nodes. More specifically, Kubernetes is designed to accommodate configurations that meet
kubernetes.io
※ public cloud에서 쿠버네티스를 구성하는 경우 노드 당 pods의 최대 갯수
EKS : 4~737 (인스턴스 타입별로)
GKE : 110
AKS : 250
작은 노드를 많이 가져갈 경우의 장점
1. 노드 장애 시 클러스터 전체에서 피해를 입는 규모가 작다. (따라서 비교적 빠르고 안전하게 복구가 가능함)
2. 더 많은 노드에 replication이 되어 위험이 효과적으로 분산되기 때문에 HA 구성 시 유리하다.
작은 노드를 많이 가져갈 경우의 단점
1. 관리하는 노드가 많기 때문에 이 노드들을 관리하는 마스터 노드의 부하가 증가할 가능성이 있다.
2. 공식문서에는 5000노드 이하의 노드를 생성하기를 권장하고 있다.
3. 노드 당 기본적으로 사용하는 리소스( OS, kubelet, 추가 데몬들..)들이 존재하는데 노드가 낮은 스팩으로 구성되어 있다면, 기본적으로 돌아가는 리소스 외에 실제 사용 가능한 리소스의 비율이 낮아지게 된다.
4. 큰 리소스를 사용하는 어플리케이션에는 적합하지 않다. (리소스의 낭비가 발생할 수 있음)
| 항목 | 고스펙 노드 | 저스펙 노드 |
| 관리 효율성 | 높음 | 낮음 |
| 어플리케이션 당 가능 리소스 | 높음 | 낮음 |
| 노드 부하 | 많음 | 적음 |
| 마스터 노드 부하 | 적음 | 많음 |
| Replication 효율 | 낮음 | 높음 |
| 노드 장애 발생시 영향도 | 높음 | 낮음 |
| 리소스 효율 | 높음 | 낮음 |
Instance Calculator 라는 웹사이트가 있는데 해당 사이트를 방문해보면 인스턴스 별로 어떤 어플리케이션을 돌리느냐에 따라서 최대로 돌릴 수 있는 pods의 갯수를 계산할 수 있고 그 pods의 갯수와 실제 인스턴스의 사용 비용 비율을 조합하여 pods의 갯수 당 지출하는 비용을 산정해준다.
https://learnk8s.io/kubernetes-instance-calculator
Kubernetes instance calculator
Explore the best instance types for your Kubernetes cluster interactively.
learnk8s.io
'Kubernetes' 카테고리의 다른 글
| [Kubernetes] 운영 환경 구성시 고려사항 (0) | 2024.06.18 |
|---|
