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).
Table des matières
Mise à jour de K3s
Avant de mettre à jour K3S, vérifier la matrice de compatibilité sur : https://www.suse.com/fr-fr/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-5/ en adaptant le lien à la version de Rancher que vous souhaitez installer.
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.3.0 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
Pour connaitre la version actuellement installée, vous pouvez taper :
kubectl describe deployment -n cert-manager cert-manager
Vous pourrez alors voir la version dans la partie controller :
Containers:
cert-manager-controller:
Image: quay.io/jetstack/cert-manager-controller:v1.12.1
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
}
Pour ce faire vous avez la commande kubectl edit cni-config -n calico-system.
Problème calico, ip_forwarding repasse à false systématiquement
Pour résoudre définitivement le problème, vous pouvez modifier et appliquer le custom-resources.yaml modifié en intégrant l’option containerIPForwarding : « Enabled ».
wget https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml
# This section includes base Calico installation configuration.
# For more information, see: https://projectcalico.docs.tigera.io/v3.23/reference/installation/api#operator.tigera.io/v1.Installation
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
name: default
spec:
# Configures Calico networking.
calicoNetwork:
# Note: The ipPools section cannot be modified post-install.
ipPools:
- blockSize: 26
cidr: 192.168.0.0/16
encapsulation: VXLANCrossSubnet
natOutgoing: Enabled
nodeSelector: all()
containerIPForwarding: "Enabled"
---
# This section configures the Calico API server.
# For more information, see: https://projectcalico.docs.tigera.io/v3.23/reference/installation/api#operator.tigera.io/v1.APIServer
apiVersion: operator.tigera.io/v1
kind: APIServer
metadata:
name: default
spec: {}
Puis l’appliquer en faisant :
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml