Pour des composants relativement simples comme kubectl ou kubelet, il suffit de compiler le code source Go et de remplacer directement les fichiers binaires existants dans /usr/bin. Cependant, certains composants, tels que l'apiserver, nécessitent le lancement d'un Pod pour leur exécution. Cela implique la compilation du code source modifié en une image Docker. Ce processus peut présenter des défis, c'est pourquoi nous allons documenter ici les étapes de compilation.

Configuration :

• Système d'exploitation : CentOS 7.6
• Version de Kubernetes : 1.20.0

Nous utiliserons le composant apiserver comme exemple.

Prérequis : vous disposez d'un cluster Kubernetes fonctionnel et vous avez cloné le code source de Kubernetes.

Méthode 1 : Utilisation de la chaîne de compilation Kubernetes

1. Modifier le code source selon vos besoins

Apportez les modifications nécessaires au code source.

2. Compiler l'image

Exécutez la commande suivante dans le répertoire racine du code source de Kubernetes :

KUBE_BUILD_PLATFORMS=linux/amd64 make quick-release WHAT=cmd/kube-apiserver

• KUBE_BUILD_PLATFORMS=linux/amd64 : spécifie la compilation d'une image pour Linux AMD64. Cette option pourrait être redondante car quick-release a déjà cet effet.
• quick-release : génère des images uniquement pour les systèmes 64 bits sous Linux, sans exécuter les tests, afin de réduire le temps de compilation.
• WHAT=cmd/kube-apiserver : limite la compilation au composant kube-apiserver.

Il est fréquent que cette commande échoue car elle dépend de trois images de base qui nécessitent un accès à Internet (contournement). Si vous utilisez un réseau d'entreprise avec un registre d'images interne, vous devrez peut-être modifier le fichier /data/gopath/src/k8s.io/kubernetes/build/common.sh.

À la ligne 46, vous trouverez une ligne similaire à :

readonly KUBE_BASE_IMAGE_REGISTRY="${KUBE_BASE_IMAGE_REGISTRY:-k8s.gcr.io/build-image}"

Remplacez k8s.gcr.io/build-image par l'URL de votre registre d'images accessible. Vous pouvez également rechercher des images appropriées sur Docker Hub, les télécharger localement et vérifier les messages d'erreur pour identifier les images manquantes et leurs versions correspondantes.

Les trois images de base couramment requises sont (les versions peuvent varier) :

k8s.gcr.io/build-image/go-runner:buster-v2.2.2
k8s.gcr.io/build-image/kube-cross:v1.15.5-1
k8s.gcr.io/build-image/debian-iptables:buster-v1.3.0

Assurez-vous que les images de base sont accessibles via docker pull ou téléchargez-les et modifiez leurs tags localement.

Après avoir résolu les dépendances des images, la commande make quick-release devrait s'exécuter sans erreur. En cas de problèmes persistants, examinez attentivement les messages d'erreur pour trouver une solution.

La compilation requiert des ressources matérielles importantes ; une machine avec 8 Go de RAM est recommandée. Le temps de compilation peut être long.

Les archives compressées des images compilées se trouveront dans kubernetes/_output/release-images/amd64/.

3. Déployer la nouvelle image

Copiez l'archive de l'image compilée sur le nœud master de votre cluster. Si votre cluster utilise Docker, vous pouvez charger l'image avec la commande docker load.

Pour les clusters utilisant containerd, utilisez :

sudo ctr -n=k8s.io images import <nom_archive>.tar

Vérifiez l'importation de l'image avec :

crictl images list

Une fois l'image importée avec succès, modifiez le fichier /etc/kubernetes/manifests/kube-apiserver.yaml. Mettez à jour le champ image avec le nom de votre nouvelle image. Le cluster Kubernetes redémarrera automatiquement le Pod apiserver dans les prochaines secondes.

Après le redémarrage, vérifiez l'état des Pods avec :

kubectl get pod -A

Des problèmes potentiels lors du redémarrage peuvent inclure :

• Q1: Unable to connect to the server: x509: certificate signed by unknown authority (...) : Supprimez le contenu de $HOME/.kube et réessayez.
• Q2: The connection to the server localhost:8080 was refused - did you specify the right host or port? : Essayez d'exécuter export KUBECONFIG=/etc/kubernetes/admin.conf.

En général, le système devrait fonctionner normalement avec la nouvelle image.

Méthode 2 : Création d'un Dockerfile personnalisé

La première méthode présente des inconvénients liés à la difficulté de trouver les images de base exactes et aux exigences matérielles pour la compilation. Cette deuxième méthode propose une alternative plus flexible.

Nous allons créer un Dockerfile pour l'apiserver. L'image de base requise, comme k8s.gcr.io/build-image/debian-iptables:buster-v1.3.0, peut être remplacée par n'importe quelle image de base Debian ou même d'autres distributions Linux comme CentOS.

1. Compiler le binaire de l'apiserver

Compilez le code source de l'apiserver pour obtenir le fichier binaire.

2. Créer un Dockerfile

Créez un fichier nommé Dockerfile avec le contenu suivant (adaptez l'image de base selon vos besoins) :

FROM k8s.gcr.io/build-image/debian-iptables:buster-v1.3.0
ADD apiserver /usr/local/bin/kube-apiserver
WORKDIR /usr/local/bin/

3. Construire l'image Docker

Exécutez la commande suivante dans le répertoire contenant le Dockerfile et le binaire compilé :

docker build . -t <nom_image>:<tag>

Par exemple : docker build . -t mon-apiserver:v1.20.0.

4. Déployer la nouvelle image

Chargez l'image constriute dans votre cluster (en utilisant docker load ou ctr images import selon votre runtime de conteneur) et modifiez le fichier /etc/kubernetes/manifests/kube-apiserver.yaml pour utiliser votre nouvelle image. Le cluster redémarrera automatiquement le Pod.