Sziasztok!
A tárgyban szereplő szentháromságot szeretném megugorni, Kubernetes kapcsán, kezdésképp egy single node-dal is beérném.
A kuberntes.io-n eléggé jó leírás van arra, ha kubeadm-mel szeretnék tevékenykedni, tiszta sor, megfelel.
Viszont abban a pillanatban, hogy a CRI kapcsán szeretném a dockert kivenni a képből, indulnak a gondok.
Nem világos több ponton sem.
1, kell-e, és ha igen, hogyan célszerű tiltani a Docker-t Flatcar linuxon?
- elég-e ha csak szimplán disabled-re állítom a docker.service-t, és a docker.socket-et?
- le kell a service-eket mask-olni esetleg?
2, Containerd beállításai: Ha jól értem, rá kell vegyem a containerd-t hogy systemd legyen a cgroup driver.
itt is elég jó leírás van a kubernetes.io-n a linux disztrókhoz, kivéve flatcar linux.
Flatcar-on ugye alapból fent van a containerd (pontosabban a docker), szuper. Csak épp a containerd konfigurációja
köszönő viszonyban sincs a kubernetes.io-n látottakkal.
a /run/torcx/unpack/docker/usr/share/containerd/config.toml tartalma igen kevés ahhoz képest, ha kigenerálom a containerd config-ot
egy külön fileba, és nem is igazán látom, hogyan tudnám /run/torcx/unpack/docker/usr/share/containerd/config.toml ben megaadni amit kellene.
A read-only mivoltát azzal kezeltem, hogy mostmár az /etc alól kapja a containerd a config.toml-t, de azt nem látom hogyan varzsolom bele az alábbiakat:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
3, Kubelet:
Elviekben, az alábbi két kiegészítés kell a kubeletnek. Gondolom ez megfelel ha a systemd unit fileban landol. (a megfelelő helyre )
--container-runtime=remote
--container-runtime-endpoint=unix:///run/containerd/containerd.sock
4, kubeadm init --config xxx.yml --cri-socket /run/containerd/containerd.sock
Flatcar okán, kell neki némi előkészület mivel a "/usr" read-only, ez oké is.
Érdemes, és/vagy kell-e egyáltalán a kubeadm init configjába további kiegészítésként betenni:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
Vagy inkább még a 3as pontban inkább a kubelet service-ébe menjen a "--cgroup-driver=systemd" ? Így fel fogja ismerni a kubeadm init?
Elviekben ha nem totál f*ság amit összehadováltam, akkor ennek így mennie kell/kellene?
PS: A google is csak egy darabig barát...
- 150 megtekintés
Hozzászólások
Igazából mi a célod?
a CRI kapcsán szeretném a dockert kivenni a képből
Miért akarod kivenni? Miért fáj, hogy van ott egy komponens, ami lehetővé teszi, hogy a jól bevált docker CLI paranccsal szétnézzél és debuggoljál a gépen?
- A hozzászóláshoz be kell jelentkezni
Mi a célom?
Idézem a kubernetes.io-ról...."Kubernetes is deprecating Docker as a container runtime after v1.20."
Annyit sikerült elérni, hogy már a containerd van használatban.
Már csak a cgroup driver kérdéskör maradt.
- A hozzászóláshoz be kell jelentkezni
Oké, de ez egy bullshitelés a k8s community részéről.
Ugyanis a containerd maga a Docker (egyik fele). Választhatsz, hogy az egész Dockert rakod fel, containerd-stül - és akkor lesz CLI toolod is hozzá, vagy csak azt a felét, ami a Kubernetesnek kell, ebben az esetben annyi változás történik, hogy elesel egy troubleshooting tooltól. Az az opció évek óta nem létezik, hogy "Docker, amibe úgy van beépítve a containerd funkcionalitás, hogy nem is látod önálló csomagként és nincs kivezetve az API-ja".
már a containerd van használatban
Emiatt ez egy látszólagos "tett", mivel ez egy friss (értsd: nem évekkel lemaradt) Dockerrel nem tud máshogy lenni.
- A hozzászóláshoz be kell jelentkezni
oké. pontosítok.
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration…
2018 közepe óta bullshit ezek szerint.
Neked szimpi a docker, másnak meg nincs rá szüksége. ennyi. Sem a CLI toolra, mert még user sincs a linuxon, amivel bejelentkezzek. De még az ssh is tiltva van.
(arról meg tényleg ne nyissunk már vitát, hogy a containerd maga a docker vagy sem. Mert már régóta nem, ezt te is tudod.)
- A hozzászóláshoz be kell jelentkezni