Testez clasele de rulare K8s și am declanșat cu succes unele pod-uri folosind containerd și gVisor.
Pentru a face asta, m-am schimbat /etc/containerd/config.toml de mai jos, apoi a repornit serviciul
disabled_plugins = ["reporniți"]
[plugins.linux]
shim_debug = adevărat
[plugins.cri.containerd.runtimes.runsc]
runtime_type = „io.containerd.runsc.v1”
Aceasta elimină default_runtime_name = "runc" config din configurația implicită care era în /etc/containerd/config.toml (care a fost generat inițial folosind implicit de configurare containerd înainte ca clusterul să fie construit cu kubeadm)
Apoi am creat o clasă de execuție pentru a utiliza runsc și am folosit-o în manifestul meu pod cu runtimeClassName: gvisor
apiVersion: node.k8s.io/v1beta1
fel: RuntimeClass
metadate:
nume: gvisor
handler: runsc
și apoi porniți în sfârșit un pod pentru a utiliza noua clasă de rulare
apiVersion: v1
fel: Pod
metadate:
nume: gvisor-pod
specificație:
runtimeClassName: gvisor
containere:
- nume: nginx
imagine: nginx
Dar bineînțeles dacă atunci fac un normal kubectl run pod1 --image nginx (adică fără a specifica runtimeClassName: gvisor într-un manifest pentru a-l face să folosească noua mea clasă de rulare), încă pornește bine folosind runc shim.
A per documentele
Dacă nu este specificat runtimeClassName, va fi folosit RuntimeHandler implicit,
care este echivalent cu comportamentul când caracteristica RuntimeClass este dezactivată.
Întrebarea mea este că fără default_runtime_name = "runc" în fișierul de configurare containerd, de unde știe kubelet/containerd încă să folosească runc atunci când o clasă de rulare/handler personalizat nu este specificat în manifestul pod? adică unde este asta RuntimeHandler implicit configurat?
