KubeAdmiral: next-generation multi-cluster orchestration engine based on Kubernetes
Member post originally published on the Bytedance blog by Gary Liu Project link: https://github.com/kubewharf/kubeadmiral Since its release in 2014, Kubernetes has become the de facto standard for…
www.cncf.io
KubeAdmiral 이란 Kubernetes Federation v2 로부터 진화한 Kubernetes Multi-cluster 관리 시스템이다. Kubernetes Federation v2는 사용자들이 Kubernetes 자원을 Multi-Cluster를 가로질러 운영할 수 있도록 도와준다. 이때 Federated Type된 자원을 사용하며, FederatedDeployment, FederatedReplicaSet, FederatedSecret 같은것들이 이에 해당한다. KubeAdmiral는 더 나아가 Kubernetes Native API와 호환성을 제공하며 더 강력한 자원 관리 능력을 제공한다. KubeAdmiral은 다음의 기능들도 할 수 있다.
- 풍부한 스케쥴링 플러그인을 통한 스케쥴링 프레임워크 기능
- Policies를 Override 하는 기능
- 후속 스케쥴링 의존성에 대한 자동 전파
- Member Cluster의 리소스들에 대한 상태 정보 수집
- 스케일링, 안정성, 사용자 경험 개선
KubeAdmiral 핵심 구성요소
Scheduler :
Kube-scheduler의 디자인에서 영감을 얻은 KubeAdmiral은 유연한 Scheduling 프레임워크를 제공합니다. Filter, Score, Select, Replica의 네 가지 개별 단계로 나누어 Scheduling 프로세스를 단순화합니다. 각 단계는 개별 플러그인에 의해 처리되어 모듈성을 촉진하는 논리적 분리를 만듭니다. 예를 들어 위에 제공된 PropagationPolicy 예제에서 대부분의 동작은 내장된 Scheduling 플러그인을 통해 구현됩니다. 이 접근 방식의 장점은 나머지 플러그인에 영향을 주지 않고 플러그인을 쉽게 추가하거나 제거할 수 있다는 것입니다. 이는 Scheduler 논리를 크게 단순화하고 전반적인 복잡성을 줄입니다. KubeAdmiral에 내장된 플러그인은 일반적인 사용 사례에 맞는 다양한 기능을 제공하지만 사용자는 특정 시나리오에 맞게 커스터마이징된 Scheduling 플러그인을 만들어 기능을 향상시킬 수 있는 유연성을 가지고 있습니다. 이를 통해 사용자는 내부 또는 기존 시스템과 원활하게 통합할 수 있습니다. KubeAdmiral 스케줄러는 HTTP 프로토콜을 통해 외부 플러그인과 상호작용하므로 사용자는 KubeAdmiral 제어 플레인을 수정하지 않고도 최소한의 노력으로 Scheduling 로직을 확장할 수 있습니다. 플러그인은 원하는 배정(Placement)에 대한 정보만 출력만하면 되며 KubeAdmiral은 해당 결과를 바인딩하고 적용합니다.
Scheduler는 Member-Cluster에서 원하는 워크로드 배정를 계산하는 KubeAdmiral의 핵심 구성 요소입니다. Replicas 기반 워크로드를 Scheduling할 때 각 클러스터에 적합한 Replicas도 계산합니다. KubeAdmiral의 "Brain" 역할을 하는 KubeAdmiral의 결정은 내구성, 리소스 효율성 및 안정성과 같은 중요한 측면에 직접적인 영향을 미칩니다.
KubeFed는 Replicas 기반 워크로드를 위한 RSP Scheduler를 제공하지만 사용자 정의 가능성과 확장성이 매우 제한적이며 동작을 수정하려면 코드 수정이 필요합니다. 또한 다양한 Scheduling 의미 체계가 필요한 Stateful한 서비스, Job 형식의 리소스 등에 대한 지원이 부족합니다.
KubeAdmiral은 보다 포괄적인 Scheduling 의미 체계를 도입합니다. labels, taints 등을 통해 클러스터를 선택하고 리소스 활용도, 선호도 등에 따라 클러스터에 점수를 매기는 보다 유연하고 세분화된 메커니즘을 지원합니다. Replicas 기반 워크로드 외에도 상태 저장 워크로드 및 작업과 유사한 리소스 Scheduling도 지원합니다. 또한 자동적인 의존성 Scheduling(ConfigMap과 같은 의존성은 해당 Member-Cluster에 대한 배포를 자동으로 따를 수 있음)과 같은 편리한 기능을 제공합니다. Scheduler 동작은 아래와 같이 PropagationPolicy 개체를 사용하여 구성할 수 있습니다.
apiVersion: core.kubeadmiral.io/v1alpha1
kind: PropagationPolicy
metadata:
name: mypolicy
namespace: default
spec:
# Many different ways to select clusters.
placement:
# Manually specify desired clusters and replica weights, if required.
- cluster: cluster-01
preferences:
weight: 4
- cluster: cluster-02
preferences:
weight: 3
- cluster: cluster-03
preferences:
weight: 4
# Filter clusters based on label selectors.
clusterSelector:
IPv6: "true"
# Filter clusters based on affinity.
clusterAffinity:
- matchExpressions:
- key: region
operator: In
values:
- us-east
# Filter clusters based on taints and tolerations.
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
# Mode of scheduling - divide or duplicate.
schedulingMode: Divide
reschedulePolicy:
# Only schedule on creation and do not reschedule afterwards.
# Suitable for stateful workloads.
disableRescheduling: false
# When rescheduling should be triggered.
# More triggers: reschedule more frequently - favor agility.
# Fewer triggers: reschedule less frequently - favor stability.
rescheduleWhen:
policyContentChanged: true
clusterLabelsChanged: false
# Whether to rebalance replicas on reschedule.
# Enabling rebalance results in optimal placement, but at the potential cost
# of disrupting existing replicas.
replicaRescheduling:
avoidDisruption: true
# Limit propagation to a single cluster.
# Suitable for job-like workloads.
maxClusters: 1
apiVersion: core.kubeadmiral.io/v1alpha1
kind: OverridePolicy
metadata:
name: example
namespace: default
spec:
# Flexible ways to select target clusters.
overrideRules:
- targetClusters:
# Select clusters by name.
clusters:
- on-prem-1
- edge-1
# Select clusters by label.
clusterSelector:
region: us-east
az: az1
# Select clusters by affinity.
clusterAffinity:
- matchExpressions:
- key: region
operator: In
values:
- us-east
# Change the container image in the target clusters using jsonpatch.
overriders:
jsonpatch:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:test"
※ Override Policy : 사용자가 특정 클러스터에서 사용할 이미지 prefix나 StorageClass 등을 지정할 수 있도록 해준다. 이를 통해 사용자는 멤버 클러스터에 따라 다른 구성을 사용할 수 있다.
※ Propagation Policy : 사용자는 워크로드를 생성할 때마다 스케쥴링 제약 조건을 설정하지 않아도 되고, 정책:워크로드의 1:N 매핑을 지원하여 정책을 여러 워크로드에 연결할 수 있다.
Auto Migration Controller :
복제본 Scheduling의 경우, KubeAdmiral은 각 Member-Cluster가 받아야 하는 Replica 수를 계산하고 Member-Cluster에 리소스를 배포하기 전에 "template" field에 "replicas" field를 재정의(Override)합니다. 리소스가 Member-Cluster에 배포된 후 각 Member의 kube-scheduler는 해당 Pod를 사용 가능한 노드에 할당합니다. 따라서 전체 Scheduling 체인이 완료됩니다.
때때로 kube-scheduler가 노드 중단, 리소스 부족, 충족되지 않은 노드 선호도 요구 사항 등의 이유로 인해 Pod에 적합한 노드를 찾지 못하는 경우가 있습니다. 주소를 지정하지 않고 두면 Scheduling할 수 없는 Pod는 Pending 상태로 유지됩니다. KubeAdmiral은 Scheduling할 수 없는 Pod를 다른 클러스터로 자동으로 마이그레이션하여 이 문제를 해결하여 전반적인 리소스 활용도를 향상시킵니다.
예를 들어, 6개의 Replicas에 대해 동일한 가중치 분포를 갖는 3개의 클러스터 A, B, C를 생각해 보세요. KubeAdmiral의 초기 예약 후 각 클러스터는 두 개의 복제본을 받습니다. 잠시 후 클러스터 C의 두 복제본이 kube-scheduler에 의해 Scheduling되지 않으면 KubeAdmiral은 이를 자동으로 클러스터 A와 B로 이관하여 모든 클러스터에서 원하는 6개의 Replicas의 가용성을 보장합니다.
'PaaS > Kubernetes' 카테고리의 다른 글
| 특정 NameSpace에서 특정 상태의 Pod를 지우고 싶을때 (0) | 2024.01.04 |
|---|---|
| Kubernetes 인증서 만료시 갱신방안 (0) | 2024.01.04 |
| 솔루션 별 적합한 Kubernetes 배포 리소스는 어떤것이 있을까? (0) | 2023.11.23 |
| Argo Rollout으로 배포한 Replica도 HPA를 탈까? (0) | 2023.11.21 |
| Failed to scrape node .. because it doesn't contain any IP SANs 오류 해결 (0) | 2023.11.20 |