Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs:translate service and pv recommendation to en #827

Merged
merged 3 commits into from
Jun 26, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,7 @@ Total Slack = Resource Slack + Usage Slack
The goal of resource optimization is to reduce Resource Slack and Usage Slack. The model provides four steps for reducing waste, in order from top to bottom:

1. Improving packing rate: Improving the packing rate can bring the Capacity and Request closer together. There are many ways to achieve this, such as:[Dynamic scheduler](/zh-cn/docs/tutorials/scheduling-pods-based-on-actual-node-load)、Tencent Cloud Native Node's node amplification function, etc.
2. Adjusting business specifications to reduce resource locking: Adjusting business specifications based on the weekly peak resource usage can reduce the Request to the weekly peak line.[Resource recommendation](/docs/tutorials/recommendation/resource-recommendation)[Replicas Recommendation](/docs/tutorials/recommendation/replicas-recommendation)can help applications achieve this goal.
2. Adjusting business specifications to reduce resource locking: Adjusting business specifications based on the weekly peak resource usage can reduce the Request to the weekly peak line.[Resource recommendation](/docs/tutorials/recommendation/resource-recommendation) and [Replicas Recommendation](/docs/tutorials/recommendation/replicas-recommendation)can help applications achieve this goal.
3. Adjusting business specifications + scaling to handle burst traffic: Based on the optimization of specifications, HPA can handle burst traffic to reduce the Request to the daily peak line. At this time, the target utilization rate of HPA is low, only to handle burst traffic, and automatic elasticity does not occur most of the time.
4. Adjusting business specifications + scaling to handle daily traffic changes: Based on the optimization of specifications, HPA can handle daily traffic to reduce the Request to the mean. At this time, the target utilization rate of HPA is equal to the average utilization rate of the application.

Expand Down Expand Up @@ -156,7 +156,9 @@ Currently, Crane supports the following Recommenders:
- [**Resource Recommendation**](/docs/tutorials/recommendation/resource-recommendation): By using the VPA algorithm to analyze the actual usage of applications, Crane recommends more appropriate resource configurations.
- [**Replicas Recommendation**](/docs/tutorials/recommendation/replicas-recommendation): By using the HPA algorithm to analyze the actual usage of applications, Crane recommends more appropriate replica numbers.
- [**HPA Recommendation**](/docs/tutorials/recommendation/hpa-recommendation): Scan the Workloads in the cluster and recommend HPA configurations for Workloads that are suitable for horizontal scaling.
- [**Idlenode Recommendation**](/docs/tutorials/recommendation/idlenode-recommendation): Scan for idle nodes in the k8s cluster.
- [**Idlenode Recommendation**](/docs/tutorials/recommendation/idlenode-recommendation): By scanning the state and utilization of nodes in the cluster, Node recommendation helps users find idle Kubernetes nodes.
- [**Service Recommendation**](/docs/tutorials/recommendation/service-recommendation): By scanning the running status of Services in the cluster, Service recommendation helps users find idle Kubernetes Services.
- [**PV Recommendation**](/docs/tutorials/recommendation/pv-recommendation): By scanning the running status of PV in the cluster, PV recommendation helps users find idle Kubernetes PV.

This article focuses on optimizing resource configurations for Workloads, therefore, the following section will focus on resource recommendations and replica recommendations.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -78,4 +78,4 @@ When deploying pod, limit and request use `gocrane.io/<$resourcename>:<$value>`
## suitable scene
In order to increase the load of nodes, some offline jobs or less important jobs can be scheduled and deployed to the cluster by using dynamic resources. Such jobs will use idle elastic resources.
With the watermark guarantee of QOS, when the node has a high load, it will be evicted and throttled first, and the utilization of the node will be improved on the premise of ensuring the stability of high-priority services.
See the section "Used with dynamic resources" in qos-interference-detection-and-active-avoidance.md.
See the section "Used with dynamic resources" in [Interference Detection and Active Avoidance](/docs/tutorials/colocation-with-enhanced-qos/qos-interference-detection-and-active-avoidance).
Original file line number Diff line number Diff line change
Expand Up @@ -238,4 +238,4 @@ In order to avoid the impact of active avoidance operations on high-priority ser
it is recommended to use PodQOS to associate workloads that use dynamic resources, so that only those workloads that use idle resources are affected when executing actions,
ensuring that The stability of the core business on the node.

For the content of dymamic resources, see qos-dynamic-resource-oversold-and-limit.md.
For the content of dymamic resources, see [Dynamic resource oversold and limit](/docs/tutorials/colocation-with-enhanced-qos/qos-dynamic-resource-oversold-and-limit).
34 changes: 18 additions & 16 deletions site/content/en/docs/Tutorials/Recommendation/pv-recommendation.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,15 @@ description: "Introduce for PV Recommendation"
weight: 17
---

PV 推荐通过扫描集群中 PV 的运行状况,帮助用户找到闲置的 Kubernetes PV。
PV recommendation scans the running status of PVs in the cluster to help users find idle Kubernetes PVs.

## 动机
## Motivation

通常在 Kubernetes 中我们会使用 PV + Workload 来自动创建和管理存储卷并将存储卷挂载到应用上,在日常的运营中难免会出现空闲或者空跑的存储卷,浪费了大量成本, PV 推荐尝试帮助用户找到这部分 PV 来实现成本优化。
In Kubernetes, we usually use PV + Workload to automatically create and manage storage volumes and attach them to applications.
However, in daily operations, idle or unused storage volumes may inevitably occur, wasting a lot of costs.
PV recommendation tries to help users find these PVs to achieve cost optimization.

## 推荐示例
## Sample

```yaml
apiVersion: analysis.crane.io/v1alpha1
Expand Down Expand Up @@ -52,22 +54,22 @@ status:
lastUpdateTime: "2023-06-14T08:55:25Z"
```

在该示例中:
In this sample:

- 推荐的 TargetRef 指向了 PV: pvc-6ce24277-24e9-4fcf-8e8a-f9bdb5694134
- 推荐类型为 PV 推荐
- action Delete,这里只是给出建议
- The recommended TargetRef points to PV: pvc-6ce24277-24e9-4fcf-8e8a-f9bdb5694134
- The recommendation type is PV recommendation
- The action is to Delete, and it is only a suggestion provided here.

## 实现原理
## Implement

PV 推荐按以下步骤完成一次推荐过程:
PV recommendation completes a recommendation process using the following steps:

1. 扫描集群中所有 PV,找到 PV 对应的 Pod 列表
2. 如果 PV 没有对应的 PVC,则判断为闲置 PV
3. 如果没有 Pod 关联这个 PV PVC,则判断为闲置 PVC
1. Scan all PVs in the cluster and find the list of Pods corresponding to each PV.
2. If the PV does not have a corresponding PVC, it is considered an idle PV.
3. If no Pods are associated with this PV and PVC, it is considered an idle PVC.

## 参数配置
## Configuration

目前 PV 推荐没有参数配置。
Currently, there is no parameter configuration for PV recommendation.

如何更新推荐的配置请参考:[**推荐框架**](/zh-cn/docs/tutorials/recommendation/recommendation-framework)
How to update recommendation configuration please refer to:[**Recommendation Framework**](/docs/tutorials/recommendation/recommendation-framework)
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,15 @@ description: "Introduce for Service Recommendation"
weight: 16
---

Service 推荐通过扫描集群中 Service 的运行状况,帮助用户找到闲置的 Kubernetes Service。
Service recommendation scans the running status of Services in the cluster to help users find idle Kubernetes Services.

## 动机
## Motivation

通常在 Kubernetes 中我们会使用 Service + Workload 来自动创建和管理负载均衡并将负载均衡挂载到应用上,在日常的运营中难免会出现空闲和低利用率的负载均衡,浪费了大量成本,Service 推荐尝试帮助用户找到这部分 Service 来实现成本优化。
In Kubernetes, we usually use Service + Workload to automatically create and manage load balancing and attach it to applications.
However, in daily operations, idle and low utilization load balancing inevitably occur, wasting a lot of costs.
Service recommendation tries to help users find these Services to achieve cost optimization.

## 推荐示例
## Sample

```yaml
apiVersion: analysis.crane.io/v1alpha1
Expand Down Expand Up @@ -54,23 +56,24 @@ status:
lastUpdateTime: "2023-06-12T11:52:23Z"
```

在该示例中:
In this sample:

- 推荐的 TargetRef 指向了 Servicenginx
- 推荐类型为 Service 推荐
- action Delete,这里只是给出建议
- The recommended TargetRef points to the Service: nginx.
- The recommendation type is Service recommendation.
- The action is to Delete, and it is only a suggestion provided here.

## 实现原理
## Implement

Service 推荐按以下步骤完成一次推荐过程:
Service recommendation completes a recommendation process using the following steps:

1. 扫描集群中所有 LoadBalancer 类型的 Service
2. 如果 Service 对应的 endpoints 中有 Address 或者 NotReadyAddresses,则不是限制的 Service
3. 依据 Service 推荐中流量相关 metric 检测 Service 是否小于阈值水位,如果小于水位则判定为闲置节点
1. Scan all LoadBalancer-type Services in the cluster.
2. If the endpoints corresponding to the Service have an Address or NotReadyAddresses, it is not a restricted Service.
3. Based on the traffic-related metrics in Service recommendation, check whether the Service is below the threshold level. If it is below the threshold level, it is determined to be an idle node.

## 如何验证推荐结果的准确性

以下是判断节点资源阈值水位的 Prom query,验证时把 node 替换成实际的节点名
## How to verify the accuracy of recommendation results

The following is the Prom query for determining the threshold level of node resources. When verifying, replace "node" with the actual node name.

```go
// Container network cumulative count of bytes received
Expand All @@ -79,19 +82,19 @@ queryFmtNetReceiveBytes = `sum(rate(container_network_receive_bytes_total{namesp
queryFmtNetTransferBytes = `sum(rate(container_network_transmit_bytes_total{namespace="%s",pod=~"%s",container!=""}[3m]))`
```

## 支持的资源类型
## Accepted resources

只支持 Service 类型,目前只会对 LoadBalancer 类型的 Service 进行分析。
Only Service type is supported, and currently, only LoadBalancer-type Services will be analyzed.

## 参数配置
## Configuration

| 配置项 | 默认值 | 描述 |
|----------|-----|---------------------------------|
| net-receive-bytes | 0 | Service 对应 Pods 接受到的网络请求 bytes,默认不检查 |
| net-receive-percentile | 0.99 | 计算接受到的网络请求时的 Percentile |
| net-transfer-bytes | 0 | Service 对应 Pods 传输的网络请求 bytes,默认不检查 |
| net-transfer-percentile | 0.99 | 计算传输的网络请求时的 Percentile |
| Configuration items | Default value | Description |
|----------|-----|--------------------------------------|
| net-receive-bytes | 0 | The amount of network request bytes received by the Pods corresponding to the Service, which is not checked by default. |
| net-receive-percentile | 0.99 | The percentile used to calculate the amount of network requests received |
| net-transfer-bytes | 0 | The amount of network request bytes transmitted by the Pods corresponding to the Service, which is not checked by default. |
| net-transfer-percentile | 0.99 | The percentile used when calculating the amount of network requests transmitted. |

注意,当 pod 配置了 liveness/readness probe 后,kubelet 的探测会带来一定的容器流量,因此流量的阈值需要设置的稍微大一些,可结合具体监控数据配置。
Note that when a pod is configured with a liveness/readiness probe, the kubelet's probing will bring some container traffic, so the threshold for traffic needs to be set slightly higher. The configuration can be combined with specific monitoring data.

如何更新推荐的配置请参考:[**推荐框架**](/zh-cn/docs/tutorials/recommendation/recommendation-framework)
How to update recommendation configuration please refer to:[**Recommendation Framework**](/docs/tutorials/recommendation/recommendation-framework)
Original file line number Diff line number Diff line change
Expand Up @@ -159,7 +159,9 @@ patchData=`kubectl get recommend workloads-rule-replicas-rckvb -n default -o jso
- [**资源推荐**](/zh-cn/docs/tutorials/recommendation/resource-recommendation): 通过 VPA 算法分析应用的真实用量推荐更合适的资源配置
- [**副本数推荐**](/zh-cn/docs/tutorials/recommendation/replicas-recommendation): 通过 HPA 算法分析应用的真实用量推荐更合适的副本数量
- [**HPA 推荐**](/zh-cn/docs/tutorials/recommendation/hpa-recommendation): 扫描集群中的 Workload,针对适合适合水平弹性的 Workload 推荐 HPA 配置
- [**闲置节点推荐**](/zh-cn/docs/tutorials/recommendation/idlenode-recommendation): 扫描集群中的闲置节点
- [**闲置节点推荐**](/zh-cn/docs/tutorials/recommendation/idlenode-recommendation): 通过扫描集群中节点的状态和利用率,帮助用户找到闲置的 Kubernetes node
- [**Service 推荐**](zh-cn/docs/tutorials/recommendation/service-recommendation): 通过扫描集群中 Service 的运行状况,帮助用户找到闲置的 Kubernetes Service
- [**PV 推荐**](zh-cn/docs/tutorials/recommendation/pv-recommendation): 通过扫描集群中 PV 的运行状况,帮助用户找到闲置的 Kubernetes PV

本文重点讨论 Workload 的资源配置优化,因此下面重点介绍资源推荐和副本推荐。

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -76,4 +76,4 @@ spec:
## 适配场景
为了提升节点的负载,可以将一些离线作业或者重要性较低的作业通过使用弹性资源的方式调度部署到集群中,这类作业会使用空闲的弹性资源,
搭配QOS的水位线保障,在节点出现负载较高的时候,也会优先被驱逐和压制,在保证高优先级业务稳定的前提下提升节点利用率。
可以参见qos-interference-detection-and-active-avoidance.zh.md中"与弹性资源搭配使用"部分的内容。
可以参见[干扰检测和主动回避](/zh-cn/docs/tutorials/colocation-with-enhanced-qos/qos-interference-detection-and-active-avoidance.zh)中"与弹性资源搭配使用"部分的内容。
Original file line number Diff line number Diff line change
Expand Up @@ -246,4 +246,4 @@ memory_total_utilization| node mem utilization percent
为了避免主动回避操作对于高优先级业务的影响,比如误驱逐了重要业务,建议使用PodQOS关联使用了弹性资源的workload,这样在执行动作的时候只会影响这些使用了空闲资源的workload,
保证了节点上的核心业务的稳定。

弹性资源的内容可以参见qos-dynamic-resource-oversold-and-limit.zh.md
弹性资源的内容可以参见[弹性资源超卖和限制](/zh-cn/docs/tutorials/colocation-with-enhanced-qos/qos-dynamic-resource-oversold-and-limit.zh)