개요

엣지 컴퓨팅은 임무 수행에 매우 중요합니다. 애플리케이션을 실행할 때 고가용성은 필수이며, 단일 노드(단일 CPU, 디스크 등)에 의존하는 것은 용납할 수 없죠.
식당 POS 애플리케이션이 클러스터 장애로 인해 다운되어 매출이 손실되는 상황 또는 제조업체의 공장 현장에서 IoT 장치를 실행하는 엣지 서버가 다운되어 생산이 중단되는 상황 대비가 필요합니다.
이 세션에서는 2대의 노드를 사용하여 비용 효율적이고 가용성 높은 Kubernetes 아키텍처를 설계하고 구현했던 고민과 시행착오를 공유합니다.

발표

노드 두 대 만으로 클러스터 구성.
그것도 ha..

왜 했냐..?

엣지와 통신의 영역에서 클네 도입 시작
5g는 이미 많이 적용됐고, 이제 컨테이너로 코어를 배포
엣지에도 적용 필요
근데 엣지는 리소스가 항상 충분하지 않은 경우가 많다.
특히 선박에서의 엣지 네트워크

선박에는 많은 센서가 존재한다.
컨테이너 선에서 방대한 데이터가 수집되고 저장된다.
해당 서버는 많은 역할을 하고 있고, 이를 고가용성으로 관리하는 게 필요하다.
근데 전원 공급이 힘들고 잦은 정전이 발생한다.
심지어 선박 전용 pc가 필요하다.
외부 원격 전송도 힘들다.
그렇다고 it 전문 인력이 상주할 수 있는가?
항구에 정박할 때마다만 보수하는 거임 ㄷㄷ
여기에 고가용성 적용을 위해, 클러스터 도입을 검토한 것.

도전과제

• 정전에 대한 자동 복구
  • 이건 그냥 etcd만 보존됐으면 문제 없다.
• 한정 자원으로 해결
• 데이터 유실 대비

마스터 플레인의 고가용성이 사실 가장 중요하다.
원래는 마스터플레인은 홀수여야 함.
그래서 3대가 보통인데, 선박에는 그게 안돼서 2대로 찾아보게 된것이다.

테스트 케이스 1

마스터가 죽었을 때 워커를 마스터로 승격시키기
바로 서버가 죽는 건 아니어도, 이후 조작을 위해 다시 마스터를 구성해서 살려내야만 한다.
kubeadm으로 되냐?
모든 게 재구성돼서 안 된다.

kubelet 설정을 바꿔서 강제로 올리면 워커 내 파드가 전부 재시작 돼서 서비스가 멈춘다.

테스트 케이스 2

런타임 핸들링은 어려울 거라는 결론 내림
kubecon 유럽에서 엣지 컴퓨팅 비용 절약을 위한 2노드 ha 발표가 있었음

카이로스란 os 활용
경량 쿠버인 k3s
kube-vip
kine이라는 etcd를 관계형 디비postgre로 활용
etcd자체는 하나로 활용하여 마스터쪽의 etcd를 활용하도록 함
etcd 자체는 복제 기능을 제공하지 않기에 활용한 것.

리더에서 장애시 팔로워가 승격됨
kine 엔드포인트를 끊고 자신의 db를 바라봄
리더에 대한 논리 복제 방식 삭제
서비스 엔드포인트도 삭제함
k3s를 멈추고, 재시작

테스트 시 4.5분 정도 다운타임 발생
stateless 앱의 경우 확산 제약 조건을 걸어둬야 함.
데몬셋으로 한던가.

stateful 앱의 경우 분산 블록 스토리지

참고로 디비 복제가 단방향이라, 궁극적으로 마스터를 다시 복구해야 함

네트워크 파티션 단절을 통한 split brain 문제 생길 수 잇음
초갈이 되어버리는 ㄷㄷ
노드 감지 시간도 조정 필요

테스트 케이스 3

mccs라는 사내 솔루션에 적용해봄
각 노드 별 hearbeat, mirror nic 구성

etcd는 static 아닌 별도의 컨테이너로 구성
etcd 엔드포인트를 vip로 해서 조금더 승격을 빠르게 할 수 있도록 함

결론적으로..
쿠버 만으로 2노드 ha는 불가능
db 가용성 연구가 특히 필요했다.
특히 split brain 문제도 잘 대처해야 할 듯.
둘이 네트워크 분절이 나면..(네트워크 분절나면 방법이 있나..? 그보다는 그로부터 발생할 문제를 대처하는게)

참고