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.
kubectl get events -A | grep Warning
kube-system 5m13s Warning Unhealthy pod/kube-apiserver-test-k8s Readiness probe failed: HTTP probe failed with statuscode: 500Und auch den ein oder anderen kube-system pod Restart
kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
calico-apiserver calico-apiserver-7bccbfdcb4-4d94t 1/1 Running 0 45h
calico-apiserver calico-apiserver-7bccbfdcb4-95sjr 1/1 Running 0 45h
calico-system calico-kube-controllers-789dc4c76b-tp4g5 1/1 Running 0 45h
calico-system calico-node-vdzq2 1/1 Running 0 45h
calico-system calico-typha-8d9cb4c54-6xxnq 1/1 Running 0 45h
calico-system csi-node-driver-jgggx 2/2 Running 0 45h
kube-system coredns-5d78c9869d-pdqss 1/1 Running 0 45h
kube-system coredns-5d78c9869d-xkwnx 1/1 Running 0 45h
kube-system kube-apiserver-test-etcd-single 1/1 Running 0 45h
kube-system kube-controller-manager-test-etcd-single 1/1 Running 60 (65m ago) 45h
kube-system kube-proxy-ftc9g 1/1 Running 0 45h
kube-system kube-scheduler-test-etcd-single 1/1 Running 56 (30m ago) 45h
tigera-operator tigera-operator-549d4f9bdb-ksdlw 1/1 Running 63 (30m ago) 45hIch habe die Sache dann auf etcd zurückführen können, denn zeitgleich mit der Warning. Haben etcd logs folgendes ausgespuckt:
{"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:
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.
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.
Im Vergleich der A-Z Laden: keine Spikes
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.
