Need to set the ip and/or any metadata of the deployment to be available as env vars to each pod under the same deployment...
ex:
having a 3 replica deploment.
need to set env var for other IP address for each of the two other pods.
need to set the host name for each other two pods.
as of having
HOSTNAME=deplymentNAME-d74cf6f77-q57jx
deplymentNAME_PORT=tcp://10.152.183.27:13000
need to add:
HOSTNAME2=deplymentNAME-d74cf6f77-y67kl
HOSTNAME3=deplymentNAME-d74cf6f77-i90ro
deplymentNAME_PORT2=tcp://10.152.183.45:13000
deplymentNAME_PORT3=tcp://10.152.16.28:13000
those should be available on the three pods relatively.
as of now each pod have only its own data, we need to spread others data to the other replicas in the same deployment.
Well,
I figured out that my application is a stateful and not stateless application, that requires fixed/stable hostname/storage etc...
I have decided to use the statefulset controller
references:
https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#statefulset-v1-apps
Related
I'm using hardware-dependents pods; in my K8s, I instantiate my pods with a DaemonSet.
Now I want to access those pods with an URL like https://domain/{pod-hostname}/
My use case is a bit more tedious than this one. my pods' names are not predefined.
Moreover, I also need a REST entry point to list my pod's name or hostname.
I publish a Docker Image to solve my issue: urielch/dyn-ingress
My YAML configuration is in the Docker doc.
This Container add label on each pod, then use this label to create a service per pod, and then update an existing Ingress to reach each node with a path //
feel free to test it.
the source code is here
Summarize the problem:
Any way we can add an ENV to a pod or a new pod in kubernetes?
For example, I want to add HTTP_PROXY to many pods and the new pods it will generate in kubeflow 1.4. So these pods can be access to internet.
Describe what you’ve tried:
I searched and found istio maybe do that, but it's too complex for me.
The second, there are too many yamls in kubeflow, as to I cannot modify them one by one to use configmap or add ENV just in them.
So anyone has a good simle way to do this? Like doing this in kubernetes configuation.
Use "PodPreset" object to inject common environment variables and other params to all the matching pods.
Please follow below article
https://v1-19.docs.kubernetes.io/docs/tasks/inject-data-application/podpreset/
If PodPreset is indeed removed from v1.20, then you seem to need a webhook.
You will have to run an additional service in your cluster that will change the configuration of the pods.
Here is an example, on the basis of which I created my webhook, which changed the configuration of the pods in the cluster, in this example the developer used the logic adding a sidecar to the pod, but you can set your own to forward the required ENV:
https://github.com/morvencao/kube-mutating-webhook-tutorial/blob/master/medium-article.md
Problem:
I want every pod created in my cluster to hold\point the same data
e.g. let's say I want all of them to have an env vars like "OWNER=MYNAME".
there are multiple users in my cluster and I don't want them to start changing their YAMLs and manually assign OWNER:MYNAME to env.
Is there a way to have all current/future pods to be assigned automatically with a predefined value or mount a configmap so that the same information will be available in every single pod?
can this be done on the cluster level? namespace level?
I want it to be transparent to the user, meaning a user would apply whatever pod to the cluster, and the info could be available to him without even asking.
Thanks, everyone!
Pod Preset might help you here to partially achieve what you need. Pod Preset resource allows injecting additional runtime requirements into a Pod at creation time. You use label selectors to specify the Pods to which a given PodPreset applies.
Check this to know how pod preset works.
First you need to enable pod preset in your cluster.
You can use Pod Preset to inject env variables or volumes in your pod.
You can also inject configmap in your pod.
Make use of some common label for all the pods which you want to have common config, use this common label in your pod preset resource.
Unfortunately there are plans to remove pod presets altogether in coming releases, but I guess you can still use it with current releases. Although there are other implementations similar to pod presets, which you can try.
A new Kubernetes Deployment with 2+ replicas for high availability.
I want to be able to execute a command on the first pod only, let's say create a DB, and let the other replicas wait for the first one to complete.
To implement this, I just want to know in the pod if this is replica #1 or not.
So in the pod's entry point I can test:
if [ $REPLICA_ID -eq 1 ]; then
CreateDB
else
WaitForDB
fi
Can this be done in Kubernetes?
in Kubernetes a Deployment is considered stateless and therefore doesn't provide the feature you're looking for. You should rather look into StatefulSet and their features.
A StatefulSete.g. supports ordered creation and when combined with the generally available readinessProbe for you pods you could create the desired behaviour. Also the pod name is stable within a StatefulSet so your test could then be done with the hostname of the Pod.
Instead of the accepted answer, wouldn't an init container fit your problem description better?
Add some kind of semaphore system (if needed) to ensure it is executed correctly?
I need to add the name of a kubernetes pod as a label to that pod when I create a pod using a replication controller. Is there a way to do that or should I do a patch once the pod is created?
There is no way to auto-promote the pod name into a label. You'll have to do that manually. Sorry.
Depending on what you're trying to do, a headless service may work for you:
http://kubernetes.io/v1.1/docs/user-guide/services.html#headless-services
Specify spec.clusterIP=None
DNS is ten configured to return multiple A records (addresses) for the Service name, which point directly to the Pods backing the Service.
Otherwise, you may want to follow progress on the PetSet proposal:
https://github.com/kubernetes/kubernetes/pull/18016