You're right! I can increase it using max-log-requests options, I did not look through everything -h gave me so could not test it. I'm not sure to what extend we can use this option in production. I'm guessing if we try to pull logs from too many log streams it's not going to do down well w.r.t Kubernetes API. I'm still very new to Kubernetes scene, but this is something that I'm planning to look through when I reach a stage wherein I can put some app to production and scale it well.
Yeah, for production you may consider looking into things like fluentd or fluentbit for forwarding logs to some external aggregator and the view them through that.
But for dev clusters or just adhoc access, kubectl logs is super handy!
You're right! I can increase it using max-log-requests options, I did not look through everything -h gave me so could not test it. I'm not sure to what extend we can use this option in production. I'm guessing if we try to pull logs from too many log streams it's not going to do down well w.r.t Kubernetes API. I'm still very new to Kubernetes scene, but this is something that I'm planning to look through when I reach a stage wherein I can put some app to production and scale it well.
Yeah, for production you may consider looking into things like fluentd or fluentbit for forwarding logs to some external aggregator and the view them through that.
But for dev clusters or just adhoc access,
kubectl logsis super handy!Nice! We already use filebeat + ES (Since it's native to AWS offering right now) I'm guessing we'll still continue to do the same way!