Why are my Kubernetes pods sharing environment variables?

up vote
0
down vote

favorite

I've got 3, completely distinct, pods:

kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"n"}}{{end}}'

kubernetes-bootcamp-5c69669756-5rh9t

queenly-seahorse-mysql-6dc964999c-h4w54

wordpress-mysql-bcc89f687-hs677

but they seem to share the same env vars. E.g.

kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep MYSQL

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

and then on a completely different, unrelated pod (but on the same node):

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep MYSQL

MYSQL_ROOT_PASSWORD=<redact>

MYSQL_PASSWORD=<redact>

MYSQL_USER=

MYSQL_DATABASE=

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

MYSQL_MAJOR=5.7

MYSQL_VERSION=5.7.14-1debian8

Any explanation why?

FWIW, I'm clearly exec'ing into 2 different pods. E.g.

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep HOSTNAME

HOSTNAME=queenly-seahorse-mysql-6dc964999c-h4w54



kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep HOSTNAME

HOSTNAME=kubernetes-bootcamp-5c69669756-5rh9t

edited Nov 11 at 17:51

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

add a comment |

up vote
0
down vote

favorite

I've got 3, completely distinct, pods:

kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"n"}}{{end}}'

kubernetes-bootcamp-5c69669756-5rh9t

queenly-seahorse-mysql-6dc964999c-h4w54

wordpress-mysql-bcc89f687-hs677

but they seem to share the same env vars. E.g.

kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep MYSQL

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

and then on a completely different, unrelated pod (but on the same node):

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep MYSQL

MYSQL_ROOT_PASSWORD=<redact>

MYSQL_PASSWORD=<redact>

MYSQL_USER=

MYSQL_DATABASE=

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

MYSQL_MAJOR=5.7

MYSQL_VERSION=5.7.14-1debian8

Any explanation why?

FWIW, I'm clearly exec'ing into 2 different pods. E.g.

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep HOSTNAME

HOSTNAME=queenly-seahorse-mysql-6dc964999c-h4w54



kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep HOSTNAME

HOSTNAME=kubernetes-bootcamp-5c69669756-5rh9t

edited Nov 11 at 17:51

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

add a comment |

up vote
0
down vote

favorite

I've got 3, completely distinct, pods:

kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"n"}}{{end}}'

kubernetes-bootcamp-5c69669756-5rh9t

queenly-seahorse-mysql-6dc964999c-h4w54

wordpress-mysql-bcc89f687-hs677

but they seem to share the same env vars. E.g.

kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep MYSQL

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

and then on a completely different, unrelated pod (but on the same node):

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep MYSQL

MYSQL_ROOT_PASSWORD=<redact>

MYSQL_PASSWORD=<redact>

MYSQL_USER=

MYSQL_DATABASE=

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

MYSQL_MAJOR=5.7

MYSQL_VERSION=5.7.14-1debian8

Any explanation why?

FWIW, I'm clearly exec'ing into 2 different pods. E.g.

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep HOSTNAME

HOSTNAME=queenly-seahorse-mysql-6dc964999c-h4w54



kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep HOSTNAME

HOSTNAME=kubernetes-bootcamp-5c69669756-5rh9t

edited Nov 11 at 17:51

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

I've got 3, completely distinct, pods:

kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"n"}}{{end}}'

kubernetes-bootcamp-5c69669756-5rh9t

queenly-seahorse-mysql-6dc964999c-h4w54

wordpress-mysql-bcc89f687-hs677

but they seem to share the same env vars. E.g.

kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep MYSQL

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

and then on a completely different, unrelated pod (but on the same node):

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep MYSQL

MYSQL_ROOT_PASSWORD=<redact>

MYSQL_PASSWORD=<redact>

MYSQL_USER=

MYSQL_DATABASE=

QUEENLY_SEAHORSE_MYSQL_PORT=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP=tcp://10.98.170.14:3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PORT=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_ADDR=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT=3306

QUEENLY_SEAHORSE_MYSQL_SERVICE_HOST=10.98.170.14

QUEENLY_SEAHORSE_MYSQL_SERVICE_PORT_MYSQL=3306

QUEENLY_SEAHORSE_MYSQL_PORT_3306_TCP_PROTO=tcp

MYSQL_MAJOR=5.7

MYSQL_VERSION=5.7.14-1debian8

Any explanation why?

FWIW, I'm clearly exec'ing into 2 different pods. E.g.

kubectl exec "queenly-seahorse-mysql-6dc964999c-h4w54" env | grep HOSTNAME

HOSTNAME=queenly-seahorse-mysql-6dc964999c-h4w54



kubectl exec "kubernetes-bootcamp-5c69669756-5rh9t" env | grep HOSTNAME

HOSTNAME=kubernetes-bootcamp-5c69669756-5rh9t

kubernetes kubectl kubernetes-pod

edited Nov 11 at 17:51

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

edited Nov 11 at 17:51

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

edited Nov 11 at 17:51

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

asked Nov 11 at 16:34

Snowcrash

36.8k39131210

add a comment |

2 Answers
2

active

oldest

votes

up vote
1
down vote

accepted

All the Kubernetes Services environment variables are shared across a namespace. This is by design so that pods can find a specific service if they need to.

There have been discussions about how to disable them, but I believe no fixes have been added upstream yet.

answered Nov 11 at 20:23

Rico

25.1k94864

Thanks - very helpful.
– Snowcrash
Nov 12 at 10:16

add a comment |

up vote
0
down vote

I deleted my comment and am adding this as an answer. I realized that the "QUEENLY_SEAHORSE_MYSQL_xxxx" env vars have been added by Kubernetes for a service named "queenly-seahorse-mysql" - see https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables

answered Nov 11 at 17:47

apisim

4176

Yeah - what I don't understand is why they're in both pods though
– Snowcrash
Nov 11 at 17:51

@Snowcrash - it is for service discovery within a namespace. The link in my answer is a subsection of "Discovering services" along with another subsection on using DNS for service discovery. HTH
– apisim
Nov 11 at 22:17

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53250822%2fwhy-are-my-kubernetes-pods-sharing-environment-variables%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

up vote
1
down vote

accepted

All the Kubernetes Services environment variables are shared across a namespace. This is by design so that pods can find a specific service if they need to.

There have been discussions about how to disable them, but I believe no fixes have been added upstream yet.

answered Nov 11 at 20:23

Rico

25.1k94864

Thanks - very helpful.
– Snowcrash
Nov 12 at 10:16

add a comment |

up vote
1
down vote

accepted

All the Kubernetes Services environment variables are shared across a namespace. This is by design so that pods can find a specific service if they need to.

There have been discussions about how to disable them, but I believe no fixes have been added upstream yet.

answered Nov 11 at 20:23

Rico

25.1k94864

Thanks - very helpful.
– Snowcrash
Nov 12 at 10:16

add a comment |

up vote
1
down vote

accepted

All the Kubernetes Services environment variables are shared across a namespace. This is by design so that pods can find a specific service if they need to.

There have been discussions about how to disable them, but I believe no fixes have been added upstream yet.

answered Nov 11 at 20:23

Rico

25.1k94864

All the Kubernetes Services environment variables are shared across a namespace. This is by design so that pods can find a specific service if they need to.

There have been discussions about how to disable them, but I believe no fixes have been added upstream yet.

answered Nov 11 at 20:23

Rico

25.1k94864

answered Nov 11 at 20:23

Rico

25.1k94864

answered Nov 11 at 20:23

Rico

25.1k94864

answered Nov 11 at 20:23

Rico

25.1k94864

Thanks - very helpful.
– Snowcrash
Nov 12 at 10:16

add a comment |

Thanks - very helpful.
– Snowcrash
Nov 12 at 10:16

Thanks - very helpful.
– Snowcrash
Nov 12 at 10:16

add a comment |

up vote
0
down vote

answered Nov 11 at 17:47

apisim

4176

Yeah - what I don't understand is why they're in both pods though
– Snowcrash
Nov 11 at 17:51

@Snowcrash - it is for service discovery within a namespace. The link in my answer is a subsection of "Discovering services" along with another subsection on using DNS for service discovery. HTH
– apisim
Nov 11 at 22:17

add a comment |

up vote
0
down vote

answered Nov 11 at 17:47

apisim

4176

Yeah - what I don't understand is why they're in both pods though
– Snowcrash
Nov 11 at 17:51

@Snowcrash - it is for service discovery within a namespace. The link in my answer is a subsection of "Discovering services" along with another subsection on using DNS for service discovery. HTH
– apisim
Nov 11 at 22:17

add a comment |

up vote
0
down vote

answered Nov 11 at 17:47

apisim

4176

answered Nov 11 at 17:47

apisim

4176

answered Nov 11 at 17:47

apisim

4176

answered Nov 11 at 17:47

apisim

4176

answered Nov 11 at 17:47

apisim

4176

Yeah - what I don't understand is why they're in both pods though
– Snowcrash
Nov 11 at 17:51

@Snowcrash - it is for service discovery within a namespace. The link in my answer is a subsection of "Discovering services" along with another subsection on using DNS for service discovery. HTH
– apisim
Nov 11 at 22:17

add a comment |

Yeah - what I don't understand is why they're in both pods though
– Snowcrash
Nov 11 at 17:51

@Snowcrash - it is for service discovery within a namespace. The link in my answer is a subsection of "Discovering services" along with another subsection on using DNS for service discovery. HTH
– apisim
Nov 11 at 22:17

Yeah - what I don't understand is why they're in both pods though
– Snowcrash
Nov 11 at 17:51

@Snowcrash - it is for service discovery within a namespace. The link in my answer is a subsection of "Discovering services" along with another subsection on using DNS for service discovery. HTH
– apisim
Nov 11 at 22:17

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Nrthugu