Kubernetes support #933
Replies: 1 comment
-
One of the things I've been thinking about is logging. I use Kubernetes, and all my applications log to standard logs, so in Rancher, Lens, kubectl, whatever I can easily check the logs. Additionally, I have Vector collect and push those logs to a log aggregator, so that I have a nice web UI with dropdowns to choose what service I want to view logs for, etc. With the current file logging, it can still be done, but I would need to setup a dedicated Vector instance to pull from the Pelican PV, do some custom labeling to fit with the other apps, and then aggregate it. I personally believe it'd make more sense if Pelican was built with Docker in mind, not necessarily Kubernetes, but if it's built to follow Docker standards, then it should be easy to integrate into a K8s solution. By this, I am specifically referring to again standard logging instead of files, and additionally, a more segmented approach, instead of a single monolithic container helps, as each process' logs will be divided up and labeled by the container's name automatically in K8s and Docker. I feel like these 2 aspects are the things that most greatly affect how suitable Pelican is for running on Kubernetes, and I've been wondering why the current approach is being taken instead? |
Beta Was this translation helpful? Give feedback.
-
This thread is intended to discuss benefits & drawbacks of having it implemented.
Are there specific aspects of Kubernetes functionality you believe would be the most beneficial for the project to support?
What are the pain points or gaps that tighter integration with Kubernetes could solve for your use cases?
Beta Was this translation helpful? Give feedback.
All reactions