一般的な状況：いくつかのアプリケーションがあり、そのうちの1つが日中にピーク負荷を持ち、他の時間には誰もアクセスしない（またはアクセスされるが、めったにない）; 他のアプリケーションは夜間にクラスター電源を使用できます。 そのようなアプリケーションの例として、Webサービス、一部のデータハンドラーを挙げることができます。



いつものように、クラスタリソースはまったく十分ではありません。 リソースの使用を最適化するために何かを考え出す必要があり、Kubernetesはこれに最適です。 水平ポッドオートスケーラーがあり 、メトリックに基づいてアプリケーションをスケーリングできます。







メトリックは通常、 メトリックサーバーによって提供されます 。 次に、メトリックサーバーをPrometheusに置き換えることについて説明します（Prometheusはメトリックサーバーによって配信されるデータを実装し、1つの余分なリンクを取り除くため）およびPrometheusのメトリックに基づいてKubernetesでアプリケーションをスケーリングする方法について説明します。



開始するには、 Prometheusオペレーターをインストールします。 個人的には、 既製のマニフェストを使用しています。 Helmのチャートを使用できます（ただし、パフォーマンスを確認しませんでした）。 メトリックサーバーがある場合は、それも削除します。 その後、すべてが正常に機能するかどうかを確認します。

# kubectl get --raw "/apis/metrics.k8s.io/v1beta1/" | jq { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "metrics.k8s.io/v1beta1", "resources": [ { "name": "nodes", "singularName": "", "namespaced": false, "kind": "NodeMetrics", "verbs": [ "get", "list" ] }, { "name": "pods", "singularName": "", "namespaced": true, "kind": "PodMetrics", "verbs": [ "get", "list" ] } ] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、 このディレクトリからマニフェストを適用します。 これにより、Prometheus-adapterがインストールされます。 これらのマニフェストを含むグラフを見つけましたが、チェックしませんでした。 その後、コマンドを正しく実行する必要があります。

 kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（非常に大きなリストがあるため、ここにはリストしません）



metrics.k8s.ioおよびcustom.metrics.k8s.ioのURLの意味を理解するには、 ドキュメントが役立ちます。



何かが機能しない場合は、通常どおり、ログを確認します。 問題の解決策を探すこともできます 。



次に、自動スケーリングを設定します。



大量のプロセッサリソースを消費し、キューを処理するアプリケーションがあります。 キューサイズがしきい値を超えたらすぐに、レプリカセットのハースの数を増やして、キューをより速く処理したいと思います。 サイズがしきい値を下回るとすぐに、クラスターリソースを解放する必要があります。



Prometheus-adapterのルールの書き方を理解するには、 このドキュメントとその関連ページを注意深く読む必要があります。 これは私に見える方法です



プロメテウスへの依頼

 wqueue_tube_total_size{tube="dmload-legacy"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは返します：

 wqueue_tube_total_size{endpoint="pprof-port",instance="10.116.2.237:8542",job="wqueue-pprof",namespace="default",pod="wqueue-b9fdd9455-66mwm",service="wqueue-pprof",tube="dmload-legacy"} 32
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Prometheus-adapterについて次のルールを記述します。

 - seriesQuery: wqueue_tube_total_size{tube="dmload-legacy"} resources: overrides: namespace: resource: namespace tube: resource: service name: {as: "wqueue_tube_total_size_dmload_legacy"} metricsQuery: wqueue_tube_total_size{tube="dmload-legacy"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用中のtube



パラメーターをマップし、説明でhpaを使用する必要があることに注意してください。



HPA設定：

 --- kind: HorizontalPodAutoscaler apiVersion: autoscaling/v2beta1 metadata: name: dmload-v3-legacy namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: dmload-v3-legacy minReplicas: 2 maxReplicas: 20 metrics: - type: Object object: metricName: wqueue_tube_total_size_dmload_legacy target: apiVersion: v1 kind: Service name: dmload-legacy targetValue: 30
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 wqueue_tube_total_size_dmload_legacy



キューのジョブ数が30を超えるとすぐに、20になるまでポッドを追加し、 wqueue_tube_total_size_dmload_legacy



が30を下回る場合は2に減らすことをtargetValue



ます。



適用して何が起こるかを確認します。 私のシステムは数日間動作しますが、現時点では炉の数を減らしています。

 # kubectl describe hpa dmload-v3-legacy Name: dmload-v3-legacy Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling/v2beta1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"dmload-v3-legacy","namespace":"d... CreationTimestamp: Thu, 24 Jan 2019 16:16:43 +0300 Reference: Deployment/dmload-v3-legacy Metrics: ( current / target ) "wqueue_tube_total_size_dmload_legacy" on Service/dmload-legacy: 14 / 30 Min replicas: 2 Max replicas: 20 Deployment pods: 15 current / 14 desired Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 14 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from Service metric wqueue_tube_total_size_dmload_legacy ScalingLimited False DesiredWithinRange the desired count is within the acceptable range Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 59m (x14 over 40h) horizontal-pod-autoscaler New size: 13; reason: All metrics below target Normal SuccessfulRescale 59m (x13 over 40h) horizontal-pod-autoscaler New size: 12; reason: All metrics below target Normal SuccessfulRescale 57m (x14 over 40h) horizontal-pod-autoscaler New size: 11; reason: All metrics below target Normal SuccessfulRescale 56m (x14 over 40h) horizontal-pod-autoscaler New size: 10; reason: All metrics below target Normal SuccessfulRescale 56m (x11 over 38h) horizontal-pod-autoscaler New size: 8; reason: All metrics below target Normal SuccessfulRescale 55m (x6 over 36h) horizontal-pod-autoscaler New size: 7; reason: All metrics below target Normal SuccessfulRescale 47m (x103 over 40h) horizontal-pod-autoscaler (combined from similar events): New size: 20; reason: Service metric wqueue_tube_total_size_dmload_legacy above target Normal SuccessfulRescale 3m38s (x19 over 41h) horizontal-pod-autoscaler New size: 17; reason: All metrics below target Normal SuccessfulRescale 2m8s (x23 over 41h) horizontal-pod-autoscaler New size: 16; reason: All metrics below target Normal SuccessfulRescale 98s (x20 over 40h) horizontal-pod-autoscaler New size: 15; reason: All metrics below target Normal SuccessfulRescale 7s (x18 over 40h) horizontal-pod-autoscaler New size: 14; reason: All metrics below target
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

説明されているすべてはKubernetes 1.13.2で実行されました。

おわりに

この短い記事では、Prometheusのメトリックを使用してKubernetesクラスター内のアプリケーションを自動的にスケーリングする方法を示しました。



Prometheus-operatorコンポーネントが構成され、必要なマニフェストが作成されました。



その結果、キューのサイズに関するプロメテウスからのメトリックに基づいて、このキューを処理するポッドの数を増減することが判明しました。





（グラフは、キューのサイズに応じて炉床の数がどのように変化するかを示しています）



ご清聴ありがとうございました！