This thread brings up an important point about available kubernetes client
bindings and their maturity in terms of full fledged support of k8s apis.
My experience has been with these :
- https://github.com/kubernetes/client-go/ : official Go binding with full
support of k8s API; we just migrated one of the project which was using
in-tree internal clientset to this.
- https://github.com/fabric8io/kubernetes-client : Java client with fluent
DSL; support most of the k8s APIs, good watch client support, also supports
higher level constructs(found only in kubectl) like rolling-upgrade,
cascading deletes, out of the box.

Advertising

I'm also interested in learning about any full fledged js/nodejs and python
bindings with good watch api support.
-Ravi
On Friday, October 14, 2016 at 11:15:01 AM UTC-7, Daniel Smith wrote:
>
> I would follow https://github.com/mbohlool/, he'll probably be the one
> making the repos.
>
> On Fri, Oct 14, 2016 at 11:07 AM, Diego Rodríguez Rodríguez <
> diego...@gmail.com <javascript:>> wrote:
>
>> It was just that, but I feel like I would need a library to rely on as
>> soon as possible (I am doing everything by hand) because the actual ones
>> are not mature enough. When do you plan to release it? I am very interested.
>>
>>
>> On Friday, 14 October 2016, 'Daniel Smith' via Kubernetes user discussion
>> and Q&A <kubernet...@googlegroups.com <javascript:>> wrote:
>>
>>> Glad you figured out what was going on (I was about to say, I don't know
>>> python well but that code doesn't look like it could possibly work for a
>>> streaming connection).
>>>
>>> We are working on generating a python client. I will make sure we try
>>> the watch feature.
>>>
>>> On Fri, Oct 14, 2016 at 5:15 AM, Diego Rodríguez Rodríguez <
>>> diegorgz...@gmail.com> wrote:
>>>
>>>> I have identified the problem. It has nothing to do with Kubernetes, it
>>>> is about how Python's requests module handles this kind of connections.
>>>> Further information can be found in:
>>>>
>>>> https://github.com/kennethreitz/requests/issues/2433 ---> I have
>>>> tested it, and it does not work for me.
>>>> https://cobe.io/blog/posts/kubernetes-watch-python/ ---> Talks
>>>> about the problem and provides a link to the Python module they have
>>>> created to wrap the k8s API calls
>>>>
>>>> The module is https://bitbucket.org/cobeio/kube/overview and it might
>>>> be of help for someone who runs in that kind of troubles, for me does not
>>>> work because as I could read in their docs, they do not support k8s jobs
>>>> yet.
>>>>
>>>>
>>>> On 14 October 2016 at 10:36, Diego Rodríguez Rodríguez <
>>>> diegorgz...@gmail.com> wrote:
>>>>
>>>>> This is what I am doing already
>>>>>
>>>>> def get_job_state(job_id):
>>>>>> response = requests.get('{}{}/{}'.format('https://kubernetes',
>>>>>> ENDPOINT, job_id),
>>>>>> headers={'Authorization': 'Bearer
>>>>>> {}'.format(
>>>>>> TOKEN
>>>>>> )},
>>>>>> verify=CA_CERT_PATH)
>>>>>>
>>>>>> if response.ok:
>>>>>> res_dict = json.loads(response.text)
>>>>>> resource_version = res_dict['metadata']['resourceVersion']
>>>>>> while not (res_dict['status'].get('succeeded', False) or
>>>>>> res_dict['status'].get('failed', False)):
>>>>>> response =
>>>>>> requests.get('{0}{1}/{2}?watch=true&resourceVersion={3}'
>>>>>> .format('https://kubernetes',
>>>>>> ENDPOINT, job_id,
>>>>>> resource_version),
>>>>>> headers={'Authorization': 'Bearer
>>>>>> {}'.
>>>>>> format(
>>>>>> TOKEN
>>>>>> )},
>>>>>> verify=CA_CERT_PATH)
>>>>>>
>>>>>> if response.ok:
>>>>>> res_dict = json.loads(response.text)
>>>>>> else:
>>>>>> # handle this
>>>>>>
>>>>> But it is not working, it is doing just the same as when I was using
>>>>> it without watch and RV.
>>>>>
>>>>>
>>>>>
>>>>> On 13 October 2016 at 19:13, 'Daniel Smith' via Kubernetes user
>>>>> discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
>>>>>
>>>>>> Watch definitely should do the thing you want.
>>>>>>
>>>>>> In a loop:
>>>>>> 1. List. Note the returned RV. This gives you the current state of
>>>>>> the system.
>>>>>> 2. Watch, passing the RV.
>>>>>> 3. Process events until the watch closes or times out.
>>>>>>
>>>>>> On Thu, Oct 13, 2016 at 7:43 AM, Diego Rodríguez Rodríguez <
>>>>>> diegorgz...@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks for the advice but I have already tried the `watch` parameter
>>>>>>> and as far as I understand it does not work as expected. It gives me
>>>>>>> the
>>>>>>> same output as if I did not use the `watch` parameter even if I provide
>>>>>>> the
>>>>>>> first `resourceVersion` in order to be sure that it is comparing with
>>>>>>> the
>>>>>>> first state of the job.
>>>>>>>
>>>>>>> I am making reference to
>>>>>>> http://kubernetes.io/docs/api-reference/extensions/v1beta1/operations/
>>>>>>> on the 'watch changes to an object of kind Job' section.
>>>>>>>
>>>>>>> To be honest I have never used something like this `watch` parameter
>>>>>>> before, so I may be misunderstanding it, but I am afraid I am not.
>>>>>>>
>>>>>>> On 13 October 2016 at 16:22, Rodrigo Campos <rodrig...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> You can probably watch via the API and get notified, but Haven't
>>>>>>>> used it.
>>>>>>>>
>>>>>>>> But if you are building something not trivial, you may be better
>>>>>>>> off creating a third party resource that handles this and creates
>>>>>>>> kubernetes jobs under the hood. You will have more flexibility, etc.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, October 13, 2016, Diego Rodríguez Rodríguez <
>>>>>>>> diegorgz...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I have already created an issue
>>>>>>>>> <https://github.com/kubernetes/kubernetes/issues/34715> in Github.
>>>>>>>>>
>>>>>>>>> Building on top of that, and closely related to
>>>>>>>>> https://github.com/kubernetes/kubernetes/issues/34363 and to
>>>>>>>>> https://github.com/kubernetes/kubernetes/pull/18827 I have the
>>>>>>>>> following question. Since I am planning to use Kubernetes as a
>>>>>>>>> executing
>>>>>>>>> backend for the workflow execution environment I am building, at some
>>>>>>>>> point
>>>>>>>>> we will need to know the current state of a job. Well, this time has
>>>>>>>>> come,
>>>>>>>>> and for now the only thing I am able to do is polling the API (
>>>>>>>>> kubernetes.io/docs/api-reference/extensions/v1beta1/operations/).
>>>>>>>>> Taking into account that this is unacceptable, and I only did it for
>>>>>>>>> testing purposes, what is the recommended way in Kubernetes for doing
>>>>>>>>> so?
>>>>>>>>> (Keep in mind that I should do it from inside the cluster, no kubectl
>>>>>>>>> command) If it is not possible right now, will it be possible soon? I
>>>>>>>>> am
>>>>>>>>> working on a quite big project and since it is starting, and the
>>>>>>>>> first
>>>>>>>>> problems we are facing are related to this issues, it is time to
>>>>>>>>> decide if
>>>>>>>>> I continue with Kubernetes or I have to start looking for
>>>>>>>>> alternatives.
>>>>>>>>>
>>>>>>>>> Thanks for your commitment
>>>>>>>>>
>>>>>>>>> On Wednesday, 12 October 2016 23:54:16 UTC+2, Derek Carr wrote:
>>>>>>>>>>
>>>>>>>>>> The quota controller observes pod deletions, and queues the
>>>>>>>>>> pertinent quotas for processing in response. The replenishment
>>>>>>>>>> should be
>>>>>>>>>> relatively quick now.
>>>>>>>>>>
>>>>>>>>>> We actually exercise this behavior in e2e runs.
>>>>>>>>>>
>>>>>>>>>> 1. What version of Kubernetes are you running?
>>>>>>>>>> 2. How many quotas?
>>>>>>>>>> 3. How many pods?
>>>>>>>>>>
>>>>>>>>>> My guess is that there is a conflict of some kind during the
>>>>>>>>>> quota sync, and the 5 minutes you are seeing is a full re-sync
>>>>>>>>>> interval for
>>>>>>>>>> the quota controller.
>>>>>>>>>>
>>>>>>>>>> It would be good to try to determine what the conflict is so we
>>>>>>>>>> can fix.
>>>>>>>>>>
>>>>>>>>>> If you have a quick set of steps I can run to reproduce that
>>>>>>>>>> would be great.
>>>>>>>>>>
>>>>>>>>>> I recommend opening an issue with the above details and cc
>>>>>>>>>> @derekwaynecarr
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Derek
>>>>>>>>>>
>>>>>>>>>> On Wednesday, October 12, 2016 at 3:18:07 PM UTC-4, David Eads
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Quota reconcilation of pods was supposed to run at a faster
>>>>>>>>>>> rate. I'm not sure if 5 minutes is that faster rate.
>>>>>>>>>>>
>>>>>>>>>>> *Derek:* Do you recall where and how the fast pod replenishment
>>>>>>>>>>> is?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wednesday, October 12, 2016 at 1:28:45 PM UTC-4, Daniel Smith
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Ah, you're blocked because the quota check reconciles slowly.
>>>>>>>>>>>> The quick fix is probably to just get more quota.
>>>>>>>>>>>>
>>>>>>>>>>>> +David who may know of an already existing issue about this.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Oct 12, 2016 at 5:39 AM, Diego Rodríguez Rodríguez <
>>>>>>>>>>>> diego...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I have already configured my cluster to test what you have
>>>>>>>>>>>>> stated. What I have done so far is to create a ResourceQuota
>>>>>>>>>>>>> which takes
>>>>>>>>>>>>> care that there will not be more than 4 pods running. Then I ask
>>>>>>>>>>>>> for say 20
>>>>>>>>>>>>> jobs to be completed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What happens in reality is that the first 4 jobs are completed
>>>>>>>>>>>>> and then, even though the pods are completed and therefore
>>>>>>>>>>>>> resources are
>>>>>>>>>>>>> available, it takes some minutes (around 4-5 minutes) to have
>>>>>>>>>>>>> another 4
>>>>>>>>>>>>> jobs being completed. Indeed, what you said is true, however it
>>>>>>>>>>>>> is no
>>>>>>>>>>>>> practical because a delay of minutes can not be assumed.
>>>>>>>>>>>>> The waiting jobs events look like this:
>>>>>>>>>>>>> `FailedCreate Error creating: pods
>>>>>>>>>>>>> "d59fa9b2-6c6b-4dc5-b149-7f89b35421bf-10-" is forbidden: Exceeded
>>>>>>>>>>>>> quota:
>>>>>>>>>>>>> compute-resources, requested: pods=1, used: pods=4, limited:
>>>>>>>>>>>>> pods=4`
>>>>>>>>>>>>> So, it fails because there are no resources but it is trying
>>>>>>>>>>>>> it again only after some minutes. This behavior is far from the
>>>>>>>>>>>>> desired
>>>>>>>>>>>>> one, which is relaying on Kubernetes for the execution of a set
>>>>>>>>>>>>> of tasks no
>>>>>>>>>>>>> matter the resources available, just getting them executed as
>>>>>>>>>>>>> soon as
>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Monday, 10 October 2016 19:24:46 UTC+2, Daniel Smith wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the system lacks resources, Pods will remain "Pending"
>>>>>>>>>>>>>> until resources become available. Cluster scalers may use
>>>>>>>>>>>>>> pending pods as a
>>>>>>>>>>>>>> signal that the cluster size should be increased.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Oct 10, 2016 at 5:58 AM, Diego Rodríguez Rodríguez <
>>>>>>>>>>>>>> diego...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello, I have a doubt about how Kubernetes' jobs are handled.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a queue to submit certain amount of incoming tasks
>>>>>>>>>>>>>>> (Celery and RabbitMQ take care of this). Each one of this tasks
>>>>>>>>>>>>>>> is, in
>>>>>>>>>>>>>>> fact, a *workflow* which will be executed in a worker
>>>>>>>>>>>>>>> (Celery worker with a DAG executor inside). Each step of the
>>>>>>>>>>>>>>> *workflow* is a Docker image with an input file and an
>>>>>>>>>>>>>>> output file.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My question is, if I submit jobs from the workflow engine
>>>>>>>>>>>>>>> directly to the Kubernetes API, what happens I at some point
>>>>>>>>>>>>>>> there are no
>>>>>>>>>>>>>>> more resources? Will the remaining tasks be kept or will they
>>>>>>>>>>>>>>> be lost? My
>>>>>>>>>>>>>>> goal is to treat Kubernetes' jobs as a black box to submit
>>>>>>>>>>>>>>> works to. This
>>>>>>>>>>>>>>> works are of a very different and heterogeneous nature and I
>>>>>>>>>>>>>>> wouldn't need
>>>>>>>>>>>>>>> to bother with what is inside them because they are dockerized
>>>>>>>>>>>>>>> and executed
>>>>>>>>>>>>>>> by Kubernetes at some point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To sum up, I already have the layer of Celery workers with a
>>>>>>>>>>>>>>> DAG executor inside which knows the right order of the tasks
>>>>>>>>>>>>>>> and knows how
>>>>>>>>>>>>>>> to manage everything concerning the *workflow*. These
>>>>>>>>>>>>>>> components will submit jobs (through Kubernetes API) and will
>>>>>>>>>>>>>>> wait for them
>>>>>>>>>>>>>>> to be executed and then continue with the remaining tasks
>>>>>>>>>>>>>>> asking Kubernetes
>>>>>>>>>>>>>>> to run them until the *workflow* ends.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have read about a somehow related issue in Github:
>>>>>>>>>>>>>>> https://github.com/kubernetes/kubernetes/pull/17787
>>>>>>>>>>>>>>> https://github.com/kubernetes/kubernetes/pull/18827
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I couldn't determine if this is closed or it is coming in a
>>>>>>>>>>>>>>> future release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks in advance!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>>> Google Groups "Kubernetes user discussion and Q&A" group.
>>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails
>>>>>>>>>>>>>>> from it, send an email to kubernetes-use...@googlegroups.com
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> To post to this group, send email to
>>>>>>>>>>>>>>> kubernet...@googlegroups.com.
>>>>>>>>>>>>>>> Visit this group at
>>>>>>>>>>>>>>> https://groups.google.com/group/kubernetes-users.
>>>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>> Google Groups "Kubernetes user discussion and Q&A" group.
>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>>> it, send an email to kubernetes-use...@googlegroups.com.
>>>>>>>>>>>>> To post to this group, send email to
>>>>>>>>>>>>> kubernet...@googlegroups.com.
>>>>>>>>>>>>> Visit this group at
>>>>>>>>>>>>> https://groups.google.com/group/kubernetes-users.
>>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "Kubernetes user discussion and Q&A" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to kubernetes-users+unsubscr...@googlegroups.com.
>>>>>>>>> To post to this group, send email to
>>>>>>>>> kubernetes-users@googlegroups.com.
>>>>>>>>> Visit this group at
>>>>>>>>> https://groups.google.com/group/kubernetes-users.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>>> the Google Groups "Kubernetes user discussion and Q&A" group.
>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>> https://groups.google.com/d/topic/kubernetes-users/qd5Ua2UqQNo/unsubscribe
>>>>>>>> .
>>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>>> kubernetes-users+unsubscr...@googlegroups.com.
>>>>>>>> To post to this group, send email to
>>>>>>>> kubernetes-users@googlegroups.com.
>>>>>>>> Visit this group at
>>>>>>>> https://groups.google.com/group/kubernetes-users.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Kubernetes user discussion and Q&A" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to kubernetes-users+unsubscr...@googlegroups.com.
>>>>>>> To post to this group, send email to
>>>>>>> kubernetes-users@googlegroups.com.
>>>>>>> Visit this group at https://groups.google.com/group/kubernetes-users
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "Kubernetes user discussion and Q&A" group.
>>>>>> To unsubscribe from this topic, visit
>>>>>> https://groups.google.com/d/topic/kubernetes-users/qd5Ua2UqQNo/unsubscribe
>>>>>> .
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> kubernetes-users+unsubscr...@googlegroups.com.
>>>>>> To post to this group, send email to
>>>>>> kubernetes-users@googlegroups.com.
>>>>>> Visit this group at https://groups.google.com/group/kubernetes-users.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Kubernetes user discussion and Q&A" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to kubernetes-users+unsubscr...@googlegroups.com.
>>>> To post to this group, send email to kubernetes-users@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/kubernetes-users.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Kubernetes user discussion and Q&A" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/kubernetes-users/qd5Ua2UqQNo/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> kubernetes-users+unsubscr...@googlegroups.com.
>>> To post to this group, send email to kubernetes-users@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/kubernetes-users.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes user discussion and Q&A" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-use...@googlegroups.com <javascript:>.
>> To post to this group, send email to kubernet...@googlegroups.com
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/kubernetes-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.