Cri-o podman et Kubernetes

VINDICATORs · 02/04/2020 11:45:02

Bon ne reste qu'une histoire de création de bridge qui n'apparait pas :

[root@localhost ~]# ifconfig
enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.122.125  netmask 255.255.255.0  broadcast 192.168.122.255
        inet6 fe80::80d4:dabd:f3d0:caa1  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:a3:e5:83  txqueuelen 1000  (Ethernet)
        RX packets 1296  bytes 99712 (97.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1384  bytes 190381 (185.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Boucle locale)
        RX packets 1670  bytes 83500 (81.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1670  bytes 83500 (81.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@localhost ~]#

Du coup il ne lance pas les containers dans cri-o.

VINDICATORs · 02/04/2020 16:25:48

Allez petit test avec cri-o tout seul histoire de voir si en fait ce n'est pas lui qui avait un souci.

Du coup il y a bien un problème avec "runc" qui n'est pas compatible avec les cgroup (du moins sur les versions Fedora31/32/Rawhide/Koji) "systemd" et aussi "cgroupv2". Du coup j'ai ajouté :

sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

Reboot de la machine, vérification du CNI (/etc/cni/net.d/... ou chez moi /etc/crio/net.d/...) ....

ET TADAM !!!!! :

[root@localhost ~]# crictl pods
POD ID              CREATED             STATE               NAME                NAMESPACE           ATTEMPT
53a55cb3b8e1a       2 minutes ago       Ready               podsandbox1         redhat.test.crio    1

Plus qu'a tester avec kubernetes en plus et je vais pouvoir avancer sur ce sujet.

VINDICATORs · 03/04/2020 16:39:49

Bon après maintes reprise, je suis enfin parvenu à une procédure valable :) :

[root@kube ~]# kubeadm init --pod-network-cidr=10.244.0.0/16
W0403 16:30:25.669713    1476 configset.go:202] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
[init] Using Kubernetes version: v1.18.0
[preflight] Running pre-flight checks
        [WARNING Firewalld]: firewalld is active, please ensure ports [6443 10250] are open or your cluster may not function correctly
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kube.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.122.125]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kube.localdomain localhost] and IPs [192.168.122.125 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kube.localdomain localhost] and IPs [192.168.122.125 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
W0403 16:30:45.951002    1476 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[control-plane] Creating static Pod manifest for "kube-scheduler"
W0403 16:30:45.951750    1476 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 24.510350 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node kube.localdomain as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kube.localdomain as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: zbbipu.24zaez8ua3egofz7
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.122.125:6443 --token zbbipu.24zaez8ua3egofz7 \
    --discovery-token-ca-cert-hash sha256:f24883015c05ba7f35fe33a1cf90caa5f485aed0e4bb3dd5cac1acddf308fce4

Je vais voir pour reproduire les étapes, je mettrais en résolu avec ce que j'ai fait si cela intérresse quelqu'un.

Cela vas être une bonne base pour la suite.
Je vais voir si je peux récupérer une version de "runc" qui supporte les cgroupv2, voir si je peux avoir plus d'info à ce sujet.

Par contre je suis partis sur la version officiel de kubernetes et non sur la version proposé sur les dépôts Fedora qui commence à dater.

J'ai suivi en grande partie la procédure fournis ici :
https://kubevirt.io/2019/KubeVirt_k8s_c … ratch.html
Je dis en grande partie car il a fallu que je manipule cri-o directement pour voir que ce n'était déjà pas fonctionnel à ce niveau.
J'ai aussi installé fuse-overlay pour utiliser overlay v2 plutôt que vfs par défaut. Il y aura plus de possibilité avant de voir si c'est utile en l'état d'utiliser autre chose.

Enfin bon c'est déjà un bon début d'arriver à comprendre où cela bloqué.

Maintenant :

[root@kube ~]# kubectl get nodes
NAME               STATUS   ROLES    AGE     VERSION
kube.localdomain   Ready    master   9m17s   v1.18.0
[root@kube ~]#

A voir ce week end avec l'introduction du deuxième noeud en machine virtuel avant de passer en prod perso wink .

VINDICATORs · 04/04/2020 12:13:35

Bon voilà j'ai reproduit la procédure sur 2 nœuds, restera plus qu'a manipuler plus loin. J'espère pouvoir enfin utiliser les cgroupv2, ainsi que de réactiver selinux par la suite.

Donc voici le descriptif de ce que j'ai fait pour rendre fonctionnel kubernetes avec cri-o :
C'est à faire sur tout les nœuds, sauf la partie :

Et on lance l'initialisation de notre kubernetes sur le premier nœud (master de base):
kubeadm init --pod-network-cidr=10.244.0.0/16

Il est nécessaire de rajouter "sudo" aux commande si vous n'êtes pas avec le compte root "su -"!

Étape 1 : installation de cri-o et préparation de la machine :

dnf module install cri-o:1.17/default -y
dnf install fuse*overlay* -y
grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

On édite le crio.conf :

vi /etc/crio/crio.conf

On modifie le storage_driver et on rajoute storage_option :

# Storage driver used to manage the storage of images and containers. Please
# refer to containers-storage.conf(5) to see all available storage drivers.
storage_driver = "overlay"

# List to pass options to the storage driver. Please refer to
# containers-storage.conf(5) to see all available storage options.
#storage_option = [
#]
storage_option = [ "overlay2.override_kernel_check=1" ]

Mais aussi :

[crio.network]


# Path to the directory where CNI configuration files are located.
#network_dir = "/etc/cni/net.d"
network_dir = "/etc/crio/net.d/"

Ainsi que :

# Cgroup management implementation used for the runtime.
cgroup_manager = "cgroupfs"

On modifie la valeur du Storage Driver dans :

vi /etc/containers/storage.conf

# Default Storage Driver
driver = "overlay2"

On désactive selinux :

sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

On ajoute les ports nécessaires au pare feu :

[root@kube02 ~]# firewall-cmd --permanent --add-port={6443,2379,2380,10250,10251,10252}/tcp --add-port=30000-32767/tcp && firewall-cmd --permanent --add-service=http --add-service=https && firewall-cmd --reload

On désactive le swap (je n'aime pas, ce n'est pas nécessaire, mais il est nécessaire de rajouter une option à chaque fois pour ne pas que kubeadm bloque):

swapoff -a

Ne pas oublier de commenter la ligne qui concerne le swap dans /etc/fstab

On active le mode bridge et autres options pour sysctl :

cat > /etc/sysctl.d/99-kubernetes-cri.conf <<EOF
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

On active br_netfilter et overlay :

modprobe br_netfilter
echo br_netfilter > /etc/modules-load.d/br_netfilter.conf
modprobe overlay
echo overlay > /etc/modules-load.d/overlay.conf

On dit à sysctl de tout prendre en compte :

sysctl -p/etc/sysctl.d/99-kubernetes-cri.conf

Perso je préfère directement faire un :

sysctl --system

On crée le fichier /etc/default/kubelet avec ce qui suit :

vi /etc/default/kubelet

KUBELET_EXTRA_ARGS=--feature-gates="AllAlpha=false,RunAsGroup=true" --container-runtime=remote --cgroup-driver=cgroupfs --container-runtime-endpoint='unix:///var/run/crio/crio.sock' --runtime-request-timeout=5m

On ajoute le dépôt kubernetes :

vi /etc/yum.repos.d/kubernetes.repo

Avec :

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

On importe la clef :

rpm --import https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

on renomme le fichier des paramètres réseaux de crio :

mv /etc/cni/net.d/100-crio-bridge.conf /etc/cni/net.d/10-crio-bridge.conf

On modifie le fichier :

sed -i 's/10.88.0.0/10.244.0.0/g' /etc/cni/net.d/10-crio-bridge.conf

On copie le dossier net.d dans :

cp -r -f /etc/cni/net.d /etc/crio/

on reboot :

reboot

Une fois rebooté :

systemctl enable --now crio
dnf install kubelet kubeadm kubectl
systemctl enable --now kubelet

On active l'autocompletion pour kubectl :

echo 'source <(kubectl completion bash)' >>~/.bashrc
kubectl completion bash >/etc/bash_completion.d/kubectl
echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -F __start_kubectl k' >>~/.bashrc

On ajoute nos hosts dans /etc/hosts par exemple (à faire sur tout les noeuds si l'on a pas de serveur DNS ):

vi /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.122.125 kube.localdomain kube
192.168.122.126 kube02.localdomain kube02

Et on lance l'initialisation de notre kubernetes sur le premier nœud (master de base):

kubeadm init --pod-network-cidr=10.244.0.0/16

On copie le résultat dans un fichier texte ou autres à la fin, par exemple :

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.122.125:6443 --token zbbipu.24zaez8ua3egofz7 \
    --discovery-token-ca-cert-hash sha256:f24883015c05ba7f35fe33a1cf90caa5f485aed0e4bb3dd5cac1acddf308fce4

Le kubeadm join permettra de rajouter des noeuds à notre cluster kubernetes.
C'est donc à faire en plus, exemple :

kubeadm join 192.168.122.125:6443 --token zbbipu.24zaez8ua3egofz7 \
    --discovery-token-ca-cert-hash sha256:f24883015c05ba7f35fe33a1cf90caa5f485aed0e4bb3dd5cac1acddf308fce4

Ne reste plus qu'a faire :

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

On lance la commande "kubectl get nodes" pour vérifier que notre/nos noeud(s) sont bien prit en compte :

[root@kube ~]# kubectl get nodes
NAME               STATUS   ROLES    AGE     VERSION
kube.localdomain   Ready    master   9m17s   v1.18.0
[root@kube ~]#

Voilà, a savoir que c'est une installation "primaire", il reste pas mal de travail à fournir pour avoir quelque chose de complet. Mais bon en l'état c'est déjà un bon début.

Je n'ai pas trouvé de solution pour utiliser la version fourni par Fedora directement. Je pense qu'il y a un gros travail sur le paramètrage à faire pour que ce soit fonctionnel. A voir si avec les différentes modification apporté à la procédure ci-dessus n'est pas la piste à suivre.

J'espère que cela aidera les personnes qui souhaitent mettre cela en place, si il y du monde je pense créer une doc quand j'aurai plus d'experience sur le sujet.

VINDICATORs · 06/04/2020 13:58:00

J'ai corrigé une coquille,

Il manque le (a confirmer, je refais la procédure de zéro pour ce faire!!!) :
cgroup_manager = "cgroupfs"

dans /etc/crio/crio.conf

J'ai aussi corrigé une coquille avec le firewall.

VINDICATORs · 27/04/2020 10:15:51

Petite piste à creuser pour pouvoir utiliser les "cgroupv2".

Il faudrait remplacer "runc" par "crun" qui les gèrent en plus d'être plus performant.

Donc je remet ce sujet en non résolu le temps de voir si cela peut ce faire.

Quelqu'un à déjà manipuler "crun"?

Je sais que c'est utilisé par podman, je pensé pas que c'était encore le cas avec cri-o par défaut.

Édit : Bon c'est à cause de "containerd" qui ne gère pas encore les cgroupv2. Du moins il n'y a pas de paquets officiels pour cela.

VINDICATORs · 27/05/2020 13:42:11

Je continue mes expérimentations avec cri-o. Vu que cela ne semble pas courant je taff de mon coté du coup un peu tout seul sur le sujet...

J'explore actuellement la piste "crun" en lieu et place de "runc" pour pouvoir utiliser les "cgroupv2".
Reste à bien gérer "selinux" pour pouvoir le réactiver.

Pour le moment cela semble bien parti, reste à voir du coté de kubernetes comment il accepte la chose.

D'ailleurs la version 1.18 devrait arriver pour Fedora33 (actuellement en rawhide).

A suivre...

Monte · 23/09/2020 14:02:24

Super, un grand merci pour la procédure. Top!

J'ai essayé avec une Fedora 32S et Calico pour le réseau, mais impossible de faire fonctionner correctement la partie réseau: la communication vers un pod d'un autre node ne passe pas, Calico ne créée pas les interfaces cali*...

As tu essayé de déployer un service sur ton cluster Fedora pour vérifier la partie réseau ?

Fedora-Fr - Communauté francophone Fedora - Linux

#26 02/04/2020 11:45:02

Re : Cri-o podman et Kubernetes

#27 02/04/2020 16:25:48

Re : Cri-o podman et Kubernetes

#28 03/04/2020 16:39:49

Re : Cri-o podman et Kubernetes

#29 04/04/2020 12:13:35

Re : Cri-o podman et Kubernetes

#30 06/04/2020 13:58:00

Re : Cri-o podman et Kubernetes

#31 27/04/2020 10:15:51

Re : Cri-o podman et Kubernetes

#32 27/05/2020 13:42:11

Re : Cri-o podman et Kubernetes

#33 23/09/2020 14:02:24

Re : Cri-o podman et Kubernetes

Pied de page des forums