search

cloudfoundry / cf-for-k8s

The open source deployment manifest for Cloud Foundry on Kubernetes
Apache License 2.0
301 stars 115 forks source link

Options to include Istio observability tools #623

Open braunsonm opened 3 years ago

braunsonm commented 3 years ago

Is your feature request related to a problem? Please describe. Understanding cf-for-k8s networking can be difficult without observability. Istio has solutions for this however cf-for-k8s had no way to enable or use them.

Describe the solution you'd like Have an option to deploy some of the Istio observability tools such as Kiali, Jaeger or Zipkin. Or at least make the deployment compatible. I personally had issues seeing anything with the included deployments of Kiali and Zipkin.

Describe alternatives you've considered Unfortunately there is none. As I said trying to roll your own seems to not work very well because of whatever customization cf-for-k8s does. For instance Zipkin will only report the app ID (not name) from the ingress gateway not proper pod-pod communications

cf-gitbot commented 3 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/176934577

The labels on this github issue will be updated when the story is started.

loewenstein commented 3 years ago

I wonder if loosening the coupling of cf-k8s-networking on this particular Istio installation/configuration and making the Istio in cf-for-k8s just the batteries included variant would be an alternative worth considering.

This would allow operators to use an Istio installation/configuration that is more to their liking.

@cloudfoundry/cf-networking @cloudfoundry/cf-release-integration WDYT?

Birdrock commented 3 years ago

@loewenstein We'll need to discuss as a team, but this sounds reasonable. As long as the out-of-the-box configuration doesn't suffer, I see additional configuration avenues as a benefit. Overall, now that we have a working product available, I'm trying to push towards opportunities for modularity. If we can maintain the ease of initial setup so people can dip their toe in the pool, I'm in favor of providing configuration points for more advanced operators.

braunsonm commented 3 years ago

The same could be said about the logging capabilities of cf-for-k8s. It would be nice to have the ability to ship them to another stack like ELK. I think I do remember this was talked about on a SIG call though. Just re-iterating it.

I think there hasn't been much work on observability in cf-for-k8s but if that's something you would rather defer to operators to figure out instead of being batteries included then that's acceptable too. Modularity would help as long as it's still clear or easy to wire up with existing clusters.