Need help with k8s-openapi?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

162 Stars 19 Forks Apache License 2.0 381 Commits 8 Opened issues


Rust bindings for the Kubernetes client API

Services available


Need anything else?

Contributors list

# 35,854
376 commits
# 97,734
2 commits
# 290,113
1 commit
# 43,102
1 commit

This crate is a Rust Kubernetes API client. It contains bindings for the resources and operations in the Kubernetes client API, auto-generated from the OpenAPI spec.



This crate is not generated using Swagger or the OpenAPI Generator directly, as clients generated by the common client generator are. This gives this crate a few important advantages.

Works around bugs in the upstream OpenAPI spec

The upstream OpenAPI spec is not written by hand; it's itself generated from the API server's Go code. As such, the spec makes mistakes when trying to convert the representations of Go types to OpenAPI, such as incorrectly representing the

type used in CRD validation, and incorrectly representing the type of objects inside a
. A client generated naively from the spec inherits all these mistakes, and it is hard for such a client to fix them in "post".

Since this crate uses a custom code generator, it is able to work around these mistakes and emit correct bindings. See the list of fixes here and the breakdown of fixes applied to each Kubernetes version here.

Better code organization, closer to the Go API

Upstream's generated clients tend to place all the API operations in massive top-level modules. For example, the Python client contains a single CoreV1Api class with a couple of hundred methods, one for each

API operation like

This crate instead associates these functions with the corresponding resource type. The

function is accessed as
, where
is the resource type for pods. This is similar to the Go API's PodInterface::List

Since all types are under the

namespace, this crate also removes those two components from the module path. The end result is that the path to
, similar to the Go path

Better handling of optional parameters, for a more Rust-like and ergonomic API

Almost every API operation has optional parameters. For example, v1.13's

API has one required parameter (the namespace) and nine optional parameters.

The clients of other languages use language features to allow the caller to not specify all these parameters when invoking the function. The Python client's functions parse optional parameters from

. The C# client's functions assign default values to these parameters in the function definition.

Since Rust does not have such a feature, auto-generated Rust clients use

parameters to represent optional parameters. This ends up requiring callers to pass in a lot of
parameters just to satisfy the compiler. Invoking the
of an auto-generated client would look like:
// List all pods in the kube-system namespace
list_namespaced_pod("kube-system", None, None, None, None, None, None, None, None, None);

// List all pods in the kube-system namespace with label foo=bar list_namespaced_pod("kube-system", None, None, None, /* label_selector */ Some("foo=bar"), None, None, None, None, None);

Apart from being hard to read, you could easily make a typo and pass in

for one of the four other optional String parameters without any errors from the compiler.

This crate moves all optional parameters to separate structs, one for each API. Each of these structs implements

and the names of the fields match the function parameter names, so that the above calls look like:
// List all pods in the kube-system namespace
list_namespaced_pod("kube-system", Default::default());

// List all pods in the kube-system namespace with label foo=bar list_namespaced_pod("kube-system", ListOptional { label_selector: Some("foo=bar"), ..Default::default());

The second example uses struct update syntax to explicitly set one field of the struct and

the rest.

Not restricted to a single HTTP client implementation, and works with both synchronous and asynchronous HTTP clients

Auto-generated clients have to choose between providing a synchronous or asynchronous API, and have to choose what kind of HTTP client they want to use internally (

, etc). If you want to use a different HTTP client, you cannot use the crate.

This crate is instead based on the sans-io approach popularized by Python for network protocols and applications.

For example, the

does not return
impl Future>
. It returns an
with the URL path, query string, request headers and request body filled out. You are free to execute this
using any HTTP client you want to use.

After you've executed the request, your HTTP client will give you the response's

and some
bytes of the response body. To parse these into a
, you use that type's
fn try_from_parts(http::StatusCode, &[u8]) -> Result
function. The result is either a successful
value, or an error that the response is incomplete and you need to get more bytes of the response body and try again, or a fatal error because the response is invalid JSON.

To make this easier, the

function also returns a callback
fn(http::StatusCode) -> ResponseBody>
is a type that contains its own internal growable byte buffer, so you can use it if you don't want to manage a byte buffer yourself. It also ensures that you deserialize the response to the appropriate type corresponding to the request, ie
, and not any other. See the crate docs for more details about this type.

Supports more versions of Kubernetes

Official clients tend to support only the three latest versions of Kubernetes. This crate supports a few more.

As mentioned above, the upstream OpenAPI spec contains mistakes. When upstream fixes these mistakes, it usually does not backport them to older versions (not even to supported older versions). This crate does backport those fixes if they're applicable.



Copyright 2018 Arnav Singh

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

The OpenAPI spec that these bindings are generated from is sourced from the Kubernetes repository which also uses the Apache-2.0 license.

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.