Support secondary custom-metric-server

[qmhu]

As we know, k8s don't support multiple custom-metric-server in one cluster :kubernetes-sigs/custom-metrics-apiserver#70

One possible solution is to build an CRD for metric routing. But, it's too complicated for mostly of the users. Most of the time we just have two custom-metric-server in one cluster, So how about let prometheus-adapter support a secondary custom-metric-server.

The configuration is like this:

spec:
      serviceAccountName: custom-metrics-apiserver
      containers:
      - name: custom-metrics-apiserver
        image: gcr.io/k8s-staging-prometheus-adapter-amd64
        args:
        - --secure-port=6443
        - --tls-cert-file=/var/run/serving-cert/serving.crt
        - --tls-private-key-file=/var/run/serving-cert/serving.key
        - --logtostderr=true
        - --prometheus-url=http://prometheus.prom.svc:9090/
        - --metrics-relist-interval=1m
        - --v=10
        - --config=/etc/adapter/config.yaml
        - --secondary-metric-server=true
        - --secondary-metric-server-service-namespace=kube-system
        - --secondary-metric-server-service-name=metric-adapter
        - --secondary-metric-server-service-port=443

the logic for handle a metric would be:

1. If the metric name is exist in prometheus-adapter, just process as before
2. If not exist, proxy forward the request to secondary-metric-server

If it is needed, I want to implement it.

[qmhu]

@dgrisonnet any suggestions?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[olivierlemasle]

/remove-lifecycle rotten

[dgrisonnet]

This is a feature that would be very useful, but it shouldn't be done at the prometheus-adapter level since we don't have the resources today to invest into that. As such I am denying this feature request. But we could benefit from the more general effort in kubernetes-sigs/custom-metrics-apiserver#70.

[qmhu]

This is a feature that would be very useful, but it shouldn't be done at the prometheus-adapter level since we don't have the resources today to invest into that. As such I am denying this feature request. But we could benefit from the more general effort in kubernetes-sigs/custom-metrics-apiserver#70.

ok, We know users that have more than one custom metric servers, it should be a way to resolve it.