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

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