실험적인 Kubernetes 클러스터(내 노트북의 몇 개의 VM)를 "고가용성"으로 구성하려고 시도하는 동안 keepalived와 haproxy의 조합을 사용하여 이 작업을 수행하라는 조언을 찾았습니다(https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing).
내가 읽은 구성 설정을 살펴보면
${STATE}는 하나의 호스트에 대해서는 MASTER이고 다른 모든 호스트에 대해서는 BACKUP이므로 가상 IP는 처음에 MASTER에 할당됩니다.
${PRIORITY}는 백업보다 마스터에서 더 높아야 합니다. 따라서 각각 101과 100이면 충분합니다.
그리고 이 설정은 나를 놀라게 했습니다. 겉보기에는 해당 시스템 중 초기 마스터가 될 시스템을 선택해야 하고 노드 자체에서 이를 "하드" 구성해야 합니다.
나에게 있어 이 "고가용성" 설정은 Kubernetes에서 찾은 "애완동물"/"가축" 비유에서 벗어났습니다.
예를 들어 HBase와 같은 다른 시스템은 유사한 설정(하나의 활성 리더와 여러 개의 대기 리더)을 가지며 모두 "동일하게" 구성됩니다(선택은 ZooKeeper를 통해 수행됨).
모든 노드가 동일한 구성을 갖고 계속 올바르게 작동하도록 Keepalived(Kubernetes에서 사용하기 위해)를 구성할 수 있는 방법이 있습니까?
답변1
Kubernetes 자체는 애플리케이션에 "가축" 서비스를 제공합니다. 많은 "마스터" Kubernetes 서비스가 동일한 인프라를 기반으로 하지만 어떤 시점에서는 서비스를 모두 시작하려면 더 낮은 수준의 서비스를 부트스트랩해야 합니다.
연결 유지에 구성된대로연결된 쿠버네티스 docco단일을 제공합니다VRRP마스터 간에 공유되는 고가용성 엔드포인트인 가상 IP 주소입니다.
노드는 모두 동일한 VRRP IP 주소(또는 이름)를 구성하고 연결 유지는 해당 주소를 마스터 주변으로 이동합니다. "선택"은 연결 유지 상태 확인 및 장애 조치 논리에서 완료됩니다.
이 방법의 대안은 로드 밸런싱 결정을 외부 장치나 클라이언트로 옮기는 것입니다. 각 노드에서 역방향 프록시를 실행할 수 있습니다(하프록시처럼)는 kube-api 서버에 가중치를 부여하고 상태 확인을 완료할 수 있습니다.
답변2
나는 이것이 오래된 스레드라는 것을 알고 있지만 모든 노드에서 동일한 구성으로 KeepaliveD를 실행했기 때문에 어쨌든 차임할 것이라고 생각했습니다.
Debian에서는 모든 노드가 처음에 BACKUP으로 설정되어 있고 우선 순위를 높이는 일종의 상태 확인 기능이 있습니다(예: KeepaliveD가 실행된 기간 또는 HA를 원하는 로컬 서비스에 대한 상태 확인...)
KeepaliveD(적어도 내가 작업한 버전)가 데비안에서 실행되는 VRRP v2에는 순위 결정 기능이 있습니다. 즉, 여러 노드에서 우선 순위가 동일하면 "가장 높은 IP"가 승리합니다.
모든 노드가 동시에 시작되면 초기 지연이 발생할 수 있지만 이를 사용하는 경우에는 허용됩니다.
도움이 되길 바랍니다.