Beiträge von Tom81

  • Sind VPS / RS für kubernetes/etcd production ready? [SOLVED 50%]

    SOLVED zu 50%: Umstellung auf SCSI verbessert, aber reduziert die nur die Häufigkeit des Auftretens.


    Grund für die Disk Spikes etc. ist der KVM VIRTIO Festplatten Treiber. Aber zum Glück kann man umstellen auf SCSI, was auch empfohlen ist, aber nicht der Default bei Serverneuinstallation. Sogar wenn man auf SCSI gestellt hat und danach den Server neu installiert, wird wieder automatisch VIRTIO gewählt.

    pasted-from-clipboard.png


    Man sieht es gut, gegen 18.40 Uhr habe ich alle etcd Server auf SCSI umgestellt.

    pasted-from-clipboard.png


    Drauf gekommen bin ich, weil mein Homelab mit Proxmox und KVM auf langsamen HDD (mit SCSI) ohne Probleme läuft.


    Die etcd Logs sind jetzt auch komplett frei von apply request took too long, nichtmal der 100ms Threshold wird gerissen.

  • Sind VPS / RS für kubernetes/etcd production ready? [SOLVED 50%]

    FYI: So setze ich die Server nach Neuinstallation auf:


    Container Runtime

    Notwendiges für K8S

    Code
    echo "br_netfilter" >> /etc/modules-load.d/modules.conf
echo "overlay" >> /etc/modules-load.d/modules.conf

cat << 'EOF' | tee /etc/sysctl.d/99-kubernetes-cri.conf
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
    Code
    reboot

    K8S:

    Code
    apt install -y apt-transport-https ca-certificates curl

curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg 

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list

apt update
apt install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

    kubeadm init../ join...

  • Sind VPS / RS für kubernetes/etcd production ready? [SOLVED 50%]

    War gestern Abend noch fleissig, weil es mir keine Ruhe gelassen hat :)


    Das Ergebnis:


    - nur 1 single Master Node (kein weiterer Node)

    - RS2000!

    - Debain 12 NC Image

    - kein VLAN Interface attached

    - k8s mit stacked etcd installiert mit kubeadm init --upload-certs --pod-network-cidr 192.168.0.0/16

    - Danach noch calico drauf:


    Code
    kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.1/manifests/tigera-operator.yaml
curl https://raw.githubusercontent.com/projectcalico/calico/v3.25.1/manifests/custom-resources.yaml -O
kubectl create -f custom-resources.yaml


    Logs des etcd pods:


    ca 1-2h nach installieren: 9.5 Sekunden - so hoch habe ich es noch nie gesehen.

    Code
    {"level":"warn","ts":"2023-06-22T23:54:00.061Z","caller":"etcdserver/util.go:170","msg":"apply request took too long","took":"9.516213776s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/clusterrolebindings/\" range_end:\"/registry/clusterrolebindings0\" count_only:true ","response":"range_response_count:0 size:8"}
{"level":"warn","ts":"2023-06-22T23:54:00.061Z","caller":"etcdserver/util.go:170","msg":"apply request took too long","took":"6.226219627s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/operator.tigera.io/apiservers/\" range_end:\"/registry/operator.tigera.io/apiservers0\" count_only:true ","response":"range_response_count:0 size:8"}
{"level":"warn","ts":"2023-06-22T23:54:00.061Z","caller":"etcdserver/util.go:170","msg":"apply request took too long","took":"7.71104878s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/jobs/\" range_end:\"/registry/jobs0\" count_only:true ","response":"range_response_count:0 size:6"}
{"level":"warn","ts":"2023-06-22T23:54:00.061Z","caller":"etcdserver/util.go:170","msg":"apply request took too long","took":"7.816738481s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/services/endpoints/calico-system/calico-typha\" ","response":"range_response_count:1 size:670"}
{"level":"warn","ts":"2023-06-22T23:54:00.061Z","caller":"etcdserver/util.go:170","msg":"apply request took too long","took":"3.632870759s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/crd.projectcalico.org/hostendpoints/\" range_end:\"/registry/crd.projectcalico.org/hostendpoints0\" count_only:true ","response":"range_response_count:0 size:6"}

    und geht dann so im gewohnten 1-2 mal pro Stunde Takt so weiter

    Das system ist absolut "clean and fresh"


    Die Pods:


  • Sind VPS / RS für kubernetes/etcd production ready? [SOLVED 50%]

    Zitat von H6G

    Mit dem VPS 200 und RS 1000 sieht es da schon dünn aus.

    VPS 200 zum Testen nur genutzt. RS 1000 4 Cores 8GB sollten ohne k8s Master absolut ausreichen ohne Belastung.

    Zitat von H6G

    Wie ist dein Debian konfiguriert? Hast du das per Image oder per ISO installiert?

    Hast du den Swap deaktiviert?

    Image von NC, Swap ist off

    Zitat von H6G

    Hast du schon mal probiert Calico über die öffentlichen IPs zu schicken, statt über das CloudVLAN?

    Das CloudVLAN ist unter der Haube ein VXLAN, nutzt also UDP.

    Ich werde es mal ohne VLAN testen die Tage

    Zitat von Paul

    Kannst du die Tests mal mit nur 1 Master durchführen? Einfach 1 RS1000 dafür nehmen

    Jop werde ich mal testen die Tage

    Zitat von Paul

    Wenn du produktive Kubernetes Cluster bei Netcup betreiben willst, hast du dir schon überlegt wie du das mit dem Storage und dem LB machen willst?

    Storage mit Longhorn, da seh ich auch keinen Grund die Workernodes Disks nicht zu verwenden. LB wird metallb

  • Sind VPS / RS für kubernetes/etcd production ready? [SOLVED 50%]

    Ich teste jetzt seit Tagen mit verschiedenen K8s Setups und habe das Gefühl auf den NC Server läuft Kubernetes nicht einwandfrei.


    Kubernetes Cluster Setup:

    - 3 Master RS 1000 (RS 2000 und VPS 200 auch probiert)

    - 1 Worker RS 1000 (RS 2000 und VPS 200 auch probiert)

    - Debian 11 (10 und 12 auch schon probiert)

    - Die Server kommunizieren über Cloud vLAN 2,5 Gbit/s

    - kubernetes mit kubeadm aufgesetzt, und abgesehen von den privaten IPs ein absolutes Standard-Setup

    - CSN calico tigera operator

    - einzige Workload (bisher) prometheus-monitoring (Aber auch ohne gibt es die Probleme)


    Angemerkt: Das gleiche Setup habe ich im privaten Homelab mit HDD (nicht SSD!) und auch beim großen A bis Z Cloud Anbieter (SSD Disks) probiert und hatte keine Problem bisher.

    Zum Problem:


    Mit ist aufgefallen, dass ich immer wieder mal Warnings habe. So ca alle 30 bis 60 Minuten.


    Code
    kubectl get events -A | grep Warning
kube-system   5m13s       Warning   Unhealthy   pod/kube-apiserver-test-k8s   Readiness probe failed: HTTP probe failed with statuscode: 500

    Und auch den ein oder anderen kube-system pod Restart


    Ich habe die Sache dann auf etcd zurückführen können, denn zeitgleich mit der Warning. Haben etcd logs folgendes ausgespuckt:


    Code
    {"level":"warn","ts":"2023-06-22T15:29:36.314Z","caller":"etcdserver/util.go:166","msg":"apply request took too long","took":"5.999710819s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/apiregistration.k8s.io/apiservices/\" range_end:\"/registry/apiregistration.k8s.io/apiservices0\" count_only:true ","response":"range_response_count:0 size:8"}
{"level":"warn","ts":"2023-06-22T15:29:36.313Z","caller":"etcdserver/util.go:166","msg":"apply request took too long","took":"4.003310712s","expected-duration":"100ms","prefix":"read-only range ","request":"key:\"/registry/ranges/servicenodeports\" ","response":"range_response_count:1 size:119"}


    Also separaten etcd Cluster aufgesetzt und alle erdenklichen Benchmarks und Checks gemacht und das Ergebnis war: NC Disks sind einfach die schnellsten, einen Ticken besser wie A bis Z und deutlich besser wie meine Homelab HDDs. Und trotzem läuft es nicht rund.


    Also k8s und etcd Cluster getrennt:

    Neues Setup (mit VPS200 und RS1000 und RS2000 gestested - kein Unterschied)


    - 3 etcd nodes

    - 1 k8s master node

    - 0 k8s worker


    Anpassen der --heartbeat-interval --election-timeout parameter half auch nicht.


    Ergebnis wie oben, grundsätzlich läuft es, aber hier und da Warnings und Neustart von kube-system pods.


    etcd endpoint checks:

    Code
    docker exec etcd /usr/local/bin/etcdctl --write-out=table --endpoints $ENDPOINTS endpoint status
+------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|     ENDPOINT     |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| 10.241.0.17:2379 | 8b6b8d8fb98eca2e |   3.5.9 |  922 MB |     false |      false |        28 |    1090732 |            1090732 |        |
| 10.241.0.18:2379 | 6592412b034dfc6c |   3.5.9 |  922 MB |     false |      false |        28 |    1090732 |            1090732 |        |
| 10.241.0.19:2379 | 4dac3bf58bf8d547 |   3.5.9 |  922 MB |      true |      false |        28 |    1090732 |            1090732 |        |
+------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

    Die große DB size kommt von den ganzen Benchmark tests.

    Code
    docker exec etcd /usr/local/bin/etcdctl --write-out=table --endpoints $ENDPOINTS endpoint health
+------------------+--------+------------+-------+
|     ENDPOINT     | HEALTH |    TOOK    | ERROR |
+------------------+--------+------------+-------+
| 10.241.0.19:2379 |   true | 2.831555ms |       |
| 10.241.0.17:2379 |   true |  2.43684ms |       |
| 10.241.0.18:2379 |   true | 3.251807ms |       |
+------------------+--------+------------+-------+


    Hier mal ein Graph der Disk Operations in den letzten 3h. Die Spikes + Zeiten passen zu den entsprechenden Logs von oben.

    pasted-from-clipboard.png


    Im Vergleich der A-Z Laden: keine Spikes

    pasted-from-clipboard.png


    Und mit diesem aktuellen Stand fühle ich mich nicht wohl ein Production Cluster zu fahren, der auch ein wenig Workload bekommen würde.


    Hat jemand ähnliche Erfahrung? Wenn es bei euch läuft, welches OS habt ihr verwendet?


    -------

    Sideeffekts:


    - Bei dem ganzen Rumgeteste, hatte ich einen RS1000, welcher einfach nicht den etcd Cluster nutzen wollten. Timeout bei kubeadm init .... Ich bin wirklich verzweifelt zumal das selbe Setupscript bei jedem anderen Server funktioniert hat, als hätte ich einen "Montagsserver" erwischt.. Auch mehrmalige OS Neuinstallation halfen nicht.

    - Vermutlich purer Zufall, aber die RS1000 haben in den 2 Tagen Testen mehr Auffälligkeiten gezeigt, als die kleinen VPS200.