우선 KEDA가 뭔지 모르는 사람들은 전에 내가 쓴 글이 있으니 참고가 필요하면 갔다오자!!
Azure Kubernetes Service에서 KEDA를 사용하는 방법은 2가지로 나눠진다.
가장 빠른 방법은 아래와 같이 azure cli를 통해 진행하는 방법이 있다.
# aks extension 설치를 위해 아래의 명령어 실행
az extension add --name aks-preview
az extension update --name aks-preview
# aks feature flag 등록
az feature register --namespace "Microsoft.ContainerService" --name "AKS-KedaPreview"
az feature show --namespace "Microsoft.ContainerService" --name "AKS-KedaPreview"
az provider register --namespace Microsoft.ContainerService
# 새로 생성하는 cluster에 add on 설치
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--enable-keda
# 기존에 있는 cluster에 add on 설치
az aks update \
--resource-group myResourceGroup \
--name myAKSCluster \
--enable-keda
이 aks 자체 add on을 사용하는 부분에는 이 글을 쓰는 9/16/23 기준에서는 아래와 같은 장점 & 단점이 있다.
장점
단점
이 부분은 우리가 여지껏 다른 툴들을 Kubernetes에서 사용한 것과 같이 그냥 설치해서 쓰면 된다. 가장 흔한 방법은 helm을 이용한 배포이다.
helm 을 이용한 배포는 손 쉬우니 배포 과정 보다는 팁을 적어볼까 한다.
Azure에 있는 metric을 읽을 때, 선택에 기로에 놓인다.
A. pod identity
B. workload identity
조금 더 최신이기도 하며 사용방법도 쉽다.
federated credentials 만들 때, 나와 같이 헤매지 말고 아래와 같이 만들자!
09/16/23 기준으로 aks의 default 버전은 1.26.6 이다.
눈치가 빠른 사람들은 왜 갑자기 왜 kubernetes 의 version을 이야기 하는지 눈치 챌 것이다.
1.24 부터 토큰 및 인증서 생성이 수동이 되었다.
keda-operator는 hpa를 생성하는데 당연히 service account를 사용해 생성한다.
1.24 이후 부터는 토큰을 수동 생성해주어야 하기 때문에, 아래의 secret을 같이 생성하여 keda-operator가 hpa를 생성할 수 있도록 만들어주자!
{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: Secret
metadata:
name: {{ .Values.serviceAccount.name }}-secret
namespace: {{ .Release.Namespace }}
annotations:
kubernetes.io/service-account.name: {{ .Values.serviceAccount.name }}
type: kubernetes.io/service-account-token
{{- end -}}
장점
단점
위의 2가지 방법중, 2번째 방법을 사용하고 있다. 최신의 keda 사용과, workload identity의 사용은 굉장히 편하다. 단지 helm을 관리하고 keda 버전을 올려줘야한다는 불편함이 있지만, 어차피 내가 관리하고 있는 aks 위의 open source 툴들은 무더기로 있다.
단지 바라는 점이 있다면, kafka scaler 제발 0개로 scale in 됬을 때 이슈가 있는데 고쳐지길 바란다. (이슈는 제기 됬으나 현재 work arround만 적용 된것으로 보여진다.)