github/client-go
1
0
Fork 0
mirror of https://github.com/kubernetes/client-go.git synced 2025-07-31 06:41:52 +00:00
Code Issues Projects Releases Wiki Activity
Go client for Kubernetes.
951 Commits 33 Branches 1,478 Tags 45 MiB
Go 100%
8b0c96689a
Go to file
Kubernetes Publisher 8b0c96689a Merge pull request #55168 from nikhita/customresources-subresources 
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

apiextensions: add subresources for custom resources

Fixes #38113
Fixes #58778

**Related**:
- Proposal: https://github.com/kubernetes/community/pull/913
- For custom resources to work with `kubectl scale`: https://github.com/kubernetes/kubernetes/pull/58283

**Add types**:

- Add `CustomResourceSubResources` type to CRD.
    - Fix proto generation for `CustomResourceSubResourceStatus`: https://github.com/kubernetes/kubernetes/pull/55970.
- Add feature gate for `CustomResourceSubResources`.
    - Update CRD strategy: if feature gate is disabled, this feature is dropped (i.e. set to `nil`).
- Add validation for `CustomResourceSubResources`:
    - `SpecReplicasPath` should not be empty and should be a valid json path under `.spec`. If there is no value under the given path in the CustomResource, the `/scale` subresource will return an error on GET.
    - `StatusReplicasPath` should not be empty and should be a valid json path under `.status`. If there is no value under the given path in the CustomResource, the status replica value in the /scale subresource will default to 0.
    - If present, `LabelSelectorPath` should be a valid json path. If there is no value under `LabelSelectorPath` in the CustomResource, the status label selector value in the `/scale` subresource will default to the empty string.
    - `ScaleGroupVersion` should be `autoscaling/v1`.
    - If `CustomResourceSubResources` is enabled, only `properties` is allowed under the root schema for CRD validation.

**Add status and scale subresources**:

- Use helper functions from `apimachinery/pkg/apis/meta/v1/unstructured/helpers.go`.
    - Improve error handling: https://github.com/kubernetes/kubernetes/pull/56563, https://github.com/kubernetes/kubernetes/pull/58215.
- Introduce Registry interface for storage.
- Update storage:
    - Introduce `CustomResourceStorage` which acts as storage for the custom resource and its status and scale subresources. Note: storage for status and scale is only enabled when the feature gate is enabled _and_ the respective fields are enabled in the CRD.
    - Introduce `StatusREST` and its `New()`, `Get()` and `Update()` methods.
    - Introduce `ScaleREST` and its `New()`, `Get()` and `Update()` methods.
        - Get and Update use the json paths from the CRD and use it to return an `autoscaling/v1.Scale` object.
- Update strategy:
    - In `PrepareForCreate`,
         - Clear `.status`.
         - Set `.metadata.generation` = 1
    - In `PrepareForUpdate`,
         - Do not update `.status`.
             - If both the old and new objects have `.status` and it is changed, set it back to its old value.
             - If the old object has a `.status` but the new object doesn't, set it to the old value.
             - If old object did not have a `.status` but the new object does, delete it.
         - Increment generation if spec changes i.e. in the following cases:
             - If both the old and new objects had `.spec` and it changed.
             - If the old object did not have `.spec` but the new object does.
             - If the old object had a `.spec` but the new object doesn't.
     - In `Validate` and `ValidateUpdate`,
        - ensure that values at `specReplicasPath` and `statusReplicasPath` are >=0 and < maxInt32.
        - make sure there are no errors in getting the value at all the paths.
    - Introduce `statusStrategy` with its methods.
        - In `PrepareForUpdate`:
            - Do not update `.spec`.
                - If both the old and new objects have `.spec` and it is changed, set it back to its old value.
                - If the old object has a `.spec` but the new object doesn't, set it to the old value.
                - If old object did not have a `.spec` but the new object does, delete it.
             - Do not update `.metadata`.
        - In `ValidateStatusUpdate`:
            - For CRD validation, validate only under `.status`.
            - Validate value at `statusReplicasPath` as above. If `labelSelectorPath` is a path under `.status`, then validate it as well.
- Plug into the custom resource handler:
    - Store all three storage - customResource, status and scale in `crdInfo`.
    - Use the storage as per the subresource in the request.
    - Use the validator as per the subresource (for status, only use the schema for `status`, if present).
    - Serve the endpoint as per the subresource - see `serveResource`, `serveStatus` and `serveScale`.
- Update discovery by adding the `/status` and `/scale` resources, if enabled.

**Add tests**:

- Add unit tests in `etcd_test.go`.
- Add integration tests.
    - In `subresources_test.go`, use the [polymporphic scale client](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/client-go/scale) to get and update `Scale`.
    -  Add a test to check everything works fine with yaml in `yaml_test.go`.

**Release note**:

```release-note
`/status` and `/scale` subresources are added for custom resources.
```

Kubernetes-commit: 6e856480c05424b5cd2cfcbec692a801b856ccb2
2018-02-27 01:09:56 +00:00
.github Remove .github in prep to sync from k/k/staging 2018-01-08 12:34:11 -08:00
discovery Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
dynamic add subresources for custom resources 2017-11-06 18:19:15 +05:30
examples Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
Godeps Merge pull request #58111 from mikedanese/id-registry 2018-02-27 01:09:55 +00:00
informers Update generated files. 2018-02-16 17:23:26 +01:00
kubernetes Update generated files. 2018-02-16 17:23:26 +01:00
listers Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
pkg/version Capture git export-subst strings in version.sh for 'git archive' use. 2017-11-08 15:37:49 -08:00
plugin/pkg/client/auth Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
rest Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
scale add subresources for custom resources 2017-11-06 18:19:15 +05:30
testing Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
third_party/forked/golang/template update BUILD files 2017-10-12 13:52:10 -07:00
tools Fix typos in configmaplock 2018-02-19 14:40:11 -05:00
transport Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
util Autogenerated: hack/update-bazel.sh 2018-02-16 13:43:01 -08:00
vendor Merge pull request #58544 from ericchiang/oidc-v2 2018-02-27 01:09:54 +00:00
.travis.yml bump go version to 1.8.1 for travis 2017-06-13 15:56:37 -07:00
CHANGELOG.md Add client-go 6.0.0 changelog 2017-12-12 15:23:55 +05:30
code-of-conduct.md Add code-of-conduct.md to staging repos 2017-12-20 15:21:56 -05:00
CONTRIBUTING.md Fix typo 2018-02-01 19:11:19 +08:00
INSTALL.md Update README.md and INSTALL.md for v6.0.0 2017-12-18 17:36:01 +01:00
LICENSE published by bot 2016-12-11 15:19:40 +00:00
OWNERS Add liggitt to client-go approvers 2017-08-29 12:54:04 +00:00
README.md Merge pull request #263 from asifdxtreme/master 2017-12-20 12:55:42 +01:00

README.md

client-go

Go clients for talking to a kubernetes cluster.

We currently recommend using the v6.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.

BuildStatus Widget GoReport Widget GoDocWidget

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.4 Kubernetes 1.5 Kubernetes 1.6 Kubernetes 1.7 Kubernetes 1.8 Kubernetes 1.9
client-go 1.4 ✓ - - - - -
client-go 1.5 + - - - - -
client-go 2.0 +- ✓ +- +- +- +-
client-go 3.0 +- +- ✓ - +- +-
client-go 4.0 +- +- +- ✓ +- +-
client-go 5.0 +- +- +- +- ✓ +-
client-go 6.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 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

As of October 2017, client-go 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-v1.8.0 tag in client-go, the code you get is exactly the same as if you check out the v1.8.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

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. Changes in the staging area will be published to this repository every day.