how to pass kubernetes pods arguments like Docker arguments from command line

[Henry Hottelet]

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.

[Tim Hockin]

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.

--
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+unsubscribe@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.

[Henry Hottelet]

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. 

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.

[Tim Hockin]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Henry Hottelet]

Tim,

Do you have an example reference on how to do this with Kubernetes Pods?  

I tried really really hard, and so far, this is what I came up with for arguments in the pod.yaml file, and the service layer results:

https://groups.google.com/forum/#!topic/kubernetes-users/B9BBECu17z0

To separate the concerns, I know this is not an issue with Docker, or Linux, I do know that this is a problem with the way the Kubernetes Pod specification has been defined, and I can't find an interface specification anywhere from Google.

A detailed explanation would be of some help, because I know I am not the first person on the plant, to want arguments to be passed.  How else would a java program get arguments, but from the command line?  If there is some other way to send arguments to a docker container I must know.

[Henry Hottelet]

Tim,

Is there any other way to have my Spring-Boot controller accept arguments from the java or Docker command line?  I need this feature, because I need to make the decision, of which ip address, and port number, are needed for my database backend at run time. (i.e. when I decide how many Rest controller Pods to bringup in the East region, vs. West Region).  I need to be able to support zoning for my database backend, and also to be able to do dynamic failover for redundancy reasons.

Please let me know what you might suggest as a workaround or template example.

-Henry

[Henry Hottelet]

Tim,

Check out the REST Spring Boot project:

https://github.com/quantum-fusion/springboot_swagger_example-master-cassandra

The goal of this project, is to offer a configurable software architecture, for a distributed Application, that runs across a global grid of distributed databases. Since everyone uses JPA, and Cassandra, I have selected Cassandra.

The catch, is that I need to know, the ip address, and port number for the Cassandra backend, that way, the Application controller can run in a Kubernetes cluster, and the Database backend can run anywhere else, I can get bare metal.

Please let me know how to proceed with this important system limitation.

-Henry

[Henry Hottelet]

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

[Henry Hottelet]

How to pass arguments to Kubernetes POD were succesfull, however Google states, that templates are needed for configurability.

https://stackoverflow.com/questions/47700482/kubernetes-pod-arguments-are-not-displayed-in-service-under-args-without-error/47703631#47703631

[Rodrigo Campos]

Google??? And, also, what is the point of that phrasing?

Someone was trying to help, maybe there was some miscommunication and the suggested solution was not what better fits you now. That's all, right?

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Henry Hottelet]

Rodrigo,

I have decided to go down another path, and consider Dynamic changes to IPaddress and Port numbers via REST interface calls remotely into a Docker image.

Although configuring Pods at definition time, with arguments might be cool, I have gone down another path, and am considering configuring connection settings being dynamic at runtime via a configure interface.

Preliminary tests, are showing me that Docker has a conflict with Datastax driver on port 9042, with local IPaddress of 127.0.0.1 due to port binding issues on a local machine.

I am investigating further to help determine if these restrictions can be lifted for DataStax driver support inside a docker container, which is limiting me using Pods at all.

I hope Datastax can help lift this restriction, however, I see it as a current limitation on Docker and Datastax driver, and have opened an issue with Datastax. (https://groups.google.com/a/lists.datastax.com/forum/#!topic/java-driver-user/QohK0Sd86-4)

If you were curious on how to recreate the problem with Docker and DataStax driver:

docker run --name cassandra -m 2g -p 127.0.0.1:9042:9042 -p 127.0.0.1:9160:9160 -d cassandr

docker run --name spring-boot-web -p 8080:8080 -p 127.0.0.1:9042:9042 -p 9160:9160 docker.io/joethecoder2/spring-boot-web TCP4-LISTEN:9042 TCP4:172.17.0.2:9042

I have hit a deadend, at this point for using Docker and Datastax driver, and I was hoping that they would work together, however the fall back path is to use SpringBoot without Docker or Kubernetes Pods.

Is anyone else currently using Data query calls from within Docker with a database driver to an outside ip address and port?

-Henry

[Rodrigo Campos]

Okay, so that's not at all related with what I've said...

I'm quite sure that port is fine regarding docker Kubernetes, don't know about your driver. Wild guess: might be just not using SO_REUSE or something like that in your local machine what you think it's the issue.

Good luck with that

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Henry Hottelet]

Rodrigo,

I am going to do a remote test with Docker, however it has to be mapped to a public IP address.  At that point, the REST service, is mapped to a remote IP and port, which means that at that point, it doesn't matter if Cassandra runs in docker or not.

However the question, still remains about whether springboot and datastax driver can run inside a docker container and target a remote ip and port.

I would have to do some stand alone tests to find out.

Do you know if anyone else is running Pods that target a remote database service?

-Henry

[Henry Hottelet]

Rodrigo,

It is Datastax driver, not my driver for clarification.

-Henry

[Rodrigo Campos]

Don't know about springboot, etc. But yes, pods connect to databases, and basically do any other network connection, without any issues. Just like any other process can.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Matt Brown]

Henry, to go back to the root of your question, I don't think you are having a problem with Docker or Kubernetes or the Datastax driver.

Your problem fundamentally is how to tell your application what IP and port to connect to for the Cassandra host(s). You get a NoHostAvailableException because you are hardcoding an address of 127.0.0.1:9042 (in your singlePod.yaml example) but you do not have a Cassandra server at that address (localhost) inside the application's pod.

I suggest taking a step back and looking at the problem as "how should my application discover what Cassandra hosts to connect to at startup time?". You can certainly hardcode this in the pod yaml if you think that the Cassandra contact points will never change. Other options you have for this are service discovery systems, DNS/SRV queries, etc. If your Cassandra instances are running in Kubernetes then you might get some mileage out of creating a Service and doing SRV queries in the application pod.

At the end of the day though, this is a decision to make at the application layer, and not something Kubernetes/Docker/Datastax can decide for you.

On Sunday, December 10, 2017 at 12:29:29 PM UTC-5, Henry Hottelet wrote:

[Tim Hockin]

Whoah, wow. Many of us were out last week, sorry for delay. Can we
back up a second?

First, I may have misinterpreted what you were asking, if so I apologize.

Looking at your StackOverflow, you say:

```
I want the arguments called to match Docker:

docker run -it -p 8080:8080 joethecoder2/spring-boot-web

cassandra_ip=127.0.0.1 cassandra_port=9042
```

This runs the image "joethecoder2/spring-boot-web" with 2 args,
"cassandra_ip=127.0.0.1" and "cassandra_port=9042".

Your YAML uses the same image:

```
image: docker.io/joethecoder2/spring-boot-web
```

You set the command field, but I don't think you need to. It's baked
into your image (or so it would seem, since `docker run` works).

You only need to pass the arguments:

```
args: ["$(cassandra_ip)", "$(cassandra_port)"]
```

So why are these variables? Where are those variables being assigned?
A reply tells you to set them in the env sections, which is correct
(though they use teh wrong syntax for accessing - $(var) is good, $var
is not.

Later you say "the java arguments now execute within the Pod, however,
they execute only once" - I have no idea what that means. Arguments
do not execute.