https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# general
a
This message was deleted.
r
Depending on how you want to use your cluster, my first expectation is that you'd set up an ingress. You could also dedicate an IP with a load balancer. Also at least some ingress controllers will let you assign a custom port for an application so you could do that too.
You can also proxy through Rancher to get to it if you just want to see/test.
If I recall correctly the proxy link is on the service page, but it might be the pod page.
s
Thank you! Unfortunately, I have about 2 weeks of experience with using anything kubernetes, so much of this is still an unknown. I'll take the info, though! I'm sure it'll help to narrow the search down quite a bit! Thanks!
Copy code
proxy:
  secretToken: "1eb6ae42e8affdd69728c0c7c22d54a487a37f19243060ed03822846117e724a"
ingress:
  enabled: true
  hosts:
    - kube0.homenet
I take it this isn't quite the ingress you might be referring to?
r
An ingress is a rule to let you route hostnames, paths, and occasionally ports through your ingress controller (defaults to nginx ingress controller with RKE2) to services or pods in your cluster. Load balancers are services that take a pool of IPs and expose services (or maybe pods) on one or more IPs. Depending on how you want to configure your network so you can get to services, you might use those in different ways.
You should be able to browse to it in Rancher, or 
kubectl get -A ingress
will show you all the ones available. You should have one for Rancher in the local cluster serving Rancher. Past that you might or might have one for any other application you set up.
Your main learning curve is Kubernetes was made by someone who loves OOP so there are layers of objects for everything that happens and you'll have to get used to swimming through them.
🤣 1
s
Copy code
cattle-system   rancher      <none>   kube0           192.168.1.70,192.168.1.71,192.168.1.72,192.168.1.73   80, 443   9h
jhub            jupyterhub   <none>   kube0.homenet   192.168.1.70,192.168.1.71,192.168.1.72,192.168.1.73   80        148m
Yep, they're both using port 80, which I don't think is correct?
I'll remember that!
r
That's correct. It's that it considers "kube0" to be different from "kube0.homenet" most likely. I think that's the host?
You can also look at the ingresses & see if they have paths.
s
kube0 / kube0.homenet is the single host VM, yes. I'll look into ingress after work as well. Sir, thank you kindly for the information!
b
You should be able to use a CNAME that points to your ingress.
The ingress will figure out where to route the traffic based off the FQDN
So when you install jupyterHub with the helm chart, you let it know that it's 
jhub.homenet
so it gets to the right service/pods.
s
Thank you! I believe that's a bit beyond my current understanding, but I hope to use the information to expand my knowledge soon!
r
Yep, CNAME in DNS will work, or if only need access from a single host could edit local hosts file. Setup I had at my previous job I used a reverse proxy and had wildcard DNS pointed there, had the proxy go to all my worker nodes which ran replicas of the ingress controller, and then set each ingress by hostname which I just made up on the fly within the wildcard domain I had for my proxy. If one were using load balancer & IPs they might assign those separately. There are a lot of ways you can do things, just depends on what your use case & handy infrastructure happens to be.
👍 1
A lot of examples use paths off the hostname instead for smaller setups where people don't want to mess with DNS.
b
We deploy a lot a jupyterHub stuff at my $dayJob so if you're using the helm chart, the cname might be the path of least resistance imho, but Bill is right in pointing out that there's lots of ways you can do this.
s
so working with /etc/hosts would help to create said CNAME for the deployment?
b
Yeah, that's one way to do it.
r
If you want to use the hostname to differentiate what service to go to, all clients need to map the hostname to the IP. If you have one client, the hosts file is fine. If you have 100, trying to sync up those hosts files will be murder and getting it in DNS will be easier even if you're dealing with an irritating IT dept.
s
trying to get soemthing set up for the lab at work, as an experiment and kind of proof of concept. I understand /etc/hosts, just not quite sure about the rest, lol.
b
Depending on your lab/home network making DNS entries can be easy or tricky (or impossible in some work locations)
r
In DNS an A record maps a hostname to an IP. A PTR record maps an IP to a hostname. A CNAME record maps a hostname to another hostname that it'll look up and use instead.
s
at home, pfsense is already whitelisting MACs to IPs and DNS names. I don't have control over the DNS at work, though.
r
If you aren't using DNS and are in a standalone lab, your hosts files will do all those things.
I didn't have control over my DNS at my previous job, but I could get IT to put in an entry for me. What I did is say I have a proxy at A.B.C.D & the company was company.com (this also could point to a single machine with ingress controller if small scale & no proxy). I requested the IT dept put in a wildcard DNS for *.kub.company.com to resolve to A.B.C.D . Then I made an ingress for each service for service1.kub.company.com , service2.kub.company.com , ... serviceN.kub.company.com and just used that, creating new ones or removing old ones whenever I needed (obviously I used more sensible names rather than serviceN and had different subdomain & company domain & IP, just giving examples). The ingress controller just pattern matches based on rules you set for hostnames & directory paths in the URL. As long as your network outside Kubernetes directs in a way that it reaches the ingress controller then it'll direct on from there.
👍 1
s
Thank you!
r
That's all an overly big hassle for a lot of situations. That's where a lot really relies on what you have & what's convenient.
s
just curious, but is there a way to place what port is used in the config.yaml during install of jupyterhub, possibly something odd, like 32354? Or at least a page like 
kube0.homenet/jhub/
? Or is that not allowed?
r
There's likely a way to do anything you want, it's a question of how convenient vs contrived it is. With an ingress it's convenient to put a service at /jhub off of a hostname and you can probably just edit the existing one to do so if you wish.
Remember if something translates kube0.homenet into just kube0 before it gets to the ingress controller, then kube0.homenet won't match any more and will get a 404. The logs on the ingress controller will show you what it gets too.
m
Depending on where you're running Rancher, the service type is going to come into play. If you're on a cloud provider, you get an IP associated with the default Jupyter traefik LB service on "proxy" and you need to point dns to that IP. If you're running locally and haven't setup something like metallb, you want ClusterIP for service type in your helm and use ingress and set dns to one of your Kubernetes nodes running ingress or to an outside proxy. If using ingress, you'll probably also want cert-manager so you can use letsencrypt.
But the hub, api, etc get exposed through the "proxy" service.
Also, good call using Rancher for this. Doing Jupyter on Openshift comes with some extra pain.
4 Views
Open in Slack
PreviousNext
Powered by