연재 시리즈

쿠버네티스 네트워크 스터디 5주차 - MetalLB BGP모드 동작원리 이해

악분 2022. 2. 19. 13:32
반응형

스터디 목차

 

안녕하세요. 이 글은 facebook 쿠버네티스 그룹에서 올라온 "쿠버네티스 네트워크 스터디" 5주차 내용을 정리했습니다.

스터디 모집글: https://www.facebook.com/groups/k8skr/posts/3202691746679143

 

1. 5주차 네번째 주제

5주차 네번째 주제는 MetalLB BGP모드 동작이해입니다.

 

2. BGP모드 동작원리

BGP모드는 외부 라우터를 통해서 로드밸런서 External IP를 관리합니다. L2모드(https://malwareanalysis.tistory.com/271)는 가장 큰 차이점이 외부접속유무입니다.

 

① speaker pod는 관리하는 external IP정보를 BGP프로토콜로 전파합니다.

② 외부에서 라우터를 통해 ECMP라우팅으로 부하 분산 접속을 합니다.

 

출처: 스터디 공유자료

 

3. BGP모드 장단점

L2모드와 다르게 speaker pod가 장애나더라도 매우 짧은 시간안에 장애복구가 가능합니다. 하지만, 외부 라우터 설정이 필요하기 때문에 네트워크 엔지니어와 협업이 필요합니다. 단순히 MetalLB만 설정하는 것이 아니라, BGP 라우팅 설정 과 라우팅 전파 관련 최적화 설정이 필요합니다.

 

4. 실습

4.1 실습환경

스터디에 공유한 vagrantfile을 활용하여 실습환경을 구축했습니다.

출처: 스터디 공유자료

 

k8s-rtr은 외부 라우터 설정입니다. BGP모드를 위한 설정이 이미 구축되어 있습니다.

router bgp 64513
	bgp router-id 192.168.10.254
	maximum-paths 4
	network 10.1.1.0/24
	neighbor 192.168.10.10  remote-as 64512
	neighbor 192.168.10.101 remote-as 64512
	neighbor 192.168.10.102 remote-as 64512

 

4.2 MetalLB 설정

 

① 공식문서(https://metallb.universe.tf/installation/)에 있는 yaml파일을 설치합니다.

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml

 

② BGP모드 metalLB설정을 configmap으로 적용합니다.

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    peers:
    - peer-address: 192.168.10.254
      peer-asn: 64513
      my-asn: 64512
    address-pools:
    - name: default
      protocol: bgp
      avoid-buggy-ips: true
      addresses:
      - 172.20.1.0/24

 

③ metallb controller와 speaker pod를 재실행합니다. 저는 pod를 삭제하는 방법으로 pod를 다시 실행했습니다.

kubectl  -n metallb-system delete po <controller po>
kubectl  -n metallb-system delete po <speaker pod>

 

각 노드에서 179/tcp 포트가 열려있는지 확인합니다. 179번포트는 spaker pod가 external IP를 BGP프로토콜을 이용하여 전달할 때 사용하는 포트입니다.

tcpdump -i <노드NIC> -nnq tcp port 179

 

4.3 pod, 로드밸런서 타입 서비스 생성

pod 2개와 로드밸런서 타입 서비스 3개를 생성합니다. 3개 서비스 모두 같은 endpoints를 같습니다.

 

apiVersion: v1
kind: Pod
metadata:
  name: webpod1
  labels:
    app: webpod
spec:
  #nodeName: k8s-w1
  containers:
  - name: container
    image: traefik/whoami
  terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Pod
metadata:
  name: webpod2
  labels:
    app: webpod
spec:
  #nodeName: k8s-w2
  containers:
  - name: container
    image: traefik/whoami
  terminationGracePeriodSeconds: 0
---
apiVersion: v1
kind: Service
metadata:
  name: svc1
spec:
  ports:
    - name: svc1-webport
      port: 80
      targetPort: 80
  selector:
    app: webpod
  type: LoadBalancer
  #externalTrafficPolicy: Local
---
apiVersion: v1
kind: Service
metadata:
  name: svc2
spec:
  ports:
    - name: svc2-webport
      port: 80
      targetPort: 80
  selector:
    app: webpod
  type: LoadBalancer
  #externalTrafficPolicy: Local
---
apiVersion: v1
kind: Service
metadata:
  name: svc3
spec:
  ports:
    - name: svc3-webport
      port: 80
      targetPort: 80
  selector:
    app: webpod
  type: LoadBalancer
  #externalTrafficPolicy: Local

 

pod와 서비스가 정상적으로 실행되었는지 확인합니다. 서비스는 External-IP가 있어야 합니다.

kubectl get po,svc

 

라우터 호스트에서는 external IP에 대한 라우팅 테이블이 갱신되어 있습니다.

ip -c route | grep 172.20. -A3

 

라우터 터미널에서도 직접 확인할 수 있습니다.

 

4.4 통신

svc1이름을 갖는 서비스는 controlplane로 라우팅됩니다. 



svc2이름을 갖는 서비스는 worker1노드로 라우팅됩니다.

반응형