Nexucis
commented
1 month ago Yes that's a good idea definitely. Would you like to help on this area @indigo423 ?
Open indigo423 opened 1 month ago
Nexucis
commented
1 month ago Yes that's a good idea definitely. Would you like to help on this area @indigo423 ?
indigo423
commented
1 month ago Yes that's a good idea definitely. Would you like to help on this area @indigo423 ?
Yes, I'm interested in helping to improve. I just saw it when I was working on the PR previously. I would say this is probably not something with a high priority. As I'm going now into the helm chart user role, using the Helm chart and getting my hands dirty on Perses itself, I can imagine we discover more important things to improve.
Nexucis
commented
1 month ago cool !
Would be great to support the whole configuration at some point.
Proposal
This field was under-specified, and its meaning varied across different implementations. It also did not support dual-stack networking, which led to its deprecation and potential removal in future API versions. To address this deprecation in a Helm chart, you should consider the following steps:
Remove the loadBalancerIP field: If your Helm chart includes the loadBalancerIP field, remove it from the service definition. This field is no longer recommended for use.
Use Provider-Specific Annotations: Instead of using loadBalancerIP, you should use provider-specific annotations to specify the load balancer IP address. Different cloud providers may have their own annotations for setting the load balancer IP.
Consider Using loadBalancerClass: If applicable, you can specify a custom load balancer implementation using the .spec.loadBalancerClass field. This allows you to use a load balancer other than the default provided by the cloud provider. By following these steps, you can ensure your Helm chart is compatible with Kubernetes v1.24 and future versions.