You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.
Is this an ISSUE or FEATURE REQUEST? (choose one): Issue
What version of acs-engine?: v0.19.3
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm) Kubernetes v1.11.0
What happened:
According to the acs-engine documentation [1], the apiServerConfig's --profiling is set by default to false and it is not user configurable (and cannot be set to true through acs-engine).
Because of this, the Kubernetes metrics API will not handle DELETE requests properly [2][3], treating them as GET instead. Some e2e tests (e.g.: [sig-scalability] Load capacity [Feature:ManualPerformance] should be able to handle 3 pods per node { ReplicationController} with 0 secrets, 0 configmaps and 0 daemons) requires the metrics to be reset / deleted before starting, but they fail because of this issue.
If profiling is enabled, the following commands should work as expected:
kubectl proxy --port=8888 &
curl -X DELETE http://localhost:8888/metrics # this should output "metrics reset"
If profiling is disabled, the curl above would be treated as a GET instead, and all the metrics will returned.
How to reproduce it (as minimally and precisely as possible):
Create a kubernetes.json file with --profiling=true [1].
Generate files:
acs-engine generate kubernetes.json
Checking the generated files, the azuredeploy.json file will contain --profiling=false for: kubernetesControllerManagerConfig, kubernetesAPIServerConfig, kubernetesSchedulerConfig.
Continuing with the deployment will result in having a Kubernetes deployment in which its API server is configured with --profiling=false and the metrics not being deletable.
Is this a request for help?: No
Is this an ISSUE or FEATURE REQUEST? (choose one): Issue
What version of acs-engine?: v0.19.3
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm) Kubernetes v1.11.0
What happened:
According to the acs-engine documentation [1], the
apiServerConfig
's--profiling
is set by default tofalse
and it is not user configurable (and cannot be set to true through acs-engine).Because of this, the Kubernetes metrics API will not handle DELETE requests properly [2][3], treating them as GET instead. Some e2e tests (e.g.:
[sig-scalability] Load capacity [Feature:ManualPerformance] should be able to handle 3 pods per node { ReplicationController} with 0 secrets, 0 configmaps and 0 daemons
) requires the metrics to be reset / deleted before starting, but they fail because of this issue.[1]https://github.com/Azure/acs-engine/blob/0acbf7c4c9a74f60888862e679298fd62e875526/docs/clusterdefinition.md#apiserverconfig
[2] https://github.com/kubernetes/kubernetes/blob/501ce61224be3f1fe4d707b4246de2d59c43b26f/staging/src/k8s.io/apiserver/pkg/server/config.go#L576
[3] https://github.com/kubernetes/kubernetes/blob/501ce61224be3f1fe4d707b4246de2d59c43b26f/staging/src/k8s.io/apiserver/pkg/server/routes/metrics.go#L48
What you expected to happen:
Profiling should be configurable.
If profiling is enabled, the following commands should work as expected:
If profiling is disabled, the curl above would be treated as a GET instead, and all the metrics will returned.
How to reproduce it (as minimally and precisely as possible):
Create a
kubernetes.json
file with--profiling=true
[1].Generate files:
Checking the generated files, the
azuredeploy.json
file will contain--profiling=false
for: kubernetesControllerManagerConfig, kubernetesAPIServerConfig, kubernetesSchedulerConfig.Continuing with the deployment will result in having a Kubernetes deployment in which its API server is configured with --profiling=false and the metrics not being deletable.
[1] https://paste.ubuntu.com/p/rgPV5hmxCZ/
Anything else we need to know:
The text was updated successfully, but these errors were encountered: