[kubernetes-users] Best way to back-up and replicate GKE cluster in different region

['Timo Reimann' via Kubernetes user discussion and Q]

Heptio's Ark is a disaster recovery tool which covers this use case by 
leveraging Kubernetes APIs only. See the docs at https://github.com/heptio/ark 
for details.

-- 
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: Any way to list all ingress paths?

['Timo Reimann' via Kubernetes user discussion and Q]

I actually first tried to provide a solution that works with jsonpath alone. 
Unfortunately, the union operator never does what I'd ideally like it to do.

Whoever reads this and knows a kubectl-only approach, please raise your voice. 
:-)

-- 
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: Any way to list all ingress paths?

['Timo Reimann' via Kubernetes user discussion and Q]

I tend to struggle with jsonpath, so here's my jq-based suggestion:

$ kubectl get ing -o json | jq -r '.items[].spec.rules[].http.paths[]'

This yields a structure like

{
  "backend": {
"serviceName": "service-foo",
"servicePort": 80
  },
  "path": "/service-foo/path"
}
{
  "backend": {
"serviceName": "service-bar",
"servicePort": 443
  },
  "path": "/service-bar/path"
}

for me. You can tweak the jq expression for extra slicing and dicing.

HTH

Timo


On Thursday, April 12, 2018 at 5:26:36 PM UTC+2, David Rosenstrauch wrote:
>
> Is there any way to produce a comprehensive list of all the paths that 
> are defined in the ingress controller?  (And all the services they map 
> to.) 
>
> The closest thing I've found is: 
>
> kubectl describe ing 
>
> But that generates a lot of verbose output. 
>
> Thanks, 
>
> DR 
>

-- 
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] Kubernetes deployment

['Timo Reimann' via Kubernetes user discussion and Q]

Hello,

my initial suggestion would be to check that your Spring pods are gracefully 
shutting down (i.e., wait a reasonable amount of time before the endpoints have 
been removed from Service / Ingress rotation) and not becoming ready too soon 
(i.e., receiving traffic before they are able to process it).

Then again, I'd expect your website metrics to show an effect as well if one of 
the two wasn't implemented properly. I'm still throwing my advice in the ring 
though, just in case other factors are possibly playing a role as well (say, a 
cache sitting in front of your website that covers the gap somehow).

Timo

-- 
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] How to secure your Kubernetes Cluster in Google Cloud: Keep everything accessible from within a network

['Timo Reimann' via Kubernetes user discussion and Q]

Maybe Google's internal load balancing 
(https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing)
 can help you. They support white-listing IP ranges through the Service's 
"loadBalancerSourceRanges" parameter.

-- 
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 add ping package to container

['Timo Reimann' via Kubernetes user discussion and Q]

Glad I could help.

-- 
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] How to add ping package to container

['Timo Reimann' via Kubernetes user discussion and Q]

If this is about validating accessibility in general, you could just replace 
your production container by one coming with ping pre-installed (like ubuntu), 
fire off your ping, and be good.

If you're okay with the ICMP flowing next to your production container, add 
that helper container as a sidecar.

Finally, if you really need to ping from the IP address of your production 
container, you'll have to make sure it exists inside the container one way or 
another. Either build a new image to add the tool, or (given your container is 
based off of some Linux distribution) execute apt-get or similar package 
management command to install ping directly inside the container. The latter 
will taint your container though until it dies.

These days, it's often easier to fire off an HTTP request (such as through 
curl), so maybe that's another option for you.

-- 
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] Rolling restart of pods in deployment

['Timo Reimann' via Kubernetes user discussion and Q]

Actually, it's the Deployment's pod template (.spec.template) that needs to 
host the annotation. Always getting confused. 
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment
 has it formally defined.

-- 
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] Rolling restart of pods in deployment

['Timo Reimann' via Kubernetes user discussion and Q]

I believe you can also update / create an annotation inside the pod spec's 
metadata section if you fear that an environment variable might collide or just 
pollute your application's env var space.

More discussions, tips, and related issues regarding the subject of forced 
restarts can be found in https://github.com/kubernetes/kubernetes/issues/27081.

-- 
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: Kubernetes RBAC & Dashboard

['Timo Reimann' via Kubernetes user discussion and Q]

Hello,

regarding the *attempt to grant extra privileges* error: this is happening 
because you're trying to grant more privileges than your own user 
possesses. See the Privilege Escalation Prevention and Bootstrapping section 

 
in the RBAC docs for how to solve this problem. Afterwards, you should be 
able to assign RBAC rules to your dashboard as you seem fit.

As to the white dashboard page issue, you're probably affected by a problem 
in Kubernetes 1.7.6. See the relevant dashboard FAQ 

 
entry for details. (*tl;dr:* make sure you add a trailing slash at the end 
of the redirected URL.)

Feel free to ask more specific questions.

HTH
Timo


On Friday, October 27, 2017 at 2:45:38 PM UTC+2, stty...@gmail.com wrote:
>
> Hello. Im facing some problems with k8s and can't figure it out how to 
> proceed.
>
> First of all I want to point this thread 
> https://github.com/kubernetes/dashboard/issues/2526#issuecomment-339944273
> which brings me here for questions. After facing those problems with 
> dashboard I ended stuck on 
> https://cloud.google.com/container-engine/docs/role-based-access-control
>  I've updated the cluster with the --no-enable-legacy-authorization
> and from here I don't literally know how to proceed.
>  Can anyone help me ? The docs are a little bit overwhelming for me and I 
> donn't understand every concept.
>

-- 
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: k8s Backup Persistent storage

['Timo Reimann' via Kubernetes user discussion and Q]

I believe Heptio's Ark  can create 
persistent volume snapshots for you and store them on a selected number of 
cloud provider storages.

I'm not sure though whether restoring on a file level is feasible.


On Tuesday, October 3, 2017 at 12:14:19 PM UTC+2, tiziano...@gmail.com 
wrote:
>
> Hi folks,
>
> I am using persistent storage on my k8s bare metal cluster through NFS .
> I would like to ask if you can suggest me a backup solution  in order to 
> be able to backup and restore just single claims or files .
>
> Thx Tiziano 
>
>

-- 
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] How to test your code with Kubernetes

['Timo Reimann' via Kubernetes user discussion and Q]

FWIW, there's Mirantis' kubeadm-dind-cluster which lets you run a containerized 
version of a  Kubernetes cluster on a single machine: 
https://github.com/Mirantis/kubeadm-dind-cluster

-- 
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] Generally speaking, separate apps = separate clusters, right?

['Timo Reimann' via Kubernetes user discussion and Q]

Somewhat of a middle ground solution might be to create "sub-clusters" using 
taints and tolerations -- that is, have dedicated nodes for dedicated 
application classes or workloads inside a given cluster. It may reduce the 
general overhead inherent to managing separate clusters while still being able 
to leverage a lot of the built-in Kubernetes tooling.

-- 
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] Proposal for a new SIG: SIG-GCP

['Timo Reimann' via Kubernetes user discussion and Q]

Would the new SIG cover GKE matters too?

-- 
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 ensure no traffic won't be sent to pod which will be retired ?

['Timo Reimann' via Kubernetes user discussion and Q]

When you terminate a pod (either directly or indirectly through more 
abstract objects like a Deployment), the kubelet sends a TERM signal to 
your pod. You can extend your application to catch this signal, trigger the 
shutdown procedure (in your case apparently "send the logs to the other 
place"), and terminate eventually. As soon as the termination procedure is 
initiated, your pod's endpoints will be removed asynchronously, which 
should cause load-balancer-like intermediaries (like Sevices and Ingress 
controllers) to remove the pod from rotation (thereby draining requests). 
Make sure though you set the graceful termination period parameter high 
enough so that your pod isn't SIGKILLed by the kubelet prior to it being 
able to conclude the shutdown.

What Kubernetes does behind the scene is mark your pod as unready as soon 
as the termination phase begins. It's also possible to trigger this event 
manually by installing a readiness check into your pod and letting it fail 
when you want to stop receiving traffic. This would be a way to drain the 
pod "during runtime".

The documentation on the pod termination sequence 
 
provides additional information.

Hope this helps!


On Tuesday, August 8, 2017 at 11:00:06 AM UTC+2, Jeremy Woo wrote:
>
> I have a question about `services` , for example, I have a pod which 
> version is v1 and it receive the traffic from the `services`, now I have 
> create a new pod which version is v2 and I want to terminate the v1 pod, 
> but the logs in the v1 pod should be sent to other place and would take 
> some time, so  how can I ensure that no traffic send to v1 pod during send 
> logs ?
>

-- 
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] Pod name parameter while creating deployment in kubernetes

['Timo Reimann' via Kubernetes user discussion and Q]

If you specify the output format name, you can still use labels to 
reference the pod you want to see logs for:

kubectl logs -f $(kubectl get pod -l app=myapp -o name)


On Friday, August 4, 2017 at 8:42:24 PM UTC+2, Shri Javadekar wrote:
>
> One problem with using labels is that you can't follow logs (-f). I use 
> the following bash-function instead... HTH
>
> fl()
> {
> if [ -z "$1" ]
> then
> echo "Usage: fl pod-name-prefix [-f]"
> return 1
> fi
> pod=`kubectl get pods | grep $1 | cut -d " " -f 1`
> kubectl logs $pod "$@"
> }
>
> If your deployment name is my-dep, simply run "fl my-dep" or "fl my-dep 
> -f" ...
>
>
> On Fri, Aug 4, 2017 at 7:56 AM, Rodrigo Campos <rodr...@gmail.com 
> > wrote:
>
>> And, also, with labels and stuff, you can just do a kubectl with sed or 
>> awk and get the pod name in a subshell :-)
>>
>>
>> On Friday, August 4, 2017, 'Timo Reimann' via Kubernetes user discussion 
>> and Q <kubernet...@googlegroups.com > wrote:
>>
>>> Installing the shell completion for your shell of choice (given you're 
>>> using one of the supported ones, which I think are bash and zsh at the 
>>> moment) can make things easier too.
>>>
>>>
>>> On Thursday, August 3, 2017 at 8:55:24 AM UTC+2, Eswari wrote:
>>>>
>>>> Whenever I try to go to pod, need to give the complete pod name 
>>>> everytime. 
>>>>
>>>> So, I am searching for the command to save the time
>>>>
>>>> On Thursday, August 3, 2017 at 12:17:13 PM UTC+5:30, Tim Hockin wrote:
>>>>>
>>>>> A deployment creates a replicaset which creates your pod.  You might 
>>>>> have N pods running (replicas) and you might have N replicasets 
>>>>> (during an update, for example).  The name is insignificant.  What 
>>>>> problem are you really having? 
>>>>>
>>>>> On Wed, Aug 2, 2017 at 11:11 PM, Eswari <tolikesw...@gmail.com> 
>>>>> wrote: 
>>>>> > 
>>>>> > Hi, 
>>>>> > 
>>>>> > When I try to create deployment in kubectl commandline, it is giving 
>>>>> some 
>>>>> > extended name to pod. 
>>>>> > Ex:  kubectl run  testdeploy --image=imagename 
>>>>> > output: deployment::: testdeploy 
>>>>> >pod testdeploy-3202566627-46j24 
>>>>> > 
>>>>> > I don't like the pod name like this. 
>>>>> > 
>>>>> > Can I give pod name parameter also in command while creating 
>>>>> deployment 
>>>>> > 
>>>>> > -- 
>>>>> > 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.
>>>
>> -- 
>> 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.

Re: [kubernetes-users] Pod name parameter while creating deployment in kubernetes

['Timo Reimann' via Kubernetes user discussion and Q]

Installing the shell completion for your shell of choice (given you're 
using one of the supported ones, which I think are bash and zsh at the 
moment) can make things easier too.


On Thursday, August 3, 2017 at 8:55:24 AM UTC+2, Eswari wrote:
>
> Whenever I try to go to pod, need to give the complete pod name everytime. 
>
> So, I am searching for the command to save the time
>
> On Thursday, August 3, 2017 at 12:17:13 PM UTC+5:30, Tim Hockin wrote:
>>
>> A deployment creates a replicaset which creates your pod.  You might 
>> have N pods running (replicas) and you might have N replicasets 
>> (during an update, for example).  The name is insignificant.  What 
>> problem are you really having? 
>>
>> On Wed, Aug 2, 2017 at 11:11 PM, Eswari  wrote: 
>> > 
>> > Hi, 
>> > 
>> > When I try to create deployment in kubectl commandline, it is giving 
>> some 
>> > extended name to pod. 
>> > Ex:  kubectl run  testdeploy --image=imagename 
>> > output: deployment::: testdeploy 
>> >pod testdeploy-3202566627-46j24 
>> > 
>> > I don't like the pod name like this. 
>> > 
>> > Can I give pod name parameter also in command while creating deployment 
>> > 
>> > -- 
>> > 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.

Re: [kubernetes-users] Is it safe to change objects created by GKE?

['Timo Reimann' via Kubernetes user discussion and Q]

Thanks for the details.

I just verified that changing the Dashboard Service Account is possible 
without addon-manager clobbering my modifications.

My only concern left at this stage is the possible revert during a GKE 
upgrade. I suppose that changing the Dashboard version is rather common, so 
I'm worried that there will be a time window during upgrades when the 
Dashboard becomes wide-open again.
Do you think it'd be reasonable to address this issue? If so, is there 
already a ticket somewhere that I could track and/or help moving forward 
somehow?


On Wednesday, June 21, 2017 at 9:15:08 AM UTC+2, Robert Bailey wrote:
>
>
>
> On Tue, Jun 20, 2017 at 2:13 AM, 'Timo Reimann' via Kubernetes user 
> discussion and Q <kubernet...@googlegroups.com > wrote:
>
>> Robert, could you please clarify what the implications of swapping out 
>> the no-restrictions ServiceAccount associated with the Dashboard would be 
>> on the GKE side?
>>
>
> The cluster addons that are managed by the system can get replaced when 
> the master gets upgraded, replacing any changes that you have made (the 
> system treats them as being owned by the system). 
>
> The dashboard addon is set to be "reconciled" (see here 
> <https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dashboard/dashboard-controller.yaml#L9>),
>  
> which means that the addon manager will run kubectl apply on the addon 
> <https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/kube-addons.sh#L149>
>  
> every 60 seconds or so. So your changes may not persist long enough to be 
> clobber by the next upgrade. 
>  
>
>>
>> Specifically, if we replaced the existing ServiceAccount with one having 
>> less privileges, would the next GKE upgrade maintain this customization or 
>> revert it? Or, even worse, could it break the overall upgrade procedure?
>>
>
> It's possible that the apply command will respect your changes, in which 
> case I'd expect them to survive an upgrade unless we change the version of 
> the dashboard addon that is running (at which point I'd expect them to get 
> reverted). In either case, it won't break the upgrade procedure.  
>
>
> As Ingo said, having a wide-open Dashboard without any ability for 
>> restriction seems like a fairly big security concern. We couldn't even 
>> block ingress access to the kube-system namespace via Network Policies 
>> because those aren't supported in GKE yet (to my knowledge).
>>
>
> You are correct that GKE does not currently support Network Policies. 
>  
>
>>
>> Thanks.
>>
>>
>>
>> On Tuesday, June 20, 2017 at 12:21:14 AM UTC+2, Robert Bailey wrote:
>>>
>>>
>>>
>>> On Mon, Jun 19, 2017 at 12:52 AM, Ingo Gottwald <in.go...@gmail.com> 
>>> wrote:
>>>
>>>> We would like to change some things on the default GKE setup and the 
>>>> docs don't clarify whether it is safe to do so or if the next GKE update 
>>>> will fail after that or revert everything.
>>>>
>>>> We're thinking about changing two things specifically:
>>>>
>>>> 1) The fluentd config map in order to parse a little more and use 
>>>> structured logging in our own containers. (while still letting them use 
>>>> stdout/stderr)
>>>> 2) Change the dashboard and give it a read only scope with no access to 
>>>> secrets.
>>>>
>>>> The 2nd is by far the most important:
>>>> Currently with k8s 1.6 via GKE we can restrict our users nicely with 
>>>> RBAC, but this does not limit the ability for users to use "kubectl proxy".
>>>> With "kubectl proxy" everybody gets access to the kubernetes-dashboard 
>>>> which by GKE default has the kube-system default token mounted, that can 
>>>> basically do anything.
>>>> The dashboard itself has no authn/authz. Therefore anybody can escalate 
>>>> their own privileges to "root" in the cluster and leave any RBAC 
>>>> restrictions behind.
>>>> This is nothing that we would be willing to launch in production.
>>>>
>>>> Our solution to this would be to use a token with limited abilities 
>>>> mounted into the dashboard container, or if everything else fails, drop 
>>>> the 
>>>> UI for now.
>>>> But in those cases we would need to modify the deployment object 
>>>> created by GKE.
>>>>
>>>> Will changes like these make our cluster go up in flames on the next 
>>>> GKE Master upgrad

Re: [kubernetes-users] Is it safe to change objects created by GKE?

['Timo Reimann' via Kubernetes user discussion and Q]

Robert, could you please clarify what the implications of swapping out the 
no-restrictions ServiceAccount associated with the Dashboard would be on 
the GKE side?

Specifically, if we replaced the existing ServiceAccount with one having 
less privileges, would the next GKE upgrade maintain this customization or 
revert it? Or, even worse, could it break the overall upgrade procedure?

As Ingo said, having a wide-open Dashboard without any ability for 
restriction seems like a fairly big security concern. We couldn't even 
block ingress access to the kube-system namespace via Network Policies 
because those aren't supported in GKE yet (to my knowledge).

Thanks.



On Tuesday, June 20, 2017 at 12:21:14 AM UTC+2, Robert Bailey wrote:
>
>
>
> On Mon, Jun 19, 2017 at 12:52 AM, Ingo Gottwald  > wrote:
>
>> We would like to change some things on the default GKE setup and the docs 
>> don't clarify whether it is safe to do so or if the next GKE update will 
>> fail after that or revert everything.
>>
>> We're thinking about changing two things specifically:
>>
>> 1) The fluentd config map in order to parse a little more and use 
>> structured logging in our own containers. (while still letting them use 
>> stdout/stderr)
>> 2) Change the dashboard and give it a read only scope with no access to 
>> secrets.
>>
>> The 2nd is by far the most important:
>> Currently with k8s 1.6 via GKE we can restrict our users nicely with 
>> RBAC, but this does not limit the ability for users to use "kubectl proxy".
>> With "kubectl proxy" everybody gets access to the kubernetes-dashboard 
>> which by GKE default has the kube-system default token mounted, that can 
>> basically do anything.
>> The dashboard itself has no authn/authz. Therefore anybody can escalate 
>> their own privileges to "root" in the cluster and leave any RBAC 
>> restrictions behind.
>> This is nothing that we would be willing to launch in production.
>>
>> Our solution to this would be to use a token with limited abilities 
>> mounted into the dashboard container, or if everything else fails, drop the 
>> UI for now.
>> But in those cases we would need to modify the deployment object created 
>> by GKE.
>>
>> Will changes like these make our cluster go up in flames on the next GKE 
>> Master upgrade?
>>
>
> To ensure that your changes aren't overwritten, it'd be best to delete the 
> GKE-managed addons (e.g. disable logging on your cluster) and install them 
> yourself (e.g. create your own fluentd daemonset).
>
> I don't think it is currently possible to disable the dashboard. 
>  
>
>>
>>
>> -- 
>> 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.

Re: [kubernetes-users] kubernetes ingress annotation syntax

['Timo Reimann' via Kubernetes user discussion and Q]

Some annotations are already shared by multiple Ingress controller 
implementations. It'd be nice to come up with an effort and associated prefix 
that allows for some level of standardization.

-- 
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] Pod that creates other Pods using the kubernetes API

['Timo Reimann' via Kubernetes user discussion and Q]

On Friday, May 19, 2017 at 2:29:49 PM UTC+2, Rodrigo Campos wrote:
> On Friday, May 19, 2017,   wrote:
> Basically, this app can be a master Pod of sorts and that creates a 
> multi-container pod through API on the cluster.
> 
> 
> You can use the API, but doesn't seem like a good idea to do that at first 
> glance.

Speaking very generally, I don't think that using the Kubernetes API from a Pod 
is a bad idea per se. That's how most controllers operate, including 
third-party ones.

What the OP describes seems to be a kind of deployment service which, in my 
opinion, could be designed and implemented in terms of the controller (or 
possibly even operator) pattern.

-- 
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: Kubernetes auto-scaling

['Timo Reimann' via Kubernetes user discussion and Q]

I responded to the other thread you started on the dev mailing list:
https://groups.google.com/topic/kubernetes-dev/wiaSTzrI28A/discussion

Please try to avoid cross posting in the future. :-)

Am 26.01.2017 16:49 schrieb "Montassar Dridi" :

> you are right there is a delay between when the pod is ready and when the
> tomcat starts running for my application to come up, I'm experiencing with
>  readinessprobe right now, but when I update it, my first deployment
> doesn't happen and my first pod keep restarting the server or won't start
> when i try this
>
> livenessProbe:
>   # an http probe
>   httpGet:
> path: /healthz
> port: 8080
>   initialDelaySeconds: 15
>   timeoutSeconds: 1
>
> readinessProbe:
>   # an http probe
>   httpGet:
> path: /readiness
> port: 8080
>   initialDelaySeconds: 20
>   timeoutSeconds: 5
>
> Can you provide me with any other tutorial I can follow, please.
>
> On Thursday, January 26, 2017 at 5:31:02 AM UTC-5, Timo Reimann wrote:
>>
>> Wild guess: Does your application possibly *not* have liveness /
>> readiness probes configured? In that case, the container might technically
>> already be up and running from kubelet's perspective and receive traffic
>> while the Java application might not be ready yet. (JVM applications tend
>> to take a bit of time to become truly available.) The solution would then
>> be to install a readiness probe
>> .
>> (See also Ian's Lewis excellent blog post on the subject
>> .)
>>
>> Note that you might also want to have a graceful termination handler to
>> smoothly shut down, e.g., when the autoscaler decides to reduce the number
>> of containers. The termination process is described here
>> .
>>
>> HTH
>> Timo
>>
>>
>> On Thursday, January 26, 2017 at 1:02:45 AM UTC+1, Montassar Dridi wrote:
>>>
>>> Hello!!
>>> I'm using Kubernetes Deployment for my java application and set-up the
>>> Horizontal pod autoscaling too, but when I stress test my application, I
>>> see the increase of the number of the pods and nodes but at the same there
>>> is a downtime, the website doesn't load sometimes when I refresh the page,
>>> how can i avoid that, and the application keeps running smoothly with no
>>> downtime when the auto-scaling happens to meet the high demand of traffic?
>>>
>> --
> 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/xxXUNM2BOo4/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: Kubernetes auto-scaling

['Timo Reimann' via Kubernetes user discussion and Q]

Wild guess: Does your application possibly *not* have liveness / readiness 
probes configured? In that case, the container might technically already be 
up and running from kubelet's perspective and receive traffic while the 
Java application might not be ready yet. (JVM applications tend to take a 
bit of time to become truly available.) The solution would then be to 
install a readiness probe 
.
 
(See also Ian's Lewis excellent blog post on the subject 
.)

Note that you might also want to have a graceful termination handler to 
smoothly shut down, e.g., when the autoscaler decides to reduce the number 
of containers. The termination process is described here 
.

HTH
Timo


On Thursday, January 26, 2017 at 1:02:45 AM UTC+1, Montassar Dridi wrote:
>
> Hello!!
> I'm using Kubernetes Deployment for my java application and set-up the 
> Horizontal pod autoscaling too, but when I stress test my application, I 
> see the increase of the number of the pods and nodes but at the same there 
> is a downtime, the website doesn't load sometimes when I refresh the page, 
> how can i avoid that, and the application keeps running smoothly with no 
> downtime when the auto-scaling happens to meet the high demand of traffic?
>

-- 
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: Object definition validator

['Timo Reimann' via Kubernetes user discussion and Q]

I recently came across this twitter discussion 
 which seems to 
indicate there's no such validator but someone (Vic Iglesias) who might 
soon work on it .

Timo


On Monday, January 9, 2017 at 5:38:05 PM UTC+1, Tomas Kral wrote:
>
> Hello everyone,
> Is there some kind of validator for Kubernetes definitions?
>
> I'm generating Kubernetes objects like Deployments and ReplicaSets, and 
> I'm looking for validator that can be used in my tests to verify that 
> generated objects are valid (for example it is not missing image name in 
> PodSpec)
>
> Thank you
> Tomas
>

-- 
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] kops and pod eviction

['Timo Reimann' via Kubernetes user discussion and Q]

I'm not familiar with kops but I'd guess you could achieve something 
similar by employing memory resources 

 and 
resource quotas  to prevent 
containers from requesting/consuming more memory than a specified limit. 
>From my understanding, containers exceeding the resource limit would be 
evicted automatically (subject to the QoS classes they fall into).

(Disclaimer: I haven't used resource constraints to the extent described, 
so I'm mostly interpreting the available documentation in best-effort 
manner.)

HTH.


On Sunday, January 1, 2017 at 12:46:53 AM UTC+1, Yervand Aghababyan wrote:
>
> for example I want the kubelet to monitor the RAM pressure and stop 
> allocating new pods to the node if the memory usage is above 70%. If it's 
> above 80 I want some of the pods to be moved to other nodes. This seems to 
> be entirely possible to do with some kubelet command line arguments but I 
> don't know how I can customize them if nodeup is starting the 
> cluster(that's what happens if one uses kops, doesn't it?).
>
> On Sat, Dec 31, 2016 at 1:42 PM, 'David Oppenheimer' via Kubernetes user 
> discussion and Q  wrote:
>
>> Can you explain what you mean in more detail?
>>
>>
>> On Sat, Dec 31, 2016 at 12:25 AM,  
>> wrote:
>>
>>> Is there a way to specify eviction policies when bringing up a cluster 
>>> using kops?
>>>
>>> --
>>> 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 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/YJJ3Cicw8Y0/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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.

Re: [kubernetes-users] from Dashboard deployment to .yaml file

['Timo Reimann' via Kubernetes user discussion and Q]

Maybe the deployment did not come with a container port specification 
(http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_container)? (I 
never deployed anything through the UI.) It's not strictly necessary, pods will 
still be able to expose ports and receive traffic.

You can run "kubectl get pods" to list all running pods and "kubectl describe 
pod " for details. Maybe that contains the information you're looking for.

Speaking of: what are you trying to achieve exactly? Knowing that would be 
helpful.

-- 
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: Rolling Update of Deployments whose Replica Count is three but one of the Replica is leader

['Timo Reimann' via Kubernetes user discussion and Q]

Does a new replica actively have to join the cluster and decide whether
it's going to be a leader or follower? If that's the case, then you could
manage the set of (unknown, follower, leader) states in your
liveness/readiness probe and only return a positive result on successful
determination. (My understanding here is that deployments won't progress
until either probe check returns successfully.)

-- 
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: Rolling Update of Deployments whose Replica Count is three but one of the Replica is leader

['Timo Reimann' via Kubernetes user discussion and Q]

It depends on the concrete requirements of your application whether you 
should use PetSets (or StatefulSets which they have been renamed to very 
recently). The documentation describes what's a good fit 
 and 
alternative 
approaches .

If I understand you correctly, you'd like to use rolling upgrades to verify 
that a new replica brought up as a follower is also able to function well 
as a leader. I'm not quite sure if the deployment is the right phase to 
make this verification: I'd rather see this within the responsibility of 
your unit/integration/end-to-end tests so that the deployment can rest 
assure leader elections will work properly no matter whether a new member 
turns out to become a follower or leader.

FWIW, there's a Helm chart for etcd 
. Check 
out the template file 

 
to see how custom commands are used to orchestrate member removal and joins 
during shutdown and startup, respectively.

HTH,
Timo


On Thursday, October 27, 2016 at 7:56:47 AM UTC+2, Mayank wrote:
>
> Hi All
> Does this scenario belong to the Deployment where i have three stateless 
> replicas, but only one is active by acquiring a leader lock using etcd and 
> the rest are inactive.
>
> In this case while doing a  rolling update, if i bring down a passive one 
> and bring a new passive one up, it can clearly not acquire  a lock, since 
> the leader is active , so we cannot ensure that the passive is properly 
> working before killing the old passive one.  Does this scenario belong to 
> PetSets, if yes, what is the future plan to handle rolling upgrades in 
> those cases where one is the leader and other are slaves ?
>
> Would love to hear thoughts and future direction in this area
>
> 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.