저자: Ma Wei, Qingyun Technology의 컨테이너 컨설턴트, 클라우드 네이티브 애호가, 현재 클라우드 네이티브 기술에 집중하고 있으며 클라우드 네이티브 분야의 기술 스택에는 Kubernetes, KubeSphere, KubeKey 등이 포함됩니다.
2019년에는 가상 네트워크와 가상 스토리지를 도입하면서 많은 기업에 가상화를 배포하고 있습니다.
2023년에 이러한 기업은 이미 클라우드 네이티브가 될 것입니다. 트래픽이 많은 웹 애플리케이션, 실시간 데이터 분석, 대규모 데이터 처리, 모바일 애플리케이션 및 기타 서비스의 경우 컨테이너는 가볍고 응답이 빠르며 포팅이 쉽고 탄력성이 강하기 때문에 가상 머신보다 더 적합합니다. .
탄력적 확장이 필요한 이유는 무엇입니까?
- 피크 부하 처리: 판촉 활동, 연휴 쇼핑 시즌 또는 비상 사태는 애플리케이션 가용성 및 성능을 보장하기 위해 수요에 따라 리소스를 빠르게 확장합니다.
- 리소스 활용도 향상: 실제 리소스 로드에 따라 리소스 규모를 동적으로 조정하고 인프라 리소스 낭비를 방지하며 TCO를 줄입니다.
- 장애 대응 및 내결함성: 비즈니스 연속성과 가용성을 개선하기 위한 다중 인스턴스 배포 및 신속한 교체.
- 수요 변화를 따르십시오: 프런트 엔드 비즈니스 요구 사항과 압력을 일치시키고, 신속하게 규모를 조정하고, 이벤트 응답 기능을 개선하고, 요구 사항과 기대치를 충족하십시오.
수평형 포드 자동 확장
Kubernetes 자체는 VPA(Vertical Pod Autoscaler) 및 HPA(Horizontal Pod Autoscaler)를 비롯한 탄력적인 확장 메커니즘을 제공합니다. HPA는 CPU 및 메모리 사용률에 따라 레플리카 컨트롤러의 파드 수를 늘리거나 줄이는데, 이는 리소스 스케일링의 기능적 특징이다.
HPA는 Metrics-Server를 사용하여 CPU 및 메모리 데이터를 캡처하여 리소스 사용량 측정 데이터를 제공하고 맞춤형 지표(예: Prometheus)에 따라 확장할 수도 있습니다.
위의 그림에서 볼 수 있듯이 HPA는 Metrics-Server의 지표를 지속적으로 모니터링한 다음 필요한 복사본 수를 계산하여 리소스 복사본을 동적으로 조정하여 설정된 대상 리소스 값의 수평적 확장을 달성합니다.
그러나 특정 제한 사항이 있습니다.
- 외부 메트릭이 지원되지 않습니다. 서로 다른 이벤트 소스, 서로 다른 미들웨어/애플리케이션 등과 같이 애플리케이션 변경 사항과 비즈니스 측면의 종속성은 CPU 및 메모리 확장에만 기반한 것이 아니라 다양합니다.
- 1->0이 될 수 없습니다. 애플리케이션이 항상 로드가 0일 때 워크로드를 실행할 수 없습니까?
그래서 쿠버네티스 기반 KEDA(Event-Driven Autoscaling)가 있습니다 !
WHO
KEDA는 이벤트 중심으로 자동 확장됩니다. 이벤트 드리븐이란? 내 이해는 시스템의 다양한 이벤트에 반응하고 그에 따라 행동하는 것입니다(스케일링). 그렇다면 KEDA는 HPA+다중 트리거입니다. 트리거가 이벤트를 수신하고 트리거되는 한 KEDA는 자동 스케일링을 위해 HPA를 사용할 수 있으며 KEDA는 1-0, 0-1이 될 수 있습니다!
건축학
KEDA 자체에는 여러 구성 요소가 있습니다.
- 에이전트: KEDA는 Kubernetes 워크로드를 활성화 및 중지합니다(keda-operator 주요 기능).
- 메트릭: KEDA는 Kubernetes 메트릭 서버 역할을 하여 Horizontal Pod Autoscaler에 풍부한 이벤트 데이터를 제공하고 소스에서 이벤트를 소비합니다. (keda-operator-metrics-apiserver의 주요 역할).
- 승인 Webhook: 잘못된 구성을 방지하기 위해 리소스 변경 사항을 자동으로 검증합니다.
- 이벤트 소스: 포드 수 변경을 위한 KEDA 외부 이벤트/트리거 소스. 프로메테우스, 카프카 등.
- 스케일러: 이벤트 소스를 모니터링하고 메트릭을 가져오고 이벤트를 기반으로 스케일링을 트리거합니다.
- 지표 어댑터: 스케일러에서 지표를 가져와서 HPA로 보냅니다.
- Controller: Adapter가 제공하는 지표에 따라 동작하고 ScaledObject에 명시된 자원 상태에 맞춰 조정한다. Scaler는 ScaledObject에 설정된 이벤트 소스에 따라 이벤트를 지속적으로 모니터링하고 트리거 이벤트가 발생하면 Metrics Adapter에 메트릭을 전달합니다. Metrics Adapter는 메트릭을 조정하여 Controller 구성 요소에 제공하고 Controller는 ScaledObject에 설정된 스케일링 규칙에 따라 배포를 확장하거나 축소합니다.
일반적으로 KEDA는 ScaledObject를 설정하고 메시지 큐의 메시지, 주제 구독의 메시지, 스토리지 큐의 메시지, 이벤트 게이트웨이의 이벤트 또는 사용자 정의 트리거가 될 수 있는 이벤트 트리거를 정의합니다. 이러한 이벤트를 기반으로 애플리케이션의 복제본 수 또는 핸들러의 리소스 구성이 자동으로 조정되어 실제 부하 상황에 따라 탄력적 확장이 가능합니다.
CRD
- ScaledObjects: 이벤트 소스(예: Rabbit MQ) 및 Kubernetes를 나타냅니다. 배포, StatefulSet 또는 하위 리소스를 정의/확장하는 모든 사용자 지정 리소스 간의 필수 매핑입니다.
- ScaledJobs: 이벤트 소스와 Kubernetes 작업 간의 매핑입니다. 이벤트 트리거에 따라 작업 크기를 조정합니다.
- TriggerAuthentications: 트리거의 인증 매개변수입니다.
- ClusterTriggerAuthentications: 클러스터 차원 인증.
KEDA 배포
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
kubectl create namespace keda
helm install keda kedacore/keda --namespace keda
kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1.yaml
root@node-1:/# kubectl get all -n keda
NAME READY STATUS RESTARTS AGE
pod/keda-metrics-apiserver-7d89dbcb54-v22nl 1/1 Running 0 44s
pod/keda-operator-5bb9b49d7c-kh6wt 0/1 Running 0 44s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/keda-metrics-apiserver ClusterIP 10.233.44.19 <none> 443/TCP,80/TCP 45s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/keda-metrics-apiserver 1/1 1 1 45s
deployment.apps/keda-operator 0/1 1 0 45s
NAME DESIRED CURRENT READY AGE
replicaset.apps/keda-metrics-apiserver-7d89dbcb54 1 1 1 45s
replicaset.apps/keda-operator-5bb9b49d7c 1 1 0 45s
root@node-1:/# kubectl get all -n keda
NAME READY STATUS RESTARTS AGE
pod/keda-metrics-apiserver-7d89dbcb54-v22nl 1/1 Running 0 4m8s
pod/keda-operator-5bb9b49d7c-kh6wt 1/1 Running 0 4m8s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/keda-metrics-apiserver ClusterIP 10.233.44.19 <none> 443/TCP,80/TCP 4m9s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/keda-metrics-apiserver 1/1 1 1 4m9s
deployment.apps/keda-operator 1/1 1 1 4m9s
NAME DESIRED CURRENT READY AGE
replicaset.apps/keda-metrics-apiserver-7d89dbcb54 1 1 1 4m9s
replicaset.apps/keda-operator-5bb9b49d7c
# kubectl get crd | grep keda
clustertriggerauthentications.keda.sh 2023-05-11T09:26:06Z
scaledjobs.keda.sh 2023-05-11T09:26:07Z
scaledobjects.keda.sh 2023-05-11T09:26:07Z
triggerauthentications.keda.sh 2023-05-11T09:26:07Z
KubeSphere의 KEDA 배포
kubectl edit cc -n kubesphere-system (kubesphere 3.4+)
spec:
···
autoscaling:
enabled: true
···
확장된 워크로드 CRD
ScaledObject 리소스 정의, 자세한 매개변수는 https://keda.sh/docs/2.10/concepts/scaling-deployments/를 참조하십시오 .
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: {scaled-object-name}
spec:
scaleTargetRef:
apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1
kind: {kind-of-target-resource} # Optional. Default: Deployment
name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject
envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0]
pollingInterval: 30 # Optional. Default: 30 seconds
cooldownPeriod: 300 # Optional. Default: 300 seconds
idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount
minReplicaCount: 1 # Optional. Default: 0
maxReplicaCount: 100 # Optional. Default: 100
fallback: # Optional. Section to specify fallback options
failureThreshold: 3 # Mandatory if fallback section is included
replicas: 6 # Mandatory if fallback section is included
advanced: # Optional. Section to specify advanced options
restoreToOriginalReplicaCount: true/false # Optional. Default: false
horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options
name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name}
behavior: # Optional. Use to modify HPA's scaling behavior
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 100
periodSeconds: 15
triggers:
# {list of triggers to activate scaling of the target resource}
KEDA Meterics Server에 의해 노출된 메트릭 보기
kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1"
데모
KEDA는 현재 Kafka, Elasticsearch, MySQL, RabbitMQ, Prometheus 등 53종의 스케일러를 지원합니다. 다음은 Prometheus와 Kafka의 예입니다.
프로메테우스 & KEDA
웹 애플리케이션을 배포하고 Prometheus를 사용하여 웹 애플리케이션의 http 요청 표시기를 모니터링합니다.
데모 효과를 찾기 위해 클릭 가능한 대화형 데모 앱이 여기에 배포되며 주소는 다음과 같습니다 . .
성공적인 배포 후 NodePort를 통한 액세스:
KubeSphere 프로젝트를 입력하고 사용자 정의 스케일링을 생성하십시오.
최소 복사 수를 1로, 최대 복사 수를 10으로, 폴링 간격을 5초로, 대기 시간을 1분으로 설정합니다.
KubeSphere는 Cron, Prometheus 및 사용자 지정 트리거를 지원합니다.
트리거는 Prometheus를 설정하고, 설정된 요청은 30초 이내의 증가율의 합이며, 임계값이 3보다 크면 이벤트가 조정을 구동합니다.
리소스 삭제 후 원래 복사본 수를 복원할지 여부 및 조정 정책 설정과 같은 몇 가지 다른 설정을 지정합니다.
이제 Web App에 동시에 액세스합니다.
사용자 정의 모니터링에서 모니터링 지표의 변경 사항을 볼 수 있습니다.
웹 앱의 사본 수가 확장되기 시작합니다.
마지막으로 ScaledObject에 정의된 10개의 복사본으로 확장되었습니다.
액세스가 중지된 후 모니터링 표시기의 값이 점차 감소하는 것을 볼 수 있습니다.
배포가 축소되기 시작합니다.
카프카와 케다
Kafka 이벤트 소스를 사용하여 KEDA에서 시연한 전체 토폴로지는 다음과 같습니다.
Kafka는 데모 코드를 사용합니다: https://github.com/ChamilaLiyanage/kafka-keda-example.git.
부서 Kafka
KubeSphere 애플리케이션 스토어를 열고 DMP 데이터베이스 센터를 봅니다.
설치할 Kafka를 선택합니다.
Kafka를 설치한 후 테스트 Kafka Topic을 만들고 Topic 파티션을 5로 설정하고 복사본을 1로 설정합니다.
Kafka 생산자 서비스를 만듭니다.
주제로 주문 보내기:
소비자 서비스 만들기:
소비자 서비스가 소비되는지 확인하기 위해 새 주문을 보냅니다.
이제 자동 크기 조정을 수행하고, ScaledObject를 만들고, 최소 복사본 수를 0으로, 최대값을 10으로, 폴링 간격을 5초로, Kafka LagThreshold를 10으로 설정할 수 있습니다.
apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
name: kafka-scaledobject
namespace: default
labels:
deploymentName: kafka-consumer-deployment # Required Name of the deployment we want to scale.
spec:
scaleTargetRef:
deploymentName: kafka-consumer-deployment # Required Name of the deployment we want to scale.
pollingInterval: 5
minReplicaCount: 0 #Optional Default 0
maxReplicaCount: 10 #Optional Default 100
triggers:
- type: kafka
metadata:
# Required
BootstrapeServers: radondb-kafka-kafka-external-bootstrap.demo:9092 # Kafka bootstrap server host and port
consumerGroup: order-shipper # Make sure that this consumer group name is the same one as the one that is consuming topics
topic: test
lagThreshold: "10" # Optional. How much the stream is lagging on the current consumer group
사용자 지정 확장을 만듭니다.
이제 약 100,000개의 주문 메시지를 대기열에 제출하고 작동 중인 자동 크기 조정을 살펴보겠습니다. 과도한 메시지로 대기열이 커짐에 따라 더 많은 kafka-consumer 포드가 생성되는 것을 볼 수 있습니다.
NAMESPACE NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
demo keda-hpa-kafka-consumer Deployment/kafka-consumer 5/10 (avg) 1 10 1 2m35s
여기에서 최대 복사본 수는 5이지만 기본 최대 복사본 수는 Kafka 토픽 파티션 수를 초과하지 않기 때문에 10이 아닙니다. 파티션은 위에서 5로 설정되어 있으며 allowIdleConsumers: true를 활성화하여 비활성화할 수 있습니다. 이 기본 동작. 사용자 지정 배율을 다시 편집한 후 최대 복사본이 10으로 변경됩니다.
메시지 소비가 없을 때 사본 변경은 0입니다.
끝
이것으로 이 기사의 끝이며 필요하거나 관심이 있는 친구들은 연습을 시작할 수 있습니다.
이 기사는 블로깅을 위한 다중 게시물 플랫폼 인 OpenWrite 에서 게시합니다 !