Flatcar - ContainerD - systemd cgroup driver

Fórumok

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...

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?

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.

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.)