-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
kubernetes_service panic runtime error: invalid memory address or nil pointer dereference #9721
Comments
I have a similar problem(But I don't have permission to change the code): |
We have addressed the panic but weren't able to get the kubeconfig from the customer to see what was causing it in the first place. Feel free to reopen if more info becomes available. |
Hi @r0mant , Are there any plans to backport this fix to V7 too? |
@ArunNadda We can if needed. Is anyone interested in a v7 backport? |
Hi @r0mant , thanks for quick response. Yes, we have a customer who is running v7 and is getting this Here is format of kubeconfig they have:
|
I've made a backport here if this is wanted for v7: #12143 |
@ArunNadda Thanks, I checked my kubeconfig and it looks like this: apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <redacted>
server: https://127.0.0.1:52828
name: mini1
contexts:
- context:
cluster: mini1
user: mini1-teleport-sa
name: mini1
current-context: mini1
kind: Config
preferences: {}
users:
- name: mini1-teleport-sa
user:
token: <redacted> Notice that I also have a I would ask the customer how they're connecting to their Kube cluster and how they generated that kubeconfig. If I had to guess, they're trying to connect to the Kubernetes API server over HTTP instead of HTTPs? What is the value of |
Description
What happened:
When a fresh kubernetes_service pod comes up it seems to be okay. The first time an end user tries to access that corresponding kubernetes cluster, they get an EOF error from kubectl:
Error from server: EOF
. The proxy_service logs on the teleport cluster also mention an EOF, and the kubernetes_service instance logs the following stacktrace:Subsequent connection attempts make the panic repeat
What you expected to happen:
No panic
Reproduction Steps
Unable to reproduce reliably in other environments at this time.
Use reports that this kubernetes_service instance is not using persistence and starts with a fresh /var/lib/teleport on each invocation. Other kubernetes_service instances in this teleport cluster are unaffected.
Server Details
teleport version
): Teleport Enterprise 7.3.2-0-gaa361fbc1/etc/os-release
):Debug Logs
The text was updated successfully, but these errors were encountered: