kubernetes-client
Cannot connect to Azure kubernetes cluster using c# sdk
Describe the bug A clear and concise description of what the bug is.
Kubernetes C# SDK Client Version
e.g. 12.1.1
Server Kubernetes Version
e.g. 1.25.5
Dotnet Runtime Version e.g. net6
To Reproduce Following this doc: https://github.com/kubernetes-client/csharp/blob/master/README.md var namespaces = client.CoreV1.ListNamespace(); foreach (var ns in namespaces.Items) { Console.WriteLine(ns.Metadata.Name); var list = client.CoreV1.ListNamespacedPod(ns.Metadata.Name); foreach (var item in list.Items) { Console.WriteLine(item.Metadata.Name); } }
The above code does not work on the line : var namespaces = client.CoreV1.ListNamespace(); Code/visual studio 2022 hangs there I am using this c# kubernetes client library with client.CoreV1.ListNamespace(); I tried setting KUBECTL_PROXY and updating the host to http: //proxyip:8001 and I am not using kube login. code execution stops at the above line and my visual studio 2022 hangs and I see messages thread exited in the output window. I can get all the details by connecting to cluster using kubectl commands in the terminal window. but not through c# libraray.
Expected behavior expect to list namespaces
KubeConfig normal AKS kube config file , which I can be able to connect using kubectl
Where do you run your app with Kubernetes SDK (please complete the following information):
- OS: [Windows]
- Environment [desktop application]
- Cloud [Azure]
Additional context Add any other context about the problem here.
I do not see any error, the code just hangs and I just see messages with thread exited in output window
i mean are you using kubelogin? you can check kubeconfig
most likely caused by waiting for stdin
I am not using kubelogin. I am just using kubeconfig to connect to cluster and check the namespace
what should i do if the process is waiting for stdin? I verified there is no kubelogin in kubeconfg file
could you please share your kubeconfig? remove all sensitive info before paste
apiVersion: v1 clusters:
- cluster: certificate-authority-data: xxx server: xxxx name:
- cluster:xxx certificate-authority-data: xxxx server: xxxx name: contexts:
- context: cluster:xxxx user: clusterAdmin_XXXXX name:
- context: cluster: xxxx user: clusterAdmin_XXXXX name: XXXX-admin current-context: XXXX-admin kind: Config preferences: {} users:
- name: clusterAdmin_XXXXX user: client-certificate-data: xxxx client-key-data: xxxxx token:xxxx
I'm having similar problem . Trying to get a list of namespaces of a microk8s remote server. Using code from example in project page:
var config = KubernetesClientConfiguration.BuildConfigFromConfigFile(@"C:\...\bin\Debug\K8s\config");
var client = new Kubernetes(config);
var namespaces = client.CoreV1.ListNamespace();
It just hangs with no error in that last line of code.
Tried in .net7 and .net framework 4.8 (classic lib) versions. Same thing on both. Also tried with multiple servers running microk8s 1.26, same thing on all of them. After further analysis using wireshark I can see it connects to remote microk8s server and exchanges about 200KB of data, then client side (c# app) starts to send TCP ZeroWindow messages, indicating it cannot process any more data...
exactly same place where my code is stuck too. I am totally blocked by this.
please see #1523, i added an example and the code was used for long time in production env
@tg123 The example you provided is using command: {kubelogin}. Here the scenario looks different.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
Well this issue make this software un-usable for like heavy number of users now a days. This fix is quite important!!
I've used this SDK in AKS for years with no issues creating my client - starting back in .net 5, through .net 6, and now .net8.
My only difference to building the config from file is that I don't put my path explicitly in as a parameter, I allow the system default kube context to be passed in (which I think is the same file referenced earlier in this thread).
My app has env var flags to flip from in-cluster to local file, so it's in a helper, but here's the code that loads the config from kube context (for local debugging primarily): https://github.com/RedSailTechnologies/kube-status/blob/953045099095a75a3a5467dfbfdc30dcb02bf7df/src/Helper.cs#L42
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
So, I had the same issue.
I switched to the async variant:
var namespaces = await client.CoreV1.ListNamespaceAsync();
This exposed an error:
HttpOperationException: Operation returned an invalid status code 'Forbidden', response body {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"namespaces is forbidden: User "guid " cannot list resource "namespaces" in API group "" at the cluster scope: User does not have access to the resource in Azure. Update role assignment to allow access.","reason":"Forbidden","details":{"kind":"namespaces"},"code":403}
