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/customizing-kubeproxy.md.

Personnaliser Kube-proxy sur un cluster Managed Kubernetes OVHcloud

Voir en Markdown

Découvrez comment personnaliser la configuration de Kube-proxy sur un cluster Managed Kubernetes OVHcloud

Objectif

Le service Managed Kubernetes OVHcloud vous fournit des clusters Kubernetes sans les contraintes liées à leur installation ou à leur exploitation.

Le composant Kubernetes kube-proxy (qui s'exécute sur chaque nœud et permet la communication réseau vers les pods) avec iptables constitue en réalité un frein au scaling du cluster vers un grand nombre de nœuds. Chez OVHcloud, nous avons donc décidé de réduire ce frein en vous permettant d'utiliser kube-proxy avec IPVS.

IPVS (IP Virtual Server) s'appuie sur Netfilter et implémente l'équilibrage de charge au niveau de la couche transport, au sein du noyau Linux.

Chez OVHcloud, nous sommes à l'écoute de nos utilisateurs et améliorons nos produits et services en conséquence ; c'est pourquoi nous vous donnons la possibilité de personnaliser la configuration de kube-proxy.

Prérequis

  • Un cluster Managed Kubernetes OVHcloud

En pratique

Configurer kube-proxy via l'API

L'API Explorer

Pour simplifier les choses, nous utilisons l'API Explorer, qui permet d'explorer, d'apprendre et d'interagir avec l'API de manière interactive.

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

GET/cloud/project/{serviceName}/kube

Endpoints de l'API

  • Récupérer la personnalisation d'un cluster existant :
GET/cloud/project/{serviceName}/kube/{kubeId}/customization

Résultat :

{
    "apiServer": {
      "admissionPlugins": {
        "disabled": [],
        "enabled": ["AlwaysPullImages", "NodeRestriction"]
      }
    },
    "kubeProxy": {
      "iptables": {
        "minSyncPeriod": "PT1S",
        "syncPeriod": "PT30S"
      },
      "ipvs": {
        "minSyncPeriod": "PT0S",
        "scheduler": "rr",
        "syncPeriod": "PT30S",
        "tcpFinTimeout": "PT0S",
        "tcpTimeout": "PT0S",
        "udpTimeout": "PT0S",
      }
    }
}
  • Créer un cluster Kubernetes dans la région GRA5 avec le mode kube-proxy IPVS :
POST/cloud/project/{serviceName}/kube
{
    "region": "GRA5",
    "name": "my-super-cluster",
    "kubeProxyMode": "ipvs",
    "customization": {
      "kubeProxy":{
          // All fields are optional
          "iptables":{
            "minSyncPeriod":"PT1S",
            "syncPeriod":"PT30S"
         },
         "ipvs":{
            "minSyncPeriod":"PT0S",
            "scheduler":"rr",
            "syncPeriod":"PT30S",
            "tcpFinTimeout":"PT0S",
            "tcpTimeout":"PT0S",
            "udpTimeout":"PT0S"
         }
      }
   }
}
Info

Cet appel API génère une configMap qui sera utilisée par le composant kube-proxy.

Pour accéder à cette configMap, vous pouvez exécuter la commande kubectl get cm kube-proxy -n kube-system -o yaml.

La configMap kube-proxy des nouveaux clusters Kubernetes inclut l'entrée config.conf.

Les configurations spécifiques à IPVS et à iptables peuvent être définies simultanément, et kube-proxy sélectionnera celle à utiliser selon la valeur du mode.

Si un champ n'est pas spécifié dans le payload de l'API, il ne sera pas présent dans le fichier de configuration, et kube-proxy utilisera sa valeur par défaut (la valeur par défaut de kubeProxyMode est 'iptables').

Vous pouvez consulter les valeurs par défaut de Kube-proxy pour plus d'informations.

  • Réinitialiser un cluster Kubernetes (toutes les données Kubernetes seront effacées (pods, services, configuration, etc.), les nœuds seront soit supprimés, soit réinstallés)
Info

kubeProxyMode ne peut pas être modifié ; vous devez réinitialiser votre cluster Kubernetes.

POST/cloud/project/{serviceName}/kube/{kubeId}/reset
{
    "region": "GRA5",
    "name": "my-super-cluster",
    "kubeProxyMode": "ipvs",
    "customization": {
      "kubeProxy":{
         "iptables":{
            "minSyncPeriod":"PT1S",
            "syncPeriod":"PT30S"
         },
         "ipvs":{
            "minSyncPeriod":"PT0S",
            "scheduler":"rr",
            "syncPeriod":"PT30S",
            "tcpFinTimeout":"PT0S",
            "tcpTimeout":"PT0S",
            "udpTimeout":"PT0S"
         }
      }
   }
}

Les champs kubeProxyMode et customization peuvent tous deux être modifiés lors de la réinitialisation du cluster, avec le même payload que celui utilisé pour la création.

Si ces champs ne sont pas spécifiés, ils seront réinitialisés à leur valeur par défaut (ipvs pour kubeProxyMode et une customization vide).

  • Mettre à jour uniquement kubeProxy et conserver la personnalisation apiServer existante, le cas échéant :
Info

kubeProxyMode ne peut pas être modifié en mettant à jour un cluster existant ; il ne peut être défini qu'à la création ou à la réinitialisation du cluster.

PUT/cloud/project/{serviceName}/kube/{kubeId}/customization
{
	"kubeProxy": {
		"iptables": {
			"minSyncPeriod": "PT60S"
			"syncPeriod": "PT60S"
		}
	}
}
  • Mettre à jour à la fois apiServer et écraser la configuration kubeProxy :
PUT/cloud/project/{serviceName}/kube/{kubeId}/customization
{
	"apiServer": {
		"admissionPlugins": {
			"enabled": [],
			"disabled": [
				"AlwaysPullImages"
			]
		}
	},
	// kubeProxy customization will be OVERRIDDEN (minSyncPeriod will be removed in this example)
	"kubeProxy": {
		"iptables": {
			"syncPeriod": "PT120S"
		}
	}
}
Info

La mise à jour du champ customization.kubeProxy déclenchera les actions suivantes :

  • application de la configMap mise à jour
  • puis redémarrage progressif (rollout restart) de kube-proxy afin qu'il utilise la nouvelle configuration

Configurer kube-proxy via Terraform

Depuis la version 0.28.1+ de notre provider Terraform OVH, vous pouvez configurer le kube proxy de votre cluster Kubernetes via Terraform.

Récupérer les informations de votre cluster/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 /*.

Une fois vos tokens OVHcloud générés avec succès, enregistrez-les, car vous en aurez besoin très prochainement.

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

Comment l'obtenir ?

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

Vous utiliserez également ces informations dans les fichiers de définition des ressources Terraform.

Instructions Terraform

Tout d'abord, créez 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.

Ici, nous avons 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 le 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" "mycluster" {
  service_name    = var.service_name
  name            = "my_kube_cluster"
  region          = "GRA5"
  kube_proxy_mode = "ipvs" # or "iptables"	
	
  customization_kube_proxy {
    iptables {
      min_sync_period = "PT0S"
      sync_period = "PT0S"
    }
        
    ipvs {
      min_sync_period = "PT0S"
      sync_period = "PT0S"
      scheduler = "rr"
      tcp_timeout = "PT0S"
      tcp_fin_timeout = "PT0S"
      udp_timeout = "PT0S"
    }
  }
}

Dans cette configuration de ressources, nous demandons à Terraform de créer un cluster Kubernetes, dans la région GRA5, en utilisant la dernière version de Kubernetes, avec une configuration Kube proxy, en spécifiant ipvs pour le mode kube proxy.

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

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of ovh/ovh...
- Installing ovh/ovh v0.28.1...
- Installed ovh/ovh v0.28.1 (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

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 dans un dépôt git donné, par exemple.

La commande init va :

  • télécharger et installer les providers/plugins Terraform
  • initialiser le backend (s'il est défini)
  • télécharger et installer les modules (s'ils sont 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.mycluster will be created
  + resource "ovh_cloud_project_kube" "mycluster" {
      + control_plane_is_up_to_date = (known after apply)
      + id                          = (known after apply)
      + is_up_to_date               = (known after apply)
      + kube_proxy_mode             = "ipvs"
      + kubeconfig                  = (sensitive value)
      + kubeconfig_attributes       = (sensitive value)
      + name                        = "my_kube_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                     = (known after apply)

      + customization {
          + apiserver {
              + admissionplugins {
                  + disabled = (known after apply)
                  + enabled  = (known after apply)
                }
            }
        }

      + customization_apiserver {
          + admissionplugins {
              + disabled = (known after apply)
              + enabled  = (known after apply)
            }
        }

      + customization_kube_proxy {
          + iptables {
              + min_sync_period = "PT0S"
              + sync_period     = "PT0S"
            }

          + ipvs {
              + min_sync_period = "PT0S"
              + scheduler       = "rr"
              + sync_period     = "PT0S"
              + tcp_fin_timeout = "PT0S"
              + tcp_timeout     = "PT0S"
              + udp_timeout     = "PT0S"
            }
        }
    }

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.mycluster will be created
  + resource "ovh_cloud_project_kube" "mycluster" {
      + control_plane_is_up_to_date = (known after apply)
      + id                          = (known after apply)
      + is_up_to_date               = (known after apply)
      + kube_proxy_mode             = "ipvs"
      + kubeconfig                  = (sensitive value)
      + kubeconfig_attributes       = (sensitive value)
      + name                        = "my_kube_cluster"
      + next_upgrade_versions       = (known after apply)
      + nodes_url                   = (known after apply)
      + region                      = "GRA5"
      + service_name                = "xxxxxxxxxxxxxxxxxxxxxxx"
      + status                      = (known after apply)
      + update_policy               = (known after apply)
      + url                         = (known after apply)
      + version                     = (known after apply)

      + customization {
          + apiserver {
              + admissionplugins {
                  + disabled = (known after apply)
                  + enabled  = (known after apply)
                }
            }
        }

      + customization_apiserver {
          + admissionplugins {
              + disabled = (known after apply)
              + enabled  = (known after apply)
            }
        }

      + customization_kube_proxy {
          + iptables {
              + min_sync_period = "PT0S"
              + sync_period     = "PT0S"
            }

          + ipvs {
              + min_sync_period = "PT0S"
              + scheduler       = "rr"
              + sync_period     = "PT0S"
              + tcp_fin_timeout = "PT0S"
              + tcp_timeout     = "PT0S"
              + udp_timeout     = "PT0S"
            }
        }
    }

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.mycluster: Creating...
ovh_cloud_project_kube.mycluster: Still creating... [10s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [20s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [30s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [40s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [50s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [1m0s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [1m10s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [1m20s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [1m30s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [1m40s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [1m50s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [2m0s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [2m10s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [2m20s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [2m30s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [2m40s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [2m50s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [3m0s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [3m10s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [3m20s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [3m30s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [3m40s elapsed]
ovh_cloud_project_kube.mycluster: Still creating... [3m50s elapsed]
ovh_cloud_project_kube.mycluster: Creation complete after 3m56s [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx]

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

Destroy

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.mycluster: Refreshing state... [id=xxxxxxxx-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.mycluster will be destroyed
  - resource "ovh_cloud_project_kube" "mycluster" {
      - control_plane_is_up_to_date = true -> null
      - id                          = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx" -> null
      - is_up_to_date               = true -> null
      - kube_proxy_mode             = "ipvs" -> null
      - kubeconfig                  = (sensitive value)
      - kubeconfig_attributes       = (sensitive value)
      - name                        = "my_kube_cluster" -> null
      - next_upgrade_versions       = [] -> null
      - nodes_url                   = "xxxxxx.nodes.c1.gra.k8s.ovh.net" -> null
      - region                      = "GRA5" -> null
      - service_name                = "xxxxxxxxxxxxxxxxxxxxxxx" -> null
      - status                      = "READY" -> null
      - update_policy               = "ALWAYS_UPDATE" -> null
      - url                         = "xxxxxx.c1.gra.k8s.ovh.net" -> null
      - version                     = "1.34" -> null

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

      - customization_kube_proxy {
          - iptables {
              - min_sync_period = "PT0S" -> null
              - sync_period     = "PT0S" -> null
            }

          - ipvs {
              - min_sync_period = "PT0S" -> null
              - scheduler       = "rr" -> null
              - sync_period     = "PT0S" -> null
              - tcp_fin_timeout = "PT0S" -> null
              - tcp_timeout     = "PT0S" -> null
              - udp_timeout     = "PT0S" -> 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.mycluster: Destroying... [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx]
ovh_cloud_project_kube.mycluster: Still destroying... [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx, 10s elapsed]
ovh_cloud_project_kube.mycluster: Still destroying... [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx, 20s elapsed]
ovh_cloud_project_kube.mycluster: Still destroying... [id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx, 30s elapsed]
ovh_cloud_project_kube.mycluster: Destruction complete after 36s

Destroy complete! Resources: 1 destroyed.

Aller plus loin

Pour avoir une vue d'ensemble du service Managed Kubernetes OVHcloud, vous pouvez consulter la page Managed Kubernetes OVHcloud.

  • Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

  • Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?