For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/apiserver-flags-configuration.md.

Configurer les flags de l'API server sur un cluster OVHcloud Managed Kubernetes

Voir en Markdown

Découvrez comment configurer les composants managés de votre Kubernetes : CoreDNS, IPVS, et même les plugins d'admission de l'API server sur un cluster OVHcloud Managed Kubernetes

Objectif

Le service OVHcloud Managed Kubernetes vous fournit des clusters Kubernetes sans les contraintes liées à leur installation ou à leur exploitation. Chez OVHcloud, nous souhaitons vous proposer les meilleurs produits et services, c'est pourquoi nous vous donnons la possibilité de personnaliser les composants managés de votre Kubernetes : CoreDNS, IPVS, et même les plugins d'admission de l'API server à activer et désactiver sur vos clusters OVHcloud Managed Kubernetes.

Dans ce guide, nous allons vous montrer comment activer et désactiver les plugins d'admission de l'API server, mais vous pouvez suivre ce guide pour d'autres personnalisations de la configuration du cluster OVHcloud Managed Kubernetes.

Prérequis

  • Un cluster OVHcloud Managed Kubernetes

En pratique

Warning

Seul le plugin d'admission AlwaysPullImages est personnalisable pour le moment. Il est activé par défaut pour des raisons de sécurité, mais peut être désactivé pour éviter une utilisation excessive des registres Docker (par exemple pour éviter d'atteindre la limite de débit de téléchargement de Docker Hub). Le plugin d'admission NodeRestriction est activé par défaut et doit rester activé pour des raisons de sécurité.

Configurer les plugins d'admission de l'API server via l'API

L'Explorateur d'API

Pour simplifier les choses, nous utilisons l'Explorateur d'API, qui permet d'explorer, d'apprendre et d'interagir avec l'API de façon interactive.

Si vous accédez à la section Kubernetes de l'Explorateur d'API, vous verrez les endpoints disponibles, tels que :

GET/cloud/project/{serviceName}/kube

Endpoints de l'API

  • Obtenir la personnalisation d'un cluster existant :
GET/cloud/project/{serviceName}/kube/{kubeId}/customization

Résultat :

{
    "apiServer": {
        "admissionPlugins": {
            "disabled": [],
            "enabled": ["AlwaysPullImages", "NodeRestriction"]
        }
    }
}
  • Mettre à jour la personnalisation d'un cluster existant pour désactiver le plugin d'admission « AlwaysPullImages » (par exemple pour éviter que nos agents kubelet n'atteignent la limite de débit de téléchargement de Docker Hub) :
PUT/cloud/project/{serviceName}/kube/{kubeId}/customization
{
    "apiServer": {
        "admissionPlugins": {
            "enabled": ["NodeRestriction"],
            "disabled": ["AlwaysPullImages"]
        }
    }
}
Info

kubeProxy ne peut pas être modifié. Vous pouvez le définir uniquement à l'étape de création du cluster.

  • Créer un cluster Kubernetes dans la région GRA5 en désactivant le plugin d'admission « AlwaysPullImages » :
POST/cloud/project/{serviceName}/kube
{
    "region": "GRA5",
    "name": "my-super-cluster",
    "customization": {
        "apiServer": {
            "admissionPlugins": {
                "enabled": ["NodeRestriction"],
                "disabled": ["AlwaysPullImages"]
            }
        }
    }
}
  • Réinitialiser un cluster existant en désactivant le plugin d'admission « AlwaysPullImages » :
POST/cloud/project/{serviceName}/kube/{kubeId}/reset
{
    "customization": {
        "apiServer": {
            "admissionPlugins": {
                "enabled": ["NodeRestriction"],
                "disabled": ["AlwaysPullImages"]
            }
        }
    }
}

Configurer les plugins d'admission de l'API server via Terraform

Depuis la version 0.21 et supérieures de notre provider Terraform OVH, vous pouvez configurer votre cluster Kubernetes (flags de l'API server, CoreDNS, IPVS...) via Terraform.

Récupérer les informations de votre cluster et de vos tokens API

Le « provider OVH » doit être configuré avec un ensemble d'identifiants :

  • une application_key
  • un application_secret
  • une consumer_key

Pourquoi ?

Parce que, en arrière-plan, le « provider Terraform OVH » effectue des requêtes vers les API OVHcloud.

Pour récupérer ces informations nécessaires, suivez notre tutoriel Premiers pas avec les API OVHcloud.

Plus précisément, vous devez générer ces identifiants via la avec les droits suivants : GET, POST, PUT et DELETE sur /*.

Lorsque vous avez généré vos tokens OVHcloud avec succès, veillez à les enregistrer, car vous devrez les utiliser très prochainement.

La dernière information nécessaire est le service_name : il s'agit de l'identifiant de votre projet Public Cloud.

Comment l'obtenir ?

Dans la section Public Cloud, vous pouvez récupérer l'identifiant de votre service grâce au bouton Copier dans le presse-papier.

Vous utiliserez également cette information dans les fichiers de définition des ressources Terraform.

Instructions Terraform

Commencez par créer un fichier provider.tf avec la version minimale, l'endpoint européen (« ovh-eu ») et les clés précédemment récupérées dans ce guide.

Terraform 0.13 et versions ultérieures :

terraform {
  required_providers {
    ovh = {
      source  = "ovh/ovh"
    }
  }
}

provider "ovh" {
  endpoint           = "ovh-eu"
  application_key    = "<your_access_key>"
  application_secret = "<your_application_secret>"
  consumer_key       = "<your_consumer_key>"
}

Terraform 0.12 et versions antérieures :

# Configure the OVHcloud Provider
provider "ovh" {
  endpoint           = "ovh-eu"
  application_key    = "<your_access_key>"
  application_secret = "<your_application_secret>"
  consumer_key       = "<your_consumer_key>"
}

Les clés secrètes peuvent également être récupérées depuis votre environnement.

  • OVH_ENDPOINT
  • OVH_APPLICATION_KEY
  • OVH_APPLICATION_SECRET
  • OVH_CONSUMER_KEY

Cette dernière méthode (ou une alternative similaire) est recommandée pour éviter de stocker des données secrètes dans un dépôt source.

Nous avons ici défini l'endpoint ovh-eu, car nous souhaitons appeler l'API OVHcloud Europe, mais d'autres endpoints existent selon vos besoins :

  • ovh-eu pour l'API OVHcloud Europe
  • ovh-us pour l'API OVHcloud US
  • ovh-ca pour l'API OVHcloud Amérique du Nord

Ensuite, créez un fichier variables.tf avec service_name :

variable service_name {
  type        = string
  default     = "`<your_service_name>`"
}

Définissez les ressources que vous souhaitez créer dans un nouveau fichier nommé ovh_kube_cluster.tf :

resource "ovh_cloud_project_kube" "cluster" {
  service_name = var.service_name
  name         = "my-super-cluster"
  region       = "GRA5"
  version      = "1.31"

  customization {
    apiserver {
      admissionplugins{
        enabled = ["NodeRestriction"]
        disabled = ["AlwaysPullImages"]
      }
    }
  }
}

Dans cette configuration de ressources, nous demandons à Terraform de créer un cluster Kubernetes, dans la région GRA5, avec la version Kubernetes 1.31, tout en désactivant le plugin d'admission « AlwaysPullImages » (par exemple pour éviter que nos agents kubelet n'atteignent la limite de débit de téléchargement de Docker Hub).

Nous devons maintenant initialiser Terraform, générer un plan, puis l'appliquer.

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of ovh/ovh...
- Installing ovh/ovh v0.21.0...
- Installed ovh/ovh v0.21.0 (signed by a HashiCorp partner, key ID F56D1A6CBDAAADA5)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
[https://www.terraform.io/docs/cli/plugins/signing.html](https://www.terraform.io/docs/cli/plugins/signing.html)

Terraform has created a lock file `.terraform.lock.hcl` to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

La commande init initialise votre répertoire de travail qui contient les fichiers de configuration .tf.

C'est la première commande à exécuter pour une nouvelle configuration, ou après avoir effectué un checkout d'une configuration existante depuis un dépôt git par exemple.

La commande init va :

  • Télécharger et installer les providers/plugins Terraform
  • Initialiser le backend (si défini)
  • Télécharger et installer les modules (si définis)

Nous pouvons maintenant générer notre plan :

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # ovh_cloud_project_kube.cluster will be created
  + resource "ovh_cloud_project_kube" "cluster" {
      + control_plane_is_up_to_date = (known after apply)
      + id                          = (known after apply)
      + is_up_to_date               = (known after apply)
      + kubeconfig                  = (sensitive value)
      + name                        = "my-super-cluster"
      + next_upgrade_versions       = (known after apply)
      + nodes_url                   = (known after apply)
      + region                      = "GRA5"
      + service_name                = "xxxxxxxxxxxxxxxxxxxxx"
      + status                      = (known after apply)
      + update_policy               = (known after apply)
      + url                         = (known after apply)
      + version                     = "1.31"

      + customization {
          + apiserver {
              + admissionplugins {
                  + disabled = [
                      + "AlwaysPullImages",
                    ]
                  + enabled  = [
                      + "NodeRestriction",
                    ]
                }
            }
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

Grâce à la commande plan, nous pouvons vérifier ce que Terraform souhaite créer, modifier ou supprimer.

Le plan nous convient, appliquons-le donc :

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # ovh_cloud_project_kube.cluster will be created
  + resource "ovh_cloud_project_kube" "cluster" {
      + control_plane_is_up_to_date = (known after apply)
      + id                          = (known after apply)
      + is_up_to_date               = (known after apply)
      + kubeconfig                  = (sensitive value)
      + name                        = "my-super-cluster"
      + next_upgrade_versions       = (known after apply)
      + nodes_url                   = (known after apply)
      + region                      = "GRA5"
      + service_name                = "xxxxxxxxxxxxxxxxxxxxx"
      + status                      = (known after apply)
      + update_policy               = (known after apply)
      + url                         = (known after apply)
      + version                     = "1.31"

      + customization {
          + apiserver {
              + admissionplugins {
                  + disabled = [
                      + "AlwaysPullImages",
                    ]
                  + enabled  = [
                      + "NodeRestriction",
                    ]
                }
            }
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

ovh_cloud_project_kube.cluster: Creating...
ovh_cloud_project_kube.cluster: Still creating... [10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [20s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [30s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [40s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [50s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m0s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m20s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m30s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m40s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [1m50s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m0s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m20s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m30s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m40s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [2m50s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m0s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m10s elapsed]
ovh_cloud_project_kube.cluster: Still creating... [3m20s elapsed]
ovh_cloud_project_kube.cluster: Creation complete after 3m23s [id=xxxxxxxxx-xxxx-xxxx-XXXX-xxxxxxxxxx]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Destruction

Si vous souhaitez supprimer le cluster Kubernetes que vous avez ajouté via Terraform, vous devez exécuter la commande terraform destroy :

$ terraform destroy
ovh_cloud_project_kube.cluster: Refreshing state... [id=xxxxxxxxx-xxxx-xxxx-XXXX-xxxxxxxxxx]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # ovh_cloud_project_kube.cluster will be destroyed
  - resource "ovh_cloud_project_kube" "cluster" {
      - control_plane_is_up_to_date = true -> null
      - id                          = "xxxxxxxxx-xxxx-xxxx-XXXX-xxxxxxxxxx" -> null
      - is_up_to_date               = true -> null
      - kubeconfig                  = (sensitive value)
      - name                        = "my-super-cluster" -> null
      - next_upgrade_versions       = [] -> null
      - nodes_url                   = "xxxxxx.nodes.c2.gra.k8s.ovh.net" -> null
      - region                      = "GRA5" -> null
      - service_name                = "xxxxxxxxxxxxxxxxxxxxx" -> null
      - status                      = "READY" -> null
      - update_policy               = "ALWAYS_UPDATE" -> null
      - url                         = "xxxxxx.c2.gra.k8s.ovh.net" -> null
      - version                     = "1.31" -> null

      - customization {
          - apiserver {
              - admissionplugins {
                  - disabled = [
                      - "AlwaysPullImages",
                    ] -> null
                  - enabled  = [
                      - "NodeRestriction",
                    ] -> null
                }
            }
        }
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

ovh_cloud_project_kube.cluster: Destroying... [id=xxxxxxxxx-xxxx-xxxx-XXXX-xxxxxxxxxx]
ovh_cloud_project_kube.cluster: Still destroying... [id=xxxxxxxxx-xxxx-xxxx-XXXX-xxxxxxxxxx, 10s elapsed]
ovh_cloud_project_kube.cluster: Still destroying... [id=xxxxxxxxx-xxxx-xxxx-XXXX-xxxxxxxxxx, 20s elapsed]
ovh_cloud_project_kube.cluster: Destruction complete after 26s

Destroy complete! Resources: 1 destroyed.

Aller plus loin

Pour obtenir une vue d'ensemble du service OVHcloud Managed Kubernetes, consultez la page OVHcloud Managed Kubernetes.

Pour en savoir plus sur l'utilisation pratique de votre cluster Kubernetes, nous vous invitons à consulter nos tutoriels.

  • Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

  • Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?