Tutoriel : Mettre à niveau la version Kubernetes d’un cluster

Le but de ce tutoriel est de présenter les différentes étapes que vous devez compléter pour mettre à niveau la version Kubernetes de l’un de vos clusters.

Lorsque vous créez un cluster, OKS utilise par défaut la dernière version de Kubernetes prise en charge. Cependant, les clusters existants ne sont pas automatiquement mis à niveau vers les nouvelles versions mineures de Kubernetes. Lorsque OKS prend en charge une nouvelle version mineure, vous devez mettre à niveau le control plane de votre cluster manuellement. Vous devez également mettre à niveau les node pools associés pour qu’ils utilisent la même version de Kubernetes que le control plane.

Lorsque vous mettez un cluster à niveau, vous pouvez préciser quelle version majeure et mineure utiliser, tandis que la version de patch est toujours la plus récente prise en charge par OKS. Pour en savoir plus sur les versions de Kubernetes prises en charge, voir À propos d’OKS > Versions Kubernetes prises en charge.

Si la stratégie de mise à niveau automatique est activée, vos clusters sont automatiquement mis à niveau vers la dernière version de patch prise en charge par OKS pendant leur fenêtre de maintenance.

  • Vous ne pouvez pas changer la version d’un cluster pour une version antérieure. Si vous voulez utiliser une version antérieure de Kubernetes, vous devez créer un nouveau cluster avec cette version.

  • Vous ne pouvez mettre à niveau un cluster que d’une version mineure à la fois. Par exemple, vous pouvez faire passer votre cluster de la version 1.30 à la 1.31, mais vous ne pouvez pas passer directement à la version 1.32. Si vous voulez faire passer votre cluster de la version 1.30 à la version 1.32, vous devez mettre votre cluster à jour et à niveau vers la version 1.31, puis répéter le processus pour passer en version 1.32.

Mettre à niveau vers une nouvelle version majeure ou mineure de Kubernetes

Avant de commencer

Récupérer la version Kubernetes de votre cluster avec OKS CLI

Avant de mettre à jour le control plane de votre cluster, vous devez identifier quelle version de Kubernetes est utilisée par votre cluster, et vers quelle version suivante de Kubernetes votre cluster peut être mis à niveau. Pour obtenir cette information, utilisez la commande cluster get en suivant cette syntaxe :

Exemple de requête
$ oks-cli cluster get \
    --cluster-name NAME_OF_CLUSTER \
    --project-name NAME_OF_PROJECT \
    --output json

Cette commande contient les options suivantes que vous devez spécifier :

  • cluster-name : Le nom du cluster sur lequel vous voulez obtenir des informations.

  • project-name : Le nom du projet contenant le cluster.

  • (optionnel) output : Le format de sortie de la réponse (json | yaml). Par défaut, le format de la réponse est JSON.

La commande cluster get renvoie des informations sur le cluster spécifié, y compris :

  • version : La version de Kubernetes actuellement déployée sur le cluster.

  • available_upgrade : La version de Kubernetes disponible pour mise à niveau (si une version de Kubernetes plus récente est prise en charge par OKS CLI).

Exemple de résultat
{
...
    "version": "1.28",
    "statuses": {
        "created_at": "2026-02-19T10:45:40.677486Z",
        "updated_at": "2026-02-19T10:52:42.303192Z",
        "status": "ready",
        "available_upgrade": "1.29"
    }
}

Mettre à jour la version Kubernetes du control plane avec OKS CLI

Après avoir récupéré la version de Kubernetes utilisée par votre cluster, vous devez mettre à jour le control plane de votre cluster avec la version de Kubernetes disponible pour la mise à niveau. Pour ce faire, utilisez la commande cluster update en suivant cette syntaxe :

Exemple de requête
$ oks-cli cluster update \
    --project-name NAME_OF_PROJECT \
    --cluster-name NAME_OF_CLUSTER \
    --version KUBERNETES_VERSION \
    --output json

Cette commande contient les options suivantes que vous devez spécifier :

  • cluster-name : Le nom du cluster que vous voulez mettre à jour.

  • project-name : Le nom du projet contenant le cluster.

  • version : La version de Kubernetes à utiliser pour le cluster.

  • (optionnel) output : Le format de sortie de la réponse (json | yaml). Par défaut, le format de la réponse est JSON.

La commande cluster update renvoie des informations sur le cluster mis à jour, y compris la version actuelle et la version attendue après la mise à niveau :

  • version : La version de Kubernetes actuellement déployée sur le cluster.

  • statuses : Les informations d’état du cluster.

    • created_at : La date et l’heure de création du cluster.

    • updated_at : La date et l’heure de dernière mise à jour du cluster.

    • status : L’état du cluster.

    • available_upgrade : La version de Kubernetes disponible pour mise à niveau.

Exemple de résultat
{
...
    "version": "1.28",
    "statuses": {
        "created_at": "2026-02-19T10:45:40.677486Z",
        "updated_at": "2026-02-23T10:51:36.614823Z",
        "status": "pending",
        "available_upgrade": "1.29"
    }
}

Vous pouvez utiliser la commande cluster get pour obtenir des informations sur le cluster que vous mettez à jour, y compris sa version de Kubernetes prévue. L’état de votre cluster passera de pending à updating, puis ready.

Exemple de résultat
{
...
    "statuses": {
        "created_at": "2026-02-19T10:45:40.677486Z",
        "updated_at": "2026-02-23T10:56:38.783584Z",
        "status": "ready",
        "available_upgrade": "1.29"
    }
}

Mettre à niveau la version Kubernetes du control plane avec OKS CLI

Après avoir mis à jour le control plane du cluster, vous pouvez lancer la mise à niveau planifiée en utilisant la commande cluster upgrade selon la syntaxe suivante :

Exemple de requête
$ oks-cli cluster upgrade \
    --project-name NAME_OF_PROJECT \
    --cluster-name NAME_OF_CLUSTER \
    --output json

Cette commande contient les options suivantes que vous devez spécifier :

  • cluster-name : Le nom du cluster que vous voulez mettre à niveau.

  • project-name : Le nom du projet contenant le cluster.

  • (optionnel) output : Le format de sortie de la réponse (json | yaml). Par défaut, le format de la réponse est JSON.

Vous êtes invités à confirmer la mise à niveau dans le terminal. Des informations sur votre cluster sont renvoyées pour confirmer que votre cluster est en cours de mise à niveau vers la version spécifiée à l’étape précédente :

Exemple de résultat
{
...
    "version": "1.28",
    "expected_version": "1.29",
    "statuses": {
        "created_at": "2026-02-19T10:45:40.677486Z",
        "deleted_at": null,
        "updated_at": "2026-02-24T08:27:37.887467Z",
        "status": "pending",
        "available_upgrade": "1.29"
    }
}

Si vous utilisez de nouveau la commande cluster get, l’état de votre cluster passera de pending à upgrading, puis ready.

Mettre à niveau les worker nodes du cluster avec kubectl

Après avoir mis à niveau la version Kubernetes du control plane de votre cluster, vous devez également mettre à niveau vos worker nodes vers cette même version.

Pour assurer une performance optimale, la différence entre la version du control plane et des worker nodes d’un cluster ne doit pas être de plus d’une version mineure.

Par défaut, un nouveau worker node utilise la même version de Kubernetes que le control plane du cluster.

Les worker nodes peuvent soit se mettre à niveau automatiquement si leur stratégie de mise à niveau le permet, soit être mis à niveau manuellement.

Vérifier si la stratégie de mise à niveau automatique est activée

Par défaut, la stratégie de mise à niveau automatique est activée pour les clusters OKS et leurs worker nodes. Pour vérifier si ce paramètre vaut true, utilisez la commande kubectl get nodepools en suivant cette syntaxe :

Exemple de requête
$ kubectl get nodepools \
    --output json

L’option output vous permet de choisir entre json et yaml.

La commande kubectl get nodepools renvoie des informations sur la stratégie de mise à niveau de vos node pools :

  • autoUpgradeEnabled : Si true, indique que la statégie de mise à niveau automatique est activée.

  • autoUpgradeMaintenance : Informations sur la stratégie de mise à niveau automatique.

    • durationHours : Durée de la fenêtre de maintenance, en heures. Pendant cette période, les mises à niveau sont autorisées à s’exécuter.

    • startHour : Heure de début de la fenêtre de maintenance, au format 24 heures (0–23).

    • weekDay : Jour de la semaine auquel la fenêtre de maintenance s’applique.

Exemple de résultat
{
...
                "upgradeStrategy": {
                    "autoUpgradeEnabled": true,
                    "autoUpgradeMaintenance": {
                        "durationHours": 1,
                        "startHour": 12,
                        "weekDay": "Tue"
                    }
                }
}

Si la mise à niveau automatique est activée, les worker nodes seront automatiquement mis à niveau vers la version Kubernetes du control plane à la date et à l’heure indiquées.

Vous pouvez modifier votre stratégie de mise à niveau à l’aide d’un manifeste de stratégie de mise à niveau. Pour en savoir plus, voir Référence des manifestes de node pool.adoc > Manifeste de stratégie de mise à niveau.

Mettre à niveau les worker nodes manuellement

Pour mettre à niveau manuellement les worker nodes existants, vous devez les drainer puis les supprimer du cluster, un par un. Un nouveau worker node sera alors automatiquement créé pour remplacer le précédent.

Si la stratégie de mise à jour automatique est désactivée et si vous ne mettez pas à niveau vos worker nodes manuellement, ces worker nodes ne seront jamais mis à niveau vers la version de Kubernetes prévue.

  1. Utilisez la commande kubectl get nodes pour obtenir la liste des worker nodes présents dans votre cluster :

    Exemple de résultat
    NAME              STATUS   ROLES    AGE   VERSION
    ip-10-50-37-71    Ready    <none>   38m   v1.28.15
    ip-10-50-59-102   Ready    <none>   38m   v1.28.15
  2. Utilisez la commande kubectl drain en suivant cette syntaxe pour drainer un node :

    Exemple de requête
    $ kubectl drain NAME_OF_NODE --ignore-daemonsets --delete-emptydir-data

    Un message est renvoyé pour confirmer que le node est drainé.

    Exemple de résultat
    node/ip-12-34-54-78 cordoned
    ...
    node/ip-12-34-54-78 drained
  3. Utilisez la commande kubectl delete en suivant cette syntaxe pour supprimer le node précédemment drainé :

    Exemple de requête
    $ kubectl delete node NAME_OF_NODE

    Un message est renvoyé pour confirmer que le node est supprimé.

    Exemple de résultat
    node "NAME_OF_NODE" deleted

    Un nouveau node avec la version Kubernetes du control plane sera automatiquement créé pour remplacer le node supprimé. Ce processus peut prendre quelques minutes.

  4. Répétez les étapes 2 et 3 pour chaque node de votre node pool.

Mettre à niveau vers une nouvelle version de patch de Kubernetes

Avant de commencer

Vérifier si la stratégie de mise à niveau automatique est activée

Si la stratégie de mise à niveau automatique est activée pour votre cluster, celui-ci sera automatiquement mis à niveau vers la dernière version de patch prise en charge par OKS durant sa fenêtre de maintenance. Dans ce cas, vous n’avez pas à mettre à niveau votre cluster manuellement.

Pour vérifier que ce paramètre est activé, utilisez la commande cluster get en suivant cette syntaxe :

Exemple de requête
$ oks-cli cluster get \
    --cluster-name NAME_OF_CLUSTER \
    --project-name NAME_OF_PROJECT \
    --output json

Cette commande contient les options suivantes que vous devez spécifier :

  • cluster-name : Le nom du cluster sur lequel vous voulez obtenir des informations.

  • project-name : Le nom du projet contenant le cluster.

  • (optionnel) output : Le format de sortie de la réponse (json | yaml). Par défaut, le format de la réponse est JSON.

La commande cluster get renvoie des informations sur le cluster spécifié, y compris :

  • patch_upgrade_maintenance : Informations sur la fenêtre de maintenance pour les mises à niveau de patch, y compris :

    • enabled : Si true, indique que la statégie de mise à niveau automatique est activée.

    • duration_hours : Durée de la fenêtre de maintenance, en heures. Pendant cette période, les mises à niveau sont autorisées à s’exécuter.

    • start_hour : Heure de début de la fenêtre de maintenance, au format 24 heures (0–23).

    • week_day : Jour de la semaine auquel la fenêtre de maintenance s’applique.

    • tz : Le fuseau horaire pour la fenêtre de maintenance.

Exemple de résultat
{
...
        "patch_upgrade_maintenance": {
            "enabled": true,
            "duration_hours": 0,
            "start_hour": 12,
            "week_day": "Tue",
            "tz": "UTC"
        }

}

Si la mise à niveau automatique est activée, votre cluster et ses worker nodes seront automatiquement mis à niveau vers la dernière version de patch disponible.

Lancer une mise à niveau de patch manuellement

Si la stratégie de mise à niveau automatique est désactivée, ou si vous ne voulez pas attendre la fenêtre de maintenance définie, vous pouvez mettre à niveau votre cluster et ses worker nodes manuellement.

  1. Utilisez la commmande cluster update en suivant cette syntaxe pour préparer votre cluster à la mise à niveau :

    Exemple de requête
    $ oks-cli cluster update \
        --project-name NAME_OF_PROJECT \
        --cluster-name NAME_OF_CLUSTER
  2. Utilisez la commande cluster upgrade en suivant cette syntaxe pour mettre à niveau le control plane de votre cluster vers la dernière version de patch disponible, et confirmez que vous souhaitez poursuivre la mise à niveau :

    Exemple de requête
    $ oks-cli cluster upgrade \
        --project-name NAME_OF_PROJECT \
        --cluster-name NAME_OF_CLUSTER
  3. Utilisez la commande kubectl drain en suivant cette syntaxe pour drainer un node :

    Exemple de requête
    $ kubectl drain NAME_OF_NODE --ignore-daemonsets --delete-emptydir-data

    Un message est renvoyé pour confirmer que le node est drainé.

    Exemple de résultat
    node/ip-12-34-54-78 cordoned
    ...
    node/ip-12-34-54-78 drained
  4. Utilisez la commande kubectl delete en suivant cette syntaxe pour supprimer le node précédemment drainé :

    Exemple de requête
    $ kubectl delete node NAME_OF_NODE

    Un message est renvoyé pour confirmer que le node est supprimé.

    Exemple de résultat
    node "NAME_OF_NODE" deleted

    Un nouveau node avec la version Kubernetes du control plane sera automatiquement créé pour remplacer le node supprimé. Ce processus peut prendre quelques minutes.

  5. Répétez les étapes 3 et 4 pour chaque node de votre node pool.

Pages connexes