I'm trying to deploy from Jenkins (which is running in GKE) using a
containerized kubectl.
Host networking results the same behavior.
On Thu, Aug 3, 2017, 20:18 Brandon Philips
wrote:
> I don't quite understand what you are trying to do, but I think you need
> host networking. Try adding: --net=
I don't quite understand what you are trying to do, but I think you need
host networking. Try adding: --net=host
Brandon
On Thu, Aug 3, 2017 at 2:19 AM Itamar O wrote:
> Hi,
>
> I have a Jenkins slave pod running on GKE.
> In that pod, I can run kubectl commands and they seem to automagically
>
There is no way to update an env var in a running container. It
simply is not possible in Linux to update an env var without being IN
that shell. This is one of the main arguments against env vars.
On Thu, Aug 3, 2017 at 7:40 AM, wrote:
> Hello,
>
> I need to update a variable in a running con
Hello,
I need to update a variable in a running container.
I can not kill the container. Is there any way to update this variable without
having to edit yaml?
Thanks
--
You received this message because you are subscribed to the Google Groups
"Kubernetes user discussion and Q&A" group.
T
On Wednesday, August 2, 2017 at 3:35:45 PM UTC+1, Rodrigo Campos wrote:
> On Wednesday, August 2, 2017, wrote:
> Hi Rodrigo. Thanks for answering.
>
>
>
> Yes, you're right. I should not talk about the containers but pods.. let me
> give another example to clarify. Suppose we have the followi
Hi,
I have a Jenkins slave pod running on GKE.
In that pod, I can run kubectl commands and they seem to automagically
operate on "self cluster" (the cluster in which the pod is running).
But if I run `docker run -it image-with-kubectl kubectl cluster-info` I get
the notorious
"The connection to th
On Thu, Aug 3, 2017 at 12:30 AM, wrote:
> Thanks a lot for the info!
>
> Is there any workaround ideas until 1.8? Like setting up a cronjob which
> periodically checks for pending guaranteed pods and if there are some kills
> other QoS pods.
>
QoS isn't about whether something goes pending vs. c
Thanks a lot for the info!
Is there any workaround ideas until 1.8? Like setting up a cronjob which
periodically checks for pending guaranteed pods and if there are some kills
other QoS pods.
On Wednesday, 2 August 2017 21:56:13 UTC+2, David Oppenheimer wrote:
> On Wed, Aug 2, 2017 at 11:44
