k8s pod根据指标自动扩缩容举例-CSDN博客

目录

基于 内存 指标实现pod自动扩缩容 举例配置

基于 cpu 指标实现pod自动扩缩容 举例配置

基于请求数次/秒 指标实现pod自动扩缩容  举例配置

基于 http请求响应时间 (ms) 指标实现pod自动扩缩容  举例配置

基于 Java GC暂停时间 (ms) 指标实现pod自动扩缩容 举例配置

扩展点

prometheus对所有pod进行流量监控 配置举例

---

---

基于 内存 指标实现pod自动扩缩容 举例配置

首先需要在Kubernetes集群中部署一个HPAHorizontal Pod Autoscaler它可以基于内存使用量自动调整Pod的数量。

以下是HPA的示例配置

apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app-deployment  
  minReplicas: 2  
  maxReplicas: 10  
  metrics:  
  - type: Resource  
    resource:  
      name: memory  
      targetAverageUtilization: 80 # 目标内存使用率%

上述配置中HPA会根据内存使用量自动调整Pod的数量。

scaleTargetRef指定了要扩展的Pod对象这里是一个Deployment。

minReplicas和maxReplicas分别指定了Pod的最小和最大数量。

metrics指定了度量指标这里使用的是内存使用量。

targetAverageUtilization设置了一个目标内存使用率当内存使用率超过这个值时HPA会自动扩展Pod的数量。

为了能够正确地监测内存使用量需要为Pod配置相应的监控指标。这可以通过加入resources字段来实现如下所示

apiVersion: v1  
kind: Pod  
metadata:  
  name: my-app-pod  
spec:  
  containers:  
  - name: my-app-container  
    resources:  
      requests:  
        memory: "64Mi" # 请求64MB内存  
      limits:  
        memory: "128Mi" # 限制128MB内存  
    # ...其他配置...

在这个例子中Pod中的容器会根据配置的内存限制来运行。

requests指定了Pod启动所需的最小内存而limits则指定了Pod运行过程中所能够使用的最大内存。

这些配置可以帮助Kubernetes更好地管理资源避免资源浪费和竞争。

基于 cpu 指标实现pod自动扩缩容 举例配置

下面是一个基于CPU使用率实现Kubernetes Pod自动扩展的示例配置。

首先需要在Kubernetes集群中部署一个HPAHorizontal Pod Autoscaler它可以基于CPU使用率自动调整Pod的数量。

以下是HPA的示例配置

apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app-deployment  
  minReplicas: 2  
  maxReplicas: 10  
  metrics:  
  - type: Resource  
    resource:  
      name: cpu  
      targetAverageUtilization: 80 # 目标CPU使用率%

上述配置中HPA会根据CPU使用率自动调整Pod的数量。

scaleTargetRef指定了要扩展的Pod对象这里是一个Deployment。

minReplicas和maxReplicas分别指定了Pod的最小和最大数量。

metrics指定了度量指标这里使用的是CPU使用率。

targetAverageUtilization设置了一个目标CPU使用率当CPU使用率超过这个值时HPA会自动扩展Pod的数量。

需要注意的是为了能够正确地监测CPU使用率需要为Pod配置相应的监控指标。这可以通过在Pod中加入resources字段来实现例如

apiVersion: v1  
kind: Pod  
metadata:  
  name: my-app-pod  
spec:  
  containers:  
  - name: my-app-container  
    resources:  
      requests:  
        cpu: "100m" # 请求1个CPU核心100毫核m核  
      limits:  
        cpu: "200m" # 限制2个CPU核心200毫核m核  
    # ...其他配置...

在这个例子中Pod中的容器会根据配置的CPU资源限制来运行。

requests指定了Pod启动所需的最小CPU资源

limits则指定了Pod运行过程中所能够使用的最大CPU资源。

基于请求数次/秒 指标实现pod自动扩缩容  举例配置

下面是一个基于每秒请求数Requests per secondRPS实现Kubernetes Pod自动扩展的示例配置。

首先需要使用一个HTTP代理或服务来监控每个Pod的RPS比如一个Prometheus Operator。以下是一个Prometheus Operator的示例配置

apiVersion: rbac.authorization.k8s.io/v1beta1  
kind: ClusterRoleBinding  
metadata:  
  name: prometheus-operator  
subjects:  
- kind: ServiceAccount  
  name: prometheus-operator  
  namespace: kube-system  
roleRef:  
  kind: ClusterRole  
  name: prometheus-operator

接下来创建一个Prometheus ServiceMonitor资源以监视HTTP代理的RPS

apiVersion: monitoring.coreos.com/v1  
kind: ServiceMonitor  
metadata:  
  name: myapp-requests  
spec:  
  jobLabel: "myapp"  
  selector:  
    matchLabels:  
      myapp: my-app  
  relabelings:  
  - sourceLabels: [__meta_service_namespace, __meta_service_name]  
    targetLabel: source  
    action: keep  
  - sourceLabels: [__meta_kubernetes_pod_container_id]  
    targetLabel: container_id  
    action: keep  
  - sourceLabels: [__meta_kubernetes_pod_name]  
    targetLabel: pod_name  
    action: keep  
  - sourceLabels: [__meta_kubernetes_pod_label_myapp]  
    targetLabel: myapp  
    action: keep  
  metricsPath: /metrics  
  scheme: http  
  httpGet:  
    path: /metrics  
    port: 8000

在这个示例中ServiceMonitor资源将根据Pod的标签选择器和HTTP Get请求监视my-app服务的RPS。请注意您需要根据您的应用程序和环境进行自定义。

最后创建一个HPAHorizontal Pod Autoscaler来根据RPS自动调整Pod的数量

apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app-deployment  
  minReplicas: 2  
  maxReplicas: 100  
  metrics:  
  - type: PodsMetricSource  
    podsMetricSource:  
      metricName: "requests_per_second" # 指定要监视的指标名称例如requests_per_second  
      targetAverageValue: 10 # 目标RPS例如每秒10个请求

在这个示例中HPA将根据Pod的RPS自动调整Pod的数量。当RPS超过设定的目标值时HPA将增加更多的Pod以保持服务的高可用性和响应能力。

基于 http请求响应时间 (ms) 指标实现pod自动扩缩容  举例配置

首先需要创建一个自定义度量源Custom Metric Source这里假设你的度量源是由Prometheus Operator提供的可以按照以下步骤进行操作

apiVersion: monitoring.coreos.com/v1  
kind: Prometheus  
metadata:  
  name: my-app-http-response-time  
spec:  
  http:  
    servicePort: 9090  
    metrics:  
    - name: http_response_time_seconds_count  
      help: Count of HTTP requests with response time greater than 1 second.  
      expression: sum(rate(http_request_duration_seconds_count{job="my-app"}[1m])) by (job)

上述配置中定义了一个Prometheus资源用于收集HTTP请求的响应时间指标。http_request_duration_seconds_count是一个Prometheus指标用于表示每秒HTTP请求的计数通过rate()函数计算每分钟的平均请求速率并使用sum()函数对所有job进行聚合。最终通过by(job)对每个job进行分组以便与Pod数量进行关联。

接下来使用以下配置创建一个HPA对象

apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app-deployment  
  minReplicas: 2  
  maxReplicas: 10  
  metrics:  
  - type: PodsMetricSource  
    podsMetricSource:  
      metricName: http_response_time_seconds_count  
      targetAverageValue: 100 # 目标平均响应时间秒  
    thresholds:  
    - type: PodsMetricSource  
      podsMetricSource:  
        metricName: http_response_time_seconds_count  
        targetAverageValue: 5 # 每秒HTTP请求的目标计数可根据需求调整

上述配置中HPA使用了PodsMetricSource类型的度量源该度量源从Pod级别的度量指标中获取数据。

metricName设置为http_response_time_seconds_count表示使用之前创建的自定义度量源来收集HTTP请求响应时间的指标数据。

targetAverageValue设置了一个目标响应时间的平均值单位为秒。在此示例中目标响应时间为5秒。

同时为了更好地控制扩缩容的灵敏度还添加了一个额外的阈值threshold该阈值使用相同的度量指标但设置了每秒HTTP请求的目标计数。在此示例中如果每秒HTTP请求的数量超过5HPA将触发扩容操作。

请注意上述示例仅为了演示如何基于HTTP请求响应时间实现Pod自动扩缩容并提供了基本的配置示例。实际应用中可能需要根据具体需求进行调整和优化。

基于 Java GC暂停时间 (ms) 指标实现pod自动扩缩容 举例配置

基于Java GC暂停时间实现自动扩缩容可以用来优化应用性能避免由于GC暂停时间过长导致的应用延迟或卡顿。以下是一个基于GC暂停时间实现Pod自动扩缩容的示例配置假设使用Kubernetes和Prometheus作为监控工具。

创建自定义度量源

首先需要从Prometheus中获取GC暂停时间的指标数据。可以使用以下配置创建一个自定义度量源从Prometheus中获取GC暂停时间的指标数据

apiVersion: monitoring.coreos.com/v1  
kind: Prometheus  
metadata:  
  name: my-app-gc-pause-time  
spec:  
  http:  
    servicePort: 9091  
    metrics:  
    - name: gc_pause_time_seconds_sum  
      help: Total GC pause time in seconds.  
      expression: sum(irate(gc_pause_time_seconds_sum[5m])) by (pod)

上述配置中创建了一个Prometheus资源用于收集GC暂停时间的指标数据。gc_pause_time_seconds_sum表示GC暂停时间的总和使用irate()函数计算最近5分钟内每分钟的平均暂停时间并使用sum()函数对所有Pod进行聚合。最终通过by(pod)对每个Pod进行分组以便与Pod数量进行关联。

接下来使用以下配置创建一个HPA对象

apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app-deployment  
  minReplicas: 2  
  maxReplicas: 10  
  metrics:  
  - type: PodsMetricSource  
    podsMetricSource:  
      metricName: gc_pause_time_seconds_sum  
      targetAverageValue: 10 # 目标平均GC暂停时间秒  
    thresholds:  
    - type: PodsMetricSource  
      podsMetricSource:  
        metricName: gc_pause_time_seconds_sum  
        targetAverageValue: 2 # 每分钟GC暂停时间的目标计数可根据需求调整

上述配置中HPA使用了PodsMetricSource类型的度量源该度量源从Pod级别的度量指标中获取数据。

metricName设置为gc_pause_time_seconds_sum表示使用之前创建的自定义度量源来收集GC暂停时间的指标数据。

targetAverageValue设置了一个目标GC暂停时间的平均值。在此示例中目标GC暂停时间为2秒。

同时为了更好地控制扩缩容的灵敏度还添加了一个额外的阈值threshold该阈值使用相同的度量指标但设置了每分钟GC暂停时间的目标计数。在此示例中如果每分钟GC暂停时间超过2HPA将触发扩容操作。

请注意上述示例仅为了演示如何基于Java GC暂停时间实现Pod自动扩缩容并提供了基本的配置示例。实际应用中可能需要根据具体的应用场景、GC类型、监控工具等进行调整和优化。

扩展点

prometheus对所有pod进行流量监控 配置举例

Prometheus是一个开源的监控和告警工具它可以用于监控各种系统和应用程序的性能。要使用Prometheus监控所有Pod的流量您可以按照以下步骤进行设置

1. 安装和配置Prometheus首先您需要在您的Kubernetes集群中安装和配置Prometheus。这可以通过使用Kubernetes的Helm Chart或类似的工具来完成。您可以参考Prometheus的官方文档以获取更详细的安装和配置说明。

2. 创建ServiceMonitor资源在您的Kubernetes集群中为每个要监控的Pod或服务创建一个ServiceMonitor资源。ServiceMonitor资源允许Prometheus监控指定服务的指标。以下是一个示例ServiceMonitor资源的配置

apiVersion: monitoring.coreos.com/v1  
kind: ServiceMonitor  
metadata:  
  name: my-pod-service-monitor  
spec:  
  namespace: your-namespace # 指定要监控的Pod所属的命名空间  
  selector:  
    matchLabels:  
      app: your-pod-app-label # 指定要监控的Pod的标签  
  endpoints:  
  - basicAuth:  
      password:  
        name: your-pod-metrics-password # 指定metrics服务的密码  
        key: password  
      username: your-pod-metrics-username # 指定metrics服务的用户名  
    path: /metrics # 指定metrics服务的路径  
    port: your-pod-metrics-port # 指定metrics服务的端口

根据您的实际情况修改上述示例中的命名空间、标签、用户名、密码和端口等信息

3. 创建Prometheus目标在Prometheus的配置文件通常是prometheus.yml中创建一个新的目标用于监控Pod的流量。以下是一个示例配置

scrape_configs:  
  - job_name: 'pod-traffic'  
    kubernetes_sd_configs:  
      - role: pod  
    relabel_configs:  
      - source_labels: [__meta_kubernetes_pod_label_app]  
        target_label: pod_app_label  
      - source_labels: [__meta_kubernetes_pod_container_id]  
        target_label: pod_container_id  
      - source_labels: [__address__]  
        target_label: pod_address  
        regex: ([^:]+)(?::\d+)?  
      - source_labels: [__metrics_path__]  
        target_label: pod_metrics_path

上述配置中我们指定了job_name为pod-traffic并配置了kubernetes_sd_configs以发现Pod。relabel_configs用于重标记指标的元数据以便更方便地识别和组织指标数据。

4. 重新加载Prometheus配置保存并关闭Prometheus的配置文件后使用以下命令重新加载Prometheus配置

curl -X POST http://<prometheus-address>:9090/-/reload

其中<prometheus-address>是Prometheus服务的主机名或IP地址。

5. 监视Pod流量现在Prometheus将会收集所有指定Pod的流量指标并在其查询界面上显示它们。您可以使用Prometheus的查询语言PromQL来编写查询以获取有关Pod流量的度量标准和趋势等信息。例如以下查询可以获取所有Pod的总请求计数

sum(rate(http_requests_total{job="pod-traffic"}[1m])) by (pod_app_label)