Go clients for talking to a kubernetes cluster.
We recommend using the kubernetes-1.x.y tag matching the current Kubernetes release (kubernetes-1.15.3 at the time this was written).
See INSTALL.md for detailed installation instructions.
go get k8s.io/client-go@master works, but will fetch master, which may be less stable than a tagged release.
- What's included
- Versioning
- Kubernetes tags
- How to get it
- How to use it
- Dependency management
- Contributing code
- The
kubernetespackage contains the clientset to access Kubernetes API. - The
discoverypackage is used to discover APIs supported by a Kubernetes API server. - The
dynamicpackage contains a dynamic client that can perform generic operations on arbitrary Kubernetes API objects. - The
plugin/pkg/client/authpackages contain optional authentication plugins for obtaining credentials from external sources. - The
transportpackage is used to set up auth and start a connection. - The
tools/cachepackage is useful for writing controllers.
client-go follows semver. We will not make
backwards-incompatible changes without incrementing the major version number. A
change is backwards-incompatible either if it i) changes the public interfaces
of client-go, or ii) makes client-go incompatible with otherwise supported
versions of Kubernetes clusters.
Changes that add features in a backwards-compatible way will result in bumping the minor version (second digit) number.
Bugfixes will result in the patch version (third digit) changing. PRs that are
cherry-picked into an older Kubernetes release branch will result in an update
to the corresponding branch in client-go, with a corresponding new tag
changing the patch version.
A consequence of this is that client-go version numbers will be unrelated to
Kubernetes version numbers.
We will create a new branch and tag for each increment in the major version number or minor version number. We will create only a new tag for each increment in the patch version number. See semver for definitions of major, minor, and patch.
The master branch will track HEAD in the main Kubernetes repo and
accumulate changes. Consider HEAD to have the version x.(y+1).0-alpha or
(x+1).0.0-alpha (depending on whether it has accumulated a breaking change or
not), where x and y are the current major and minor versions.
client-go follows semver, so until the major version of
client-go gets increased, your code will compile and will continue to work with
explicitly supported versions of Kubernetes clusters. You must use a dependency
management system and pin a specific major version of client-go to get this
benefit, as HEAD follows the upstream Kubernetes repo.
Since Kubernetes is backwards compatible with clients, older client-go
versions will work with many different Kubernetes cluster versions.
We will backport bugfixes--but not new features--into older versions of
client-go.
| Kubernetes 1.9 | Kubernetes 1.10 | Kubernetes 1.11 | Kubernetes 1.12 | Kubernetes 1.13 | Kubernetes 1.14 | Kubernetes 1.15 | |
|---|---|---|---|---|---|---|---|
| client-go 6.0 | ✓ | +- | +- | +- | +- | +- | +- |
| client-go 7.0 | +- | ✓ | +- | +- | +- | +- | +- |
| client-go 8.0 | +- | +- | ✓ | +- | +- | +- | +- |
| client-go 9.0 | +- | +- | +- | ✓ | +- | +- | +- |
| client-go 10.0 | +- | +- | +- | +- | ✓ | +- | +- |
| client-go 11.0 | +- | +- | +- | +- | +- | ✓ | +- |
| client-go 12.0 | +- | +- | +- | +- | +- | +- | ✓ |
| client-go HEAD | +- | +- | +- | +- | +- | +- | +- |
Key:
✓Exactly the same features / API objects in both client-go and the Kubernetes version.+client-go has features or API objects that may not be present in the Kubernetes cluster, either due to that client-go has additional new API, or that the server has removed old API. However, everything they have in common (i.e., most APIs) will work. Please note that alpha APIs may vanish or change significantly in a single release.-The Kubernetes cluster has features the client-go library can't use, either due to the server has additional new API, or that client-go has removed old API. However, everything they share in common (i.e., most APIs) will work.
See the CHANGELOG for a detailed description of changes between client-go versions.
| Branch | Canonical source code location | Maintenance status |
|---|---|---|
| client-go 1.4 | Kubernetes main repo, 1.4 branch | = - |
| client-go 1.5 | Kubernetes main repo, 1.5 branch | = - |
| client-go 2.0 | Kubernetes main repo, 1.5 branch | = - |
| client-go 3.0 | Kubernetes main repo, 1.6 branch | = - |
| client-go 4.0 | Kubernetes main repo, 1.7 branch | = - |
| client-go 5.0 | Kubernetes main repo, 1.8 branch | = - |
| client-go 6.0 | Kubernetes main repo, 1.9 branch | = - |
| client-go 7.0 | Kubernetes main repo, 1.10 branch | = - |
| client-go 8.0 | Kubernetes main repo, 1.11 branch | =- |
| client-go 9.0 | Kubernetes main repo, 1.12 branch | =- |
| client-go 10.0 | Kubernetes main repo, 1.13 branch | ✓ |
| client-go 11.0 | Kubernetes main repo, 1.14 branch | ✓ |
| client-go 12.0 | Kubernetes main repo, 1.15 branch | ✓ |
| client-go HEAD | Kubernetes main repo, master branch | ✓ |
Key:
✓Changes in main Kubernetes repo are actively published to client-go by a bot=Maintenance is manual, only severe security bugs will be patched.-Deprecated; please upgrade.
We will maintain branches for at least six months after their first stable tag is cut. (E.g., the clock for the release-2.0 branch started ticking when we tagged v2.0.0, not when we made the first alpha.) This policy applies to every version greater than or equal to 2.0.
For the initial release of client-go, we thought it would be easiest to keep separate directories for each minor version. That soon proved to be a mistake. We are keeping the top-level folders in the 1.4 and 1.5 branches so that existing users won't be broken.
This repository is still a mirror of
k8s.io/kubernetes/staging/src/client-go,
the code development is still done in the staging area. Since Kubernetes 1.8
release, when syncing the code from the staging area, we also sync the Kubernetes
version tags to client-go, prefixed with "kubernetes-". For example, if you check
out the kubernetes-1.15.3 tag in client-go, the code you get is exactly the
same as if you check out the v1.15.3 tag in Kubernetes, and change directory to
staging/src/k8s.io/client-go. The purpose is to let users quickly find matching
commits among published repos, like
sample-apiserver,
apiextension-apiserver,
etc. The Kubernetes version tag does NOT claim any backwards compatibility
guarantees for client-go. Please check the semantic versions if
you care about backwards compatibility.
Use go1.11+ and fetch the desired version using the go get command. For example:
go get k8s.io/client-go@kubernetes-1.15.3
See INSTALL.md for detailed instructions.
If your application runs in a Pod in the cluster, please refer to the in-cluster example, otherwise please refer to the out-of-cluster example.
For details on how to correctly use a dependency management for installing client-go, please see INSTALL.md.
Please send pull requests against the client packages in the Kubernetes main repository. Changes in the staging area will be published to this repository every day.