a493c8da9a
Close outbound connections when using a cert callback and certificates rotate. This means that we won't get into a situation where we have open TLS connections using expires certs, which would get unauthorized errors at the apiserver Attempt to retrieve a new certificate if open connections near expiry, to prevent the case where the cert expires but we haven't yet opened a new TLS connection and so GetClientCertificate hasn't been called. Move certificate rotation logic to a separate function Rely on generic transport approach to handle closing TLS client connections in exec plugin; no need to use a custom dialer as this is now the default behaviour of the transport when faced with a cert callback. As a result of handling this case, it is now safe to apply the transport approach even in cases where there is a custom Dialer (this will not affect kubelet connrotation behaviour, because that uses a custom transport, not just a dialer). Check expiry of the full TLS certificate chain that will be presented, not only the leaf. Only do this check when the certificate actually rotates. Start the certificate as a zero value, not nil, so that we don't see a rotation when there is in fact no client certificate Drain the timer when we first initialize it, to prevent immediate rotation. Additionally, calling Stop() on the timer isn't necessary. Don't close connections on the first 'rotation' Remove RotateCertFromDisk and RotateClientCertFromDisk flags. Instead simply default to rotating certificates from disk whenever files are exclusively provided. Add integration test for client certificate rotation Simplify logic; rotate every 5 mins Instead of trying to be clever and checking for rotation just before an expiry, let's match the logic of the new apiserver cert rotation logic as much as possible. We write a controller that checks for rotation every 5 mins. We also check on every new connection. Respond to review Fix kubelet certificate rotation logic The kubelet rotation logic seems to be broken because it expects its cert files to end up as cert data whereas in fact they end up as a callback. We should just call the tlsConfig GetCertificate callback as this obtains a current cert even in cases where a static cert is provided, and check that for validity. Later on we can refactor all of the kubelet logic so that all it does is write files to disk, and the cert rotation work does the rest. Only read certificates once a second at most Respond to review 1) Don't blat the cert file names 2) Make it more obvious where we have a neverstop 3) Naming 4) Verbosity Avoid cache busting Use filenames as cache keys when rotation is enabled, and add the rotation later in the creation of the transport. Caller should start the rotating dialer Add continuous request rotation test Rebase: use context in List/Watch Swap goroutine around Retry GETs on net.IsProbableEOF Refactor certRotatingDialer For simplicity, don't affect cert callbacks To reduce change surface, lets not try to handle the case of a changing GetCert callback in this PR. Reverting this commit should be sufficient to handle that case in a later PR. This PR will focus only on rotating certificate and key files. Therefore, we don't need to modify the exec auth plugin. Fix copyright year Kubernetes-commit: 929b1559a0b855d996257ab3ad5364605edc253d |
||
|---|---|---|
| .github | ||
| deprecated | ||
| discovery | ||
| dynamic | ||
| examples | ||
| Godeps | ||
| informers | ||
| kubernetes | ||
| kubernetes_test | ||
| listers | ||
| metadata | ||
| pkg | ||
| plugin/pkg/client/auth | ||
| rest | ||
| restmapper | ||
| scale | ||
| testing | ||
| third_party/forked/golang/template | ||
| tools | ||
| transport | ||
| util | ||
| CHANGELOG.md | ||
| code-of-conduct.md | ||
| CONTRIBUTING.md | ||
| go.mod | ||
| go.sum | ||
| INSTALL.md | ||
| LICENSE | ||
| OWNERS | ||
| README.md | ||
| SECURITY_CONTACTS | ||
client-go
Go clients for talking to a kubernetes cluster.
We recommend using the v0.x.y tags for Kubernetes releases >= v1.17.0 and
kubernetes-1.x.y tags for Kubernetes releases < v1.17.0.
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.
Table of Contents
- What's included
- Versioning
- Kubernetes tags
- How to get it
- How to use it
- Dependency management
- Contributing code
What's included
- 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.
Versioning
-
For each
v1.x.yKubernetes release, the major version (first digit) would remain0. -
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.
Branches and tags.
We will create a new branch and tag for each increment in the 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 HEAD of the master branch in client-go will track the HEAD of the master branch in the main Kubernetes repo.
Compatibility: your code <-> client-go
The v0.x.y tags indicate that go APIs may change in incompatible ways in
different versions.
See INSTALL.md for guidelines on requiring a specific version of client-go.
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.15 | Kubernetes 1.16 | Kubernetes 1.17 | |
|---|---|---|---|
kubernetes-1.15.0 |
✓ | +- | +- |
kubernetes-1.16.0 |
+- | ✓ | +- |
kubernetes-1.17.0/v0.17.0 |
+- | +- | ✓ |
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 |
|---|---|---|
release-1.4 |
Kubernetes main repo, 1.4 branch | = - |
release-1.5 |
Kubernetes main repo, 1.5 branch | = - |
release-2.0 |
Kubernetes main repo, 1.5 branch | = - |
release-3.0 |
Kubernetes main repo, 1.6 branch | = - |
release-4.0 |
Kubernetes main repo, 1.7 branch | = - |
release-5.0 |
Kubernetes main repo, 1.8 branch | = - |
release-6.0 |
Kubernetes main repo, 1.9 branch | = - |
release-7.0 |
Kubernetes main repo, 1.10 branch | = - |
release-8.0 |
Kubernetes main repo, 1.11 branch | =- |
release-9.0 |
Kubernetes main repo, 1.12 branch | =- |
release-10.0 |
Kubernetes main repo, 1.13 branch | =- |
release-11.0 |
Kubernetes main repo, 1.14 branch | ✓ |
release-12.0 |
Kubernetes main repo, 1.15 branch | ✓ |
release-13.0 |
Kubernetes main repo, 1.16 branch | ✓ |
release-14.0 |
Kubernetes main repo, 1.17 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.
Kubernetes tags
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 v1.8.0, when syncing the code from the staging area,
we also sync the Kubernetes version tags to client-go, prefixed with
kubernetes-. From Kubernetes v1.17.0, we also create matching semver
v0.x.y tags for each v1.x.y Kubernetes release.
For example, if you check out the kubernetes-1.17.0 or the v0.17.0 tag in
client-go, the code you get is exactly the same as if you check out the v1.17.0
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.
How to get it
Use go1.11+ and fetch the desired version using the go get command. For example:
go get k8s.io/client-go@v0.17.0
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
For details on how to correctly use a dependency management for installing client-go, please see INSTALL.md.
Contributing code
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.