Tim, I could make a configurable REST API for database, that accepts Ipaddress, and Port, via REST with Json message. This could work at run time dynamically, so that I can configure the backend database with its necessary settings, and since I can setup a Singleton class, this could be common within all POD replicas of the same service?
What happens internally, if I update a singleton class within the same JVM, that is running within a cluster of Pods with the same functionality? Lets say I have node1, and node2, for 2 Pods, and I sent a REST request to update myDatabaseIP, and myDatabasePort. If the service router handles which Pod to route to, do the singletons contents in memory get updated in both Pods, node1, and node2? or just within a single Pod, node1 or node2? Since, I have only one REST interface to update database settings, wouldn't that mean that the singletons update for both node1, and node2? Please clarify how Kubernetes Pods would handle this scenario? -Henry -Henry On Thursday, December 7, 2017 at 11:27:23 AM UTC-5, Tim Hockin wrote: > > You want a template expander before you get to kubectl. Otherwise, the > thing that is running isn't reflected by any versionable artifact. > > Because templating is a high-opinion space, we do not (currently) have one > that is built-in. > > On Dec 7, 2017 10:12 AM, "Henry Hottelet" <hott...@gmail.com <javascript:>> > wrote: > >> >> Is there not a way to pass arguments from command line to the Pod >> specification? There should be, because this is not the first time that a >> Docker argument is needed when calling a Pod instance, whether dynamic or >> staticly defined. >> >> I could have Pod1.yaml, Pod2.yaml, and have an Ipaddress, and Port number >> for reach separate Pod that is defined. >> >> >> >> On Thursday, December 7, 2017 at 11:03:28 AM UTC-5, Tim Hockin wrote: >>> >>> Kubectl is not a templating system, which is what you are asking for. >>> Create/Apply are declarative plumbing, suitable to things you would check >>> in to source control. There are porcelain commands, eg. kubectl run, which >>> are closer to docker run, but less suitable to source control. >>> >>> On Dec 7, 2017 9:56 AM, "Henry Hottelet" <hott...@gmail.com> wrote: >>> >>>> >>>> A problem: >>>> >>>> Docker arguments will pass from command line: >>>> >>>> docker run -it -p 8080:8080 joethecoder2/spring-boot-web >>>> -Dcassandra_ip=127.0.0.1 -Dcassandra_port=9042 >>>> >>>> However, when I do: >>>> >>>> kubectl create -f ./singlePod.yaml >>>> >>>> Kubernetes POD arguments will not pass from singlePod.yaml file: >>>> >>>> apiVersion: v1 >>>> kind: Pod >>>> metadata: >>>> name: spring-boot-web-demo >>>> labels: >>>> purpose: demonstrate-spring-boot-web >>>> spec: >>>> containers: >>>> - name: spring-boot-web >>>> image: docker.io/joethecoder2/spring-boot-web >>>> env: ["name": "-Dcassandra_ip", "value": "127.0.0.1"] >>>> command: ["java","-jar", "spring-boot-web-0.0.1-SNAPSHOT.jar", >>>> "-D","cassandra_ip=127.0.0.1", "-D","cassandra_port=9042"] >>>> args: ["-Dcassandra_ip=127.0.0.1", "-Dcassandra_port=9042"] >>>> restartPolicy: OnFailure >>>> >>>> Question: How do I correctly specify arguments that will change at >>>> runtime? I want to add two arguments that change at Kubernetes POD >>>> runtime, because these should be configurable for each POD that is >>>> defined. >>>> Arguments for the POD are: -Dcassandra_ip=127.0.0.1", >>>> "-Dcassandra_port=9042 >>>> >>>> I want the arguments to be accepted just like the Docker command line. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Kubernetes user discussion and Q&A" 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&A" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-use...@googlegroups.com <javascript:>. >> To post to this group, send email to kubernet...@googlegroups.com >> <javascript:>. >> 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&A" 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.
