Re: [kubernetes-users] destoryed pod containers trigger

2018-01-31 Thread Colstuwjx


> kubectl logs ... --previous ? 
>

I have tried that, but it shows `Error from server (BadRequest): previous 
terminated container "main" in pod "demo-1050-5fb5698d4f-8qtsw" not found` 

BTW, I found `maximum-dead-containers-per-container` and 
`maximum-dead-containers` to configure the policy, and these two has been 
deprecated, the new coming parameters are: `--eviction-hard`, 
`--eviction-soft`, just configure them as the eviction policy.

reference 
document: 
https://kubernetes.io/docs/concepts/cluster-administration/kubelet-garbage-collection/

Thanks.

-- 
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] destoryed pod containers trigger

2018-01-31 Thread 'Tim Hockin' via Kubernetes user discussion and Q
kubectl logs ... --previous ?

On Wed, Jan 31, 2018 at 6:38 AM, Colstuwjx  wrote:
>>
>>
>>>
>>> But, what if we want to trigger the detail exited reason for the exited
>>> containers? Is there any parameters configure that?
>>
>>
>> Have you checked the terminationGracePeriod? I think it will do just that.
>
>
> I'm afraid not, I need to check the exited container, such as some container
> with wrong configurations, and determine the root cause.
> After  the `terminationGracePeriod `, the unhealthy container would be
> deleted, and we can't do things like `docker inspect `
> to trigger that case.
>
> --
> 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-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] destoryed pod containers trigger

2018-01-31 Thread Rodrigo Campos
On Wed, Jan 31, 2018 at 06:38:36AM -0800, Colstuwjx wrote:
> >
> >> But, what if we want to trigger the detail exited reason for the exited 
> >> containers? Is there any parameters configure that?
> >
> > Have you checked the terminationGracePeriod? I think it will do just that.
> 
> I'm afraid not, I need to check the exited container, such as some 
> container with wrong configurations, and determine the root cause.
> After  the `terminationGracePeriod `, the unhealthy container would be 
> deleted, and we can't do things like `docker inspect 
> ` to trigger that case.

Ohh, sorry, my bad. I didn't understood that.

And sorry again, not sure how to do that. I've never looked into that myself :-/

-- 
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] destoryed pod containers trigger

2018-01-31 Thread Colstuwjx

>
>
>  
>
>> But, what if we want to trigger the detail exited reason for the exited 
>> containers? Is there any parameters configure that?
>>
>
> Have you checked the terminationGracePeriod? I think it will do just that.
>

I'm afraid not, I need to check the exited container, such as some 
container with wrong configurations, and determine the root cause.
After  the `terminationGracePeriod `, the unhealthy container would be 
deleted, and we can't do things like `docker inspect 
` to trigger that case.

-- 
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] destoryed pod containers trigger

2018-01-31 Thread Rodrigo Campos
On Wednesday, January 31, 2018, Colstuwjx  wrote:

> Hi team,
>
> As I known, kubernetes will kill the POD while the readiness probe failed
> over than `FailureThreshold` limit, and the unhealthy containers will be
> deleted by kubelet.
>

I think only the liveness probe will do that.



> But, what if we want to trigger the detail exited reason for the exited
> containers? Is there any parameters configure that?
>

Have you checked the terminationGracePeriod? I think it will do just that.

-- 
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.