PHP-FPM在Kubernetes的FinOps优化：基于HPA的伸缩策略与闲置资源回收
各位同学，大家好！今天我们来聊聊如何在Kubernetes环境中，针对PHP-FPM应用进行FinOps优化。FinOps，简单来说，就是云计算环境下的财务优化，目标是在保证应用性能的前提下，尽可能地降低云资源的成本。我们将重点关注基于HPA（Horizontal Pod Autoscaler）的伸缩策略以及闲置资源的回收，并通过代码示例和详细的配置说明，帮助大家更好地理解和应用这些技术。
1. 理解PHP-FPM与Kubernetes
首先，我们需要明确PHP-FPM在Kubernetes中的角色。PHP-FPM（FastCGI Process Manager）是一个PHP解释器的进程管理器，负责接收Web服务器（如Nginx）的请求，并执行PHP代码。在Kubernetes中，PHP-FPM通常运行在Pod中，由Deployment或StatefulSet进行管理。
- Pod: Kubernetes中最小的可部署单元，包含一个或多个容器。在这里，一个Pod通常包含一个PHP-FPM容器和一个Web服务器容器（比如Nginx）。
- Deployment/StatefulSet: 用于管理Pod的副本数量，并提供滚动更新等功能。
- Service: 为Pod提供稳定的网络接口，允许其他应用访问PHP-FPM服务。
2. HPA：自动伸缩的关键
HPA是Kubernetes提供的自动伸缩机制，它可以根据Pod的CPU利用率、内存使用率等指标，自动调整Pod的副本数量，从而应对流量的变化。为了更好地进行FinOps优化，我们需要深入了解HPA的工作原理以及如何配置它。
HPA工作原理:
HPA控制器定期查询Metrics Server（或Custom Metrics API）获取Pod的资源使用情况，然后根据预定义的伸缩策略，计算出期望的Pod副本数量，并更新Deployment/StatefulSet的副本数。
配置HPA:
一个典型的HPA配置如下：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: php-fpm-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: php-fpm-deployment
minReplicas: 2 # 最小副本数
maxReplicas: 10 # 最大副本数
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70 # 目标CPU利用率
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80 # 目标内存利用率配置详解:
scaleTargetRef: 指定HPA要控制的Deployment/StatefulSet。minReplicas: Pod的最小副本数，即使流量很低，也要保持至少这么多的Pod运行。maxReplicas: Pod的最大副本数，防止流量过大导致资源耗尽。metrics: 定义伸缩的指标。这里我们使用了CPU和内存利用率。target.averageUtilization: 目标CPU和内存利用率。当实际利用率超过这个值时，HPA会增加Pod副本数量；当实际利用率低于这个值时，HPA会减少Pod副本数量。
关键点:
- 选择合适的指标: CPU和内存利用率是最常用的指标，但也需要根据应用的特性进行调整。例如，对于IO密集型应用，可以考虑使用磁盘IOPS作为指标。
- 设置合理的阈值:
minReplicas,maxReplicas,averageUtilization的值需要根据实际情况进行调整。过高的averageUtilization可能导致性能下降，过低的averageUtilization可能导致资源浪费。
3. 基于自定义指标的HPA伸缩策略
除了CPU和内存利用率，我们还可以使用自定义指标来控制HPA。例如，我们可以根据PHP-FPM的活跃连接数来伸缩Pod。
步骤:
-
暴露PHP-FPM的活跃连接数: 我们可以通过PHP-FPM的status页面来获取活跃连接数，然后将其暴露为Prometheus指标。
首先，确保
php-fpm.conf中开启了status页面：pm.status_path = /status然后，配置Nginx将
/status请求转发到PHP-FPM：location /status { fastcgi_pass php-fpm:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } -
安装和配置Prometheus: Prometheus是一个流行的监控系统，可以从PHP-FPM的status页面抓取数据。
安装Prometheus的步骤这里省略，假设你已经安装好了Prometheus。我们需要配置Prometheus从Nginx抓取
/status页面：scrape_configs: - job_name: 'php-fpm' static_configs: - targets: ['nginx:80'] # 替换为你的Nginx Service的地址 labels: app: php-fpm然后，我们需要配置Prometheus将
/status页面中的数据转换为Prometheus指标。可以使用nginx-module-vts或者编写自定义的Exporter来实现。这里我们假设已经有一个名为php_fpm_active_connections的Prometheus指标，表示PHP-FPM的活跃连接数。 -
部署Metrics Server: Metrics Server是Kubernetes的组件，负责从Prometheus获取自定义指标。我们需要安装Metrics Server，并配置它从Prometheus抓取
php_fpm_active_connections指标。具体的安装和配置步骤可以参考Metrics Server的官方文档。
-
创建HPA: 现在我们可以创建HPA，根据
php_fpm_active_connections指标来伸缩Pod。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-fpm-hpa-custom spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: php-fpm-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: php_fpm_active_connections # 自定义指标名称 target: type: AverageValue averageValue: 50 # 每个Pod的目标活跃连接数
配置详解:
type: Pods: 指定使用Pod级别的指标。pods.metric.name: 自定义指标的名称，这里是php_fpm_active_connections。pods.target.averageValue: 每个Pod的目标活跃连接数。当所有Pod的平均活跃连接数超过这个值时，HPA会增加Pod副本数量；当平均活跃连接数低于这个值时，HPA会减少Pod副本数量。
关键点:
- 指标的准确性: 自定义指标的准确性直接影响HPA的伸缩效果。确保Prometheus能够正确抓取和转换数据。
- 指标的选择: 选择与应用性能密切相关的指标。例如，对于高并发应用，活跃连接数可能比CPU利用率更有效。
- 指标的单位: 确保指标的单位正确。例如，如果
php_fpm_active_connections的单位是连接数/秒，则需要将其转换为连接数。
4. 闲置资源回收：降低成本的有效手段
即使使用了HPA，仍然可能存在闲置资源。例如，在流量低谷期，即使Pod的数量已经缩减到最小值，仍然可能存在大量的CPU和内存没有被使用。为了进一步降低成本，我们可以使用以下技术来回收闲置资源：
4.1. 垂直Pod自动伸缩 (VPA)
VPA可以自动调整Pod的CPU和内存请求（request）和限制（limit）。它可以根据Pod的历史资源使用情况，动态地调整Pod的资源需求，从而避免资源浪费。
VPA工作原理:
VPA控制器定期监控Pod的资源使用情况，并根据预定义的策略，计算出Pod的推荐资源请求和限制。然后，它可以自动更新Pod的配置，或者生成建议，让管理员手动更新Pod的配置.
配置VPA:
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: php-fpm-vpa
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: php-fpm-deployment
updatePolicy:
updateMode: "Auto" # "Off", "Initial", "Recreate", "Auto"
resourcePolicy:
containerPolicies:
- containerName: '*' # 对所有容器生效
mode: "Auto" # "Off", "Initial", "Auto"
minAllowed:
cpu: "100m" # 允许的最小CPU request
memory: "128Mi" # 允许的最小内存 request
maxAllowed:
cpu: "2" # 允许的最大CPU request
memory: "2Gi" # 允许的最大内存 request配置详解:
targetRef: 指定VPA要控制的Deployment/StatefulSet。updatePolicy.updateMode: 指定VPA的更新模式。"Off": VPA只提供建议，不自动更新Pod。"Initial": VPA只在Pod创建时更新Pod的配置。"Recreate": VPA会删除并重新创建Pod，以更新Pod的配置。不推荐，会导致短暂的服务中断。"Auto": VPA自动更新Pod的配置。
resourcePolicy.containerPolicies: 定义容器的资源策略。containerName: 容器的名称，"*"表示对所有容器生效。mode: 资源策略的模式。"Off": 不调整该容器的资源。"Initial": 只在容器创建时调整资源。"Auto": 自动调整容器的资源。
minAllowed: 允许的最小资源请求。maxAllowed: 允许的最大资源请求。
关键点:
- 选择合适的更新模式:
"Auto"模式最方便，但也可能导致Pod频繁重启，影响服务稳定性。建议先使用"Off"模式观察一段时间，然后根据实际情况选择合适的更新模式。 - 设置合理的最小和最大资源请求:
minAllowed和maxAllowed的值需要根据应用的特性进行调整。过小的minAllowed可能导致应用崩溃，过大的maxAllowed可能导致资源浪费。 - 监控VPA的效果: 监控VPA的推荐资源请求和实际资源使用情况，及时调整VPA的配置。
4.2. 资源QoS (Quality of Service)
Kubernetes提供了三种资源QoS等级：Guaranteed, Burstable, BestEffort。我们可以根据应用的特性，为Pod设置合适的QoS等级，从而更好地利用资源。
- Guaranteed: Pod的CPU和内存请求等于限制。这种Pod具有最高的优先级，可以保证资源的可用性。适用于对性能要求非常高的应用。
- Burstable: Pod的CPU和内存请求小于限制。这种Pod可以在资源空闲时使用超出请求的资源，但在资源紧张时可能会被驱逐。适用于对性能有一定要求，但可以容忍短暂的性能下降的应用。
- BestEffort: Pod没有设置CPU和内存请求和限制。这种Pod具有最低的优先级，在资源紧张时最容易被驱逐。适用于对性能要求不高的应用。
配置资源QoS:
apiVersion: apps/v1
kind: Deployment
metadata:
name: php-fpm-deployment
spec:
template:
spec:
containers:
- name: php-fpm
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"在这个例子中，Pod的CPU和内存请求小于限制，因此它的QoS等级是Burstable。
关键点:
- 根据应用特性选择合适的QoS等级: 对于对性能要求非常高的应用，应该选择Guaranteed等级；对于对性能要求不高的应用，可以选择BestEffort等级。
- 合理设置资源请求和限制: 资源请求决定了Pod的调度优先级，资源限制决定了Pod可以使用的最大资源量。
4.3. 利用率低的节点驱逐
Kubernetes 1.21版本之后，引入了NodeResourceFit的驱逐功能，在节点资源利用率低的情况下，可以将Pod驱逐到其他资源充足的节点，从而释放资源，关闭节点。
需要启用NodeResourceFit特性门控，并配置KubeletConfiguration。
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
NodeResourceFit: true同时配置驱逐策略：
apiVersion: v1
kind: Pod
metadata:
name: pod-example
spec:
containers:
- name: busybox-container
image: busybox:latest
command: ["sleep", "3600"]
priorityClassName: high-priority # 优先级高的Pod不会被驱逐
terminationGracePeriodSeconds: 0关键点:
- 节点资源利用率监控: 需要监控节点的CPU、内存等资源利用率，才能判断节点是否处于闲置状态。
- Pod优先级: 需要设置Pod的优先级，防止重要的Pod被驱逐。
- 驱逐策略: 需要根据实际情况调整驱逐策略，防止频繁驱逐导致服务不稳定。
5. 代码示例：动态调整PHP-FPM配置
为了更好地利用资源，我们还可以动态调整PHP-FPM的配置，例如调整pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers等参数。
我们可以编写一个Sidecar容器，定期监控Pod的资源使用情况，并根据预定义的策略，动态调整PHP-FPM的配置。
步骤:
-
编写Sidecar容器: Sidecar容器可以使用Python、Go等语言编写。它需要能够：
- 获取Pod的资源使用情况（例如CPU和内存利用率）。
- 读取PHP-FPM的配置文件。
- 修改PHP-FPM的配置文件。
- 重启PHP-FPM进程。
-
部署Sidecar容器: 将Sidecar容器添加到Pod中。
apiVersion: apps/v1 kind: Deployment metadata: name: php-fpm-deployment spec: template: spec: containers: - name: php-fpm image: php-fpm:latest - name: php-fpm-configurator image: php-fpm-configurator:latest # 替换为你的Sidecar容器镜像 volumeMounts: - name: php-fpm-config mountPath: /usr/local/etc/php/conf.d volumes: - name: php-fpm-config configMap: name: php-fpm-config # PHP-FPM的配置文件 -
配置ConfigMap: 将PHP-FPM的配置文件存储在ConfigMap中。
apiVersion: v1 kind: ConfigMap metadata: name: php-fpm-config data: www.conf: | [www] listen = 9000 user = www-data group = www-data pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3
代码示例 (Python):
import os
import time
import psutil
import subprocess
CONFIG_FILE = "/usr/local/etc/php/conf.d/www.conf"
def get_cpu_usage():
return psutil.cpu_percent()
def adjust_php_fpm_config(cpu_usage):
max_children = 5
start_servers = 2
min_spare_servers = 1
max_spare_servers = 3
if cpu_usage > 80:
max_children = 10
start_servers = 5
min_spare_servers = 3
max_spare_servers = 7
elif cpu_usage < 20:
max_children = 3
start_servers = 1
min_spare_servers = 1
max_spare_servers = 2
with open(CONFIG_FILE, "r") as f:
config = f.readlines()
new_config = []
for line in config:
if "pm.max_children" in line:
new_config.append(f"pm.max_children = {max_children}n")
elif "pm.start_servers" in line:
new_config.append(f"pm.start_servers = {start_servers}n")
elif "pm.min_spare_servers" in line:
new_config.append(f"pm.min_spare_servers = {min_spare_servers}n")
elif "pm.max_spare_servers" in line:
new_config.append(f"pm.max_spare_servers = {max_spare_servers}n")
else:
new_config.append(line)
with open(CONFIG_FILE, "w") as f:
f.writelines(new_config)
print("PHP-FPM config adjusted")
subprocess.run(["/usr/sbin/php-fpm", "-t"])
subprocess.run(["/usr/sbin/php-fpm", "-R"])
while True:
cpu_usage = get_cpu_usage()
print(f"CPU Usage: {cpu_usage}%")
adjust_php_fpm_config(cpu_usage)
time.sleep(60)关键点:
- 安全地修改配置文件: 在修改配置文件之前，先备份配置文件，并在修改之后进行语法检查。
- 平滑重启PHP-FPM: 使用
php-fpm -R命令平滑重启PHP-FPM，避免服务中断。 - 监控调整效果: 监控调整后的PHP-FPM性能，及时调整调整策略。
6. 总结：优化策略的灵活运用
通过以上的讲解，我们了解了如何在Kubernetes环境中，针对PHP-FPM应用进行FinOps优化。关键在于灵活运用HPA的伸缩策略，并结合VPA和资源QoS来回收闲置资源。同时，还可以通过Sidecar容器动态调整PHP-FPM的配置，进一步提升资源利用率。希望大家能够根据自己的实际情况，选择合适的优化策略，降低云资源的成本，实现真正的FinOps！