일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- nginx ingress
- Argo
- blue/green
- keda
- Litmus
- seldon core
- knative
- Continuous Deployment
- opensearch
- Kopf
- xdp
- tekton
- eBPF
- 오퍼레이터
- kubernetes operator
- Pulumi
- CANARY
- CI/CD
- Kubernetes 인증
- serving
- gitops
- opentelemetry
- 카오스 엔지니어링
- Model Serving
- Kubernetes
- MLflow
- mlops
- Kubeflow
- operator
- argocd
- Today
- Total
Kubernetes 이야기
Kubernetes Cluster 설계 본문
소수의 대규모 클러스터(각 클러스터에 많은 워크로드 포함) 또는 많은 클러스터(각 클러스터에 적은 워크로드 포함)에서 주어진 워크로드 세트를 실행할 수 있다.
클러스터 설계에 따른 장단점은 아래와 같다.
즉, 하나의 클러스터로 모든 application을 운영할때는 비용과 관리가 용이하나 회복력이나 보안에는 취약하다.
반대로 작은 여러개의 클러스터로 application을 운영하면 비용 (특히 마스터 3중화를 고려하는 경우 훨씬 많은 비용을 고려해야 한다.) 과 관리는 어려우나 회복력이나 보안에는 효과적으로 운영이 가능하다. 최근에는 멀티 클러스터를 운영가능하게 하는 솔루션들이 있기 때문에 이러한 솔루션으로 Kubernetes cluster를 운영한다면 좀 더 효과적인 운영이 가능할 것이다.
위의 사항은 아래와 같은 환경이 적용되는 경우를 고려한다.
1. 하나의 대규모 공유 클러스터
Kubernetes에서는 Namespace로 논리적인 업무 구분을 할 수 있다. 이렇게 앱 단위를 Namespace로 구분하여 하나의 클러스터를 운영하는 경우 장단점을 보자.
장점
- 효율적인 리소스 사용
- 비용절감
- 효율적인 관리
단점
- 마스터 장애나 CNI 장애인 경우 전체 업무가 중단될 수 있다.
- Container가 운영체제 및 네트워크를 공유하기 때문에 엄격한 보안 격리에 취약하다. Kubernetes에서는 PodSecurityPolicy나 NetworkPolicies 등 이러한 보안 격리를 위해 다양한 도구가 있기 때문에 잘 사용하면 어느정도 예방할 수 있다.
- 적절한 Request, Limit없이 앱을 운영시 특정 앱으로 인해 다른 앱들의 성능저하가 발생될 수 있다.
2. 환경별 클러스터
하나의 대규모 클러스터와 아주 작은 업무 단위 클러스터를 생성하는 것은 장단점이 뚜렷하다. 환경별 클러스터는 이 장단점을 효과적으로 운영할 수 있는 방법이라고 생각되고, 많은 곳에서 운영되는 방식이기도 하다.
장점
- 운영환경의 격리
- 클러스터 환경에 맞는 커스터마이징 가능 ( 예를 들어 개발기에는 디버깅 도구 설치, 운영기에는 엄격한 보안 도구 설치 등 )
단점
- 클러스터간 동일 앱 배포 문제 : 효율적인 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/
'Kubernetes > 일반' 카테고리의 다른 글
올바른 Dockerfile 작성하기 (0) | 2022.04.19 |
---|---|
Nginx ingress - External OAUTH Authentication ( Google ) (0) | 2022.04.17 |
Bare metal VS VM Kubernetes (0) | 2022.04.09 |
Vertical Pod Autoscaler (VPA) (0) | 2022.04.09 |
Service Account 권한 설정 및 kube config (0) | 2022.04.04 |