HPAの正式名称はHorizontal Pod Autoscalerであり、中国語はPOD水平自動スケーリングとして解釈されます。以下では、Horizontal Pod Autoscalerの代わりにHPAが使用されます。HPAは、CPU使用率（CPUを除く）に基づいて、レプリケーションコントローラー、デプロイ、レプリケーションケースのポッドの数を自動的に拡大および縮小できます。 （使用率は、他のアプリケーションによって提供されるカスタム指標に基づいて自動的に拡大または縮小することもできます）。ポッドの自動スケーリングは、DaemonSetsなど、スケーリングできないオブジェクトには適していません。HPAは、Kubernetes APIリソースとコントローラーによって実装されます。リソースはコントローラーの動作を決定します。コントローラーは定期的に平均CPU使用率を取得し、それをターゲット値と比較して、レプリケーションコントローラーまたは展開内のコピー数を調整します。
カスタム指標の詳細な紹介は次のとおりです。
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md参考公式サイトアドレスは以下の通りです。
https://v1-17.docs.kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/1. HPAの動作原理
HPAの実装は制御サイクルであり、コントローラーマネージャーの--horizontal-pod-autoscaler-sync-periodパラメーターで指定されています（デフォルト値は15秒です）。各サイクルで、コントローラーマネージャーは各HorizontalPodAutoscaler定義で指定されたインジケーターに従ってリソース使用率をクエリします。コントローラーマネージャーは、リソースメトリックAPI（ポッドリソースメトリック）およびカスタムメトリックAPI（カスタムメトリック）からメトリックを取得できます。
1）各ポッド（CPUなど）のリソースインジケーターの場合、コントローラーはHorizontalPodAutoscalerで指定された各ポッドのインジケーターをリソースインジケーターAPIから取得します。次に、ターゲット使用率が設定されている場合、コントローラーは各ポッドのコンテナーリソースを取得します使用量、およびリソース使用量を計算します。元の値を使用すると、元のデータが直接使用されます（パーセンテージは計算されなくなります）。次に、コントローラーは、平均リソース使用率または元の値に従ってスケーリング率を計算し、次に目標コピー数を計算します。一部のポッドコンテナーがリソース収集をサポートしていない場合、コントローラーはポッドのCPU使用率を使用しないことに注意してください
2）ポッドがカスタムインジケーターを使用する場合、コントローラーメカニズムはリソースインジケーターと同様ですが、カスタムインジケーターは元の値のみを使用し、使用率は使用しない点が異なります。
3）ポッドがオブジェクトインジケーターと外部インジケーターを使用する場合（各インジケーターはオブジェクト情報を示します）。このインジケーターは、ターゲット設定と直接比較され、上記のズーム比を生成します。自動スケーリング/ v2beta2 APIでは、このインジケーターは、均等に分割されたポッドの数に基づいて計算することもできます。通常、コントローラーは一連の集約API（metrics.k8s.io、custom.metrics.k8s.io、およびexternal.metrics.k8s.io）からインジケーターデータを取得します。metrics.k8s.io APIは通常、metrics-serverによって提供されます（追加の起動が必要です）。
二、メトリックサーバー
Metrics-Serverはクラスタ全体のリソースデータセットとツールです。同様に、Metrics-Serverはデータを表示するだけで、データストレージサービスは提供しません。主な問題は、CPU、ファイル記述子などのリソース測定APIの実装です。メモリやリクエストの遅延などのインジケーター、metric-serverはkubes、hpa、スケジューラーなどのk8sクラスターで使用するデータを収集します。
1. metrics-serverをデプロイし、k8sのマスターノードで動作する
1）画像をオフラインにする
必要な画像は次のとおりです。
k8s.gcr.io/metrics-server-amd64:v0.3.6和
k8s.gcr.io/addon-resizer:1.8.4ミラーが配置されているBaiduネットワークディスクのアドレスは次のとおりです。
链接：https://pan.baidu.com/s/1SKpNaskVr_zQJVQuM_GzIQ
提取码：24yb
链接：https://pan.baidu.com/s/1KXOSiSJGGGaUXCjdCHoXjQ
提取码：yab5マシンが外部ネットワークにアクセスできない場合は、画像をk8sの各ノードにアップロードし、次のように手動で解凍できます。
docker load -i metrics-server-amd64_0_3_1.tar.gz
docker load -i addon.tar.gz2）metrics.yamlファイル
猫metrics.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: metrics-server:system:auth-delegator
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: metrics-server-auth-reader
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: metrics-server
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: system:metrics-server
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
rules:
- apiGroups:
- ""
resources:
- pods
- nodes
- nodes/stats
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- "extensions"
resources:
- deployments
verbs:
- get
- list
- update
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system:metrics-server
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:metrics-server
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
name: metrics-server-config
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: EnsureExists
data:
NannyConfiguration: |-
apiVersion: nannyconfig/v1alpha1
kind: NannyConfiguration
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: metrics-server
namespace: kube-system
labels:
k8s-app: metrics-server
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
version: v0.3.6
spec:
selector:
matchLabels:
k8s-app: metrics-server
version: v0.3.6
template:
metadata:
name: metrics-server
labels:
k8s-app: metrics-server
version: v0.3.6
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ''
seccomp.security.alpha.kubernetes.io/pod: 'docker/default'
spec:
priorityClassName: system-cluster-critical
serviceAccountName: metrics-server
containers:
- name: metrics-server
image: k8s.gcr.io/metrics-server-amd64:v0.3.6
command:
- /metrics-server
- --metric-resolution=30s
- --kubelet-preferred-address-types=InternalIP
- --kubelet-insecure-tls
ports:
- containerPort: 443
name: https
protocol: TCP
- name: metrics-server-nanny
image: k8s.gcr.io/addon-resizer:1.8.4
resources:
limits:
cpu: 100m
memory: 300Mi
requests:
cpu: 5m
memory: 50Mi
env:
- name: MY_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MY_POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
volumeMounts:
- name: metrics-server-config-volume
mountPath: /etc/config
command:
- /pod_nanny
- --config-dir=/etc/config
- --cpu=300m
- --extra-cpu=20m
- --memory=200Mi
- --extra-memory=10Mi
- --threshold=5
- --deployment=metrics-server
- --container=metrics-server
- --poll-period=300000
- --estimator=exponential
- --minClusterSize=2
volumes:
- name: metrics-server-config-volume
configMap:
name: metrics-server-config
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
- key: node-role.kubernetes.io/master
effect: NoSchedule
---
apiVersion: v1
kind: Service
metadata:
name: metrics-server
namespace: kube-system
labels:
addonmanager.kubernetes.io/mode: Reconcile
kubernetes.io/cluster-service: "true"
kubernetes.io/name: "Metrics-server"
spec:
selector:
k8s-app: metrics-server
ports:
- port: 443
protocol: TCP
targetPort: https
---
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
name: v1beta1.metrics.k8s.io
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
spec:
service:
name: metrics-server
namespace: kube-system
group: metrics.k8s.io
version: v1beta1
insecureSkipTLSVerify: true
groupPriorityMinimum: 100
versionPriority: 100kubectl apply -f metrics.yaml
3）メトリックサーバーが正常にデプロイされているかどうかを確認します。
kubectl get pods -n kube-system
起動が成功したことを示す次の実行ステータスが表示されます
4）kubectl topコマンドをテストします
metrics-serverコンポーネントが正常にインストールされたら、kubectl topコマンドを使用できます
kubectlトップノード
表示は次のとおりです。
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k8s-master 660m 16% 1608Mi 20%
k8s-node 348m 8% 1046Mi 28% kubectl top pods -n kube-systemは
次のように表示されます。
NAME CPU(cores) MEMORY(bytes)
calico-node-9wkmr 100m 26Mi
calico-node-sp5m6 162m 35Mi
coredns-6955765f44-j2xrl 8m 8Mi
coredns-6955765f44-th2sb 10m 8Mi
etcd-k8s-master 48m 44Mi
kube-apiserver-k8s-master 128m 286Mi
kube-controller-manager-k8s-master 79m 38Mi
kube-proxy-9s48h 2m 17Mi
kube-proxy-vcx2s 2m 10Mi
kube-scheduler-k8s-master 12m 15Mi
metrics-server-5cf9669fbf-jmrdx 3m 17Mi3、HPA APIオブジェクト
HPA APIには3つのバージョンがあり、kubectl api-versions | grep autoscalで確認できます
自動スケーリング/ v1
自動スケーリング/ v2beta1
自動スケーリング/ v2beta2
autoscaling/v1只支持基于CPU指标的缩放；
autoscaling/v2beta1支持Resource Metrics（资源指标，如pod的CPU）和Custom Metrics（自定义指标）的缩放；
autoscaling/v2beta2支持Resource Metrics（资源指标，如pod的CPU）和Custom Metrics（自定义指标）和ExternalMetrics（额外指标）的缩放。4、kubectlを使用してHPAを操作する
他のAPIリソースと同様に、kubectlはポッド自動スケーリングもサポートしています。kubectl createコマンドを使用して自動スケーラブルオブジェクトを作成し、kubectl get hpaコマンドを使用してすべての自動スケーラブルオブジェクトを取得し、kubectl describe hpaコマンドを使用して自動スケーラブルオブジェクトの詳細を表示できます。最後に、kubectl delete hpaコマンドを使用してオブジェクトを削除できます。さらに、自動スケーリングオブジェクトを作成する簡単なコマンドkubectl autoscaleがあります。たとえば、コマンドkubectl autoscale rs foo --min = 2 --max = 5 --cpu-percent = 80は、fooという名前のレプリケーションセットの自動スケーラブルオブジェクトを作成します。ターゲットターゲットのCPU使用率は80％です。コピー数は2から5の間で構成されます。
5つ、複数のインジケーターのサポート
Kubernetes1.6以降の複数のメトリックに基づくスケーリングのサポート。自動スケーリング/ v2beta2 APIを使用して、HPAの複数のインジケーターを指定できます。HPAは各指標に従って計算し、スケーリングの提案を生成します。
6、カスタム指標のサポート
Kubernetes 1.6以降、HPAはカスタムインジケーターの使用をサポートしています。自動スケーリング/ v2beta2 APIを使用して、HPAのユーザー定義インジケーターを指定できます。Kubernetesは、ユーザー定義のインジケーターAPIを介して対応するインジケーターを取得します。
7、HPAの自動スケーリング/ v1バージョン-CPUベースの自動拡張および縮小をテストする
Deploymentを使用してphp-apacheサービスを作成し、HPAを使用して自動的に拡大および縮小します。手順は次のとおりです。
1.デプロイを通じてポッドを作成し、k8sのマスターノードで動作する
1）php-apacheサービスを作成して実行する
dockerfileを使用して新しいイメージをビルドし、k8sのマスターノードでビルドします
猫ドックファイル
FROM php:5-apache
ADD index.php /var/www/html/index.php
RUN chmod a+rx index.php猫のindex.php
<?php
$x = 0.0001;
for ($i = 0; $i <= 1000000;$i++) {
$x += sqrt($x);
}
echo "OK!";
?>docker build -t k8s.gcr.io/hpa-example:v1。
2）パッケージミラー
docker save -o hpa-example.tar.gz k8s.gcr.io/hpa-example:v1
3）画像を解凍します
イメージをk8sの各ノードに転送し、docker load-i hpa-example.tar.gzで解凍できます。
4）デプロイメントを通じてphp-apacheサービスをデプロイします
猫php-apache.yaml
apiVersion:apps/v1
kind:Deployment
metadata:
name:php-apache
spec:
selector:
matchLabels:
run:php-apache
replicas:1
template:
metadata:
labels:
run:php-apache
spec:
containers:
-name:php-apache
image:k8s.gcr.io/hpa-example:v1
ports:
-containerPort:80
resources:
limits:
cpu:500m
requests:
cpu:200m
---
apiVersion: v1
kind:Service
metadata:
name:php-apache
labels:
run:php-apache
spec:
ports:
-port:80
selector:
run:php-apachekubectl apply -f php-apache.yaml
5）PHPが正常にデプロイされていることを確認します
kubectl get pods
以下が表示され、phpサービスが正常にデプロイされたことを示します
NAME READY STATUS RESTARTS AGE
php-apache-5694767d56-mmr88 1/1 Running 0 66s2. HPAを作成する
php-apacheサービスが実行されています。kubectlautoscaleを使用して、自動スケーラーを作成し、php-apacheのデプロイによって作成されたポッドを自動的に拡大および縮小します。次のコマンドはHPAを作成します。HPAは、CPU、メモリ、その他のリソースインジケーターに基づいて増加します。または、コピーの数を減らして、次の目的を達成できるHPAを作成します。
1）让副本数维持在1-10个之间（这里副本数指的是通过deployment部署的pod的副本数）
2）将所有Pod的平均CPU使用率维持在50％（通过kubectlrun运行的每个pod如果是200毫核，这意味着平均CPU利用率为100毫核1）php-apacheの上のデプロイメント用にHPAを作成します
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10上記コマンドの説明
kubectl autoscale deployment php-apache （php-apache表示deployment的名字） --cpu-percent=50（表示cpu使用率不超过50%） --min=1（最少一个pod）
--max=10（最多10个pod）2）HPAが正常に作成されたことを確認します
kubectl get hpa
この表示は、作成が成功したことを示しています。
注：サーバーにリクエストを送信していないため、現在のCPU消費は0％です（TARGET列は、対応するデプロイメントによって制御されるすべてのポッドの平均を示しています）。
3. php-apacheサービスの圧力テスト、CPUの圧力テストを実行
コンテナーを開始し、php-apacheサービスに無限クエリループを送信します（k8sマスターノードのターミナルをコピーします。つまり、新しいターミナルウィンドウを開きます）。
kubectl run v1 -it --image=busybox /bin/shコンテナにログインした後、次のコマンドを実行します
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done1分ほどで、次のコマンドを実行するとCPUの負荷が高くなります。
kubectl get hpa
表示は次のとおりです：
上記のように、CPU消費量は256％に達し、各ポッドのターゲットCPU使用率は50％で
あるため、php-apacheのデプロイによって作成されるポッドのコピー数は5に調整されます。
256/50 = 5 kubectl get pod
が次のように表示されるため、コピー：
NAME READY STATUS RESTARTS AGE
php-apache-5694767d56-b2kd7 1/1 Running 0 18s
php-apache-5694767d56-f9vzm 1/1 Running 0 2s
php-apache-5694767d56-hpgb5 1/1 Running 0 18s
php-apache-5694767d56-mmr88 1/1 Running 0 4h13m
php-apache-5694767d56-zljkd 1/1 Running 0 18skubectl get deployment php-apacheを
以下に示します。
NAME READY UP-TO-DATE AVAILABLE AGE
php-apache 5/5 5 5 2h1m注：コピー数が安定するまで数分かかる場合があります。負荷の量はまったく制御されないため、最終的なコピー数はこの例とは異なる場合があります。
4. php-apacheサービスの耐圧テストを停止します。HPAは、php-apacheのデプロイによって作成されたポッドを自動的に縮小します
php-apacheサービスへのクエリリクエストの送信を停止します。busyboxイメージ作成コンテナのターミナルで、<Ctrl> + Cを使用して、whileリクエストを今すぐ停止します。次に、結果のステータスを確認します（約1分後）。
kubectl get hpa
は次のように表示されます。
kubectl get deployment php-apache
表示は次のとおりです。
上記からわかるように、CPU使用率は0に低下するため、HPAは自動的にコピー数を1に減らします。
注：コピーが自動的にスケーリングされるまで数分かかる場合があります。
8、テストHPA自動スケーリング/ v2beta1バージョンメモリベースの自動拡張と縮小
1. nginxポッドを作成する
猫nginx.yaml
apiVersion:apps/v1
kind: Deployment
metadata:
name:nginx-hpa
spec:
selector:
matchLabels:
app: nginx
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.9.1
ports:
- containerPort: 80
name: http
protocol: TCP
resources:
requests:
cpu: 0.01
memory: 25Mi
limits:
cpu: 0.05
memory: 60Mi
---
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
selector:
app: nginx
type: NodePort
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80
nodePort: 30080kubectl apply -f nginx.yaml
2. nginxが実行されていることを確認します
kubectl get pods
表示は次のとおりで、nginxポッドが正常に実行されていることを示しています。
NAME READY STATUS RESTARTS AGE
nginx-hpa-bb598885d-j4kcp 1/1 Running 0 17m注： nginxポッドには次のフィールドが必要です。それ以外の場合、hpaはメモリインジケーターを収集できません。
resources:
requests:
cpu: 0.01
memory: 25Mi
limits:
cpu: 0.05
memory: 60Mi3. hpaを作成する
猫hpa-v1.yaml
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: nginx-hpa
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion:apps/v1
kind: Deployment
name: nginx-hpa
metrics:
- type: Resource
resource:
name: memory
targetAverageUtilization: 60kubectl get hpa
は次のように表示されます。
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 20s4.を押してnginxのメモリを測定します。hpaはポッドを自動的に拡大および縮小します
上記のポッドで作成されたnginxにログインし、メモリを増やすためのファイルを生成します
kubectl exec -it nginx-hpa-bb598885d-j4kcp -- /bin/sh圧力テスト：
dd if=/dev/zero of=/tmp/a新しいターミナルを開きます：
kubectl get hpa表示は次のとおりです。
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx-hpa Deployment/nginx-hpa 200%/60% 1 10 3 12m上記のターゲット列には200％/ 60％が表示され、200％は現在のCPU使用率を表し、60％は60％に維持されているすべてのポッドのCPU使用率を表し、CPU使用率は200％に達しているため、ポッドは4
kubectl get deployment
表示は次のとおりです。
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-hpa 4/4 4 4 25mkubectl get pods
表示は次のとおりです。
NAME READY STATUS RESTARTS AGE
nginx-hpa-bb598885d-j4kcp 1/1 Running 0 25m
nginx-hpa-bb598885d-rj5hk 1/1 Running 0 63s
nginx-hpa-bb598885d-twv9c 1/1 Running 0 18s
nginx-hpa-bb598885d-v9ft5 1/1 Running 0 63s5. nginxメモリの圧力テストをキャンセルします。hpaは自動的にポッドを縮小します
kubectl exec -it nginx-hpa-bb598885d-j4kcp -- /bin/sh
/ tmp /ファイルを削除します
rm -rf /tmp/akubectl get hpa
以下に示すように、メモリ使用量が5％に低下したことがわかります。
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
nginx-hpa Deployment/nginx-hpa 5%/60% 1 10 1 26mkubectl getデプロイメントを
以下に示します。デプロイメントポッドは1つに戻りました。
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-hpa 1/1 1 1 38m複数のインジケーターとカスタムインジケーターに基づく9つの自動スケーリング
自動スケーリング/ v2beta2 APIバージョンを使用して、php-apacheのデプロイを自動的にスケーリングするときに使用される他のメトリックを導入できます。
自動スケーリングのyamlファイルを取得する/ v2beta2 APIバージョンHPA
kubectl get hpa.v2beta2.autoscaling -o yaml> /tmp/hpa-v2.yaml
エディターでファイル/tmp/hpa-v2.yaml を開き、不要なフィールドをいくつか削除します。次のyamlが表示されます
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
status:
observedGeneration: 1
lastScaleTime: <some-time>
currentReplicas: 1
desiredReplicas: 1
currentMetrics:
- type: Resource
resource:
name: cpu
current:
averageUtilization: 0
averageValue: 0targetCPUUtilizationPercentageフィールドは指標に置き換えられます。CPU使用率指標は、コンテナ上の指定されたリソースの割合を表すため、リソース指標です。CPUに加えて、他のリソースメトリックも指定できます。デフォルトでは、現在サポートされている他の唯一のリソースメトリックはメモリです。metrics.k8s.io APIが存在する限り、これらのリソースメトリックは使用可能であり、異なるKubernetesクラスターで名前を変更することはありません。パーセンテージの代わりに絶対値を使用するようにリソースメトリックを指定することもできます。ターゲットタイプAverageUtilizationをAverageValueに置き換え、target.averageUtilizationをtarget.averageValueに置き換えて、対応する値を設定する必要があります。メトリックには他に2つのタイプがあり、カスタムメトリック（カスタムメトリック）と見なされます。ポッドメトリックとオブジェクトメトリックです。これらのメトリックには、クラスター固有の名前が付いている場合があり、より高度なクラスター監視設定が必要です。最初のオプションの指標タイプはポッド指標です。これらのインジケーターは、ポッドを1つの側面から説明し、異なるポッド間でそれらを平均し、ターゲット値と比較することでコピー数を決定します。これらはリソースメトリックと非常によく似ていますが、ターゲットタイプAverageValueしかサポートしていないという違いがあります。
ポッドメトリックは次のコードブロックによって定義されます
type: Pods
pods:
metric:
name: packets-per-second
target:
type: AverageValue
averageValue: 1k2番目のオプションのメトリックタイプはオブジェクトメトリックです。ポッドの説明に関連して、これらのメトリックは同じ名前空間内の他のオブジェクトを説明するために使用されます。これらのメトリックは、オブジェクトからではなく、これらのオブジェクトを説明するために使用されることに注意してください。オブジェクトメトリックでサポートされるターゲットタイプには、ValueとAverageValueがあります。タイプがValueの場合、ターゲット値はAPIによって返されるメトリックと直接比較されますが、AverageValueの場合、APIによって返されるメトリックはポッドの数に従って分割され、ターゲット値と比較されます。次のYAMLファイルは、1秒あたりのリクエスト数を表す指標を示しています。
type: Object
object:
metric:
name: requests-per-second
describedObject:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
type: Value
value: 2k上記のタイプの複数のメトリックを指定した場合、HorizontalPodAutoscalerはそれらのそれぞれを順番に考慮します。HorizontalPodAutoscalerは、各インジケーターに対して提案されたコピー数を計算し、最後に最高値を選択します。たとえば、モニタリングシステムがネットワークトラフィックデータを提供できる場合、kubectl editコマンドを使用して、上記の水平ポッドオートスケーラーの定義を次のように変更できます。
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-apache
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: AverageUtilization
averageUtilization: 50
- type: Pods
pods:
metric:
name: packets-per-second
targetAverageValue: 1k
- type: Object
object:
metric:
name: requests-per-second
describedObject:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
target:
kind: Value
value: 10k
status:
observedGeneration: 1
lastScaleTime: <some-time>
currentReplicas: 1
desiredReplicas: 1
currentMetrics:
- type: Resource
resource:
name: cpu
current:
averageUtilization: 0
averageValue: 0
- type: Object
object:
metric:
name: requests-per-second
describedObject:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: main-route
current:
value: 10k次に、HorizontalPodAutoscalerは、各ポッドのCPU使用率が50％以内であることを確認し、毎秒1000パケットリクエストを処理でき、Ingress後のすべてのポッドが毎秒合計10,000リクエストを処理できることを確認します。
10、より特定された指標の下での自動スケーリング
多くの測定パイプラインでは、名前または添付された_labels_で測定指標を説明できます。すべての非リソースタイプメトリック（ポッド、オブジェクト、および外部）については、追加のタグセレクターを指定できます。たとえば、動詞タグを含むhttp_requestsメトリックを収集する場合、次のようにGETリクエストで必要なメトリックを指定できます。
type:Object
object:
metric:
name:`http_requests`
selector:`verb=GET`このセレクターは、Kubernetesタグセレクターと同じ構文を使用します。名前とタグのセレクターが複数のシリーズと一致する場合、モニタリングパイプラインは、複数のシリーズを1つの値に組み合わせる方法を決定します。セレクターは追加であり、ターゲット（タイプポッドのターゲットとタイプオブジェクトのターゲット）以外のオブジェクトは選択しません。
11. kubernetesオブジェクト以外の指標に基づく自動スケーリング
Kubernetesで実行されているアプリケーションは、Kubernetesのどの名前空間にも含まれていないサービスを記述するものなど、Kubernetesクラスター内のオブジェクトと明確な関係がないメトリックに基づいて自動的にスケーリングする必要がある場合があります。外部指標を使用するには、使用しているモニタリングシステムを理解する必要があります。関連する設定は、カスタム指標の使用に似ています。外部指標は、モニタリングシステムの任意の指標を使用して、クラスターを自動的にスケーリングできます。メトリックブロックで名前とセレクターを指定し、タイプをオブジェクトから外部に変更するだけです。metricSelectorが複数のメトリックに一致する場合、HorizontalPodAutoscalerはそれらを合計します。外部メトリックは、オブジェクトタイプのメトリックと同じであるValueおよびAverageValueタイプの両方をサポートします。たとえば、アプリケーションがホスト上のメッセージキューを処理する場合、30のタスクごとに1つのワーカーを持つために、HorizontalPodAutoscalerの構成に以下を追加できます。
-type：External
external：
metric：
name：queue_messages_ready
selector： "queue = worker_tasks"
target：
type：AverageValue
averageValue：30
は、システム管理者がカスタムメトリックAPIを容易に強化できるため、外部メトリックではなくカスタムメトリックを推奨します。外部メトリックAPIはすべてのメトリックへのアクセスを許可します。これらのサービスを公開する場合、システム管理者はこの問題を慎重に検討する必要があります。
Kubernetes、マイクロサービス、DevOps、プロダクションケースについて詳しく知りたい場合は、無料の動画を入手してください。次のようにして入手できます~~~
WeChat： luckylucky421302
