[kubernetes-users] Re: Backup Datastore via Kubernetes CronJobs possible?

['Eric Tune' via Kubernetes user discussion and Q]

Kubernetes Cron Jobs do not have any special relationship to App Engine 
Cron Files or Datastore.

It looks like you can trigger a backup using the gcloud command: 
https://cloud.google.com/datastore/docs/export-import-entities
And you could run that gcloud command in a Container 
(https://hub.docker.com/r/google/cloud-sdk/)
And CronJob can help you run that container periodically.
But, you are going to have to roll your own solution.
 
On Monday, February 26, 2018 at 4:47:48 PM UTC-8, jl...@papego.de wrote:
>
> Hi there,
>
> is there any possibility to trigger a backup a Datastore backup via a 
> kubernetes CronJobs like previously via app engine described here: 
> https://cloud.google.com/appengine/articles/scheduled_backups#Specifying_Backups_in_a_Cron_File
>
> Greeting
>
> Jan
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

Re: [kubernetes-users] Is there any way to create ordinal index of pods in a normal ReplicaSet similarly to StatefulSet?

['Eric Tune' via Kubernetes user discussion and Q]

Are you using OnFailure policy and exiting with success often?

On Mon, Sep 11, 2017 at 12:40 PM, 'Tim Hockin' via Kubernetes user
discussion and Q  wrote:

> Pod restarts should not create new series'.  Only if they get rescheduled,
> as in a rolling update.  In that case they ARE different.
>
> On Sep 6, 2017 2:06 AM,  wrote:
>
> Is there any way to create ordinal index of pods in a normal ReplicaSet
> similarly to StatefulSet?
> From functional point of view this doesn't make much sense. But could be
> really useful for our monitoring solution. We use Prometheus that scrapes
> metrics from kubernetes cluster and sends it to InfluxDB.  Each newly
> created pod gets a unique name by adding a random suffix. The problem is
> that each time a new pod of the same replica is created, a new time series
> is created. This increases the metrics cardinality reducing performance and
> increasing memory footprint. It also results in creating each time a new
> line in a dashboard instead of continuing the same line.
> For example, suppose, we have a ReplicaSet with 2 replicas and each
> replica had 5 restarts. This will result in 10 separate time series and 10
> lines in a monitoring dashboard, while with the ordinal index in place,
> there will be just 2.
> When dealing with very long time intervals, hundred/thousands time series
> will be created for the same instance instead of one.
> Any suggestions are  greatly appreciated
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" 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" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/kubernetes-users/Mf6z3ZZZf90/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" 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.

[kubernetes-users] Re: Is there any way to create ordinal index of pods in a normal ReplicaSet similarly to StatefulSet?

['Eric Tune' via Kubernetes user discussion and Q]

No.  This is not possible.  

Note that some metrics are dependent on time since start (e.g. memory usage 
especially when there is a memory leak) or image version (E.g. new bug 
introduced), which is often a reason for restart.

Also, if you are using deployment, and you do a rolling update, then the 
replacements will come from a new replicaSet,
so even if ReplicaSet supported this, you would still maybe get many time 
series.

If all the replicas are really identical, then maybe you want to aggregate 
most of the metrics into a single time series for the collection of Pods?
You could still keep a few metrics split out to debug load imbalance issues.
 

On Wednesday, September 6, 2017 at 2:06:20 AM UTC-7, sergei.st...@gmail.com 
wrote:
>
> Is there any way to create ordinal index of pods in a normal ReplicaSet 
> similarly to StatefulSet? 
> From functional point of view this doesn't make much sense. But could be 
> really useful for our monitoring solution. We use Prometheus that scrapes 
> metrics from kubernetes cluster and sends it to InfluxDB.  Each newly 
> created pod gets a unique name by adding a random suffix. The problem is 
> that each time a new pod of the same replica is created, a new time series 
> is created. This increases the metrics cardinality reducing performance and 
> increasing memory footprint. It also results in creating each time a new 
> line in a dashboard instead of continuing the same line. 
> For example, suppose, we have a ReplicaSet with 2 replicas and each 
> replica had 5 restarts. This will result in 10 separate time series and 10 
> lines in a monitoring dashboard, while with the ordinal index in place, 
> there will be just 2.
> When dealing with very long time intervals, hundred/thousands time series 
> will be created for the same instance instead of one. 
> Any suggestions are  greatly appreciated

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: App management and monitoring in k8

['Eric Tune' via Kubernetes user discussion and Q]

Eswari-

I see that you posted 5 or 6 questions about Kubernetes in the last several 
days.
I'm glad you are excited about Kubernetes, but that is a lot more posts 
than most people do at a time.   
Some of your posts can be answered quickly by reading the docs.  For 
example, the front page
of http://kubernetes.io is an answer to this question.

I suggest spending some time reading the docs at http://kubernetes.io, and 
the next time you post, please provide a link
to what docs you tried reading first, and why they didn't help.




On Monday, August 7, 2017 at 9:49:49 AM UTC-7, Eswari wrote:
>
>
> If customer ask what are the services you can give to my application if it 
> is hosted on Kubernetes. (Application management and monitoring)
> How can we impress them.
>
> ex: we can say like autoscaling (load controllers)  etc.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

Re: [kubernetes-users] How to execute command in a pod (kubernetes) using API?

['Eric Tune' via Kubernetes user discussion and Q]

Did you know if you run kubectl with -v=10 it prints the equivalent curl 
command for the command you just ran?
Try "kubectl exec -v=10 $PODNAME -- ls"

On Saturday, July 29, 2017 at 4:50:14 AM UTC-7, Matthias Rampke wrote:
>
> I haven't tried this, but IIRC the required upgrade is to HTTP/2. Try 
> `curl --http2`?
>
> /MR
>
> On Sat, Jul 29, 2017, 05:31 Rodrigo Campos  > wrote:
>
>> If it wasn't resolved as it's not in the documentation wiki (sorry, away 
>> from laptop now) you can probably check how kubectl exec does it. It might 
>> not be the simpler code, but it may shed some light
>>
>> On Friday, July 28, 2017, Madhukar Nayakbomman > > wrote:
>>
>>> Hi Robinly,
>>>
>>> How did you work through this issue? Is there any API which we can use 
>>> for executing a command in a container?
>>>
>>> Thanks,
>>> Madhukar
>>>
>>> On Tuesday, February 28, 2017 at 1:30:09 AM UTC-8, Robinly wrote:

 I want to execute command in a container using k8s API, don't use any 
 libraries or tools.

 Example:
 curl -XPOST "
 http://172.25.255.22:8080/api/v1/namespaces/default/pods/redis-master-1qpyf/exec?commond=ls=master=master=true=true
 "
 {
   "kind": "Status",
   "apiVersion": "v1",
   "metadata": {},
   "status": "Failure",
   "message": "Upgrade request required",
   "reason": "BadRequest",
   "code": 400
 }

 there is a error. 

 The /api/v1/proxy should I use? what should I do?

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Kubernetes user discussion and Q" 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 the Google Groups 
>> "Kubernetes user discussion and Q" 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" 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.

[kubernetes-users] Re: SIG Architecture

['Eric Tune' via Kubernetes user discussion and Q]

+1.


On Thu, Jun 22, 2017 at 1:39 PM, Andy Goldstein  wrote:

> +1 from me too
>
> On Thu, Jun 22, 2017 at 4:37 PM, Clayton Coleman 
> wrote:
>
>> +1 - there have been several sig discussions recently about having a more
>> streamlined way to seek consensus on broad reaching technical changes, and
>> this seems like a natural (possibly overdue) sig.
>>
>> On Jun 22, 2017, at 3:13 PM, 'Brian Grant' via Kubernetes
>> developer/contributor discussion  wrote:
>>
>> At the leadership summit a few weeks ago, I believe there was consensus
>> that we should start an Architecture SIG. There were also discussions of
>> Working Groups around extensibility and repo refactoring, but I'd like to
>> fold that into SIG Architecture, since they are all related, and because
>> I've been driving these areas, directly or indirectly, and there are only
>> so many meetings I can attend.
>>
>> This is the proposal for such a SIG, as the first step in the SIG
>> creation procedure:
>> https://github.com/kubernetes/community/blob/master/sig-gove
>> rnance.md#sig-creation-procecure
>>
>> Initial mission statement (thanks to Jaice):
>>
>> The SIG would be intended to guide the design principles of Kubernetes,
>> as well as provide a consistent body of expertise necessary to ensure
>> architectural consistency over time.
>>
>>
>> The scope would cover the whole project -- issues that span/encompass all
>> the components, how they fit together, how they interact, etc. But the SIG
>> would not get involved with issues specific to a particular component or
>> functional area, which would be the purview of some other SIG, except where
>> they deviate from project-wide principles/conventions.
>>
>> The specific areas I propose are:
>>
>> Defining the scope of the Kubernetes project:
>>
>>- https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
>>- Ecosystem examples
>>
>> 
>>
>> Documenting and evolving the system architecture:
>>
>>- https://github.com/kubernetes/community/blob/master/contribu
>>tors/design-proposals/architecture.md
>>
>> 
>>- Kubernetes Architecture presentation
>>
>> 
>>- Kubernetes Architectural roadmap working document
>>
>> 
>>
>> Defining and driving necessary extensibility points
>> 
>> .
>>
>> Establishing and documenting design principles and conventions for the
>> overall system and user-facing APIs:
>>
>>- https://github.com/kubernetes/community/blob/master/contribu
>>tors/design-proposals/principles.md
>>
>> 
>>- https://github.com/kubernetes/community/blob/master/contribu
>>tors/devel/api-conventions.md
>>Note that the API conventions aren't part of API machinery because
>>that SIG is about the mechanisms for building the apiservers, APIs, and
>>client libraries, not the principles/conventions driving the design of the
>>APIs and their contents.
>>
>> Driving improvement of overall code organization -- multiple repos, etc.
>>
>> Developing necessary review processes, such as the proposal and API
>> review processes.
>>
>> Educating approvers/owners of other SIGs (e.g., by holding office hours).
>>
>>
>> Suggested meeting day/time: Thursday @ 9am Pacific, before the community
>> meeting, biweekly
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes developer/contributor discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-dev+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/kubernetes-dev/CAKCBhs6Wmq%2BKgo8ayrnHvS-jL-MBFgv%3DoUj%
>> 2BpS7-u_jFdM-QHQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes developer/contributor discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-dev+unsubscr...@googlegroups.com.
>> To post to this 

[kubernetes-users] Re: How is "spec.containers[].resources.requests.memory" is enforced by Kubernetes?

['Eric Tune' via Kubernetes user discussion and Q]

See https://kubernetes.io/docs/concepts/cluster-administration/out-of-resource/ 
and 
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-limits-are-run

On Tuesday, March 21, 2017 at 2:36:41 AM UTC-7, Qian Zhang wrote:
>
> Hi,
>
> In this doc 
> ,
>  
> I see "spec.containers[].resources.limits.memory" will be used by 
> Kubernetes as the value of the --memory flag in the docker run command, but 
> what about "spec.containers[].resources.requests.memory"? I know it will be 
> checked against the allocatable memory of the node by scheduler, but how 
> will it be enforced by kubelet when creating container?
>
>
> Thanks,
> Qian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Behavior of StatefulSets when a claim bound to PV is somehow unbound

['Eric Tune' via Kubernetes user discussion and Q]

Currently PVs have no way of signalling unhealthyness, so nothing happens.

This proposal discusses how we may handle that case in the future:
https://github.com/vishh/community/blob/2f01ad576f0f40fd77c851b02c4fb7e28cbf4b67/contributors/design-proposals/local-storage-overview.md
Search for the string "health" in that doc to see what is being proposed.


On Thu, Feb 16, 2017 at 7:47 PM, 'Brian Grant' via Kubernetes
developer/contributor discussion  wrote:

> kubernetes-dev to BCC
>
> On Thu, Feb 16, 2017 at 7:23 PM, Mayank  wrote:
>
>> Hi All
>> When a StatefulSet is running with all instances successfully have their
>> claim bound to a PV. What happens if for some reason, the underlying PV is
>> unhealthy. Will that pod reschedule to a different node, what is the
>> current behavior and are their parameters to control  the timeout ?
>>
>> -mayank
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes developer/contributor discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-dev+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/kubernetes-dev/090a695a-223c-4903-8fcf-681ad83fb7c9%40go
>> oglegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/kubernetes-dev/CAKCBhs7i_GAF1-UOwUusg6mkxxQZ518nA2kDiL8NRugw
> Bmk8HQ%40mail.gmail.com
> 
> .
>
> 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" 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.

Re: [kubernetes-users] Re: Cron Job Limitations question

['Eric Tune' via Kubernetes user discussion and Q]

On Wed, Feb 1, 2017 at 7:19 AM, Eric Tune <et...@google.com> wrote:

> Actually, thinking about this more,  I don't think the above scenario can
> happen.
> The cron controller uses deterministic names for the Jobs to prevent the
> scenario I mentioned.
> I know there can't be two objects with the same name in the kubernetes
> API.  I'm not actually certain how this is accomplished,
> though presumably it involves quorum reads for at least the key names.
> I'll ask around and report back what I learn.
>
Oh, duh.  Writes are always quorum, and they just fail if there is name
collision.
Hadn't had my morning tea yet.


>
> However, even if there is only one Job, that job can still run a pod more
> than once.  For example, a kubelet running the pod of the job might crash
> in between the time the Pod started and when it finished.  We (Kubernetes
> Cron controller and Job Controller) don't know how far it got.  So, we
> retry until success.
>
>
> On Wed, Feb 1, 2017 at 7:00 AM, Matthias Rampke <m...@soundcloud.com> wrote:
>
>> Asking as someone with such a replicated master setup – how do quorum
>> reads (from etcd) interact with this? Would they prevent these stale reads?
>>
>> On Wed, Feb 1, 2017 at 2:57 PM 'Eric Tune' via Kubernetes user discussion
>> and Q <kubernetes-users@googlegroups.com> wrote:
>>
>>> In some configurations, the API servers are replicated, with eventual
>>> consistency between them.
>>> The Cron controller is memoryless: it uses the API server for its state.
>>>
>>> Therefore, the following can happen:
>>>  1. Cron controller starts a job J a the appointed time (10:00:00, say)
>>> by POSTing J to the API Servers.  It is persisted in API server 1.  We
>>> don't wait for write confirmation.
>>> 2. 10 seconds later, the Cron controller checks if it needs to run
>>> anything. It does this by GETting the list of existing Jobs from the API
>>> server.  Say it hits API server 2 the second time, and due to some unlikely
>>> circumstances, job J's record has not replicated from API server 1 to 2.
>>> 3. Cron controller thinks that it has not started the job, and 10:00:10
>>> is not too late to start it, so it starts the job a second time.
>>>
>>> I haven't heard of this happening but it is possible in theory.
>>>
>>>
>>> On Wed, Feb 1, 2017 at 12:50 AM, Milan Sladký <milan.sla...@gmail.com>
>>> wrote:
>>>
>>> Thanks a lot for explanation Eric, this works for my use case.
>>>
>>> Can you please briefly explain how it can happen that two jobs are
>>> created?
>>>
>>> 2017-02-01 1:49 GMT+01:00 Eric Tune <et...@google.com>:
>>>
>>> Filed https://github.com/kubernetes/kubernetes.github.io/issues/2393 to
>>> improve the docs.
>>>
>>> On Tue, Jan 31, 2017 at 9:11 AM, Eric Tune <et...@google.com> wrote:
>>>
>>> If startingDeadlineSeconds is set to a large value or unset (the
>>> default) and if concurrencyPolicy is AllowConcurrent, then your jobs will
>>> always run at least once.
>>>
>>> Longer explanation:
>>>
>>> The "no job might be created" case is when the Cron Controller is down
>>> or misconfigured for an extended period of time, and your CronJob specifies
>>> that it doesn't want to be run if it is started too late.  For example, if
>>> you say that your cron job has to start at exactly 12:00:00 and not a
>>> second later, and your cron controller happens to be down for several
>>> seconds for for a software upgrade at that time, then the job will not run.
>>>
>>>
>>>
>>>
>>>
>>> On Monday, January 30, 2017 at 12:43:48 AM UTC-8, milan@gmail.com
>>> wrote:
>>>
>>> Hi,
>>> There is a following limitation mentioned in Crob Jobs section:
>>>
>>> A cron job creates a job object about once per execution time of its
>>> schedule. We say “about” because there are certain circumstances where two
>>> jobs might be created, or no job might be created.
>>>
>>> I can live with fact that the job might run more than once, but the "no
>>> job runs" option is something which makes the cron job useless for me. E.g.
>>> I cannot afford not to run a job for particular customer.
>>>
>>> Are the any plans to fix or address this in the (near) future?
>>>
>>> Thanks a lot.
>>>
>>> M.
>>>
>>>
>>>
>>>
>>

Re: [kubernetes-users] Re: Cron Job Limitations question

['Eric Tune' via Kubernetes user discussion and Q]

Actually, thinking about this more,  I don't think the above scenario can
happen.
The cron controller uses deterministic names for the Jobs to prevent the
scenario I mentioned.
I know there can't be two objects with the same name in the kubernetes
API.  I'm not actually certain how this is accomplished,
though presumably it involves quorum reads for at least the key names.
I'll ask around and report back what I learn.

However, even if there is only one Job, that job can still run a pod more
than once.  For example, a kubelet running the pod of the job might crash
in between the time the Pod started and when it finished.  We (Kubernetes
Cron controller and Job Controller) don't know how far it got.  So, we
retry until success.


On Wed, Feb 1, 2017 at 7:00 AM, Matthias Rampke <m...@soundcloud.com> wrote:

> Asking as someone with such a replicated master setup – how do quorum
> reads (from etcd) interact with this? Would they prevent these stale reads?
>
> On Wed, Feb 1, 2017 at 2:57 PM 'Eric Tune' via Kubernetes user discussion
> and Q <kubernetes-users@googlegroups.com> wrote:
>
>> In some configurations, the API servers are replicated, with eventual
>> consistency between them.
>> The Cron controller is memoryless: it uses the API server for its state.
>>
>> Therefore, the following can happen:
>>  1. Cron controller starts a job J a the appointed time (10:00:00, say)
>> by POSTing J to the API Servers.  It is persisted in API server 1.  We
>> don't wait for write confirmation.
>> 2. 10 seconds later, the Cron controller checks if it needs to run
>> anything. It does this by GETting the list of existing Jobs from the API
>> server.  Say it hits API server 2 the second time, and due to some unlikely
>> circumstances, job J's record has not replicated from API server 1 to 2.
>> 3. Cron controller thinks that it has not started the job, and 10:00:10
>> is not too late to start it, so it starts the job a second time.
>>
>> I haven't heard of this happening but it is possible in theory.
>>
>>
>> On Wed, Feb 1, 2017 at 12:50 AM, Milan Sladký <milan.sla...@gmail.com>
>> wrote:
>>
>> Thanks a lot for explanation Eric, this works for my use case.
>>
>> Can you please briefly explain how it can happen that two jobs are
>> created?
>>
>> 2017-02-01 1:49 GMT+01:00 Eric Tune <et...@google.com>:
>>
>> Filed https://github.com/kubernetes/kubernetes.github.io/issues/2393 to
>> improve the docs.
>>
>> On Tue, Jan 31, 2017 at 9:11 AM, Eric Tune <et...@google.com> wrote:
>>
>> If startingDeadlineSeconds is set to a large value or unset (the default)
>> and if concurrencyPolicy is AllowConcurrent, then your jobs will always run
>> at least once.
>>
>> Longer explanation:
>>
>> The "no job might be created" case is when the Cron Controller is down or
>> misconfigured for an extended period of time, and your CronJob specifies
>> that it doesn't want to be run if it is started too late.  For example, if
>> you say that your cron job has to start at exactly 12:00:00 and not a
>> second later, and your cron controller happens to be down for several
>> seconds for for a software upgrade at that time, then the job will not run.
>>
>>
>>
>>
>>
>> On Monday, January 30, 2017 at 12:43:48 AM UTC-8, milan@gmail.com
>> wrote:
>>
>> Hi,
>> There is a following limitation mentioned in Crob Jobs section:
>>
>> A cron job creates a job object about once per execution time of its
>> schedule. We say “about” because there are certain circumstances where two
>> jobs might be created, or no job might be created.
>>
>> I can live with fact that the job might run more than once, but the "no
>> job runs" option is something which makes the cron job useless for me. E.g.
>> I cannot afford not to run a job for particular customer.
>>
>> Are the any plans to fix or address this in the (near) future?
>>
>> Thanks a lot.
>>
>> M.
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes user discussion and Q" 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 

[kubernetes-users] Re: Cron Job Limitations question

['Eric Tune' via Kubernetes user discussion and Q]

In some configurations, the API servers are replicated, with eventual
consistency between them.
The Cron controller is memoryless: it uses the API server for its state.

Therefore, the following can happen:
 1. Cron controller starts a job J a the appointed time (10:00:00, say) by
POSTing J to the API Servers.  It is persisted in API server 1.  We don't
wait for write confirmation.
2. 10 seconds later, the Cron controller checks if it needs to run
anything. It does this by GETting the list of existing Jobs from the API
server.  Say it hits API server 2 the second time, and due to some unlikely
circumstances, job J's record has not replicated from API server 1 to 2.
3. Cron controller thinks that it has not started the job, and 10:00:10 is
not too late to start it, so it starts the job a second time.

I haven't heard of this happening but it is possible in theory.


On Wed, Feb 1, 2017 at 12:50 AM, Milan Sladký 
wrote:

> Thanks a lot for explanation Eric, this works for my use case.
>
> Can you please briefly explain how it can happen that two jobs are created?
>
> 2017-02-01 1:49 GMT+01:00 Eric Tune :
>
>> Filed https://github.com/kubernetes/kubernetes.github.io/issues/2393 to
>> improve the docs.
>>
>> On Tue, Jan 31, 2017 at 9:11 AM, Eric Tune  wrote:
>>
>>> If startingDeadlineSeconds is set to a large value or unset (the
>>> default) and if concurrencyPolicy is AllowConcurrent, then your jobs will
>>> always run at least once.
>>>
>>> Longer explanation:
>>>
>>> The "no job might be created" case is when the Cron Controller is down
>>> or misconfigured for an extended period of time, and your CronJob specifies
>>> that it doesn't want to be run if it is started too late.  For example, if
>>> you say that your cron job has to start at exactly 12:00:00 and not a
>>> second later, and your cron controller happens to be down for several
>>> seconds for for a software upgrade at that time, then the job will not run.
>>>
>>>
>>>
>>>
>>>
>>> On Monday, January 30, 2017 at 12:43:48 AM UTC-8, milan@gmail.com
>>> wrote:

 Hi,
 There is a following limitation mentioned in Crob Jobs section:

 A cron job creates a job object about once per execution time of its
 schedule. We say “about” because there are certain circumstances where two
 jobs might be created, or no job might be created.

 I can live with fact that the job might run more than once, but the "no
 job runs" option is something which makes the cron job useless for me. E.g.
 I cannot afford not to run a job for particular customer.

 Are the any plans to fix or address this in the (near) future?

 Thanks a lot.

 M.
>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Cron Job Limitations question

['Eric Tune' via Kubernetes user discussion and Q]

Filed https://github.com/kubernetes/kubernetes.github.io/issues/2393 to
improve the docs.

On Tue, Jan 31, 2017 at 9:11 AM, Eric Tune  wrote:

> If startingDeadlineSeconds is set to a large value or unset (the default)
> and if concurrencyPolicy is AllowConcurrent, then your jobs will always run
> at least once.
>
> Longer explanation:
>
> The "no job might be created" case is when the Cron Controller is down or
> misconfigured for an extended period of time, and your CronJob specifies
> that it doesn't want to be run if it is started too late.  For example, if
> you say that your cron job has to start at exactly 12:00:00 and not a
> second later, and your cron controller happens to be down for several
> seconds for for a software upgrade at that time, then the job will not run.
>
>
>
>
>
> On Monday, January 30, 2017 at 12:43:48 AM UTC-8, milan@gmail.com
> wrote:
>>
>> Hi,
>> There is a following limitation mentioned in Crob Jobs section:
>>
>> A cron job creates a job object about once per execution time of its
>> schedule. We say “about” because there are certain circumstances where two
>> jobs might be created, or no job might be created.
>>
>> I can live with fact that the job might run more than once, but the "no
>> job runs" option is something which makes the cron job useless for me. E.g.
>> I cannot afford not to run a job for particular customer.
>>
>> Are the any plans to fix or address this in the (near) future?
>>
>> Thanks a lot.
>>
>> M.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: The Resurrection of SIG-big-data

['Eric Tune' via Kubernetes user discussion and Q]

+1

On Fri, Jan 27, 2017 at 1:36 PM, Anirudh Ramanathan 
wrote:

> The Kubernetes Big Data Special Interest Group
>  was
> suspended in late 2015 in favor of SIG-Apps. Today, SIG-Apps has grown in
> scope and has a broad charter dealing with everything from distributed
> databases to external controllers to package management. The focus is
> mostly on enhancing functionality in the core to support applications.
>
> Big-data applications and their support within Kubernetes is sufficiently
> different that it would be appropriate to resurrect SIG-big-data at this
> stage. SIG-big-data would focus on external applications and integrations
> with them, to allow them to run effectively on Kubernetes. Currently, we
> have an effort around Apache Spark integration
> , which the
> previous iteration of the SIG
> 
> also discussed and designated as top priority. We have several contributors
> who would like to find a single place to discuss
> , and others who
> are interested in helping us test and productionize our efforts. In the
> short term, the SIG will serve as meeting ground to help us organize our
> efforts.
>
> Our broader mission is to focus on big data frameworks on Kubernetes
> (Spark, Kafka, Hadoop, Flink, Storm, etc). It is intended to be a common
> platform to discuss the following:
>
>-
>
>Architecture and design of integrations
>-
>
>Common reusable patterns in implementation
>-
>
>Resource allocation and fairness
>
>
> Proposed weekly meeting time: 10am PT on Wednesdays
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Authenticating Proxy help

['Eric Tune' via Kubernetes user discussion and Q]

Did you figure this out?  If not try posting in 
https://groups.google.com/forum/#!forum/kubernetes-sig-auth 

On Wednesday, January 4, 2017 at 5:33:57 PM UTC-8, Rudy Bonefas wrote:
>
> I am attempting to use an Authenticating Proxy with version 1.5.1 and am 
> having no luck.  I wrote my own proxy and am passing the user id in 
> X-REMOTE-USER.  My API server has the following relevant settings
>
> --requestheader-user-headers=X-REMOTE-USER
> --requestheader-client-ca-file=
> --authorization-mode=AlwaysAllow
> --anonymous-auth=false
> --audit-log-path=
>
> NO matter what i try, I always get 'Unauthorized' back from the apiserver. 
>  I know my client-ca file is okay because I use the same file when running 
> with x509 certification and everything works fine.
>
> To make sure that I wasn't dropping the header somehow in my java app, I 
> used curl and still got Unauthorized.
>
> I turned my server verbosity up to 8 but all I can see in the log is my 
> request uri with a 401 status code.
>
> Nothing shows up in the audit log
>
> Not sure what else to try, any help would be appreciated.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: How to share my story with community?

['Eric Tune' via Kubernetes user discussion and Q]

I'd be interested in hearing about tensorkube and your experience.  Send me 
a mail at et...@google.com and we can setup a time to chat.


On Sunday, January 8, 2017 at 5:48:03 PM UTC-8, xuxi...@gmail.com wrote:
>
> I have worked with kubernetes for about 1 year. And our team push the apps 
> of out company using containers and kubernetes. Recently, we build a 
> platform for deep learning with tensorflow and kubernetes, which named as 
> `tensorkube`.
> We want to share the experience and the story with others. Also, we'd like 
> to listen to the advice of the others.
> How can I share my story? Is there a way to push my story on `
> http://kubernetes.io/case-studies`  or 
> `blog.kubernetes.io`? 
> BTW, I post my form on `tell your story` link in `
> http://kubernetes.io/case-studies` , 
> but no response.

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: what is the best way to templatize the image field of containers in Kubernetes manifests

['Eric Tune' via Kubernetes user discussion and Q]

Short answer:

There are no kubectl features for this. 
I would do:
 cat foo.yaml.tpl | sed s/IMAGENAME/actualimagename | kubectl apply -f -


Long answer:
- we know there is a need for a reference system for templatized and 
generated config for Kubernetes, and people are working on it, but we don't 
have something to point you at right now.
- you could use jinja or jsonnet or erb.  template languages are like 
editors.  People have ones they like and there is no point in trying to get 
them to standardize on one.  So I would not hold my breath for the "one 
true Kubernetes way to do templating". 
- we think a good practice is to check config into revision control and 
then have a process that continuously kubectl-applies that checked in 
config to the cluster.   You want to expand the templates before commiting 
to revision control, so that revision controlled config is repeatable, and 
roll-back-able.   (This is where the declarative nature of Kubernetes 
really shines). Having kubectl fill in the template at "apply" or "create" 
time would not be useful, since it would make revision controlled config 
not repeatable.
- you might want to use a CI/CD system like Jenkins  or Spinnaker.  Those 
have some Kubernetes integrations already, so you'd solve the image 
template problem in the context of that CI/CD system.
-  I have not heard any plans to make it come from a configmap, and I think 
such a feature would be a tough sell and tough implementation.


On Tuesday, September 27, 2016 at 11:08:03 PM UTC-7, Mayank wrote:
>
> I want to templatize the image field of Kubernetes containers in the 
> manifest. What is the best way to do it. I see some people use jsonnet. 
>
> 1: Are there builtin features in kubectl to make this happen. 
> 2: Is there a plan to make image field come from configmap ?
>
> Any other ideas ?
> -Mayank
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.