Pour éviter des erreurs qui s’accumuleraient tel que des éléments d’API disparus, révoqués ou obsolètes ou d’autres bugs concernant des versions intermédiaires, je vous conseille fortement d’effectuer vos mises à jour régulièrement (une fois par mois au minimum).
Mise à jour de K3s
Lors des mises à jour, vous retrouverez les logs soit au format syslog (si système compatible) donc dans /var/log/syslog ou via journalctl -f -u k3s soit dans /var/log/k3s.log. Les logs sont configurables via des options k3s.
Pour mettre à jour k3s, il suffit de récupérer les paramètres de votre cluster k3s sur votre master ou agent en allant les récupérer dans /etc/systemd/system/k3s.service et de refaire un curl sur get.k3s.io. Par exemple, dans mon k3s installé en mode « External DB » sous postgresql :
ExecStart=/usr/local/bin/k3s \
server \
'--datastore-endpoint=postgres://k3s:[email protected]:5432/k3s' \
--flannel-backend=none \
--disable-network-policy \
Ainsi, il faudra lancer la commande :
curl -sfL https://get.k3s.io | sh -s - server --datastore-endpoint='postgres://k3s:[email protected]:5432/k3s' --flannel-backend=none --disable-network-policy
Mise à jour de Rancher
De la même manière, on va récupérer les valeurs actuelles de votre déploiement Rancher via la commande :
helm repo update
helm fetch rancher-stable/rancher
helm get values rancher -n cattle-system > values.yaml
On modifie le fichier en question pour enlever la première ligne (« USER-SUPPLIED VALUES: »).
Puis on lance l’upgrade :
helm upgrade rancher rancher-stable/rancher --namespace cattle-system -f values.yaml
Exemple de fichier values :
hostname: rancher.pascal-mietlicki.fr
ingress:
tls:
source: letsEncrypt
letsEncrypt:
email: [email protected]
Mise à jour de Longhorn
Vous pouvez soit faire l’upgrade avec helm soit avec kubectl si vous avez des problèmes lors du déploiement, il vaut mieux effectuer les mises à jour intermédiaires (1.21 puis 1.2.X puis 1.30 puis 1.3.1 par exemple) :
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.3.1/deploy/longhorn.yaml
Pour information, si vous avez des problèmes la KB longhorn est très complète.
Mise à jour de Cert-manager
Vous pouvez soit faire l’upgrade avec helm soit avec kubectl si vous avez des problèmes lors du déploiement, il vaut mieux effectuer les mises à jour intermédiaires comme pour longhorn. Pour ma part, cela a été indispensable (v1.0.4 puis v1.1.1, etc.).
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.0.4/cert-manager.crds.yaml
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.0.4/cert-manager.yaml
Troubleshoot
J’ai eu divers soucis lors des différentes mises à jour que ce soit avec k3s, rancher ou cert-manager.
Problème « no endpoints available for service « rancher-webhook »
J’ai donc du forcer la rotation des webhook : https://github.com/rancher/rancher/issues/35068#issuecomment-954457381
kubectl get validatingwebhookconfiguration rancher.cattle.io -o yaml > vwc-rancher.cattle.io.yaml
kubectl get mutatingwebhookconfiguration rancher.cattle.io -o yaml > mwc-rancher.cattle.io.yaml
kubectl delete validatingwebhookconfiguration rancher.cattle.io
kubectl delete mutatingwebhookconfiguration rancher.cattle.io
Puis lorsque le webhook est de nouveau « healthy » :
kubectl apply -f vwc-rancher.cattle.io.yaml
kubectl apply -f mwc-rancher.cattle.io.yaml
Problème coredns « 8.8.8.8:53: i/o timeout » et pas de connectivité externe dans les pods
Le problème venait de flannel, même en ajoutant toutes les options possibles que ce soit dans iptables ou en désactivant le checksum via ethtool sur l’interface flannel.1 ou cni0 (ethtool -K flannel.1 tx-checksum-ip-generic off), rien n’a résolu le problème. Je crois que cela vient d’une incompatibilité avec un kernel Linux trop ancien. Un tcpdump -i any port 53 renvoyait des « ServFail » et je ne voyais rien passer dans l’interface flannel.1.
Passage à calico
J’ai ajouté les options « –flannel-backend=none –disable-network-policy » dans les options de démarrage de k3s (/etc/systemd/system/k3s.service) puis :
systemctl daemon-reload
systemctl restart k3s
Puis on peut suivre le quickstart : https://projectcalico.docs.tigera.io/getting-started/kubernetes/k3s/quickstart
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.1/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.24.1/manifests/custom-resources.yaml
Puis modifier le configmap « cni-config » du namespace « calico-system » en mettant :
"container_settings": {
"allow_ip_forwarding": true
}