Kubernetes, Azure Kubernetes Service 도입하기 - 4

눕눕·2023년 9월 16일
1

Kubernetes 도입하기

목록 보기
5/8

AKS에서 KEDA를 사용할 수 있는 방법은?

우선 KEDA가 뭔지 모르는 사람들은 전에 내가 쓴 글이 있으니 참고가 필요하면 갔다오자!!

https://velog.io/@pwcasdf/Azure-Kubernetes-Service-KEDA-service-bus-%EA%B8%B0%EB%B0%98-hpa-%EA%B5%AC%EC%84%B1

Azure Kubernetes Service에서 KEDA를 사용하는 방법은 2가지로 나눠진다.

  1. AKS add on 사용하기
  2. AKS 에 내가 직접 설치해서 사용하기

해보자!!

1. AKS add on 사용하기

Microsoft docs 링크!

가장 빠른 방법은 아래와 같이 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 기준에서는 아래와 같은 장점 & 단점이 있다.

장점

  • 설치가 및 버전 관리가 편하다.

단점

  • 현재 preview 단계이다.
  • 최신의 keda 버전을 사용하지 못한다.
  • managed identity를 사용하지 못한다.

2. AKS 에 내가 직접 설치해서 사용하기

이 부분은 우리가 여지껏 다른 툴들을 Kubernetes에서 사용한 것과 같이 그냥 설치해서 쓰면 된다. 가장 흔한 방법은 helm을 이용한 배포이다.

helm 을 이용한 배포는 손 쉬우니 배포 과정 보다는 팁을 적어볼까 한다.

workload identity를 사용하자!

Azure에 있는 metric을 읽을 때, 선택에 기로에 놓인다.

A. pod identity
B. workload identity

조금 더 최신이기도 하며 사용방법도 쉽다.
federated credentials 만들 때, 나와 같이 헤매지 말고 아래와 같이 만들자!

keda helm 차트의 template 밑에 아래 yaml을 secret.yaml로 넣고 쓰자!!

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 -}}

장점

  • 최신의 keda 사용 가능!
  • managed identity를 쓸 수 있다. (workload identity)

단점

  • helm 차트 관리가 너무 귀찮다.
  • 버전 업데이트도 직접 해야한다.

마치며

위의 2가지 방법중, 2번째 방법을 사용하고 있다. 최신의 keda 사용과, workload identity의 사용은 굉장히 편하다. 단지 helm을 관리하고 keda 버전을 올려줘야한다는 불편함이 있지만, 어차피 내가 관리하고 있는 aks 위의 open source 툴들은 무더기로 있다.
단지 바라는 점이 있다면, kafka scaler 제발 0개로 scale in 됬을 때 이슈가 있는데 고쳐지길 바란다. (이슈는 제기 됬으나 현재 work arround만 적용 된것으로 보여진다.)

profile
n년차 눕눕

0개의 댓글