View
온프로미스 환경의 쿠버넷에서 서비스를 사용할 때 LoadBalancer(이하 LB)
는 사용할 수 없다. 쿠버넷은 서비스의 LB 기능을 외부의 역할로 두었고 퍼블릭 클라우드 환경에서는 각 클라우드 벤더사들이 자체적으로 제공하는 LB가 있지만 온프로미스 설정을 위해 별도로 공개하진 않았다.
CNCF Landscape의 Orchestration & Management - Service Proxy 항목을 보면 온프로미스에서 설치가능한 오픈소스 프로젝트 2개가 있는데 MetalLB와 PorterLB 이다. 둘다 쿠버넷의 Service에 필요한 LB 를 제공해주는데 git star를 보면 알겠지만 MetalLB가 사용자가 더 인기가 많아?보인다.
MetalLB와 PorterLB의 설정 문서를 대충 훑어봤는데 LB로써의 설정 관련된 네트워크 지식은 뼈대가 거의 같은것 같아서 한쪽먼저 설치하고 개념을 익혀두면 다른 하나는 쉽게 접근이 가능할 것 같아서 인기가많아서 레퍼런스가 좀 더 있을 것 같은 MetalLB 컨셉이해와 설치를 하기로 했다.
Basic Concept
MetalLB의 주요기능은 쿠버넷에서 서비스에 사용가능한 외부 LoadBalancer
가 되는 것이다. LB가 되기위해서 크게 두가지 기능을 제공한다.
- Address Allocation : 외부와 연결가능한 아이피를 서비스와 연결한다. MetalLB가 자체적으로 아이피를 생성하는 것은 아니며 사용자가 설정한 ip pool에서 사용가능한 아이피를 할당한다. 이 아이피는 public, private 모두 가능하다.
- External Annocement : 사용할 아이피를 서비스와 연결하고, ARP, NDP, BGP 프로토콜을 사용해 외부와 통신할 수 있도록 네트워크를 구성한다.
Preparation
설치 요구사항은 몇개 없다.
- load-balancing 기능이 없는 1.13.0 버전 이상의 Kubernetse
- 지원하는 CNI(** 이슈가 있음) : Calica, Canal, Ciliium, Flannel, Kube-router, Romana, Weave Net**
- kube-proxy의 IPVS mode에서 작동은 하지만 이슈가 약간 있음
- MetalLB에서 제공해줄 아이피 셋
- BGP 모드를 사용할 경우 BGP 기능을 지원하는 하나 이상의 라우터
- MetalLB와 통신하기 위해 모든 클러스터상의 노드가 TCP/UDP 7946가 오픈이 되어있어야 함
- 대부분의 public cloud platform에선 동작하지 않음(metallb.universe.tf/installation/clouds/)
Install
# namespace 생성
$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/namespace.yaml
# MetalLB 오프젝트 생성
$ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.5/manifests/metallb.yaml
위 스크립트 과정을 완료하면 metallb-system
네임스페이스에 생성된 controller
, speaker
팟을 확인할 수 있다.
controller
는 deployment
로 동작하며 LoadBalancer
을 타입으로 사용하는 Service
를 감지하고 보유중인 아이피 풀에서 아이피를 Service
에 배정하는 역할을 한다. 쿠버넷 클러스터의 노드마다 하나씩 배포되는 Speaker
는 daemonset
형태로 배포되며, 실제로 외부 트래픽과 서비스를 연결해 네트워크 통신이 가능하도록 구성하는 역할을 담당한다.
Configuration
MetalLB의 설정은 ConfigMap
으로 배포된 my-release-metallb-config
를 수정하여 설정할 수 있다. service
생성 시 spec.loadBalancerIP
의 값을 통해 아이피를 지정하거나 ip pool을 하나이상 지정해서 그 중 하나를 사용하도록 설정이 가능하다. MetalLB가 네트워크를 구성하는 방식은 크게 Layer2, BGP 방식이 있으며 data.config.address-pools.[].protocol
에서 설정이 가능하다.
Layer2
제일 간단하게 설정할 수 있는 방법이다. 별다른 설정 없이 MetalLB
가 서비스에 할당할 아이피 풀만 지정하면 된다.
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.1.240-192.168.1.250
Layer2
방식은 클러스터를 구성하고 있는 여러 노드 중 하나의 노드가 사용할 IP 하나를 담당해서 모든 트래픽을 하나의 노드로 집중하는 방식이다. 하나의 노드가 ARP
프로토콜 관련 작업을 수행하며 모든 네트워크 트래픽을 담당하기 때문에 노드레벨에서의 로드밸런싱이 되지않아 최대 네트워크 bandwidth는 해당 아이피를 담당하는 노드의 네트워크 bandwidth와 동일하다.
세부 traffic policy를 설정할 수 있는데 Cluster
로 설정할 경우 ip를 담당하는 노드의 kube-proxy
가 서비스의 모든 노드로 트래픽을 분배, 균일하게 로드밸런싱하는 방법이며 pod의 네트워크 관련 트래픽을 관찰하면 source가 ip를 담당하기로한 node의 아이피로 나오는 것을 볼 수 있다. Local
policy의 경우 ip를 담당하기로 한 노드에 있는 pod에만 트래픽을 보낸다. 이 방식은 Cluster
방식과는 달리 kube-proxy
가 다른 노드로 트래픽을 보낼 필요가 없기 때문에 pod에 들어오는 네트워크 소스는 원래 출발지를 가르킨다. Cluster
방식의 경우 다른 노드의 pod은 트래픽을 수신하지 않으며 트래픽을 받는 노드의 replica로서 failover를 방지하기 위한 용도로 사용된다.
BGP