dotnet add package KubernetesClient

dotnet msbuild /Restore /t:SlnGen kubernetes-client.proj 

You should be able to use a standard KubeConfig file with this library, see the BuildConfigFromConfigFile function below. Most authentication methods are currently supported, but a few are not, see the known-issues.

You should also be able to authenticate with the in-cluster service account using the InClusterConfig function shown below.

Metrics are built in to HttpClient using System.Diagnostics.DiagnosticsSource. https://learn.microsoft.com/en-us/dotnet/core/diagnostics/built-in-metrics-system-net

There are many ways these metrics can be consumed/exposed but that decision is up to the application, not KubernetesClient itself. https://learn.microsoft.com/en-us/dotnet/core/diagnostics/metrics-collection

// Load from the default kubeconfig on the machine.varconfig=KubernetesClientConfiguration.BuildConfigFromConfigFile();// Load from a specific file:varconfig=KubernetesClientConfiguration.BuildConfigFromConfigFile(Environment.GetEnvironmentVariable("KUBECONFIG"));// Load from in-cluster configuration:varconfig=KubernetesClientConfiguration.InClusterConfig()// Use the config object to create a client.varclient=newKubernetes(config);

varnamespaces=client.CoreV1.ListNamespace();foreach(varnsinnamespaces.Items){Console.WriteLine(ns.Metadata.Name);varlist=client.CoreV1.ListNamespacedPod(ns.Metadata.Name);foreach(variteminlist.Items){Console.WriteLine(item.Metadata.Name);}}

varns=newV1Namespace{Metadata=newV1ObjectMeta{Name="test"}};varresult=client.CoreV1.CreateNamespace(ns);Console.WriteLine(result);varstatus=client.CoreV1.DeleteNamespace(ns.Metadata.Name,newV1DeleteOptions());

There is extensive example code in the examples directory.

git clone git@github.com:kubernetes-client/csharp.git cd csharp\examples\simple dotnet run

While the preferred way of connecting to a remote cluster from local machine is:

varconfig=KubernetesClientConfiguration.BuildConfigFromConfigFile();varclient=newKubernetes(config);

Not all auth providers are supported at the moment #91. You can still connect to a cluster by starting the proxy command:

$ kubectl proxy Starting to serve on 127.0.0.1:8001

and changing config:

varconfig=newKubernetesClientConfiguration{Host="http://127.0.0.1:8001"};

Notice that this is a workaround and is not recommended for production use.

The project uses XUnit as unit testing framework.

To run the tests:

cd csharp\tests dotnet restore dotnet test

You'll need a Linux machine with Docker.

Check out the generator project into some other directory (henceforth $GEN_DIR).

cd$GEN_DIR/.. git clone https://github.com/kubernetes-client/gen

# Where REPO_DIR points to the root of the csharp repositorycd${GEN_DIR}/openapi/csharp.sh ${REPO_DIR}/src/KubernetesClient ${REPO_DIR}/csharp.settings

• Starting from 2.0, dotnet sdk versioning adopted

• Kubernetes Version here means the version sdk models and apis were generated from

• Kubernetes api server guarantees the compatibility with n-2 (n-3 after 1.28) version. for example:

  • 1.19 based sdk should work with 1.21 cluster, but not guaranteed to work with 1.22 cluster.
    

  and vice versa:

  • 1.21 based sdk should work with 1.19 cluster, but not guaranteed to work with 1.18 cluster.
    Note: in practice, the sdk might work with much older clusters, at least for the more stable functionality. However, it is not guaranteed past the n-2 (or n-3 after 1.28 ) version. See #1511 for additional details.
    

  see also https://kubernetes.io/releases/version-skew-policy/

• Fixes (including security fixes) are not back-ported automatically to older sdk versions. However, contributions from the community are welcomed 😊; See Contributing for instructions on how to contribute.

• *KubernetesClient.Classic: netstandard2.0 and net48 are supported with limited features

Please see CONTRIBUTING.md for instructions on how to contribute.