Kubernetes LoadBalancer _ On-premise 기반 로드밸런서 (MetalLB), HPA

 

Kubernetes LoadBalancer _ On-premise 기반 로드밸런서 (MetalLB), HPA

 

※ 본 내용은 「컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 길벗」를 참고하여 작성하였습니다.

 

1. LoadBalancer(MetalLB)

 

쿠버네티스 외부 연결방식 중 노드포트를 통해 노드포트 서비스로 이동하고

이를 쿠버네티스의 파드로 보내는 구조는 배우 비효율적입니다.

 

로드밸런서라는 서비스타입은 매우 간단한 구조로 부하를 분산시킬 수 있습니다.

쿠버네티스에서 로드밸런서를 사용하려면 보통 서비스업체를 통해 구현할 수 있습니다.

하지만 온프레미스에서도 구성이 가능한데 이를 지원해주는 것이 MetalLB입니다.

 

MetalLB는 기존의 L2 네트워크(ARP/NDP)와 L3 네트워크(BGP)로 로드밸런서를 구현합니다.

 

구현 절차

(1) 기존에 3개의 pod를 각각 가진 2개의 deployment가 존재한다고 가정하였을 때,

아래와 같은 metallb.yaml 매니페스트 파일을 통해 사전에 정의된 오브젝트 스펙으로 MetalLB를 구성할 수 있습니다.

이를 통해 MetalLB에 필요한 요소가 모두 설치되고 독립적인 네임스페이스(metallb-syustem)도 함께 설치됩니다.

 kubectl apply -f ./metallb.yaml

 

(2) 배포된 MetalLB의 파드가 5개(controller 1개, speaker 4개)인지 확인하고 IP와 상태도 확인합니다.

kubectl get pods -n metallb-system -o wide

 

(3) ConfigMap 오브젝트(설정이 정의된 포맷)를 사용하여 MetalLB 설정을 적용합니다.

kubectl apply -f ./metallb-l2config.yaml

# metallb-l2config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: nginx-ip-range
      protocol: layer2
      addresses:
      - 192.168.1.11-192.168.1.13

 

 

(4) ConfigMap 생성여부를 확인합니다.

kubectl get configmap -n metallb-system

 

(5) 적용이 잘 되었는지도 확인해줍니다.

kubectl get configmap -n metallb-system -o yaml

 

 

(6) 각 디플로이먼트(lb-hname-pods, lb-ip-pods)를 로드밸런서 서비스에 노출시켜줍니다.

kubectl expose deployment lb-hname-pods --type=LoadBalancer --name=lb-hname-svc --port=80
kubectl expose deployment lb-ip-pods --type=LoadBalancer --name=lb-ip-svc --port=80

 

(7) 서비스벌로 CLUSTER-IP와 EXTERNAL-IP가 적용이 잘 되었는지 확인합니다.

kubectl get services

 

 

 

---

2. HAP(Horizontal Pod Autoscaler)

사용자 1명이 파드에 접근하는 것은 위의 방식으로도 크게 문제가 없으나

여러 사람이 접근하는 경우에도 대비해야 하는 상황이 발생할 수 있습니다.

 

쿠버네티스에서는 이를 대비하기 위해서 HPA(Horizontal Pod Autoscaler)를 통해

부하량에 따라 디플로이먼트의 파드 수를 유동적으로 관리하는 기능을 제공합니다.

 

 

절차

먼저 대상이 될 deployment를 생성합니다.

그리고 앞서와 같이 expose를 실행해 로드밸런서 서비스로 설정합니다.

kubectl expose deployment hpa-hname-pods --type=LoadBalancer --name=hpa-hname-svc --port=80

 

설정된 로드밸런서 서비스와 부여된 IP를 확인합니다.

kubectl get services

 

그런데 HPA는 각 워커노드의 kubelet에서 계측값을 수집해서 Metrics-Server로 보내고,

Metrics-Server에서는 API서버를 통해 HPA로 계측값을 전달합니다. 

전달받은 계측값을 확인하고 HPA는 더 많은 자원이 필요한 경우

Scale 요청을 Deployment로 전달하여 파드의 수를 조절합니다.

 

하지만 여기서 Metrics-Server는 아직 구현하지 않았기 때문에 설정해주어야 합니다.

 

메트릭서버도 오브젝트 스펙(매니페스트) 파일로 설치할 수 있습니다.

 

메트릭 서버의 원본 소스(https://github.com/kubernetes-sigs/metrics-server)에서

96~106번째 라인을 아래 내용과 같이 수정해줍니다.

(TLS 인증 무시, kubelet이 내부주소를 우선 사용하게 만듦)

 

# metrics-server-service.yaml

...
      containers:
      - name: metrics-server
        image: k8s.gcr.io/metrics-server-amd64:v0.3.6
        args:
        # Manually Add for lab env(Sysnet4admin/k8s)
        # skip tls internal usage purpose
          - --kubelet-insecure-tls
        # kubelet could use internalIP communication
          - --kubelet-preferred-address-types=InternalIP
          - --cert-dir=/tmp
          - --secure-port=4443
...

 

아래 명령어를 통해 파드의 top값을 확인할 수 있습니다.

여기서는 CPU와 메모리 부하를 확인 가능합니다.

kubectl top pods

 

 

edit 명령을 통해 배포된 디플로이먼트 내용 중 아래 내용을 수정해줍니다.

 kubectl edit deployment hpa-hname-pods

# 40번째 줄 부터
name: echo-hname


resources:
  requests:
    cpu: "10m"
  limits:
    cpu: "50m"
    
    
terminationMessagePath: /dev/termination-log

 

일정 시간 지난 후 kubectl top pods를 실행하면 스펙이 변경되어 새로운 파드가 생성됨을 확인할 수 있습니다.

아래와 같이 autoscale을 설정해서 특정 조건이 만족되는 경우 자동으로 scale 명령이 수행되도록 할 수 있습니다.

kubectl autoscale deployment hpa-hname-pods --min=1 --max=30 --cpu-percent=50