filigranepodautoscaler
0.7.0
Avis de non-responsabilité : ce projet est en version bêta - L'API peut changer.
Le contrôleur Watermark Pod Autoscaler (WPA) est un contrôleur personnalisé qui étend le horizontal Pod Autoscaler (HPA).
Le contrôleur Watermark Pod Autoscaler est un contrôleur alternatif au contrôleur horizontal Pod Autoscaler en amont.
Si vous souhaitez mettre à l'échelle automatiquement certaines de vos applications, mais :
par exemple
apiVersion : datadoghq.com/v1alpha1
kind : WatermarkPodAutoscaler
[...]
spec :
algorithm : absolute
[...]Il existe deux options pour calculer le nombre souhaité de répliques :
average Le contrôleur utilisera la value from the external metrics provider / current number of replicas et la comparera aux filigranes. Le nombre recommandé de répliques est value from the external metrics provider / watermark (faible ou élevé en fonction de la valeur actuelle).
L'algorithme average convient bien si vous utilisez une métrique qui ne dépend pas du nombre de réplicas. Généralement, le nombre de requêtes reçues par un ELB peut indiquer le nombre de serveurs Web que nous souhaitons avoir, étant donné que nous savons qu'un seul serveur Web doit gérer n rq/s. L'ajout d'un réplica n'augmentera ni ne diminuera le nombre de requêtes reçues par l'équilibreur de charge.
absolute La valeur par défaut est absolute . Une métrique moyenne doit être utilisée. Le nombre recommandé de répliques est calculé comme current number of replicas * value from the external metrics provider / watermark .
L'algorithme absolute est celui par défaut, car il représente le cas d'utilisation le plus courant. Par exemple, si vous souhaitez que votre application exécute entre 60 % et 80 % du processeur et avg:cpu.usage est à 85 %, vous devez effectuer une mise à l'échelle. La métrique doit être corrélée au nombre de répliques.
Remarque : Dans le contrôleur amont, seule la fonction math.Ceil est utilisée pour arrondir le nombre de répliques recommandé.
Cela signifie que si vous avez un seuil à 10, vous devrez atteindre une utilisation de 8,999... de la part du fournisseur de métriques externe pour réduire la taille d'une réplique. Cependant, une utilisation de 10.001 vous fera évoluer d’une réplique.
Le contrôleur WPA utilisera math.Floor si la valeur est sous le filigrane inférieur. Cela garantit un comportement symétrique. Combiné avec d’autres options de mise à l’échelle, cela permet un contrôle plus précis sur le moment de réduire la mise à l’échelle.
Pour utiliser le Watermark Pod Autoscaler, déployez-le dans votre cluster Kubernetes :
Téléchargez le fichier zip du projet Watermark Pod Autoscaler. Le code source peut être trouvé sur DataDog/watermarkpodautoscaler .
Décompressez le projet et accédez au dossier ./watermarkpodautoscaler .
Définissez votre espace de noms et votre contrôleur Watermark Pod Autoscaler :
DD_NAMESPACE= " datadog "
DD_NAMEWPA= " wpacontroller "Créez l'espace de noms :
kubectl create ns $DD_NAMESPACEInstallez le contrôleur Watermark Pod Autoscaler avec Helm :
helm install $DD_NAMEWPA -n $DD_NAMESPACE ./chart/watermarkpodautoscalerLe contrôleur WatermarkPodAutoscaler est livré avec un plugin kubectl fournissant un ensemble d'utilitaires d'assistance. plus d'informations sur la page de documentation dédiée : docs/kubectl-plugin.md
Créez votre WPA dans le même espace de noms que votre déploiement cible.
Le Datadog Cluster Agent récupérera l’événement de création/mise à jour/suppression. Il analyse la spécification WPA pour extraire la métrique et la portée à obtenir de Datadog.
Dans cet exemple, nous utilisons la configuration de spécifications suivante :
apiVersion : datadoghq.com/v1alpha1
kind : WatermarkPodAutoscaler
metadata :
name : example-watermarkpodautoscaler
spec :
downscaleForbiddenWindowSeconds : 60
downscaleDelayBelowWatermarkSeconds : 300
upscaleForbiddenWindowSeconds : 30
upscaleDelayAboveWatermarkSeconds : 30
scaleDownLimitFactor : 30
scaleUpLimitFactor : 50
minReplicas : 4
maxReplicas : 9
scaleTargetRef :
kind : " Deployment "
name : " some_app "
apiVersion : " apps/v1 "
metrics :
- external :
highWatermark : 400m
lowWatermark : 150m
metricName : custom.request_duration.max
metricSelector :
matchLabels :
kubernetes_cluster : mycluster
service : billing
short_image : billing-app
type : External
tolerance : " 0.01 " Les types de métriques External et Resource sont pris en charge. Le contrôleur WPA utilise le même format que le HPA. Plus d'informations ici.
En commençant par les filigranes, la valeur de la métrique collectée ( watermarkpodautoscaler.wpa_controller_value ) auprès de Datadog en violet lorsqu'elle se situe entre les limites ( watermarkpodautoscaler.wpa_controller_low_watermark et watermarkpodautoscaler.wpa_controller_high_watermark ) demandera au contrôleur de ne pas déclencher d'événement de mise à l'échelle. Ils sont spécifiés sous forme de Quantities , vous pouvez donc utiliser m | "" | k | M | G | T | P | E pour représenter facilement la valeur que vous souhaitez utiliser.
Nous pouvons utiliser la métrique watermarkpodautoscaler.wpa_controller_restricted_scaling{reason:within_bounds} pour vérifier qu'elle est bien restreinte. Remarque : la métrique a été multipliée par 1000 afin de rendre plus explicite que pendant ce temps, aucun événement de mise à l'échelle n'a pu être déclenché par le contrôleur.
Le deuxième ensemble d'options de configuration concerne la vitesse de mise à l'échelle de votre déploiement, contrôlée par scaleDownLimitFactor et scaleUpLimitFactor . Il s'agit d'entiers compris entre 0 et 100. Ils représentent respectivement le rapport maximum de mise à l'échelle et de mise à l'échelle, compte tenu du nombre actuel de répliques.
Dans ce cas, si nous avions 10 répliques et un nombre recommandé de répliques à 14 (voir la section Algorithme pour plus de détails sur la recommandation) avec un scaleUpFactor de 30 (%), nous serions plafonnés à 13 répliques.
Dans le graphique suivant, nous pouvons voir que le nombre de répliques suggéré (en violet), représenté par la métrique watermarkpodautoscaler.wpa_controller_replicas_scaling_proposal est trop élevé par rapport au nombre actuel de répliques. Cela déclenchera la logique de plafonnement ascendant, qui peut être surveillée à l'aide de la métrique watermarkpodautoscaler.wpa_controller_restricted_scaling{reason:upscale_capping} ( Remarque : comme ci-dessus, la métrique a été multipliée pour la rendre plus explicite). Ainsi, le nombre effectif de répliques watermarkpodautoscaler.wpa_controller_replicas_scaling_effective augmentera, mais en fonction du scaleUpLimitFactor .
Dans cet exemple similaire, nous évitons de trop réduire la taille et nous pouvons utiliser le même ensemble de métriques pour garantir que nous réduisons uniquement un nombre raisonnable de réplicas.
Il est important de noter que nous prenons toujours des décisions prudentes en matière de mise à l’échelle.
scaleUpLimitFactor de 29 % : si nous avons 10 réplicas et qu'on nous en recommande 13, nous passerons à 12.scaleDownLimitFactor de 29 % : si nous avons 10 répliques et qu'on nous en recommande 7, nous passerons à 8.minReplicas et maxReplicas sont prioritaires. Reportez-vous à la section Priorité. Enfin, les dernières options disponibles sont downscaleForbiddenWindowSeconds et upscaleForbiddenWindowSeconds . Ceux-ci représentent le temps (en secondes) à attendre après un événement de mise à l'échelle avant de réduire et d'augmenter, respectivement. Nous ne conservons que le dernier événement de mise à l'échelle et nous ne comparons pas les upscaleForbiddenWindowSeconds à la dernière mise à l'échelle.
Dans l’exemple suivant, nous pouvons voir que le nombre de répliques recommandé est ignoré si nous sommes dans une période de refroidissement. La période de refroidissement de downscale peut être visualisée avec watermarkpodautoscaler.wpa_controller_transition_countdown{transition:downscale} , et est représentée en jaune sur le graphique ci-dessous. Nous pouvons voir qu'elle est nettement supérieure à la période de recharge ascendante ( transition:upscale ) en orange sur notre graphique. Une fois qu’il nous est recommandé d’évoluer, nous n’évoluerons que si la fenêtre de temps de recharge appropriée est terminée. Cela réinitialisera les deux comptes à rebours.
Afin d'éviter la mise à l'échelle des rafales, vous pouvez utiliser les fonctionnalités suivantes : downscaleDelayBelowWatermarkSeconds et/ou upscaleDelayAboveWatermarkSeconds . Ces options sont spécifiées sous forme d'entiers. La ou les métriques doivent rester au-dessus ou en dessous de leur filigrane respectif pendant la durée configurée. Vous pouvez suivre le temps restant dans l'état du WPA :
- lastTransitionTime: "2022-11-15T02:02:09Z"
message: Allow downscaling if the value stays under the Watermark
reason: Value below Low Watermark
status: "False"
type: BelowLowWatermark
Ou dans les logs du contrôleur :
{"level":"info","ts":1668481092517.446,"logger":"controllers.WatermarkPodAutoscaler","msg":"Will not scale: value has not been out of bounds for long enough","watermarkpodautoscaler":"datadog/example-watermarkpodautoscaler","wpa_name":"example-watermarkpodautoscaler","wpa_namespace":"datadog","time_left":3209}
Remarque : Si vous utilisez plusieurs métriques avec cette fonctionnalité, la condition ci-dessus/ci-dessous est considérée comme utilisant le OR des métriques.
Par exemple, supposons que vous disposiez d’un upscaleDelay de 60 secondes avec deux métriques, M1 et M2. Si M1 reste au-dessus de sa limite supérieure pendant 40 secondes [t0; t40] , et celui de M2 dépasse son filigrane élevé pendant 30 secondes, se chevauchant avec M1 au cours de ses 10 dernières secondes, [t30; t60] , cela valide la condition upscaleDelay et permet un événement de mise à l'échelle.
Au fur et à mesure que nous récupérons la valeur de la métrique externe, nous la comparerons d'abord à la somme highWatermark + tolerance et à la différence lowWatermark - tolerance . Si nous sommes en dehors des limites, nous calculons le nombre recommandé de répliques. Nous comparons ensuite cette valeur au nombre actuel de répliques pour potentiellement limiter le nombre de répliques recommandé également en fonction de minReplicas et maxReplicas . Enfin, nous examinons si nous sommes autorisés à évoluer, compte tenu des downscaleForbiddenWindowSeconds et upscaleForbiddenWindowSeconds .
Afin d'avoir un contrôle plus précis sur les conditions dans lesquelles une cible peut être mise à l'échelle, vous pouvez utiliser les fonctionnalités suivantes :
minAvailableReplicaPercentage : indique le pourcentage minimum de réplicas qui doivent être disponibles pour que le contrôleur puisse effectuer une mise à l'échelle automatique de la cible. Par exemple, si la valeur est définie sur 50 et que moins de la moitié des pods derrière la cible sont dans un état Disponible, la cible ne sera pas mise à l'échelle par le contrôleur.
readinessDelaySeconds : Spécifie la durée pendant laquelle les réplicas doivent être exécutés, avant d'être pris en compte dans les décisions de mise à l'échelle.
Si toutes les conditions sont remplies, le contrôleur mettra à l'échelle l'objet ciblé dans scaleTargetRef au nombre recommandé de répliques uniquement si l'indicateur dryRun n'est pas défini sur true . Il l'indiquera en enregistrant :
{ "level" : " info " , "ts" : 1566327479.866722 , "logger" : " wpa_controller " , "msg" : " DryRun mode: scaling change was inhibited currentReplicas:8 desiredReplicas:12 " }L'agent de cluster exécute un informateur sur les ressources WPA et, comme le HPA, lors de la création/mise à jour/suppression, il analysera la spécification pour interroger la métrique auprès de Datadog.
L'agent de cluster n'exécute pas l'écouteur WPA par défaut. Pour activer WPA dans l'agent de cluster, définissez la variable d'environnement DD_EXTERNAL_METRICS_PROVIDER_WPA_CONTROLLER=true et mettez à jour le ClusterRole attribué au compte de service de l'agent de cluster pour avoir accès aux objets WatermarkPodAutoscaler :
[...]
- apiGroups : ["datadoghq.com"]
resources :
- watermarkpodautoscalers
verbs :
- get
- list
- watch
[...] Remarque : Pour activer WPA dans l'agent de cluster à l'aide du graphique de barre Datadog, définissez clusterAgent.metricsProvider.wpaController sur true . Le ClusterRole sera mis à jour automatiquement.
Une fois que vous avez appliqué ces modifications et créé un objet WPA, si vous exécutez dans le pod Datadog Cluster Agent et exécutez agent status vous pourrez voir des détails plus spécifiques sur les spécifications des autoscalers qui ont été analysés (qu'il s'agisse d'un horizontal ou d'un autoscaler de pod de filigrane).
* watermark pod autoscaler: default/example2-watermarkpodautoscaler
- name : example2-watermarkpodautoscaler
- namespace : default
- type : watermark
- uid : ff09b7d8-d99b-11e9-a8c1-42010a8001c4
Metric name : sinus
Labels :
- foo : bar
Value : 75.1297378540039
Timestamp : 15688259400
Valid : true
* horizontal pod autoscaler: default/nginxext
- name : nginxext
- namespace : default
- type : horizontal
- uid : 61ef3f6e-af32-11e9-a8c1-42010a8001c4
Metric name : docker.mem.rss
Labels :
- cluster-location : us-central1-a
- cluster-name : charly
Value : 263888700952
Timestamp : 15688259400
Valid : trueEn plus des métriques mentionnées ci-dessus, ce sont des logs qui vous aideront à mieux comprendre le bon fonctionnement du WPA.
Toutes les 15 secondes, nous récupérons la métrique répertoriée dans la section metrics de la spécification auprès de Datadog.
{ "level" : " info " , "ts" : 1668484420515.7678 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Metrics from the External Metrics Provider " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "metrics" :[ 33959 ]}
{ "level" : " info " , "ts" : 1668484420515.8203 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Value is below lowMark " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "usage" : " 33959m " , "replicaCount" : 7 , "currentReadyReplicas" : 8 , "tolerance (%)" : 1 , "adjustedLM" : 34650 , "adjustedUsage" : 33959 }
{ "level" : " info " , "ts" : 1668484420515.8906 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Proposing replicas " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "proposedReplicas" : 7 , "metricName" : " datadogmetric@datadog:example-watermarkpodautoscaler-utilization-metric{map[kube_container_name:my-container service:my-target]} " , "reference" : " Deployment/datadog/example-watermarkpodautoscaler " , "metric timestamp" : " Tue, 15 Nov 2022 03:53:20 UTC " }
{ "level" : " info " , "ts" : 1668484420515.9324 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Normalized Desired replicas " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "desiredReplicas" : 7 }
{ "level" : " info " , "ts" : 1668484420515.946 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Cooldown status " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "backoffUp" : false , "backoffDown" : false , "desiredReplicas" : 7 , "currentReplicas" : 8 }
{ "level" : " info " , "ts" : 1668484420515.9563 , "logger" : " controllers.WatermarkPodAutoscaler " , "msg" : " Will not scale: value has not been out of bounds for long enough " , "watermarkpodautoscaler" : " datadog/example-watermarkpodautoscaler " , "wpa_name" : " example-watermarkpodautoscaler " , "wpa_namespace" : " datadog " , "time_left" : 2335 }Ici, le nombre actuel de réplicas observés dans le déploiement cible est de six. Nous voyons ensuite la valeur brute récupérée du fournisseur de métriques externes et nous la comparons aux filigranes haut et bas. Compte tenu du résultat de cette comparaison, nous imprimons le nombre de répliques recommandé. Dans ce cas, il est cinq.
Si vous souhaitez interroger directement le fournisseur de métriques externe, vous pouvez utiliser la commande suivante :
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces// | jq ."
Vous pouvez éventuellement ajouter des sélecteurs d'étiquettes en ajoutant ?labelSelector=key%3Dvalue . Si nous voulions récupérer notre métrique dans ce cas, nous pourrions utiliser :
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces// | jq .?labelSelector=key%3Dvalue%2Cotherkey%3Dothervalue%2Cshort_image%3Dimage "
Si vous voyez des journaux tels que :
{ "level" : " info " , "ts" : 1566397216.8918724 , "logger" : " wpa_controller " , "msg" : " failed to compute desired number of replicas based on listed metrics for Deployment/datadog/propjoe-green: failed to get external metric dd.propjoe.request_duration.max: unable to get external metric datadog/propjoe-green/&LabelSelector{MatchLabels:map[string]string{fooa: bar,},MatchExpressions:[],}: no metrics returned from external metrics API " }Vous pouvez ensuite vérifier que cette métrique n'est effectivement pas disponible auprès du fournisseur de métriques externes. Cela peut être dû à une faute de frappe dans les étiquettes, ou à la métrique qui ne peut pas être récupérée depuis Datadog (ce qui peut être dû à divers facteurs : trop clairsemé, API en panne, limite de débit atteinte, etc.). Vous pouvez consulter les journaux du fournisseur de métriques externes pour une enquête plus approfondie.
Nous vérifions ensuite le plafonnement de la vitesse de mise à l'échelle et les fenêtres de temps de recharge. Dans le cas d’un plafonnement de mise à l’échelle, vous verriez quelque chose comme :
{ "level" : " info " , "ts" : 1566327268.8839815 , "logger" : " wpa_controller " , "msg" : " Upscaling rate higher than limit of 50.0% up to 9 replicas. Capping the maximum upscale to 9 replicas " }
{ "level" : " info " , "ts" : 1566327268.884001 , "logger" : " wpa_controller " , "msg" : " Returning 9 replicas, condition: ScaleUpLimit reason the desired replica count is increasing faster than the maximum scale rate " }
{ "level" : " info " , "ts" : 1566327479.8845513 , "logger" : " wpa_controller " , "msg" : " -> after normalization: 9 " }Ensuite, nous considérons les périodes de refroidissement. Vous disposerez de journaux indiquant la date du dernier événement de mise à l'échelle, ainsi que le moment où les prochains événements de mise à l'échelle et de mise à l'échelle seront interdits jusqu'à :
{ "level" : " info " , "ts" : 1566327479.8845847 , "logger" : " wpa_controller " , "msg" : " Too early to downscale. Last scale was at 2019-08-20 18:57:44 +0000 UTC, next downscale will be at 2019-08-20 18:58:44 +0000 UTC, last metrics timestamp: 2019-08-20 18:57:59 +0000 UTC " }
{ "level" : " info " , "ts" : 1566327479.8846018 , "logger" : " wpa_controller " , "msg" : " Too early to upscale. Last scale was at 2019-08-20 18:57:44 +0000 UTC, next upscale will be at 2019-08-20 18:58:14 +0000 UTC, last metrics timestamp: 2019-08-20 18:57:59 +0000 UTC " }
{ "level" : " info " , "ts" : 1566327479.884608 , "logger" : " wpa_controller " , "msg" : " backoffUp: true, backoffDown: true, desiredReplicas 5, currentReplicas: 6 " }Enfin, nous avons vérifié que le déploiement a été correctement mis à l'échelle automatiquement :
{ "level" : " info " , "ts" : 1566327253.7887673 , "logger" : " wpa_controller " , "msg" : " Successful rescale of watermarkpodautoscaler, old size: 8, new size: 9, reason: cutom_metric.max{map[kubernetes_cluster:my-cluster service:my-service short_image:my-image]} above target " }wpa.datadoghq.com/logs-attributes pour ajouter des valeurs de clé supplémentaires dans les journaux associés à l'objet WPA sous-jacent. Exemple: apiVersion: datadoghq.com/v1alpha1
kind: WatermarkPodAutoscaler
metadata:
annotations:
wpa.datadoghq.com/logs-attributes: '{"mywpa": "isgreat"}'
name: watermarkpodautoscaler-sinus
namespace: default
[...]
Donne :
{"level":"info","ts":1643642642091.062,"logger":"controllers.WatermarkPodAutoscaler","msg":"getReadyPodsCount","watermarkpodautoscaler":"default/watermarkpodautoscaler-sinus","mywpa":"isgreat","full podList length":2,"toleratedAsReadyPodCount":2,"incorrectly targeted pods":0}
Que se passe-t-il si je fais évoluer manuellement mon déploiement ?
Dans la prochaine boucle de réconciliation, le nouveau nombre de répliques sera pris en compte pour calculer le nombre de répliques souhaité. Vous pourriez voir un journal indiquant que la ressource a été modifiée par quelqu'un d'autre. Toutefois, si le nombre de répliques configurées est en dehors des limites, le contrôleur le réduira à un nombre de répliques compris dans la plage acceptable.
Comment désactiver temporairement le WPA pour augmenter/réduire manuellement mon déploiement ?
La méthode recommandée consiste à définir le WPA en mode d’exécution à sec, puis à l’adapter au nombre de répliques souhaité. Vous pouvez définir le WPA en mode d'exécution à sec à l'aide de cette commande de patch :
kubectl patch wpa --type='json' -p='[{"op": "replace", "path": "/spec/dryRun", "value":true}]'
N'oubliez pas de remettre le mode d'exécution à sec sur false une fois votre remplacement temporaire terminé afin que le WPA soit à nouveau actif.
Quelle est l’encombrement du contrôleur ?
D'après nos tests, il s'agit d'un facteur du nombre de déploiements dans le cluster.
Le contrôleur est-il apatride ?
Oui.
WPA prend-il en charge plusieurs métriques ?
Oui, WPA peut évoluer sur plusieurs métriques et fonctionne de manière similaire à HPA. WPA évalue chaque métrique séparément et propose le nombre de réplicas associés à la métrique qui nécessite le plus grand nombre. Par exemple, si WPA évalue metric1, metric2, metric3 et pour chacune, il calcule respectivement 10, 20 et 30 propositions de réplique, la proposition finale est 30.
Puisque nous surveillons toutes les définitions WPA à l’échelle du cluster, nous utilisons un clusterrole.
Une option utile consiste à usurper l’identité de l’utilisateur pour vérifier les droits. Par exemple, pour vérifier que vous avez le droit d'obtenir un déploiement en tant que compte de service du contrôleur WPA :
kubectl get deploy < your_deploy > --as system:serviceaccount:datadog:watermarkpodautoscaler -n < your_ns >Ou interrogez le fournisseur de métriques externe :
kubectl get --raw " /apis/external.metrics.k8s.io/v1beta1/namespaces//metric --as system:serviceaccount::watermarkpodautoscaler Exigences:
Après avoir cloné le référentiel https://github.com/DataDog/watermarkpodautoscaler , définissez quelques variables d'environnement :
export GO111MODULE=on
unset GOPATH
export PATH= $PATH : $( pwd ) /bin Ensuite, pour installer certaines dépendances d'outils, exécutez make install-tools .
make install-tools : installez les outils pour utiliser le SDK de l'opérateur.make build : Construisez le contrôleur localement.make generate : Exécutez le générateur SDK de plusieurs opérateurs, qui génère du code pour le contrôleur et l'enregistrement de l'informateur.make test : Exécutez des tests unitaires.make validate : exécutez les linters Golang courants ( golangci-lint ).make e2e : exécutez des tests de bout en bout sur le cluster Kubernetes actuellement configuré.make container : créez l'image Docker du contrôleur à l'aide du SDK de l'opérateur.make container-ci : créez l'image Docker du contrôleur avec le Dockerfile à plusieurs étapes.La documentation du processus de publication est disponible ici.
Certaines fonctionnalités ont été inspirées du Configurable HPA ou CHPA. La majeure partie de la structure du code a également été utilisée pour le Watermark Pod Autoscaler, bien que l'empaquetage global du CRD ait été réalisé avec le SDK de l'opérateur.
