Beiträge von michaeleifel

    Wie schwenkst du die IP denn? Prinzipiell habe ich für solche Szenarien keepalived im Einsatz. Das kann entsprechende Healthchecks und über hinterlegte Skripte direkt mittels Netcup API die Failover switchen. Die Healthchecks sorgen dann dafür, dass die Gewichtung entsprechend hoch oder runter gesetzt wird. Oder geht es jetzt eher darum, dass du die passiven Hosts ebenfalls im Monitoring haben willst?

    Hab das nun "erstmal" per Socat gelöst, da shadowsdocks und dante aus Gründen X mit dem Dualstack nicht so wollten bisher.

    Socat macht den Redirect auf den Ingress Healthchecks per Failover IP und somit kann ich nun den eigenen Status über remote abfragen:


    Socat Kommandos (habs mit SystemD verpackt):

    Code
    socat TCP4-LISTEN:8080,fork,reuseaddr openssl:example.com.443,verify=0,pf=ip4
    socat TCP6-LISTEN:8080,fork,reuseaddr,ipv6only openssl:example.com:443,verify=0,pf=ip6

    Lokal kann ich dann:

    Code
    curl http://fqdn:8080/healthz -4
    curl http://fqdn:8080/healthz -6

    und kriege was ich brauche, ohne API Limits oder so.


    PS: Das CloudVLAN Problem ist auch gelöst.

    Das könnte natürlich sein, dass ich das nicht gemerkt habe und jetzt erst beim Umbau aufgefallen ist (hatte es sehr wohl mitbekommen, Danke)


    Positiv: Nach 1 Stunde Antwort auf Ticket bekommen

    Negativ: Antwort sah nach Textbaustein aus und das Wort "SCP" wurde wohl übersehen und der Sachverhalt war nicht verstanden worden.


    Beim Anruf der Hotline danach war der Kollege sehr bemüht den Sachverhalt richtig zu formulieren und musste es nochmals schriftlich bestätigen. Bin mal gespannt was bei raus kommt.

    Wie schwenkst du die IP denn? Prinzipiell habe ich für solche Szenarien keepalived im Einsatz. Das kann entsprechende Healthchecks und über hinterlegte Skripte direkt mittels Netcup API die Failover switchen. Die Healthchecks sorgen dann dafür, dass die Gewichtung entsprechend hoch oder runter gesetzt wird. Oder geht es jetzt eher darum, dass du die passiven Hosts ebenfalls im Monitoring haben willst?

    Wie schwenkst du die IP denn? => keepalived


    Genau, ich habe bereits Healthchecks im Einsatz die auf Dinge reagieren ( HAProxy nicht erreichbar, Storage nicht Healthy etc.) Die passiven Nodes fragen ab, ob der Webseiten Healthcheck grün ist, oder sie übernehmen müssen, weil was auf der aktiven Node passiert ist, was sie nicht mitbekommen haben. Wenn alle Checks grün sind, wird immer Instanz A die Failover IP haben.

    Auf der aktiven Node nimmt CURL dann über den lokalen Shortcut, da die FailoverIP ja auf dem Interface anliegt und der Check deswegen immer grün ist, auch wenn die IP im Netcup Backend nicht auf den Server zeigt. Und für diesen Fall will ich eine Verbesserung.

    Thema Monitoring:
    Szenario:
    - Cluster Instanzen A,B,C
    - FailoverIP
    - Seite X zeigt auf FailoverIP, die normalerweise Instanz A gehört

    - Sofern Seite X erreichbar ist, reduziert das die Priorität von B und C, sodass diese sich nicht die FailoverIP schnappen

    Ich habe mir derzeit was zusammengehackt um mit Curl und JQ über mein externes Monitoring abfragen zu können für den letzten Punkt. Das ist allerdings recht träge und fragt nur einen vorher ermittelten Wert ab. Kennt da jemand einen Dienst oder ähnliches womit ich das einfacher realisieren könnte? Quasi nen CURL Proxy oder so.


    Du meinst über dnscontrol? Da sah der Export bei meinem Test am WE eigentlich ganz brauchbar aus.


    Ich finde es allerdings auch etwas schade, dass es bei netcup keine offizielle Exportfunktion über die API gibt. Bei I**X und deSEC ist das kein Problem :rolleyes:

    Ja, das war aber auch nur ein ganz kurzer Test und hab die Warnungen in der Ausgabe gelesen. Wenns funktioniert, umso besser. Ich mische aktuell meine DNS Provider und probiere noch Sachen aus, vorzugsweise HE.

    Das ist spitze. Kommt bei dir direkt ein brauchbarer Export im bind Format heraus, oder arbeitest du noch nach?

    Das kann ich dir nicht sagen, da ich nur die andere Richtung nutze und DNS als IaC pflege damit.

    Hab aber gerade bei einem kurzen Test feststellen müssen, dass der Export auf den ersten Blick beim Netcup Provider etwas eingeschränkt ist im Vergleich zu he.

    Option 1.1 ( Falls unbound laufen hast), legst eine local-zone an => https://nlnetlabs.nl/documentation/unbound/unbound.conf/ . Beispielsweise:

    Code
        local-zone: "infra.local." static
        local-data: "k8s-master-1.infra.local A 172.16.0.11"
        local-data: "k8s-master-2.infra.local A 172.16.0.12"
        local-data: "k8s-master-3.infra.local A 172.16.0.13"
        local-data: "k8s-master-1.infra.local AAAA fd72:16::11"
        local-data: "k8s-master-2.infra.local AAAA fd72:16::12"
        local-data: "k8s-master-3.infra.local AAAA fd72:16::13"

    Einen wichtigen Aspekt finde ich, ist die Containersicherheit, insbesondere bei privilegierten Containern
    Dazu gucke ich mir die Dockerfiles an, wie werden diese zusammengesetzt

    Über welche Zahl sprechen wir hier, nur als grobe Einschätzung?
    Ich gucke mir die auch sporadisch an, für alle fehlt mir einfach die Zeit.


    ContainerD + NFtables:

    Das Kubernetes Setup ist so eingerichtet, dass es das sekundäre Interface nutzt und lauscht + Cloud VLAN. Nur der Ingress lauscht dann auf der Public IP und nimmt die Verbindungen an, sofern der Port in Nftables freigegeben ist. Aktuell sind das nur 5 Stück.


    Ich habe tatsächlich nur noch einen Host auf dem Docker selbst läuft und denn ich deswegen nicht venrünftig auf Nftables bekommen ( habe ). Dort darf Docker aber nicht die vorher gesetzten Regeln in Iptables modifizieren "iptables": false 
    Da dass sowieso eine Build Node ist und nichts anderes außer einem DNS Server dort läuft, kann ich das aber verschmerzen.

    Uff, das ist das erste Mal, dass ich vor dem Release "Testing" nicht einmal angeschaut habe. Normalerweise mache ich mich schon monatelang vorher damit vertraut :sleeping:

    Same here, werde das heute mal nachholen. Bin mal gespannt ob meine Ansible Playbooks direkt durchlaufen.