Fedora-Fr - Communauté francophone Fedora - Linux

Communauté francophone des utilisateurs de la distribution Linux Fedora.

  

Dernière news : Fedora 30 est mort ce soir

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

VINDICATORs
RédactWikix and the graphicatorix!
Modérateur
Lieu : Toulouse(31) France
Inscription : 23/11/2004
Messages : 18 007
Site Web

Re : Cri-o podman et Kubernetes

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.


AMD R7 2700X, MSI Pro Carbon X470, 32Go DDR4 3200@3333Mhz Gskill TridentZ CL14, RX 5700XT MSI Watercooling OC
SSD: 1x 970 EVO NVME 500Go + 1x500Go BX500 + 1x500Go 860 EVO, 3x1To 860 Evo, HDD 1x2To WD black, 1x4to WD Black, 1x3To WD Red, GMT BeQuiet Dark 900+Lepa 800W 80+gold
AMD R5 2600, Asus A320, 16Go DDR4 2400Mhz Gskill AEGIS, 1x250GO SSD EVO, 3x 2To RAID 5 WD Blue, Gigabyte 400W+Cube Chieftec/ AMD R3 2200g + 8Go DDR4 2133+1xSSD Evo 500Go , 3x1To QVO RAID5

Hors ligne

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

VINDICATORs
RédactWikix and the graphicatorix!
Modérateur
Lieu : Toulouse(31) France
Inscription : 23/11/2004
Messages : 18 007
Site Web

Re : Cri-o podman et Kubernetes

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.


AMD R7 2700X, MSI Pro Carbon X470, 32Go DDR4 3200@3333Mhz Gskill TridentZ CL14, RX 5700XT MSI Watercooling OC
SSD: 1x 970 EVO NVME 500Go + 1x500Go BX500 + 1x500Go 860 EVO, 3x1To 860 Evo, HDD 1x2To WD black, 1x4to WD Black, 1x3To WD Red, GMT BeQuiet Dark 900+Lepa 800W 80+gold
AMD R5 2600, Asus A320, 16Go DDR4 2400Mhz Gskill AEGIS, 1x250GO SSD EVO, 3x 2To RAID 5 WD Blue, Gigabyte 400W+Cube Chieftec/ AMD R3 2200g + 8Go DDR4 2133+1xSSD Evo 500Go , 3x1To QVO RAID5

Hors ligne

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

VINDICATORs
RédactWikix and the graphicatorix!
Modérateur
Lieu : Toulouse(31) France
Inscription : 23/11/2004
Messages : 18 007
Site Web

Re : Cri-o podman et Kubernetes

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 .


AMD R7 2700X, MSI Pro Carbon X470, 32Go DDR4 3200@3333Mhz Gskill TridentZ CL14, RX 5700XT MSI Watercooling OC
SSD: 1x 970 EVO NVME 500Go + 1x500Go BX500 + 1x500Go 860 EVO, 3x1To 860 Evo, HDD 1x2To WD black, 1x4to WD Black, 1x3To WD Red, GMT BeQuiet Dark 900+Lepa 800W 80+gold
AMD R5 2600, Asus A320, 16Go DDR4 2400Mhz Gskill AEGIS, 1x250GO SSD EVO, 3x 2To RAID 5 WD Blue, Gigabyte 400W+Cube Chieftec/ AMD R3 2200g + 8Go DDR4 2133+1xSSD Evo 500Go , 3x1To QVO RAID5

Hors ligne

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

VINDICATORs
RédactWikix and the graphicatorix!
Modérateur
Lieu : Toulouse(31) France
Inscription : 23/11/2004
Messages : 18 007
Site Web

Re : Cri-o podman et Kubernetes

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.


AMD R7 2700X, MSI Pro Carbon X470, 32Go DDR4 3200@3333Mhz Gskill TridentZ CL14, RX 5700XT MSI Watercooling OC
SSD: 1x 970 EVO NVME 500Go + 1x500Go BX500 + 1x500Go 860 EVO, 3x1To 860 Evo, HDD 1x2To WD black, 1x4to WD Black, 1x3To WD Red, GMT BeQuiet Dark 900+Lepa 800W 80+gold
AMD R5 2600, Asus A320, 16Go DDR4 2400Mhz Gskill AEGIS, 1x250GO SSD EVO, 3x 2To RAID 5 WD Blue, Gigabyte 400W+Cube Chieftec/ AMD R3 2200g + 8Go DDR4 2133+1xSSD Evo 500Go , 3x1To QVO RAID5

Hors ligne

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

VINDICATORs
RédactWikix and the graphicatorix!
Modérateur
Lieu : Toulouse(31) France
Inscription : 23/11/2004
Messages : 18 007
Site Web

Re : Cri-o podman et Kubernetes

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.


AMD R7 2700X, MSI Pro Carbon X470, 32Go DDR4 3200@3333Mhz Gskill TridentZ CL14, RX 5700XT MSI Watercooling OC
SSD: 1x 970 EVO NVME 500Go + 1x500Go BX500 + 1x500Go 860 EVO, 3x1To 860 Evo, HDD 1x2To WD black, 1x4to WD Black, 1x3To WD Red, GMT BeQuiet Dark 900+Lepa 800W 80+gold
AMD R5 2600, Asus A320, 16Go DDR4 2400Mhz Gskill AEGIS, 1x250GO SSD EVO, 3x 2To RAID 5 WD Blue, Gigabyte 400W+Cube Chieftec/ AMD R3 2200g + 8Go DDR4 2133+1xSSD Evo 500Go , 3x1To QVO RAID5

Hors ligne

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

VINDICATORs
RédactWikix and the graphicatorix!
Modérateur
Lieu : Toulouse(31) France
Inscription : 23/11/2004
Messages : 18 007
Site Web

Re : Cri-o podman et Kubernetes

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.


AMD R7 2700X, MSI Pro Carbon X470, 32Go DDR4 3200@3333Mhz Gskill TridentZ CL14, RX 5700XT MSI Watercooling OC
SSD: 1x 970 EVO NVME 500Go + 1x500Go BX500 + 1x500Go 860 EVO, 3x1To 860 Evo, HDD 1x2To WD black, 1x4to WD Black, 1x3To WD Red, GMT BeQuiet Dark 900+Lepa 800W 80+gold
AMD R5 2600, Asus A320, 16Go DDR4 2400Mhz Gskill AEGIS, 1x250GO SSD EVO, 3x 2To RAID 5 WD Blue, Gigabyte 400W+Cube Chieftec/ AMD R3 2200g + 8Go DDR4 2133+1xSSD Evo 500Go , 3x1To QVO RAID5

Hors ligne

Pied de page des forums