Go client for Kubernetes.
Go Protocol Buffer
Latest commit 6500775 Feb 24, 2017 @caesarxuchao caesarxuchao committed on GitHub Merge pull request #130 from caesarxuchao/minor-fix-install.md
minor fix of 'go get' command
Permalink
Failed to load latest commit information.
.github Add PR tempalte Oct 7, 2016
Godeps manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
discovery manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
dynamic manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
examples manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
informers manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
kubernetes manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
listers manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
pkg manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
plugin/pkg published by bot Jan 25, 2017
rest manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
testing published by bot Jan 27, 2017
third_party/forked/golang/template published by bot Jan 31, 2017
tools manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
transport published by bot Jan 14, 2017
util manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
vendor manually sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750b… Feb 23, 2017
.travis.yml add back travis Feb 11, 2017
CHANGELOG.md update CHANGELOG Feb 23, 2017
INSTALL.md minor fix of 'go get' command Feb 24, 2017
LICENSE published by bot Dec 11, 2016
OWNERS published by bot Feb 3, 2017
README.md client-go issues should be reported at this repo now Feb 22, 2017

README.md

client-go

Go clients for talking to a kubernetes cluster.

We currently recommend using the v2.0.0 tag. See INSTALL.md for detailed installation instructions. go get k8s.io/client-go/... works, but will give you head and doesn't handle the dependencies well.

Table of Contents

What's included

  • The kubernetes package contains the clientset to access Kubernetes API.
  • The discovery package is used to discover APIs supported by a Kubernetes API server.
  • The dynamic package contains a dynamic client that can perform generic operations on arbitrary Kubernetes API objects.
  • The transport package is used to set up auth and start a connection.
  • The tools/cache package is useful for writing controllers.

Versioning

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.

Branches and tags.

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.

Compatibility: your code <-> client-go

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.

Compatibility: client-go <-> Kubernetes clusters

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.

Compatibility matrix

Kubernetes 1.3 Kubernetes 1.4 Kubernetes 1.5 Kubernetes 1.6 (not released yet)
client-go 1.4 + - -
client-go 1.5 + + - -
client-go 2.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, but everything they have in common will work.
  • - The Kubernetes cluster has features the client-go library can't use (additional API objects, etc).

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 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.

Deprecation policy

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.

Why do the 1.4 and 1.5 branch contain top-level folder named after the version?

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.

How to get it

You can use go get k8s.io/client-go/... to get client-go, but you will get the unstable master branch and client-go's vendored dependencies will not be added to your $GOPATH. So we think most users will want to use a dependency management system. See INSTALL.md for detailed instructions.

How to use it

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.

Dependency management

If your application depends on a package that client-go depends on, and you let the Go compiler find the dependency in GOPATH, you will end up with duplicated dependencies: one copy from the GOPATH, and one from the vendor folder of client-go. This will cause unexpected runtime error like flag redefinition, since the go compiler ends up importing both packages separately, even if they are exactly the same thing. If this happens, you can either

  • run godep restore (godep) in the client-go/ folder, then remove the vendor folder of client-go. Then the packages in your GOPATH will be the only copy
  • or run godep save in your application folder to flatten all dependencies.

Contributing code

Please send pull requests against the client packages in the Kubernetes main repository, and run the /staging/copy.sh script to update the staging area in the main repository. Changes in the staging area will be published to this repository every day.