您可以通过命令行或配置替换功能来扩缩在 Kubernetes 中运行的大多数服务。您可以在 overrides.yaml
文件中为 Apigee Hybrid 运行时服务设置扩缩参数。
服务 | 实施形式 | 扩缩 |
---|---|---|
Cassandra | ApigeeDatastore (CRD) | 请参阅扩缩 Cassandra。 |
Ingress/LoadBalancer | 部署 | Cloud Service Mesh 使用 Pod 横向自动扩缩 (HPA)。 |
Logger | DaemonSet | DaemonSet 会管理所有节点上的 Pod 副本,因此它们会在您扩缩 Pod 时自行扩缩。 |
MART Apigee Connect Watcher |
ApigeeOrganization (CRD) | 如需通过配置进行扩缩,请增加 mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 这些 Deployment 使用 Pod 横向自动扩缩器进行自动扩缩。将 Deployment 对象的 如需详细了解如何设置配置属性,请参阅管理运行时平面组件。 |
Runtime Synchronizer UDCA |
ApigeeEnvironment (CRD) | 如需通过配置进行扩缩,请增加替换文件中 udca 、synchronizer 和/或 runtime 这几节的 replicaCountMin 属性的值。例如:synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 注意:这些更改适用于替换文件中的所有环境。如果您要为每个环境自定义扩缩功能,请参阅下文中的高级配置。 Deployment 使用 Pod 横向自动扩缩器进行自动扩缩。将 Deployment 对象的 如需详细了解如何设置配置属性,请参阅管理运行时平面组件。 |
高级配置
在某些情况下,您可能需要使用高级扩缩选项。示例场景包括:
- 为每个环境设置不同的扩缩选项。例如,其中 env1 的
minReplica
为 5,而 env2 的minReplica
为 2。 - 为环境中的每个组件设置不同的扩缩选项。例如,其中
udca
组件的maxReplica
为 5,synchronizer
组件的maxReplica
为 2。
以下示例展示了如何使用 kubernetes patch
命令更改 runtime
组件的 maxReplicas
属性:
- 创建要用于该命令的环境变量:
export ENV=my-environment-name export NAMESPACE=apigee #the namespace where apigee is deployed export COMPONENT=runtime #can be udca or synchronizer export MAX_REPLICAS=2 export MIN_REPLICAS=1
- 应用补丁程序。请注意,以下示例假定
kubectl
位于您的PATH
中:kubectl patch apigeeenvironment -n $NAMESPACE \ $(kubectl get apigeeenvironments -n $NAMESPACE -o jsonpath='{.items[?(@.spec.name == "'$ENV'" )]..metadata.name}') \ --patch "$(echo -e "spec:\n components:\n $COMPONENT:\n autoScaler:\n maxReplicas: $MAX_REPLICAS\n minReplicas: $MIN_REPLICAS")" \ --type merge
- 确认更改:
kubectl get hpa -n $NAMESPACE
基于环境的扩缩
默认情况下,在组织级层描述扩缩。您可以通过在 overrides.yaml
文件中指定特定于环境的扩缩来替换默认设置,如以下示例所示:
envs: # Apigee environment name - name: test components: # Environment-specific scaling override # Otherwise, uses scaling defined at the respective root component runtime: replicaCountMin: 2 replicaCountMax: 20
基于指标的扩缩
使用基于指标的扩缩时,运行时可以使用 CPU 和应用指标来扩缩 apigee-runtime
Pod。Kubernetes 水平 Pod 自动扩缩器 (HPA) API 使用 hpaBehavior
字段来配置目标服务的纵向扩容和纵向缩容行为。基于指标的扩缩不适用于混合部署中的任何其他组件。
可以根据以下指标调整扩缩:
指标 | 测量 | 注意事项 |
---|---|---|
serverNioTaskWaitTime | 在 http 层代理请求的运行时实例中处理队列的平均等待时间(以毫秒为单位)。 | 该指标衡量代理请求和响应的数量和载荷大小的影响。 |
serverMainTaskWaitTime | 代理请求的运行时实例中处理政策的处理队列的平均等待时间(以毫秒为单位)。 | 该指标衡量附加到代理请求流的政策的复杂性的影响。 |
overrides.yaml
中 runtime
节的以下示例展示了在混合实现中扩缩 apigee-runtime
pod 的标准参数(和允许的范围):
hpaMetrics: serverMainTaskWaitTime: 400M (300M to 450M) serverNioTaskWaitTime: 400M (300M to 450M) targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 (30 - 180) value: 20 (5 - 50) pods: periodSeconds: 60 (30 - 180) value: 2 (1 - 15) selectPolicy: Min stabilizationWindowSeconds: 120 (60 - 300) scaleUp: percent: periodSeconds: 60 (30 - 120) value: 20 (5 - 100) pods: periodSeconds: 60 (30 - 120) value: 4 (2 - 15) selectPolicy: Max stabilizationWindowSeconds: 30 (30 - 120)
配置更积极的扩缩
增加纵向扩容政策的 percent
和 pods
值将产生更积极的纵向扩容政策。同样,增加 scaleDown
中的 percent
和 pods
值会导致积极的纵向缩容政策。例如:
hpaMetrics: serverMainTaskWaitTime: 400M serverNioTaskWaitTime: 400M targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 value: 20 pods: periodSeconds: 60 value: 4 selectPolicy: Min stabilizationWindowSeconds: 120 scaleUp: percent: periodSeconds: 60 value: 30 pods: periodSeconds: 60 value: 5 selectPolicy: Max stabilizationWindowSeconds: 30
在上面的示例中,scaleDown.pods.value
增加到 5,scaleUp.percent.value
增加到 30,scaleUp.pods.value
增加到 5。
配置更保守的扩缩
hpaBehavior
配置值也可以降低,以实施更保守的纵向扩容和纵向缩容政策。例如:
hpaMetrics: serverMainTaskWaitTime: 400M serverNioTaskWaitTime: 400M targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 value: 10 pods: periodSeconds: 60 value: 1 selectPolicy: Min stabilizationWindowSeconds: 180 scaleUp: percent: periodSeconds: 60 value: 20 pods: periodSeconds: 60 value: 4 selectPolicy: Max stabilizationWindowSeconds: 30
在上面的示例中,scaleDown.percent.value
减少到 10,scaleDown.pods.value
减少到 1,scaleUp.stablizationWindowSeconds
增加到 180。
如需详细了解使用 hpaBehavior
字段的基于指标的扩缩,请参阅扩缩政策。
停用基于指标的扩缩
虽然基于指标的扩缩默认启用且无法完全停用,但您可以在不触发基于指标的扩缩的级别配置指标阈值。产生的扩缩行为与基于 CPU 的扩缩相同。例如,您可以使用以下配置来防止触发基于指标的扩缩:
hpaMetrics: serverMainTaskWaitTime: 4000M serverNioTaskWaitTime: 4000M targetCPUUtilizationPercentage: 75 hpaBehavior: scaleDown: percent: periodSeconds: 60 value: 10 pods: periodSeconds: 60 value: 1 selectPolicy: Min stabilizationWindowSeconds: 180 scaleUp: percent: periodSeconds: 60 value: 20 pods: periodSeconds: 60 value: 4 selectPolicy: Max stabilizationWindowSeconds: 30
问题排查
本部分介绍在配置扩缩和自动扩缩时可能会遇到的常见错误的问题排查方法。
HPA 针对指标值显示 unknown
如果基于指标的扩缩不起作用,并且 HPA 显示 unknown
的指标值,请使用以下命令检查 HPA 输出:
kubectl describe hpa HPA_NAME
运行该命令时,请将 HPA_NAME 替换为您要查看的 HPA 的名称。
输出将显示服务的 CPU 目标和利用率,表示 CPU 扩缩在没有基于指标的扩缩的情况下有效。如需了解使用多个参数的 HPA 行为,请参阅根据多个指标进行扩缩。