<p>I have:</p>
<ol>
<li>deployments of services A and B in k8s</li>
<li>Prometheus stack</li>
</ol>
<p>I wanna scale service A when metric m1 of service B is changed.
Solutions which I found and not suitable more or less:</p>
<ol>
<li>I can define HPA for service A with the following part of spec:</li>
</ol>
<pre><code>  - type: Object
      object:
        metric:
          name: m1
        describedObject:
          apiVersion: api/v1
          kind: Pod
          name: certain-pod-of-service-B
        current:
          value: 10k
</code></pre>
<p>Technically, it will work. But it's not suitable for dynamic nature of k8s.
Also I can't use pods metric (metrics: - type: Pods pods:) in HPA cause it will request m1 metric for pods of service A (which obviously doesn't have this)</p>
<ol start="2">
<li><p>Define custom metric in prometheus-adapter which query m1 metric from pods of service B. It's more suitable, but looks like workaround cause I already have a metric m1</p>
</li>
<li><p>The same for external metrics</p>
</li>
</ol>
<p>I feel that I miss something cause it doesn't seem like a non realistic case :)
So, advise me please how to scale one service by metric of another in k8s?</p>

pingrulkin
<p>I decided to provide a Community Wiki answer that may help other people facing a similar issue.</p>
<p>The <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/" rel="nofollow noreferrer">Horizontal Pod Autoscaler</a> is a Kubernetes feature that allows to scale applications based on one or more monitored metrics.<br />
As we can find in the <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/" rel="nofollow noreferrer">Horizontal Pod Autoscaler documentation</a>:</p>
<blockquote>
<p>The Horizontal Pod Autoscaler automatically scales the number of Pods in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with custom metrics support, on some other application-provided metrics).</p>
</blockquote>
<p>There are <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis" rel="nofollow noreferrer">three groups of metrics</a> that we can use with the Horizontal Pod Autoscaler:</p>
<ul>
<li><a href="https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/" rel="nofollow noreferrer">resource metrics</a>: predefined resource usage metrics (CPU and
memory) of pods and nodes.</li>
<li><a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics" rel="nofollow noreferrer">custom metrics</a>: custom metrics associated with a Kubernetes
object.</li>
<li><a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects" rel="nofollow noreferrer">external metrics</a>: custom metrics not associated with a
Kubernetes object.</li>
</ul>
<p>Any HPA target can be scaled based on the resource usage of the <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-resource-metrics" rel="nofollow noreferrer">pods</a> (or <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics" rel="nofollow noreferrer">containers</a>) in the scaling target. The CPU utilization metric is a <code>resource metric</code>, you can specify other resource metrics besides CPU (e.g. memory). This seems to be the easiest and most basic method of scaling, but we can use more specific metrics by using <code>custom metrics</code> or <code>external metrics</code>.</p>
<p>There is one major difference between <code>custom metrics</code> and <code>external metrics</code> (see: <a href="https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics#custom-metrics" rel="nofollow noreferrer">Custom and external metrics for autoscaling workloads</a>):</p>
<blockquote>
<p>Custom metrics and external metrics differ from each other:</p>
</blockquote>
<blockquote>
<p>A custom metric is reported from your application running in Kubernetes.
An external metric is reported from an application or service not running on your cluster, but whose performance impacts your Kubernetes application.</p>
</blockquote>
<p>All in all, in my opinion it is okay to use <code>custom metrics</code> in the case above,
I did not find any other suitable way to accomplish this task.</p>
