Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configuration instead of hard code values #7

Open
mattma opened this issue Aug 12, 2015 · 3 comments
Open

configuration instead of hard code values #7

mattma opened this issue Aug 12, 2015 · 3 comments
Labels

Comments

@mattma
Copy link
Owner

mattma commented Aug 12, 2015

Case 1:

localhost usage, it used throughout the api-server, control-manager, schuduler:

 --etcd_servers=http://127.0.0.1:2379,http://127.0.0.1:4001 \

Should we use an Environment variable instead of? like $private_ivp4

Case 2:

insecure port used to indicate the open port on master node, so user could do http://172.17.8.100:8080 to check api-serverhealth, schdule something. Several other service is using it to talk to api-server. We should make the port configurable without hard code value.

Case 3

cluster ip range is used by flannel network overlay which is later being saved in etcd after flannel.service started. Should be an variable here.

Case 4

api-server public address. Can this one be something like --api_servers=http://${ETH1_IPV4}:8080 \?

Case 5

cluster-domain and cluster-dns is shared by yaml and service files, how could we introduce an variable to work in different type of file format.

In general, we should use as many as Environment variable instead of static value, use as many as Environment variable instead of user configurable value, if we absolutely need to use user configurable value, we should do it cleanly and intuitively.

In conclusion, we should make it much easy to go in production without less configurable value, I think the absolutely thing would be master ip address which used to talk to api-server, master machine id which used in node etcd cluster setting?

@yichengq
Copy link
Collaborator

case 1: i think localhost is good. They always run in the machine that has etcd endpoint available.
case 4: we hardcoded 172.17.8.100 a lot. maybe we could write the master ip into some file in the node machine, and let service read that out.

master ip address which used to talk to api-server

if we could do that, that is great.

@mattma
Copy link
Owner Author

mattma commented Aug 13, 2015

127.0.0.1 is the same as localhost, and most likely works in all the situation. If I am right, we should just keep it in 127.0.0.1. Need the confirmation. Thanks

@mattma
Copy link
Owner Author

mattma commented Aug 26, 2015

Case 4:

This setting works for starting the api server. Will submit a PR today.

[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes,http://kubernetes.io/v1.0/docs/admin/kube-apiserver.html
Requires=etcd2.service setup-network-environment.service
After=etcd2.service setup-network-environment.service

[Service]
EnvironmentFile=/etc/network-environment
ExecStartPre=-/usr/bin/docker kill kube-apiserver
ExecStartPre=-/usr/bin/docker rm kube-apiserver
ExecStartPre=/usr/bin/docker pull mattma/kube-apiserver:1.0.1
ExecStart=/usr/bin/docker run \
  --net=host \
  --name kube-apiserver \
  mattma/kube-apiserver:1.0.1 \
  --allow_privileged=true \
  --insecure_bind_address=0.0.0.0 \
  --insecure_port=8080 \
  --kubelet_https=true \
  --secure_port=6443 \
  --service-cluster-ip-range=10.100.0.0/16 \
  --etcd_servers=http://127.0.0.1:2379,http://127.0.0.1:4001 \
  --cors_allowed_origins=.* \
  --logtostderr=true
  --runtime_config=api/v1

Restart=always
RestartSec=10

[X-Fleet]
Global=true
MachineMetadata=role=master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants