Wazuh kubernetes deployment must be valid for all environments (EKS, GKE, etc)

[alberpilot]

The Wazuh Kubernetes repository was designed for local and EKS environments. We should identify what dependencies exist and adapt them to make the repository universal for all kinds of environments, not only for EKS.

[vcerenu]

I was reviewing the creation of the managed k8s cluster in Google Cloud and it exceeded the limit of CPU and IP addresses of quota, so I sent a request to increase it.

[xtylez-eskardinha]

Hi everyone, I'm currently working on it, I was able to deploy this on GKE (Not with autopilot due to quotas) and only AKS is missing for the 3 major cloud providers. I'll keep you updated and when everything works I'll PR everything.

[mac-chaffee]

Really applications such as Wazuh should not include cloud-provider-specific things since Kubernetes itself provides cloud-agnostic constructs. I'm having a lot of trouble deploying Wazuh to a vanilla Kubernetes cluster for this reason. Some areas for improvement:

• Applications should not ship with their own StorageClass. The fact that EKS doesn't include a default storageclass is unfortunate, but that's something which should typically be managed outside of individual applications like Wazuh.
• It's best for applications not to explicitly specify a storageClassName in PVCs. That way the default storage class is used, which is best for most environments.
• Applications should not have an opinion on how ingress traffic is handled since it varies per cluster. Using multiple services of type: LoadBalancer is actually one of the more expensive options for cloud providers. Allowing users to choose between LoadBalancer IPs or Ingresses would be ideal.