-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ProtocolError - InvalidChunkLength #233
Comments
Hi @ngc4579 , no, it's not AFAIK. Can you provide us some more details? Are you able to call the k8s API manually (through a |
@jekkel Thanks for your answer... - Well, at least a {
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "api.eval.420214.internal.prod.<redacted>:443"
}
]
} |
We noticed the same issue around 2 months ago. It seems to be not critical because configmaps are successfully processed. The only sign that something is not right is the error messages in logs. |
And this is a stack trace which I managed to retrieve.
The code was used (it was running in a loop because most of the time it works as expected):
So far it looks like some networking issues rather than an issue with k8s-sidecar itself. |
Related issues in the Kubernetes python client:
The suggested solution (which is actually a workaround) is to implement a retry logic. However, looking at the k8s-sidecar's code it seems to be not really needed, because the retry logic is implemented on a higher level already. Personally, I'd decrease the severity of the corresponding log message from ERROR to WARNING, because, in fact, everything is working fine. |
Hm, I am running into the same issue, and can confirm it's still the case with With |
This issue has been automatically marked as stale because it has not had any activity in the last 60 days. Thank you for your contributions. |
A
quay.io/kiwigrid/k8s-sidecar:1.21.0
container deployed alongside Grafana in a k8s 1.24 evaluation cluster seems to start correctly, but afterwards floods logs withProtocolError
messages as seen below:Is this a known issue?
The text was updated successfully, but these errors were encountered: