You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there!
We started usage of oidc-proxy recently. In our deployment it's "hidden" from users behind regular NGINX balancer. Before current topic events there was an issue with exec-mode which was solved by adding couple extra headers regarding upgrade from HTTP to websocket connection. But couple days ago we've faced with another problem related to logs output in follow mode as it is mentioned.
Expected behavior: obviously, show new logs lines right after it is generated by app in pod. Here is some piece of output with verbose=10:
Additional info: kubeconfig is rendered by Gangway service, authentication passed via Dex as LDAP auth-provider. In fact, ldap-auth is the main reason for us to use oidc-proxy.
I almost sure that solution is somewhere in NGINX configuration. But I don't know anything about internal mechanism of oidc-proxy. That's why it's almost impossible for me even to analyze the problem. Any advice or assumptions are welcome!
The text was updated successfully, but these errors were encountered:
Hi there!
We started usage of oidc-proxy recently. In our deployment it's "hidden" from users behind regular NGINX balancer. Before current topic events there was an issue with exec-mode which was solved by adding couple extra headers regarding upgrade from HTTP to websocket connection. But couple days ago we've faced with another problem related to logs output in follow mode as it is mentioned.
Expected behavior: obviously, show new logs lines right after it is generated by app in pod. Here is some piece of output with verbose=10:
Actual behavior: shows some portion of logs missing last 10-15 minutes, updates come with unpredictable manner. Some output is:
Additional info: kubeconfig is rendered by Gangway service, authentication passed via Dex as LDAP auth-provider. In fact, ldap-auth is the main reason for us to use oidc-proxy.
I almost sure that solution is somewhere in NGINX configuration. But I don't know anything about internal mechanism of oidc-proxy. That's why it's almost impossible for me even to analyze the problem. Any advice or assumptions are welcome!
The text was updated successfully, but these errors were encountered: