Kubernetes mehre fragen

Firewire2002 said:
Aber für die User-1001 (ich geh mal davon aus, es ist die uid gemeint) fehlen mir grad Details
Click to expand...
Ja genau, ich meinte natürlich UID 1001 :)
Es ist eine (afaik) von OCD/OKD eingeführte best-practice dass nicht alle Container aller Tenants auf der gleichen UID laufen sollen. OKD generiert generiert automatische eine getrennte default-UID pro Namespace für den executing-user und erlaubt das Ausführen der Container in einer ID-Range um die User-ID einzelner Pods zu trennen wenn man will.
Dies sorgt dafür dass die impliziten Rechteverwaltung von UNIX automatisch auch auf Abhängigkeiten wie dem NFS-Share gelten und reduziert das Risiko von cross-Container oder cross-Namespace Zugriff auf Daten (insbesondere NFS) andere Angriffsversuche.
Dass auch dies aber vor Sicherheitslücken in der Runtime nicht hilft beweist cr8escape aber nur zu gut :rolleyes:

Rein theoretisch ist es auch nicht per se extrem gefährlich UID-0 Container aus zu führen. Aber die Idee der Containerisierung ist ja eben Trennung und Abschottung, wenn man alles als root ausführen will und wild miteinander kommunizieren soll tut es eine Linux Büchse auch, ganz ohne Container.
 
Super vielen Dank für die ausführliche Eröterung wieder. Mal eine ganz andere Frage, hast du schon einmal ein externes etcd Cluster aufgesetzt für K8S?
 
Milchbroetchen said:
Mal eine ganz andere Frage, hast du schon einmal ein externes etcd Cluster aufgesetzt für K8S?
Click to expand...
Nein, immer nur zusammen mit der Kubernetes Controlplane zusammen. Rein subjektiv sehe ich aber auch keine Vorteile solange man nicht die notwendige Grösse hat um dedizierte Maschinen zu wollen.
 
Habe leider massive Probleme beim installieren eines HA Clusters nach dieser Anleitung hier Set up a High Availability etcd Cluster with kubeadm
und zwar ab dem Punkt "Setting up the Cluster", dass Systemd unit File habe ich wie dort erklärt erstellt, Daemon Reload gemacht und Kubeadm gestartet. Leider bekomme ich immer wieder einen error und kubeadm startet nicht.
root::infra01-de-nbg1-dc3]
~: systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf, 20-etcd-service-manager.conf
Active: activating (auto-restart) (Result: exit-code) since Mon 2022-04-04 23:15:30 CEST; 1s ago
Docs: https://kubernetes.io/docs/home/
Process: 9790 ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime=remote --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock (co>
Main PID: 9790 (code=exited, status=1/FAILURE)
CPU: 101ms

Apr 04 23:15:30 infra01-de-nbg1-dc3 systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE
Apr 04 23:15:30 infra01-de-nbg1-dc3 systemd[1]: kubelet.service: Failed with result 'exit-code'.
Click to expand...

Auszug aus cat /var/log/syslog
Apr 4 23:18:26 infra02-de-fsn1-dc14 systemd[1]: Started Kubernetes systemd probe.
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.541170 9188 server.go:446] "Kubelet version" kubeletVersion="v1.23.5"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.541689 9188 server.go:606] "Standalone mode, no API client"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: W0404 23:18:26.541974 9188 manager.go:159] Cannot detect current cgroup on cgroup v2
Apr 4 23:18:26 infra02-de-fsn1-dc14 systemd[1]: run-rc45c51e84b3a43e683fa6c76f8856464.scope: Succeeded.
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.594504 9188 server.go:494] "No api server defined - no events will be sent to API server"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.594831 9188 server.go:693] "--cgroups-per-qos enabled, but --cgroup-root was not specified. defaulting to /"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.595192 9188 container_manager_linux.go:281] "Container manager verified user specified cgroup-root exists" cgroupRoot=[]
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.595422 9188 container_manager_linux.go:286] "Creating Container Manager object based on Node Config" nodeConfig={RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: ContainerRuntime:remote CgroupsPerQOS:true CgroupRoot:/ CgroupDriver:systemd KubeletRootDir:/var/lib/kubelet ProtectKernelDefaults:false NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: ReservedSystemCPUs: EnforceNodeAllocatable:map[pods:{}] KubeReserved:map[] SystemReserved:map[] HardEvictionThresholds:[{Signal:nodefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.1} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.inodesFree Operator:LessThan Value:{Quantity:<nil> Percentage:0.05} GracePeriod:0s MinReclaim:<nil>} {Signal:imagefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.15} GracePeriod:0s MinReclaim:<nil>} {Signal:memory.available Operator:LessThan Value:{Quantity:100Mi Percentage:0} GracePeriod:0s MinReclaim:<nil>}]} QOSReserved:map[] ExperimentalCPUManagerPolicy:none ExperimentalCPUManagerPolicyOptions:map[] ExperimentalTopologyManagerScope:container ExperimentalCPUManagerReconcilePeriod:10s ExperimentalMemoryManagerPolicy:None ExperimentalMemoryManagerReservedMemory:[] ExperimentalPodPidsLimit:-1 EnforceCPULimits:true CPUCFSQuotaPeriod:100ms ExperimentalTopologyManagerPolicy:none}
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.595612 9188 topology_manager.go:133] "Creating topology manager with policy per scope" topologyPolicyName="none" topologyScopeName="container"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.595771 9188 container_manager_linux.go:321] "Creating device plugin manager" devicePluginEnabled=true
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.595942 9188 state_mem.go:36] "Initialized new in-memory state store"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.603747 9188 kubelet.go:422] "Kubelet is running in standalone mode, will skip API server sync"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: I0404 23:18:26.604073 9188 kubelet.go:278] "Adding static pod path" path="/etc/kubernetes/manifests"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: E0404 23:18:26.628680 9188 remote_runtime.go:165] "Version from runtime service failed" err="rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: E0404 23:18:26.629142 9188 kuberuntime_manager.go:235] "Get runtime version failed" err="get remote runtime typed version failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
Apr 4 23:18:26 infra02-de-fsn1-dc14 kubelet[9188]: E0404 23:18:26.629345 9188 server.go:302] "Failed to run kubelet" err="failed to run Kubelet: failed to create kubelet: get remote runtime typed version failed: rpc error: code = Unimplemented desc = unknown service runtime.v1alpha2.RuntimeService"
Apr 4 23:18:26 infra02-de-fsn1-dc14 systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE
Apr 4 23:18:26 infra02-de-fsn1-dc14 systemd[1]: kubelet.service: Failed with result 'exit-code'.
Click to expand...
Langsam bin ich absolut ratlos, Kubeadm wurde wie folgt aufgesetzt: Installing kubeadm und Docker habe ich wie folgt aufgesetzt: Install Docker Engine on Debian.
Als System kommt ein aktuelles Debian 11 zum Einsatz, ich bin langsam echt ratlos und finde auch im Internet nichts passendes, hast du vielleicht noch irgendwie eine Idee für mich @d4f ich bin seit Tagen an diesem Fehler.

Edit: nach einigen Stunden Qual bin ich noch auf die Lösung gekommen, ich werde morgen im laufe des Tages die Lösung posten, jetzt ruf das Bett.
 
Last edited:
So wie versprochen werde ich hier einmal ergänzen was geändert werden muss um mittels kubeadm ein HA Etcd Cluster aufzusetzen. Diese Anleitung kommt dazu zum Einsatz: Set up a High Availability etcd Cluster with kubeadm

Unter der Kategorie Setting up the cluster
1. Anstatt das dort angegebene system.d Script zu verwenden musste dies etwas abgeändert werden in folgendes:
[Service]
ExecStart=
# Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
# Replace the value of "--container-runtime-endpoint" for a different container runtime if needed.
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
Restart=always
Click to expand...

Danach musste ich noch folgende Sachen erledigen:
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
systemctl restart containerd
Click to expand...

Danach noch ein:
systemctl daemon-reload
Click to expand...
systemctl restart kubelet
Click to expand...
systemctl status kubelet
Click to expand...
Und schon funktioniert es ohne Probleme und man kann ganz normal mit Punkt 2 "Create configuration files for kubeadm." fortfahren.
Mit diesen Tricks hat es wunderbar funktioniert und ich habe nun ein HA Setup für Etcd, bitte beachtet das diese Steps für Docker bzw. Containerd.io sind welche ich oben erläutert habe. Zusätzlich dazu habe ich alle Etcd member in ein internes LAN gepackt über welche diese kommunizieren, in diesem LAN ist ebenfalls ein LoadBalancer welcher als Ansprechpartner nach Außenhin fungiert. Auf den eigentlichen Servern habe ich alle Ports bis auf SSH gesperrt, damit das Cluster wirklich nur über den Loadbalancer angesprochen wird.
 
Last edited:
  • Like
Reactions: d4f
Ja, ganz klassisch ESXi. Aber wir schweifen hier vom Thema ab. In dem Thread geht's nicht inhaltlich um Kubernetes, sondern um die Orga im SSF :D
 
@d4f ich bräuchte leider nochmal deine Hilfe und zwar kommen die beiden CoreDNS Pods nicht hoch, diese bleiben die ganze Zeit im Pending stehen. Der KubeAPI dienst geht in ein Crash Loop, hatte gelesen, dass es am fehlendem Netzwerk Plugin liegen könnte, was aber eigentlich nicht sein kann da ich Flannel nach der offiziellen Anleitung installiert habe.

[root::cp01-de-nbg1-dc3]
~: kubectl get pods --namespace=kube-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
coredns-64897985d-f5csq 0/1 Pending 0 50m <none> <none> <none> <none>
coredns-64897985d-zwf2w 0/1 Pending 0 50m <none> <none> <none> <none>
hcloud-cloud-controller-manager-78bd6bcffc-t945g 1/1 Running 1 (14m ago) 40m 10.244.0.4 cp01-de-nbg1-dc3 <none> <none>
hcloud-csi-controller-6cb4b557bf-d755m 0/5 Pending 0 45m <none> <none> <none> <none>
hcloud-csi-node-cqpm2 3/3 Running 3 (14m ago) 45m 10.244.0.5 cp01-de-nbg1-dc3 <none> <none>
hcloud-csi-node-fhzcs 3/3 Running 0 11m 10.244.3.2 node01-de-fsn1-dc14 <none> <none>
hcloud-csi-node-lsgq7 3/3 Running 3 (13m ago) 21m 10.244.2.3 cp03-de-fsn1-dc14 <none> <none>
hcloud-csi-node-vc6q8 3/3 Running 3 (13m ago) 27m 10.244.1.3 cp02-de-nbg1-dc3 <none> <none>
kube-apiserver-cp01-de-nbg1-dc3 1/1 Running 2 (13m ago) 42m 49.12.234.236 cp01-de-nbg1-dc3 <none> <none>
kube-apiserver-node01-de-fsn1-dc14 0/1 CrashLoopBackOff 6 (3m45s ago) 11m 49.12.74.234 node01-de-fsn1-dc14 <none> <none>
kube-controller-manager-cp01-de-nbg1-dc3 1/1 Running 1 (14m ago) 42m 49.12.234.236 cp01-de-nbg1-dc3 <none> <none>
kube-controller-manager-node01-de-fsn1-dc14 1/1 Running 0 11m 49.12.74.234 node01-de-fsn1-dc14 <none> <none>
kube-flannel-ds-5p494 1/1 Running 0 6m31s 49.12.74.234 node01-de-fsn1-dc14 <none> <none>
kube-flannel-ds-fv5fv 1/1 Running 0 6m43s 49.12.192.3 cp02-de-nbg1-dc3 <none> <none>
kube-flannel-ds-jzvlj 1/1 Running 0 6m36s 142.132.231.194 cp03-de-fsn1-dc14 <none> <none>
kube-flannel-ds-s55mk 1/1 Running 0 6m40s 49.12.234.236 cp01-de-nbg1-dc3 <none> <none>
kube-proxy-8g8kl 1/1 Running 1 (13m ago) 21m 142.132.231.194 cp03-de-fsn1-dc14 <none> <none>
kube-proxy-9smqr 1/1 Running 0 11m 49.12.74.234 node01-de-fsn1-dc14 <none> <none>
kube-proxy-9vc92 1/1 Running 2 (14m ago) 50m 49.12.234.236 cp01-de-nbg1-dc3 <none> <none>
kube-proxy-ck7ch 1/1 Running 1 (13m ago) 27m 49.12.192.3 cp02-de-nbg1-dc3 <none> <none>
kube-scheduler-cp01-de-nbg1-dc3 1/1 Running 2 (14m ago) 42m 49.12.234.236 cp01-de-nbg1-dc3 <none> <none>
kube-scheduler-node01-de-fsn1-dc14 1/1 Running 0 11m 49.12.74.234 node01-de-fsn1-dc14 <none> <none>
[root::cp01-de-nbg1-dc3]
~:
Click to expand...

[root::cp01-de-nbg1-dc3]
~: kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
cp01-de-nbg1-dc3 Ready control-plane,master 44m v1.23.5 49.12.234.236 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-13-amd64 docker://20.10.14
cp02-de-nbg1-dc3 Ready <none> 29m v1.23.5 49.12.192.3 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-13-amd64 docker://20.10.14
cp03-de-fsn1-dc14 Ready <none> 23m v1.23.5 142.132.231.194 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-13-amd64 docker://20.10.14
node01-de-fsn1-dc14 Ready control-plane,master 14m v1.23.5 49.12.74.234 <none> Debian GNU/Linux 11 (bullseye) 5.10.0-13-amd64 docker://20.10.14
[root::cp01-de-nbg1-dc3]
~:
Click to expand...

Hast du vielleicht einen Rat für mich?
 
Aus dem regulären "get pods" kann man leider nicht viel ableiten. Poste mal den "describe pod", also hier
Bash: 
kubectl -n kube-system describe pod/coredns-64897985d-f5csq

Beachte dass Events nicht ewig gehalten werden, im Zweifelsfall musst du den Pod einfach deleten und die Events des neuen Pods verfolgen falls er schon lange hängt.
 
You must log in or register to reply here.
Back
Top