서비스의 가동 중지 시간은 상당한 비즈니스 손실로 이어질 수 있으므로 Kubernetes 클러스터기반의 서비스는 높은 가용성을 제공해야 합니다. 많은 조직에서는 중단 없는 운영을 보장하기 위해 고가용성 솔루션의 필요성을 점점 더 강조하고 있습니다. 기존 HA 측정은 어느 정도의 안정성을 제공하지만 클러스터에 1초 미만의 Fail-over 시간을 제공하면 판도가 달라집니다. 거의 즉각적인 장애 조치 기능을 제공하여 가동 중지 시간을 최소화하여 기존 조치를 뛰어넘습니다. 음성 애플리케이션, 금융 거래 등의 서비스 중단으로 인해 고객 경험이 나빠질 뿐만 아니라 비즈니스 및 평판 손실도 발생할 수 있습니다.
고가용성을 달성하는 방법에는 여러 가지가 있습니다. 예를 들어 HAProxy와 Keepalived를 사용하여 고가용성을 제공할 수 있지만 다음은 몇 가지 중요한 질문입니다.
" 할 수 있다 어떤 클라우드 환경에서도 계속 실행될 수 있나요?" - 아니요 .
" HAProxy나 다른 LB를 사용하면 클러스터 성능이 향상됩니까 ? " - 아니요! (자세한 내용은 LoxiLB vs Cilium vs MetalLB 및 LoxiLB vs IPVS vs HAProxy를 확인하세요.)
그리고 마지막으로 "1초 미만의 HA를 제공합니까?"입니다. - 아니요.
앞서 LoxiLB는 " 무중단 고가용성(Hitless High Availability) " 기능을 출시했으며 1초 미만의 장애 조치 감지를 목표로 하는 긍정적인 피드백과 함께 커뮤니티로부터 황홀한 반응을 받았습니다. 이를 위해 우리는 BFD (양방향 전달 프로토콜) 프로토콜을 기본적으로 구현했습니다. BFD 두 네트워크 장치 간의 전달 경로에서 오류를 신속하게 감지하는 데 사용되는 프로토콜입니다. 이는 고가용성을 유지하고 서비스 중단을 최소화하기 위해 빠른 장애 조치 감지가 중요한 시나리오에서 주로 사용됩니다. 네트워크 장애를 신속하게 감지하는 능력, 프로토콜에 구애받지 않는 설계, 오버헤드 최소화 등과 같은 핵심 측면은 고가용성과 안정성을 보장하는 데 필수적인 도구입니다.
이 기사에서는 LoxiLB가 클러스터의 서비스를 중단하지 않고 1초 미만 수준의 원활한 복원력을 달성하는 데 어떻게 도움이 되는지 살펴보겠습니다.
클러스터 다이어그램
이 데모의 기본 개념은 매우 간단합니다. 서비스 중단 없이 1초 미만의 장애 조치를 수행하는 것입니다. 설정에서는 Kubernetes용 노드 4개, LoxiLB용 노드 2개 및 외부 클라이언트를 준비했습니다. 2개의 LoxiLB 노드 간에 BFD를 실행하겠습니다. Fail-safe 전략은 주로 탐지(Detection)와 조치(Action)라는 두 가지 측면을 가지고 있습니다. BFD는 오류 감지 도구입니다. 오류가 감지된 후 조치는 새 MASTER를 선택하는 것입니다. BFD는 이를 다시 수행한 다음 새 MASTER에서 서비스 IP를 광고합니다. 후자는 LoxiLB에 의해 수행되며 클러스터 아키텍처에 따라 달라집니다. 더 자세히 설명하자면 BFD는 LoxiLB 인스턴스 하나를 MASTER로 선택하고 다른 인스턴스를 BACKUP으로 선택합니다. LoadBalancer 서비스가 생성되고 서비스 IP가 할당되며 그에 따라 광고됩니다.
작업을 단순하게 유지하기 위해 단일 서브넷을 사용하여 모든 것을 구성했습니다. 이 예에서 이 서비스 IP는 가상 IP 또는 유동 IP로 사용됩니다. 즉, 실패 또는 새로 선택되는 경우 이는 MASTER LoxiLB에 연결되고 gARP 메시지를 사용하여 공지됩니다. 그러나 사용자가 externalServiceIPCIDR의 다른 서브넷을 갖고자 한다면 클라이언트 및/또는 클러스터 엔드포인트와 BGP 피어링을 설정하는 것이 좋습니다. 이 경우 서비스 IP는 MASTER 및 BACKUP LoxiLB 인스턴스와 다른 BGP 측정항목을 사용하여 광고됩니다. 예를 들어 gARP가 작동하지 않거나 기본 VM에서 BGP 경로 전달이 지원되지 않는 일부 클라우드 환경에서는 LoxiLB가 해당 환경에서 필요한 구성을 수행하기 위한 작업의 일부로 클라우드 기본 API를 호출할 수 있습니다.
LoxiLB 설치
kube-loxilb 설치
LoxiLB는 K8s용 로드 밸런서 사양 구현인 kube-loxilb 를 제공하여 이를 실행합니다. github 에서 kube-loxilb를 다운로드하고 필요한 경우 변경한 후 K8s 노드 중 하나에 적용할 수 있습니다.
$ cd kube-loxilb/manifest/ext-cluster
$ vi kube-loxilb.yaml몇 가지 변경을 수행하고 apiServerURL을 찾아 IP 주소를 LoxiLB 도커 IP(Kubernetes 네트워크 방향)로 바꿔야 할 수도 있습니다.
containers:
- name: kube-loxilb
image: ghcr.io/loxilb-io/kube-loxilb:latest
imagePullPolicy: Always
command:
- /bin/kube-loxilb
args:
#- --setRoles=0.0.0.0
- --loxiURL=http://192.168.80.252:11111,http://192.168.80.253:11111
- --externalCIDR=192.168.80.5/32
- --setLBMode=2
#- --setBGP=65111
#- --extBGPPeers=192.168.90.9:64512
#- --listenBGPPort=1791 #Mandatory to mention if running with Calico CNI이제 간단히 적용해 보세요.
$ sudo kubectl apply -f kube-loxilb.yaml
serviceaccount/kube-loxilb created clusterrole.rbac.authorization.k8s.io/kube-loxilb created clusterrolebinding.rbac.authorization.k8s.io/kube-loxilb created deployment.apps/kube-loxilb created참고: "setRoles" 옵션을 사용하면 kube-loxilb에서 마스터십 중재가 활성화되어 일반적으로 몇 초 내에 LoxiLB 인스턴스에 대한 활성-대기 역할을 감지하고 설정할 수 있습니다. 우리의 경우에는 BFD와 같은 신뢰할 수 있는 다른 외부 활성-대기 감지 메커니즘이 있는 경우 이 옵션을 활성화해서는 안 됩니다.
LoxiLB 인스턴스 준비
이제 별도의 VM에 LoxiLB 인스턴스를 설정해야 합니다.
첫 번째 VM에서 다음과 같이 LoxiLB( llb1 )를 실행합니다.
docker run -u root --cap-add SYS_ADMIN --restart unless-stopped --privileged -dit -v /dev/log:/dev/log --net=host --name loxilb ghcr.io/loxilb-io/loxilb:latest --cluster=<llb2-ip> --self=0 --ka=<llb2-ip>:<llb1-ip>두 번째 VM에서 다음과 같이 LoxiLB( llb2 )를 실행합니다.
docker run -u root --cap-add SYS_ADMIN --restart unless-stopped --privileged -dit -v /dev/log:/dev/log --net=host --name loxilb ghcr.io/loxilb-io/loxilb:latest --cluster=<llb1-ip> --self=1 --ka=<llb1-ip>:<llb2_ip>서비스 만들기
$ kubectl apply -f tcp-fullnat.yml
service/tcp-lb-fullnat created
pod/tcp-fullnat-test created
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 172.17.0.1 <none> 443/TCP 24m
tcp-lb-fullnat LoadBalancer 172.17.58.84 llb-192.168.80.5 56002:32448/TCP 16mHA 상태 확인
llb1에서 다음 명령을 실행하여 상태를 확인합니다.
$ sudo docker exec -it loxilb loxicmd get bfd -o wide
| INSTANCE | REMOTEIP | SOURCEIP | PORT | INTERVAL | RETRY COUNT | STATE |
|----------|------------|------------|------|-----------|-------------|-------|
| default | 172.17.0.4 | 172.17.0.3 | 3784 | 200000 us | 3 | BFDUp |
$ sudo docker exec -it loxilb loxicmd get hastate
| INSTANCE | HASTATE |
|----------|---------|
| default | BACKUP |
$ sudo docker exec -it loxilb ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft foreverllb2에서 다음 명령을 실행하여 상태를 확인합니다.
$ sudo docker exec -it loxilb loxicmd get bfd -o wide
| INSTANCE | REMOTEIP | SOURCEIP | PORT | INTERVAL | RETRY COUNT | STATE |
|----------|------------|------------|------|-----------|-------------|-------|
| default | 172.17.0.3 | 172.17.0.4 | 3784 | 200000 us | 3 | BFDUp |
$ sudo docker exec -it loxilb loxicmd get hastate
| INSTANCE | HASTATE |
|----------|---------|
| default | MASTER |
$ sudo docker exec -it loxilb ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 192.168.80.5/32 scope global lo
valid_lft forever preferred_lft forever또한 BFD 세션 매개변수를 미세 조정하여 장애 조치를 더욱 빠르게 감지할 수도 있습니다.
$ # loxicmd set bfd <remoteIP> --interval=<time in usec> --retryCount=<value>
$ loxicmd set bfd 172.17.0.4 --interval=100000 --retryCount=2원활한 HA 장애 조치를 볼 수 있는 작은 데모 비디오:
결론
이 데모에서 우리는 올바른 도구를 배치하여 Kubernetes 클러스터에 높은 복원력을 제공할 수 있는 방법을 경험했습니다. 다음 단계의 일환으로 일부 VoIP 애플리케이션을 탐색하고 LoxiLB 및 BFD를 사용하여 유사한 테스트를 수행할 것입니다.
Comentários