Skip to main content

Overview

The client module provides utilities for creating and configuring Kubernetes clients, including support for both real and fake clients for testing purposes.

get_client

Get a configured Kubernetes DynamicClient instance. This function creates a Kubernetes client from various configuration sources including kubeconfig files, configuration dictionaries, or environment variables. It supports multiple authentication methods and can return a fake client for testing.

Parameters

str | None
default:"None"
Path to a kubeconfig file. If not provided, will use KUBECONFIG environment variable or ~/.kube/config.
dict[str, Any] | None
default:"None"
Dictionary containing kubeconfig configuration. Mutually exclusive with config_file.
str | None
default:"None"
Name of the context to use from the kubeconfig.
kubernetes.client.Configuration | None
default:"None"
Pre-configured Kubernetes client configuration object.
bool
default:"True"
Whether to persist the configuration file when using config_dict.
str | None
default:"None"
Path to a temporary kubeconfig file when using config_dict.
bool
default:"True"
Whether to attempt token refresh for in-cluster configuration.
str | None
default:"None"
Username for basic authentication. Must be used with password and host.
str | None
default:"None"
Password for basic authentication. Must be used with username and host.
str | None
default:"None"
Cluster API server host URL (e.g., “https://api.cluster.example.com:6443”).
bool | None
default:"None"
Whether to verify SSL certificates when connecting to the cluster.
str | None
default:"None"
Bearer token for authentication. Must be used with host.
bool
default:"False"
If True, returns a FakeDynamicClient for testing instead of a real client.

Returns

DynamicClient | FakeDynamicClient
A configured Kubernetes DynamicClient instance (or FakeDynamicClient if fake=True).

Behavior

The function attempts to create a client in the following order:
  1. Basic Auth: If username, password, and host are provided
  2. Token Auth: If host and token are provided
  3. Config Dict: If config_dict is provided
  4. Config File: Uses config_file parameter, KUBECONFIG env var, or ~/.kube/config
  5. In-Cluster: Falls back to in-cluster configuration if other methods fail
The function automatically detects and uses proxy settings from HTTPS_PROXY or HTTP_PROXY environment variables.

Examples

Creating a Client with Token Authentication

Using a Specific Kubeconfig Context

Creating a Client from Configuration Dictionary


FakeDynamicClient

A fake implementation of the Kubernetes DynamicClient for testing purposes. FakeDynamicClient provides an in-memory mock of the Kubernetes API that can be used in unit tests without requiring a real cluster connection. It implements the same interface as the real DynamicClient.

Key Features

  • In-Memory Storage: All resources are stored in memory, no actual cluster required
  • Full CRUD Operations: Supports create, read, update, and delete operations
  • Custom Resource Support: Can register custom resources dynamically
  • Namespace Management: Automatically handles namespace creation
  • Compatible Interface: Drop-in replacement for DynamicClient in tests

Methods

resources

Access the resource manager for getting resource APIs.

register_resources

Register custom resource definitions for testing.
dict[str, Any] | list[dict[str, Any]]
Either a single resource definition or a list of resource definitions. Each definition should contain:
  • kind: Resource kind (required)
  • api_version: API version without group (required)
  • group: API group (optional, empty string for core resources)
  • namespaced: Whether resource is namespaced (optional, defaults to True)
  • plural: Plural name (optional, auto-generated if not provided)
  • singular: Singular name (optional, defaults to lowercase kind)

ensure_namespace

Ensure a namespace exists, creating it if necessary.

version

Get the fake server version information.

Testing Example

Limitations

  • No Validation: Schema validation is not enforced
  • Simplified Watch: Watch operations are limited
  • No Side Effects: Controllers and operators are not simulated
  • In-Memory Only: Data is lost when the client is destroyed