GithubHelp home page GithubHelp logo

client-go's Introduction

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.

The fastest way to add this library to a project is to run go get k8s.io/client-go@latest with go1.16+. See INSTALL.md for detailed installation instructions and troubleshooting.

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 plugin/pkg/client/auth packages contain optional authentication plugins for obtaining credentials from external sources.
  • The transport package is used to set up auth and start a connection.
  • The tools/cache package is useful for writing controllers.

Versioning

  • For each v1.x.y Kubernetes release, the major version (first digit) would remain 0.

  • 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.23 Kubernetes 1.24 Kubernetes 1.25 Kubernetes 1.26 Kubernetes 1.27 Kubernetes 1.28
kubernetes-1.23.0/v0.23.0 +- +- +- +- +-
kubernetes-1.24.0/v0.24.0 +- +- +- +- +-
kubernetes-1.25.0/v0.25.0 +- +- +- +- +-
kubernetes-1.26.0/v0.26.0 +- +- +- +- +-
kubernetes-1.27.0/v0.27.0 +- +- +- +- +-
kubernetes-1.28.0/v0.28.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.19 Kubernetes main repo, 1.19 branch =-
release-1.20 Kubernetes main repo, 1.20 branch =-
release-1.21 Kubernetes main repo, 1.21 branch =-
release-1.22 Kubernetes main repo, 1.22 branch =-
release-1.23 Kubernetes main repo, 1.23 branch =-
release-1.24 Kubernetes main repo, 1.24 branch =-
release-1.25 Kubernetes main repo, 1.25 branch
release-1.26 Kubernetes main repo, 1.26 branch
release-1.27 Kubernetes main repo, 1.27 branch
release-1.28 Kubernetes main repo, 1.28 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

To get the latest version, use go1.16+ and fetch using the go get command. For example:

go get k8s.io/client-go@latest

To get a specific version, use go1.11+ and fetch the desired version using the go get command. For example:

go get k8s.io/[email protected]

See INSTALL.md for detailed instructions and troubleshooting.

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.

client-go's People

Contributors

alexzielenski avatar aojea avatar ash2k avatar caesarxuchao avatar cblecker avatar deads2k avatar dims avatar enj avatar ericchiang avatar ixdy avatar jpbetz avatar k8s-ci-robot avatar k8s-publish-robot avatar k8s-publishing-bot avatar kevindelgado avatar lavalamp avatar liggitt avatar mikedanese avatar mikespreitzer avatar nikhita avatar p0lyn0mial avatar pohly avatar seans3 avatar smarterclayton avatar soltysh avatar sttts avatar thockin avatar tkashem avatar tnozicka avatar wojtek-t avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

client-go's Issues

This repository depends on k8s.io/kubernetes

The ./pkg/util/flowcontrol/throttle.go file imports the k8s.io/kubernetes/pkg/util/ratelimit package (see here). This import makes glide pull in the entire k8s.io/kubernetes codebase in order to satisfy that dependency.

My initial understanding of this repository was that it would not have dependencies on k8s.io/kubernetes, so it could serve as a lightweight Go client for the Kubernetes API. Is that wrong?

cc/ @krancour

Fake Clientset requires namespace be set on Create and Update but the real Clientset and API server do not

The fake Clientset requires creates and updates of namespaced objects to have the namespace specified in the target runtime object metadata while the same does not appear to be true for the real Clientset and API server.

In particular, something like this:

func createConfigMap(c kubernetes.Interface) error {
	_, err := c.Core().ConfigMaps("namespace").Create(&v1.ConfigMap{
		ObjectMeta: v1.ObjectMeta{Name: "name"},
		Data:       map[string]string{"key": "value"},
	})
	return err
}

works against a real cluster with a real Clientset but fails with no namespace specified for a namespaced kind /v1, Kind=ConfigMap when using the fake.


It looks like Create and Update end up adding the object to the tracker in fixture.go where the namespace is checked. The current implementation passes the namespace from the target object without accounting for the namespace from the request.

In the real API server, namespaces are propagated from the request path to the target object when a namespace isn't set on the object. This happens when ValidNamespace is called out of BeforeCreate and BeforeUpdate.

Should the behavior of the tracker be updated to propagate the namespace from the request to the object when it's missing on the object?

Support for Network Policies

Hello all,

As described in this thread, I've discovered that the existing "client-go" package does not yet support extension methods for network policies.

By modelling it after existing support for PodSecurityPolicy -- and some help from the main repository -- I have now implemented those methods.

They are located in my fork here: https://github.com/FlorianOtel/client-go

However, it seems that any PRs have to be submitted via main repo, as opposed to directly here.

Unless otherwise advised, I will try doing so next.

Submitting this issue here for reference.

Thanks,

/Florian

panic in cache: interface {} is *v1.Service, not *api.Service

Using the StoreToServiceLister in master (f11d57f) leads to panics due to an unmet type assertion in the List function.

func (s *StoreToServiceLister) List(selector labels.Selector) (ret []*api.Service, err error) {
    err = ListAll(s.Indexer, selector, func(m interface{}) {
        ret = append(ret, m.(*api.Service))
    })
    return ret, err
}

Informer framework

To write third-party controllers having object stores and the informer framework would be very handy.

Using for ThirdPartyResource's

I've started using this library and it works very well.

When extending the API with ThirdPartyResource resources, things become a major issue. Using the dynamic part doesn't work well because I don't want to convert all my objects into map[string]interface{} objects. The rest part alone also doesn't work well, because there are no Encoders/Decoders.

I'm sure all the tools required to start working with my own resources is available, but get them all up and running is just a major pain point currently.

Right now I don't know enough of the internals to be productive towards a solution, but any solution would be MUCH appreciated.

cannot build project in the 1.5 branch

Trying to build in the 1.5 branch (and directory) gives me this:

> ~/Development/client-go/src/k8s.io/client-go/1.5 # go build ./...
kubernetes/typed/core/v1/fake/fake_core_client.go:66: cannot use FakePods literal (type *FakePods) as type "k8s.io/client-go/1.5/kubernetes/typed/core/v1".PodInterface in return argument:
    *FakePods does not implement "k8s.io/client-go/1.5/kubernetes/typed/core/v1".PodInterface (missing Evict method)

On master, things are working fine.

/cc @caesarxuchao

examples/third-party-resources does not compile

The recently added third-party-resource example does not compile

% go get k8s.io/client-go/examples/third-party-resources
package k8s.io/client-go/pkg/api/unversioned: cannot find package "k8s.io/client-go/pkg/api/unversioned" in any of:
        /home/dfc/go/src/k8s.io/client-go/pkg/api/unversioned (from $GOROOT)
        /home/dfc/src/k8s.io/client-go/pkg/api/unversioned (from $GOPATH)

Compatibility matrix documentation

The documentation on the compatibility is rather puzzling ;-)

Compatibility matrix

client-go/1.4 is compatible with Kubernetes 1.3 through 1.5; it includes all features provided by Kubernetes 1.4.
client-go/1.5 is compatible with Kubernetes 1.3 through 1.5; it includes all features provided by Kubernetes 1.4.

So when should one use 1.4 and when 1.5?

[RFC] client-go versioning

We need to reorganize client-go to follow semver. I'll first describe the currenlty favored solution, and then list the considered alternatives. Please let us know what do you think.

What we'll do:

  • Let's ditch the individual folders.
  • Head of the master branch will track head of the kubernetes main repo.
  • We'll move the 1.4 client into a 1.4 branch. (and tag it as 1.4.0)
  • We'll cut new branches/tags when we've accumulated enough changes.

Consequence:

  • go get will give unstable development versions (!!!!)
  • Users must vendor to get a stable client
  • ...or they could use gopkg.in and rewrite our internal import statements.

Considered alternatives

1. Following the Go convention

  • Repository layout:
    • A new repository for every major version, i.e., k8s.io/client-go-v1, k8s.io/client-go-v2…
    • Each repositories have tags for minor versions
    • Head of each repository is backward compatible
  • How to use client-go:
    • import k8s.io/client-go-v2/tools/cache
    • go get k8s.io/client-go-v2, it will checkout the HEAD of the repository
    • Local code will be stored at $GOPATH/src/k8s.io/client-go-v2
  • Operational cost:
    • Creating a repository for every major release
  • How it affects developer workflow:
    • When making a backward incompatible change, i.e., needing to bump the major version, someone with write permission needs to create a new repository. Developers then need to make 2 PRs. They need to submit the first PR to k8s.io/client-go-<latest-version>. They also need to submit a second PR to the k8s.io/kubernetes to rewrite the imports. Until then integration tests will be run with the latest version of client-go.

2. Using gopkg.in: we don’t need to create new repository for major version bumps.

  • Repository layout:
    • Only one repository: k8s.io/client-go
    • Branches for major versions; tags for minor versions
  • How to use client-go:
    • import gopkg.in/k8s.io/client-go.v2/tools/cache
    • go get gopkg.in/k8s.io/client-go.v2, it will checkout tag or branch of the highest version that satisfies v2, e.g. branch v2.1.2.
    • Local code will be stored at $GOPATH/src/gopkg.in/k8s.io/client-go.v2
  • Operational cost: N/A
  • How it affects developer workflow:
    • Similar to 1, when introducing breaking changes, two PRs are required to run integration tests.

3. Using our own fork of gopkg.in: avoid being locked in with gopkg.in

  • Repository layout: same as 2
  • How to use client-go:
    • import k8s.io/client-go.v2/tools/cache
    • go get k8s.io/client-go.v2, it will checkout tag or branch of the highest version that satisfies v2, e.g. branch v2.1.2.
    • Local code will be stored at $GOPATH/src/k8s.io/client-go.v2
  • Operational cost: We need to deploy a server to redirect git requests, like what gopkg.in does.
  • How it affects developer workflow:
    • Similar to 1 and 2

4. Keeping versions in the folders: this is what we do today. The disadvantage is code duplication.

  • Repository layout:
    • Single repository: k8s.io/client-go
    • A folder for each version
  • How to use client-go:
    • import k8s.io/client-go/2.1.2/tools/cache
    • go get k8s.io/client-go/2.1.2/tools/cache, but all versions of client-go will be downloaded
  • Operational cost: N/A
  • How it affects developer workflow:
    • Worse than 1,2, and 3, for every version change, developers need to submit one PR to k8s.io/client-go to make the changes, and another PR to k8s.io/kubernetes to rewrite the import lines. Proper integration tests will then be run.

5. Abandoning go get: go get will always checkout the HEAD of client-go. To track a branch/tag, user needs to use a vendor tool like godep, govendor or glide.

  • Repository layout:
    • Single repository: k8s.io/client-go
    • A branch for each major version, a tag for each minor version
  • How to use client-go:
    • import k8s.io/client-go/tools/cache
    • go get k8s.io/client-go/tools/cache
  • Operational cost: N/A
  • How it affects developer workflow:
    • Same as 1, 2, and 3

How to get node resource?

In NodeInformer callback (AddFunc), it received v1.Node which I can not get allocatable of that node:

pkg/util/resource.go:17: cannot call pointer method on rl["github.com/k82cn/kube-arbitrator/vendor/k8s.io/client-go/1.5/pkg/api/v1".ResourceCPU]
pkg/util/resource.go:17: cannot take the address of rl["github.com/k82cn/kube-arbitrator/vendor/k8s.io/client-go/1.5/pkg/api/v1".ResourceCPU]
pkg/util/resource.go:18: cannot call pointer method on rl["github.com/k82cn/kube-arbitrator/vendor/k8s.io/client-go/1.5/pkg/api/v1".ResourceMemory]
pkg/util/resource.go:18: cannot take the address of rl["github.com/k82cn/kube-arbitrator/vendor/k8s.io/client-go/1.5/pkg/api/v1".ResourceMemory]

Related codes:

func NewResource(rl v1.ResourceList) *Resource {
	return &Resource{
		MilliCPU: float64(rl[v1.ResourceCPU].MilliValue()),
		Memory:   float64(rl[v1.ResourceMemory].Value()),
	}
}

Any suggestion?

Proposal: provide a SetLog() func

Is it possible to provide a SetLog() in the packages? For example, I'm using 3 cache.NewInformer to watch for changes on 3 different resources, but if, for whatever reason, the connection between the client and the apiserver doesn't exist, I have this error messages in my log:

ERROR: logging before flag.Parse: E1018 14:16:07.808569    5156 reflector.go:214] k8s.io/client-go/1.5/tools/cache/reflector.go:109: Failed to list *v1.Endpoints: Get http://192.168.33.11:8080/api/v1/endpoints?resourceVersion=0: dial tcp 192.168.33.11:8080: getsockopt: connection refused
ERROR: logging before flag.Parse: E1018 14:16:08.809443    5156 reflector.go:214] k8s.io/client-go/1.5/tools/cache/reflector.go:109: Failed to list *v1beta1.NetworkPolicy: Get http://192.168.33.11:8080/apis/extensions/v1beta1/networkpolicies?resourceVersion=0: dial tcp 192.168.33.11:8080: getsockopt: connection refused
ERROR: logging before flag.Parse: E1018 14:16:08.809458    5156 reflector.go:214] k8s.io/client-go/1.5/tools/cache/reflector.go:109: Failed to list *v1.Service: Get http://192.168.33.11:8080/api/v1/services?resourceVersion=0: dial tcp 192.168.33.11:8080: getsockopt: connection refused
ERROR: logging before flag.Parse: E1018 14:16:08.809526    5156 reflector.go:214] k8s.io/client-go/1.5/tools/cache/reflector.go:109: Failed to list *v1.Endpoints: Get http://192.168.33.11:8080/api/v1/endpoints?resourceVersion=0: dial tcp 192.168.33.11:8080: getsockopt: connection refused
ERROR: logging before flag.Parse: E1018 14:16:09.811722    5156 reflector.go:214] k8s.io/client-go/1.5/tools/cache/reflector.go:109: Failed to list *v1beta1.NetworkPolicy: Get http://192.168.33.11:8080/apis/extensions/v1beta1/networkpolicies?resourceVersion=0: dial tcp 192.168.33.11:8080: getsockopt: connection refused
ERROR: logging before flag.Parse: E1018 14:16:09.811733    5156 reflector.go:214] k8s.io/client-go/1.5/tools/cache/reflector.go:109: Failed to list *v1.Endpoints: Get http://192.168.33.11:8080/api/v1/endpoints?resourceVersion=0: dial tcp 192.168.33.11:8080: getsockopt: connection refused
ERROR: logging before flag.Parse: E1018 14:16:09.811733    5156 reflector.go:214] k8s.io/client-go/1.5/tools/cache/reflector.go:109: Failed to list *v1.Service: Get http://192.168.33.11:8080/api/v1/services?resourceVersion=0: dial tcp 192.168.33.11:8080: getsockopt: connection refused

I would like to at least change the layout to be the same as my logs or/and silent the log messages until I get a new kubernetes connection.

Third Party Resources example improvements

Thanks for all the work that has been done here! I tried to use the client when it was part of main repo and it was so hard I gave up. Now it is much more useable! I have a few questions/suggestions:

  • Example struct uses ObjectMeta from k8s.io/client-go/pkg/api package. Is that right? Should it be a versioned API object from k8s.io/client-go/pkg/api/v1? I only found this document api_changes.md with the phrase "Clients should consume and operate on the versioned APIs exclusively". Is there a mode specific document with guidelines on how to use Third Party Resources with detailed explanations and code samples? Would be nice to improve TPR docs with at least a link to this repo.
  • Package level config variable in main.go is not used, it is shadowed by the one defined in main(). Should probably be deleted.
  • configureClient() mutates global api.Scheme - it is probably a bad idea. Because of that a program I'm writing had a race condition on that field. Any reasons not to create a new Scheme instance and mutate it (that is what I did)?

ThirdPartyResources TypeMeta empty?

While using ThirdPartyResources together with Informer I noticed that sometimes the Kind and APIVersion are missing.

I wrote a little test app based on the ThirdPartyResources and Informer examples to reproduce the issue. Source: https://github.com/yvespp/tpr-example
Here is the output of the app:

lodur:tpr-example yves$ $GOPATH/bin/tpr-example -kubeconfig ~/.kube/config 
SKIPPING: already exists &v1beta1.ThirdPartyResource{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"example.k8s.io", GenerateName:"", Namespace:"", SelfLink:"/apis/extensions/v1beta1/thirdpartyresourcesexample.k8s.io", UID:"98135044-d69c-11e6-9758-165fba9cabe3", ResourceVersion:"12807", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{sec:63619584673, nsec:0, loc:(*time.Location)(0x15d1720)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ClusterName:""}, Description:"An Example ThirdPartyResource", Versions:[]v1beta1.APIVersion{v1beta1.APIVersion{Name:"v1"}}}
GET: main.Example{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, Metadata:v1.ObjectMeta{Name:"example1", GenerateName:"", Namespace:"default", SelfLink:"/apis/k8s.io/v1/namespaces/default/examples/example1", UID:"c6f43676-d6a7-11e6-9758-165fba9cabe3", ResourceVersion:"18219", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{sec:63619589476, nsec:0, loc:(*time.Location)(0x15d1720)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ClusterName:""}, Spec:main.ExampleSpec{Foo:"hello", Bar:true}}
LIST: main.ExampleList{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, Metadata:v1.ListMeta{SelfLink:"/apis/k8s.io/v1/examples", ResourceVersion:"18804"}, Items:[]main.Example{main.Example{TypeMeta:v1.TypeMeta{Kind:"Example", APIVersion:"k8s.io/v1"}, Metadata:v1.ObjectMeta{Name:"example1", GenerateName:"", Namespace:"default", SelfLink:"/apis/k8s.io/v1/namespaces/default/examples/example1", UID:"c6f43676-d6a7-11e6-9758-165fba9cabe3", ResourceVersion:"18219", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{sec:63619589476, nsec:0, loc:(*time.Location)(0x15d1720)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ClusterName:""}, Spec:main.ExampleSpec{Foo:"hello", Bar:true}}}}
Starting watch!
listing examples from store:
CREATED: default/example1, APIVersion: k8s.io/v1, Kind: Example
UPDATED:
  old: default/example1, APIVersion: k8s.io/v1, Kind: Example
  new: default/example1, APIVersion: k8s.io/v1, Kind: Example
UPDATED:
  old: default/example1, APIVersion: k8s.io/v1, Kind: Example
  new: default/example1, APIVersion: k8s.io/v1, Kind: Example
UPDATED:
  old: default/example1, APIVersion: k8s.io/v1, Kind: Example
  new: default/example1, APIVersion: k8s.io/v1, Kind: Example
UPDATED:
  old: default/example1, APIVersion: k8s.io/v1, Kind: Example
  new: default/example1, APIVersion: k8s.io/v1, Kind: Example
DELETED: default/example1, APIVersion: , Kind: 
CREATED: default/example1, APIVersion: , Kind: 
UPDATED:
  old: default/example1, APIVersion: , Kind: 
  new: default/example1, APIVersion: , Kind: 
UPDATED:
  old: default/example1, APIVersion: , Kind: 
  new: default/example1, APIVersion: , Kind: 
UPDATED:
  old: default/example1, APIVersion: , Kind: 
  new: default/example1, APIVersion: , Kind: 
^Creceived signal 2, exiting...

As you can see, the first create and update events have the TypeMeta but all events starting form the DELETED event have no TypeMeta.
The first resource get's created in the code, the DELETED and CREATED events come from these commands:

kubectl delete -f example.yaml 
kubectl create -f example.yaml 

I used the client from HEAD but originally run into the problem with the v1.5.0 and Kubernetes 1.4.7.

Are there some issues with the test code or is this a bug?

Cannot use GetOptions{}?

I'm having code like this:

_, err = nsClient.Get(t.namespace, meta_v1.GetOptions{})

Where nsClient is a v1.NamespaceInterface.

This defines the Get() method as follows:

Get(name string, options meta_v1.GetOptions) (*v1.Namespace, error)

Sadly meta_v1 is a vendored package:

meta_v1 "k8s.io/apimachinery/pkg/apis/meta/v1"

If I refer to GetOptions() in my code directly, by adding the same import, I get the following:

./targets.go:138: cannot use "k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions
 literal (type "k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions) as type
 "k8s.io/client-go/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions
 in argument to nsClient.Get

Whereas when I try to refer to the vendored package, I get the (correct) error:

package github.com/rubenv/kube-appdeploy
        imports k8s.io/client-go/vendor/k8s.io/apimachinery/pkg/apis/meta/v1:
        use of vendored package not allowed

How on earth is one supposed to use this library?

Segmentation violation while creating a service

I have been successfully able to get a service by name, but I am running into a segmentation violation while I create a service.

This is the function is created:

func createService(namespace string, serviceName string, servicePort int32) {
    fmt.Println("Service '", serviceName, "' in namespace '", namespace, "' does not exist!")
    metadata := v1.ObjectMeta{Name: serviceName, Namespace: namespace}

    servicePorts := []v1.ServicePort{v1.ServicePort{Port: servicePort}}
    serviceSpec := v1.ServiceSpec{Ports: servicePorts}

    service := v1.Service{ObjectMeta: metadata, Spec: serviceSpec}

    clientset.Core().Services(namespace).Create(&service)
}

This is the stacktrace I get related to client-go:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4913d0]

goroutine 1 [running]:
panic(0xd6af80, 0xc42000c0c0)
    /usr/local/Cellar/go/1.7.1/libexec/src/runtime/panic.go:500 +0x1a1
k8s.io/client-go/1.4/kubernetes/typed/core/v1.(*services).Create(0xc42028b8c0, 0xc420426780, 0x7, 0x1538040, 0xc42028b8c0)
    /Users/wombat/golang/src/k8s.io/client-go/1.4/kubernetes/typed/core/v1/service.go:62 +0x70

Error using EventBroadcaster.StartRecordingToSink

I am converting a client to client-go and I see this error:

../../pkg/ingress/controller/controller.go:157: cannot use config.Client.Core().Events(config.Namespace) (type "k8s.io/client-go/kubernetes/typed/core/v1".EventInterface) as type record.EventSink in argument to eventBroadcaster.StartRecordingToSink:
	"k8s.io/client-go/kubernetes/typed/core/v1".EventInterface does not implement record.EventSink (wrong type for Patch method)
		have Patch(string, "k8s.io/client-go/pkg/api".PatchType, []byte, ...string) (*"k8s.io/client-go/pkg/api/v1".Event, error)
		want Patch(*"k8s.io/client-go/pkg/api/v1".Event, []byte) (*"k8s.io/client-go/pkg/api/v1".Event, error)

This is the code:

eventBroadcaster := record.NewBroadcaster()
eventBroadcaster.StartLogging(glog.Infof)
eventBroadcaster.StartRecordingToSink(config.Client.Core().Events(config.Namespace))

I'm doing something wrong or it's a bug?
Thanks!

Edit: same behavior in master or 1.5 branch

Consider versioning against API version rather than Kubernetes version

With the API guarantees since 1.0, it makes more sense to version the client against the API version. There should be no need to use a matching client version against Kubernetes version, the only thing that matters is the API version. Software using the go-client should not have to keep versions in lock-step with the Kubernetes version they are running against. This would seriously limit the usability of the client.

So I propose that the client be versioned independently to Kubernetes itself & the API compatibility be documented instead, e.g. client-go v0.1 supports Kubernetes API v1, extensions API v1beta1, etc.

1.4 subdirectory causes glide to fail

When using the following glide.yaml, glide is unable to update or install the client-go to the "1.4" subdirectory under the root.

`
package: github.com/30x/postgres-k8s/cli
import:

  • package: github.com/spf13/cobra
    vcs: git
  • package: k8s.io/client-go
    version: v1.4.0
    `

This causes the following error.

[ERROR] Error scanning k8s.io/client-go/kubernetes: open /Users/apigee/.glide/cache/src/https-k8s.io-client-go/kubernetes: no such file or directory [ERROR] This error means the referenced package was not found. [ERROR] Missing file or directory errors usually occur when multiple packages [ERROR] share a common dependency and the first reference encountered by the scanner [ERROR] sets the version to one that does not contain a subpackage needed required [ERROR] by another package that uses the shared dependency. Try setting a [ERROR] version in your glide.yaml that works for all packages that share this [ERROR] dependency. [ERROR] Error scanning k8s.io/client-go/pkg/api: open /Users/apigee/.glide/cache/src/https-k8s.io-client-go/pkg/api: no such file or directory [ERROR] This error means the referenced package was not found. [ERROR] Missing file or directory errors usually occur when multiple packages [ERROR] share a common dependency and the first reference encountered by the scanner [ERROR] sets the version to one that does not contain a subpackage needed required [ERROR] by another package that uses the shared dependency. Try setting a [ERROR] version in your glide.yaml that works for all packages that share this [ERROR] dependency.

Is it possible to remove the 1.4 subdirectory on the tag?

Bundling k8s client-go includes internal packages

Trying to bundle k8s client-go with godep throws the following error:


        imports k8s.io/client-go/kubernetes
	imports k8s.io/client-go/discovery
	imports k8s.io/client-go/pkg/api
	imports k8s.io/client-go/pkg/api/meta
	imports k8s.io/client-go/pkg/api/unversioned
	imports github.com/go-openapi/spec
	imports github.com/go-openapi/jsonreference
	imports github.com/PuerkitoBio/purell
	imports golang.org/x/text/secure/precis
	imports golang.org/x/text/cases
	imports golang.org/x/text/internal
	imports golang.org/x/text/language
	imports golang.org/x/text/internal/tag

App Engine support

My app running on appengine needs to control k8s cluster running in container engine. So I patched v2.0.0-alpha.0 release to make it work.

The patch is at adieu@a2092b1

I'm not quite sure if we have plan to support appengine. If we do, I'd be pleased to create a PR with my patch.

I also tried to apply the patch with the latest master, it wouldn't work since latest commits use unsafe package for conversion. We might have to make another patch to disable conversion for appengine.

govendor get k8s.io/client-go failed

when exec
govendor get k8s.io/client-go

I get following error:
can't load package: package k8s.io/client-go: no buildable Go source files in ~/go/src/k8s.io/client-go

[qestion] release-2.0 compatibility

There is a branch named release-2.0. But the ReadMe file looks either irrelevant or outdated.
Is it a truly another release or just release-1.5 renamed?
Anyway, that would be great to know compatibilities of this release
Thanks

versioning: this repo is weird to use with godocs and glide

Using this repo with glide is super bizarre UX. When I pin it to

Essentially the workflow works like this:

  • Visit godoc.org/k8s.io/client-go, see functions I want
  • glide get k8s.io/client-go
  • glide asks me if I want to use v1.5 release b/c it is tagged
  • Try to import k8s.io/client-go/dynamic and it doesn't exist

Can we put the v1.4, v1.5, etc dirs into the master branch as well? Otherwise this UX is really confusing when compared to every other Go library.

Support for Exec & Attach APIs

Currently the client doesn't seem to support the Exec into container, attach to container APIs. The client should support those APIs.

discovery: don't import client auth provider plugins

Import statement here[0].

I maintain the OIDC auth plugin, and I don't think they're useful for most clients, and it has a pretty big dependency footprint.

Can we document which empty imports you need to use to get oidc or gce support instead of importing these by default? Happy to open this same issue in the Kubernetes repo if that's where it needs to be addressed.

[0]

_ "k8s.io/client-go/plugin/pkg/client/auth"

kube-apiserver flag redefined: log_dir

hi,forums
when i run go install in cmd/kube-apiserver, then start this binary, the service always failed with
panic(0x305bb20, 0xc8203cb430)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
flag.(_FlagSet).Var(0xc820088300, 0x7f9dde6366a0, 0xc8203cb3e0, 0x42546b0, 0x7, 0x4714660, 0x2f)
/usr/local/go/src/flag/flag.go:776 +0x454
flag.(_FlagSet).StringVar(0xc820088300, 0xc8203cb3e0, 0x42546b0, 0x7, 0x0, 0x0, 0x4714660, 0x2f)
/usr/local/go/src/flag/flag.go:679 +0xc7
flag.(*FlagSet).String(0xc820088300, 0x42546b0, 0x7, 0x0, 0x0, 0x4714660, 0x2f, 0xc8203cb3d0)
/usr/local/go/src/flag/flag.go:692 +0x83
flag.String(0x42546b0, 0x7, 0x0, 0x0, 0x4714660, 0x2f, 0x7f9dde5b4d00)
/usr/local/go/src/flag/flag.go:699 +0x5f
github.com/golang/glog.init()
/opt/k8s/src/github.com/golang/glog/glog_file.go:41 +0x13e
k8s.io/client-go/1.4/pkg/labels.init()
/opt/k8s/src/k8s.io/client-go/1.4/pkg/labels/selector.go:822 +0x5b
k8s.io/client-go/1.4/pkg/api/unversioned.init()
/opt/k8s/src/k8s.io/client-go/1.4/pkg/api/unversioned/zz_generated.deepcopy.go:390 +0x6f
k8s.io/client-go/1.4/pkg/api.init()
/opt/k8s/src/k8s.io/client-go/1.4/pkg/api/zz_generated.deepcopy.go:3749 +0x6e
k8s.io/client-go/1.4/rest.init()
/opt/k8s/src/k8s.io/client-go/1.4/rest/versions.go:88 +0x75
k8s.io/kubernetes/plugin/pkg/client/auth/gcp.init()
/opt/k8s/src/k8s.io/kubernetes/plugin/pkg/client/auth/gcp/gcp.go:119 +0x59
k8s.io/kubernetes/plugin/pkg/client/auth.init()
/opt/k8s/src/k8s.io/kubernetes/plugin/pkg/client/auth/plugins.go:23 +0x3b
k8s.io/kubernetes/pkg/client/unversioned.init()
/opt/k8s/src/k8s.io/kubernetes/pkg/client/unversioned/util.go:79 +0xe7
k8s.io/kubernetes/pkg/controller/serviceaccount.init()
/opt/k8s/src/k8s.io/kubernetes/pkg/controller/serviceaccount/tokens_controller.go:746 +0xa8
k8s.io/kubernetes/cmd/kube-apiserver/app.init()
/opt/k8s/src/k8s.io/kubernetes/cmd/kube-apiserver/app/server.go:310 +0x107
main.init()
/opt/k8s/src/k8s.io/kubernetes/cmd/kube-apiserver/apiserver.go:54 +0x4f

even doing the steps below:
1)run godep restore (godep) in the client-go/1.4 folder, then remove the vendor folder of client-go. Then the packages in your GOPATH will be the only copy
2)or run godep save in your application folder to flatten all dependencies.

the problems can not be resolved, how can i do to solve this, thks.

watcher error after 20m

When I create a watch on pods e.g. like this:

import (
...
  "k8s.io/client-go/1.4/kubernetes"
  "k8s.io/client-go/1.4/pkg/api"
  apiv1 "k8s.io/client-go/1.4/pkg/api/v1"
  "k8s.io/client-go/1.4/pkg/labels"
  "k8s.io/client-go/1.4/pkg/selection"
  "k8s.io/client-go/1.4/pkg/util/sets"
  "k8s.io/client-go/1.4/pkg/watch"
  ...
)
...
podsClient := clientset.Core().Pods("default")
watcher, err := podsClient.Watch(api.ListOptions{...})
...
select {
...
  case ev := <-watcher.ResultChan():
  ...
}

I have the trouble that after exactly 20 minutes, the ResultChan() receives infinite messages, but they are all empty. Trying to print the returned ev from the channel shows that it is an empty/uninitialized map map[Type: Object:<nil>].

Is this expected behaviour? Am I supposed to renew the watch after some time?

add support for release-1.3

This is really a great step forward, thank you very much! Sometimes we may need an old version such as release-1.3, hope to support for it

Dependency on k8s.io/kubernetes/pkg/util/ratelimit

Hello!

It looks like a dependency on k8s.io/kubernetes crept in earlier today: 49f8f1b

Is this intentional?

I only noticed this after adding client-go as a dependency in my project (using Glide) without providing a specific version to depend on.

Import leader election code?

As a user, if I want to use the leader election code (https://github.com/kubernetes/kubernetes/tree/master/pkg/client/leaderelection), then I have to switch back to import from kubernetes/pkg/client because the types defined here has a different path with the types defined in kubernetes/pkg/client. e.g.

leader_election.go:33: cannot use c (type *Client) as type "github.com/yifan-gu/test/vendor/k8s.io/kubernetes/pkg/client/unversioned".Interface in field value:
	*Client does not implement "github.com/yifan-gu/test/vendor/k8s.io/kubernetes/pkg/client/unversioned".Interface (wrong type for Apps method)
		have Apps() "github.com/yifan-gu/test/vendor/k8s.io/client-go/1.4/kubernetes/typed/apps/v1alpha1".AppsInterface
		want Apps() "github.com/yifan-gu/test/vendor/k8s.io/kubernetes/pkg/client/unversioned".AppsInterface

v1.Event.Search does not work

k8s.io/client-go/kubernetes/typed/core/v1/event_expansion.go:

func (e *events) Search(objOrRef runtime.Object) (*v1.EventList, error) {
	ref, err := api.GetReference(objOrRef)
	if err != nil {
		return nil, err
	}
	if e.ns != "" && ref.Namespace != e.ns {
		return nil, fmt.Errorf("won't be able to find any events of namespace '%v' in namespace '%v'", ref.Namespace, e.ns)
	}
	stringRefKind := string(ref.Kind)
	var refKind *string
	if stringRefKind != "" {
		refKind = &stringRefKind
	}
	stringRefUID := string(ref.UID)
	var refUID *string
	if stringRefUID != "" {
		refUID = &stringRefUID
	}
	fieldSelector := e.GetFieldSelector(&ref.Name, &ref.Namespace, refKind, refUID)
	return e.List(v1.ListOptions{FieldSelector: fieldSelector.String()})
}

ref, err := api.GetReference(objOrRef) should be ref, err := v1.GetReference(objOrRef), or the search will be failed if the parameter is a v1 object.

release 1.5 doesn't build

Hi all,

Thank you for making the client-go available!

I'm having trouble generally using the library with release 1.5 (needed for google auth). The only process I was able to get working involved checkout release 1.5, godep restore, and copying it over to a k8s.io directory in my src/ folder. This allowed me to get the examples up and running, but doesn't allow me to use godep save once i want to save my host project.

Would it be possible to get go get k8s.io/kubernetes/client-go/1.5/... working to eschew the complexity of messing with git?

Furthermore, simply checking out release-1.5 and running godep install ./... yields the following type of errors

can't load package: package github.com/kubernetes/client-go/1.5/tools/cache: code in directory .../src/github.com/kubernetes/client-go/1.5/tools/cache expects import "k8s.io/client-go/1.5/tools/cache"

Where can I find the Deployments API?

Hello,

I try to use Deployments, but can't find the right subpackage?
I'm really confused about which package implements which set of APIs. Where are the extension, alpha and beta API-Objekts implemented?

When should I use:
/kubernetes
/ai
/api/v1
/unversioned
/rest

Thank your very much!

Copy versioned listers to client-go

Problem
client-go currently only has listers for internal version object, but the clients provided by client-go use versioned objects (like v1.Pod).

Solution
We need to copy the listers from k8s to client-go.

Temporary workaround
For now, users can call the conversion functions translate between versioned and internal API, e.g., this line (use nil for conversion.Scope).

GCP auth Provider

Is there already a documented way to use gcp as auth provider? I am looking into accessing a GKE cluster with my local kubeconfig file and also tried to use the gcpAuthProvider from https://github.com/kubernetes/kubernetes/blob/99295356ed152663698e002494a5af00d682dc6b/plugin/pkg/client/auth/gcp/gcp.go but things are not working out.

I inlined the gcpAuthProvider (to to fix all dependencies) into a little test application, but I am getting this error: the server has asked for the client to provide credentials (get pods).

This is what I have so far: https://gist.github.com/tobstarr/6765104c764a3a6af8ec894bb5a0028b

Watcher doesn't see events after it was recreated

We are writing application using client-go https://github.com/Mirantis/k8s-externalipcontroller.

Logs from scheduler (removes ipclaims and watches events):

I1124 11:19:59.327322       1 scheduler.go:373] Deleting ipclaim 10-107-10-2-24
I1124 11:19:59.356793       1 scheduler.go:179] Ipclaim deleted 10-107-10-2-24, resource version 14437
I1124 11:19:59.356837       1 scheduler.go:373] Deleting ipclaim 10-107-10-3-24
I1124 11:19:59.370075       1 scheduler.go:179] Ipclaim deleted 10-107-10-3-24, resource version 14439
I1124 11:19:59.370490       1 scheduler.go:373] Deleting ipclaim 10-107-10-4-24
I1124 11:19:59.385053       1 scheduler.go:179] Ipclaim deleted 10-107-10-4-24, resource version 14441
I1124 11:19:59.385136       1 scheduler.go:373] Deleting ipclaim 10-107-10-5-24
I1124 11:19:59.391902       1 scheduler.go:179] Ipclaim deleted 10-107-10-5-24, resource version 14442

Controller (watches events):

I1124 11:19:59.353745       7 controller.go:119] Received delete event for 10-107-10-2-24 - dind-node-2. Resource version 14437
I1124 11:19:59.353779       7 controller.go:148] Processing claim 10.107.10.2/24 with node dind-node-2 and uid dind-node-2
I1124 11:19:59.353790       7 netutils.go:78] Removing addr 10.107.10.2/24 from link docker0
I1124 11:19:59.394784       7 streamwatcher.go:107] Unable to decode an event from the watch stream: read tcp 172.17.0.7:43748->10.0.0.1:443: read: connection reset by peer
I1124 11:19:59.394836       7 reflector.go:403] github.com/Mirantis/k8s-externalipcontroller/vendor/k8s.io/client-go/1.5/tools/cache/reflector.go:109: Watch close - *extensions.IpClaim total 11 items received
I1124 11:19:59.394852       7 controller.go:48] Calling claim watcher with options {{ } <nil> <nil> false 14437 0xc8203eeff8}

I am using cache.ListerWatcher and NewInformer. Maybe i am missing something, but i didn't find any special handling of this failures in existing controllers.

@caesarxuchao can you take a look at this problem?

vendor directory

I'm so stoked to see this client pulled out from the main repo. Thank you so much!

Okay, so it'd be nice for this repository to not vendor its dependencies. I think it may have happened accidentally since the Godeps directory next to it is blank.

There's been a rough consensus so far that vendoring dependencies is great for OSS binaries but that for OSS libraries they tend to hurt more than they help. This is because a number of Go libraries set globals and fiddle bits in other libraries and the collisions that occur when two (or more) versions of the library interact can be difficult to suss out or even identify.

And since the Godeps directory is blank, even if I was a supremely disciplined engineer that inspect all of my dependencies' dependencies' versions, that would be difficult to do.

But maybe this battle was fought some time ago. Would love to get a link that discussion!

v1beta1/deployment: delete dependents

When removing a deployment I'd like the related replicaset/pods to be removed as well (this is the cascading mode in kubectl).

I tried to call Deployments("ns").Delete with the OrphanDependents option set to true or false but it didn't seem to do anything.
How can I do the cascading delete with client-go?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.