Beim Versuch, einen experimentellen Kubernetes-Cluster (in einigen VMs auf meinem Laptop) als „hochverfügbar“ zu konfigurieren, stieß ich auf den Rat, dies mit der Kombination von keepalived und haproxy zu tun (https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing).
Beim Betrachten der Konfigurationseinstellungen lese ich
${STATE} ist für einen Host MASTER und für alle anderen Hosts BACKUP, daher wird die virtuelle IP zunächst dem MASTER zugewiesen.
${PRIORITY} sollte auf dem Master höher sein als auf den Backups. Daher reichen 101 bzw. 100 aus.
und diese Einstellungen überraschen mich. Anscheinend muss ich auswählen, welches dieser Systeme der anfängliche Master sein soll, und ich muss dies in den Knoten selbst „hart“ konfigurieren.
Für mich weicht dieses „hochverfügbare“ Setup von der „Haustier“/„Vieh“-Analogie ab, die ich bei Kubernetes finde.
Andere Systeme wie beispielsweise HBase haben ein ähnliches Setup (ein aktiver und mehrere Standby-Leader) und alle sind „identisch“ konfiguriert (die Auswahl erfolgt über ZooKeeper).
Gibt es eine Möglichkeit, Keepalived (für die Verwendung in Kubernetes) so zu konfigurieren, dass alle Knoten die gleiche Konfiguration haben und es trotzdem ordnungsgemäß funktioniert?
Antwort1
Kubernetes selbst stellt „Vieh“-Dienste für Anwendungen bereit. Obwohl viele der „Master“-Kubernetes-Dienste auf derselben Infrastruktur basieren, müssen Sie irgendwann einen Dienst mit einer niedrigeren Ebene booten, um alles zum Laufen zu bringen.
am Leben bleibenwie konfiguriert inverknüpftes Kubernetes Doccobietet eine einzigeVRRPvirtuelle IP-Adresse als hochverfügbarer Endpunkt, der von den Mastern gemeinsam genutzt wird.
Die Knoten konfigurieren alle dieselbe VRRP-IP-Adresse (oder denselben Namen) und Keepalived verschiebt diese Adresse zwischen den Mastern. Die „Auswahl“ wird in der Keepalived-Healthcheck- und Failover-Logik abgeschlossen.
Eine Alternative zu dieser Methode besteht darin, die Lastverteilungsentscheidung auf ein externes Gerät oder die Clients zu verlagern. Sie können auf jedem Knoten einen Reverse-Proxy ausführen (wie Haproxy), das die Kube-API-Server gewichten und die Integritätschecks durchführen kann.
Antwort2
Mir ist klar, dass dies ein veralteter Thread ist, aber ich dachte, ich mische mich trotzdem ein, da ich KeepaliveD mit identischer Konfiguration auf allen Knoten ausgeführt habe.
Unter Debian haben wir alle Knoten zunächst auf BACKUP eingestellt und führen eine Art Integritätscheck durch, der die Priorität erhöht (z. B. wie lange KeepaliveD ausgeführt wurde oder ein Integritätscheck für den lokalen Dienst, für den Sie HA wünschen ...)
VRRP v2, das KeepaliveD (zumindest die Versionen, mit denen ich gearbeitet habe) unter Debian ausführt, verfügt über eine Tie-Breaker-Funktion: Wenn die Priorität auf mehreren Knoten gleich ist, gewinnt die „höchste IP“.
Dies kann zu einer anfänglichen Verzögerung führen, wenn alle Knoten gleichzeitig gestartet werden. Bei unserer Verwendung ist dies jedoch akzeptabel.
Hoffentlich hilft das.