router fails to come up with `FailedScheduling` about router HOT 18 CLOSED

Which k8s environment are you using? Wondering if this is clashing with API server.

from router.

I'm using a vagrant cluster created with micro-kube. Here's version info:

ENG000656:slugbuilder aaronschlesinger$ kubectl version
Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.3+6a81b50", GitCommit:"6a81b50c7e97bbe0ade075de55ab4fa34f049dc2", GitTreeState:"not a git tree"}
Server Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.1", GitCommit:"92635e23dfafb2ddc828c8ac6c03c7a7205a84d8", GitTreeState:"clean"}

from router.

Alright, @krancour will have to weigh in on this.

from router.

This is a port conflict. micro-kube includes the nginx-alpha ingress controller and that's using host port 80, which the router also wants. You need to uninstall the nginx-alpha ingress controller.

from router.

You need to uninstall the nginx-alpha ingress controller

I'm not very familiar with ingress controllers (beyond just reading the docs), but I don't see any ingress controllers installed (see log below). Can you advise?

ENG000656:builder aaronschlesinger$ kubectl get ing && kubectl --namespace=deis get ing
NAME      RULE      BACKEND   ADDRESS
NAME      RULE      BACKEND   ADDRESS

from router.

It would be in the kube-system namespace

from router.

The controller is also an rc resource; not ing.

from router.

@krancour ok, I deleted the RC:

ENG000656:deis aaronschlesinger$ k get --namespace=kube-system rc
CONTROLLER                CONTAINER(S)              IMAGE(S)                                         SELECTOR                          REPLICAS   AGE
kube-dns                  etcd                      gcr.io/google_containers/etcd:2.0.9              k8s-app=kube-dns,version=v8       1          21d
                          kube2sky                  gcr.io/google_containers/kube2sky:1.11                                             
                          skydns                    gcr.io/google_containers/skydns:2015-03-11-001                                     
kube-ingress-controller   kube-ingress-controller   krancour/k8s-nginx-ingress:0.0                   k8s-app=kube-ingress-controller   1         21d
kube-ui                   kube-ui                   gcr.io/google_containers/kube-ui:v3              k8s-app=kube-ui,version=v3        1         21d

...then started a new deis cluster using the Deis chart:

ENG000656:deis aaronschlesinger$ kd logs -f deis-router-9h2g6
2015/12/16 18:52:05 INFO: Starting nginx...
2015/12/16 18:52:05 INFO: nginx started.
2015/12/16 18:52:05 INFO: Router configuration has changed in k8s.
2015/12/16 18:52:05 INFO: Reloading nginx...
2015/12/16 18:52:05 INFO: nginx reloaded.
2015/12/16 18:52:05 [notice] 11#0: signal process started

... and then tried ./deis register <router IP>, but it fails:

core@micro-kube ~/example-go $ ./deis register 10.3.0.94
Error: http://10.3.0.94 does not appear to be a valid Deis controller.
Make sure that the Controller URI is correct and the server is running.

Should it correctly route to the controller given it was installed from the chart?

from router.

I wouldn't expect using the naked IP like that to work. The router routes traffic based on HTTP host headers. That request goes to the default vhost, which exposes a /healthz endpoint-- all other paths on that vhost return 404s.

from router.

@krancour I might have this wrong then. Instructions at https://github.com/deis/workflow#hacking-workflow say to deis register <cluster IP>. I was assuming that <cluster IP> was the IP to router, since when you deis create --no-remote it prints out a git remote with the same <cluster IP>. Is it the end goal to have router route to both the controller (port 80) and builder (port 2222)?

cc/ @helgi

from router.

Since you're on micro-kube, I know the VM's IP is 172.17.8.100...

$ kubectl edit rc deis-router --namespace=deis

Find metadata.annotations.deis.io/routerConfig and within, change example.com to whatever domain you like.

Edit your Mac's /etc/hosts file to include:

172.17.8.100 deis.<whatever-domain-you-picked>

Then:

$ deis register http://deis.<whatever-domain-you-picked>

from router.

And yes... I guess workflow instructions are not making any assumption that router is in play. Router listens on the host's ports 80, 443, 2222, and 9090 and proxies to different services (workflow, builder, or applications) based on HTTP host headers.

from router.

@krancour makes perfect sense now. I was still thinking about executing everything from the minion, but I was kinda missing the whole point of the router... Thanks!

I think we need docs to explain how to use our components with the following configurations:

1. All Deis components installed, probably using helm up. The instructions for setup would be the same as you just laid out here
2. Only select components installed. We can't cover all possible combinations, but I think we should at least explain how to work without a router and just a builder and a workflow.

Thoughts? If these are good, I volunteer to document.

from router.

The instructions for setup would be the same as you just laid out here

The instructions differ a bit depending on where your cluster runs.

Anywhere where the k8s "cloud provider" has support for creating "external" load balancers (e.g. an ELB in AWS): helm install deis gets you almost all the way there. Then you just need to edit router RC in the chart to pick a platform domain and add an A record to DNS that points to your load balancer.

Anywhere where the k8s "cloud provider" no-ops the support for creating "external" load balancers (e.g. Vagrant or bare metal): helm install deis, edit router RC in the chart to pick a platform domain, then manually creates a load balancer (if possible) or use DNS / /etc/hosts tricks to route your traffic to a particular host(s).

from router.

Reading the comments here, are we beyond the original ticket and off into the RC config documentation gap?

from router.

yes, I think so

from router.

So can we close this and open a Workflow issue on getting this documented in the installation guide?

from router.

@technosophos yes, I'll create shortly

from router.