-
Notifications
You must be signed in to change notification settings - Fork 44
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
Added support for ingress over routes on cluster creation #251
Added support for ingress over routes on cluster creation #251
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Bobbins228 The PR seems to replace Route with Ingress completely. I think we still want to support Route for Openshift unless Openshift supports Ingress. I have not tried this.
@tedhtchang OpenShift supports ingress so we don't really need to use routes anymore because of this. Tested this out myself and the ingress works on OpenShift |
48459da
to
1d77bed
Compare
LGTM! |
Also needs a rebase while addressing Ted's comments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The local interactive did not work for me.
Couple of reasons I can see:
- I think the ray client route/ingress needs to be something like
rayclient-hfgputest-1-default.apps.ted413med.cp.fyre.ibm.com
(rayclient without dash) because it needs to match the Subject Alternative Name in the server.crt in the ray pods. For example:
# kubectl exec -it hfgputest-1-head-9hlgk -- bash
openssl x509 -text -noout -in /home/ray/workspace/tls/server.crt
...
X509v3 Subject Alternative Name:
DNS:127.0.0.1, DNS:localhost, DNS:hfgputest-1-head-svc.default.svc.cluster.local, DNS:10.254.16.36, DNS:rayclient-hfgputest-1-default.apps.ted413med.cp.fyre.ibm.com
- The ray client route termination needs be passthrough. For example:
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
ray-dashboard-hfgputest-1 ray-dashboard-hfgputest-1-default.apps.ted413med.cp.fyre.ibm.com hfgputest-1-head-svc dashboard None
rayclient-hfgputest-1 rayclient-hfgputest-1-default.apps.ted413med.cp.fyre.ibm.com hfgputest-1-head-svc client passthrough None
This ingress should give you some clue how to enable passthrough for grpc. It could take a different form to translate this ingress to route.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Bobbins228 I verified this worked on my OCP and Openshift local but like you said this api
api_client = client.CustomObjectsApi(api_config_handler())
ingress = api_client.get_cluster_custom_object(
"config.openshift.io", "v1", "ingresses", "cluster"
)
except Exception as e: # pragma: no cover
return _kube_api_error_handling(e)
domain = ingress["spec"]["domain"]
is not supported on KinD(k8s). We will need to find a way to return a domain name.
Can this |
Perhaps instead of using a |
I might have mistaken the Openshift crd
Then we can use
For KinD or K8s (KinD) we don't have the ingresses.config crd. We may need a different code path for: If KinD, get the cluster domain from hostname of workstation where the KinD is installed. For local development, this should work. |
Not related to return cluster domain but FYI tutorial for set up local domain on KinD for development https://mjpitz.com/blog/2020/10/21/local-ingress-domains-kind/ |
I have not find a way for the KinD cluster to return the ingress domain.
|
KubeRay operator already provides support for creating and managing the Ingress (and route in the main branch). Why do we create this externally to the operator? Would it be easier to just add this to the KubeRay yaml? |
@blublinsky This PR also converts the ray client route into ingress. The sdk optionally creates a ray client route for the advanced users to interact with the the ray cluster from their own laptop directly. The ray client is gRPC(port 10001) and requires TLS and passthrough to be enabled on a route. However, the dashboard route support for OCP was created a while ago. It's possible to convert to the KubeRay native feature you implemented recently If the resulting dashboard route object meet the requirement. We should create another thread to discuss with @Maxusmusti and @Bobbins228 to understand the requirements. |
Be sure to also include @KPostOffice in any future threads. He also left some comments on the last slack thread that may be worth a read |
a8f4dc2
to
1f08a6d
Compare
Here when enabling OAuth sidecar the 1 index of generic items is deleted |
603ff5b
to
369387c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/LGTM thanks @Bobbins228
b3fa425
to
b7c24eb
Compare
c5606d1
to
0a452cf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/LGTM I think this is just a rebased.
Update: Thanks you actually removed more unused code. I will test out again.
Update2: It works for me on KinD. Maybe someone can try on OpenShift.
/LGTM cancel
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was not able to verify the local interactive client on OCP but @KPostOffice was to able successfully verify the PR. /LGTM
Update: I verified on the OCP cluster from my Linux VM.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: KPostOffice, tedhtchang The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Issue link
Closes #219
What changes have been made
Added an ingressOptions dict for specifying what options you want to set for your dashboard ingress.
An example of the specified ingressOptions would look like this (based off the routes for dashboard)
Without specifying any ingress options the default dashboard and client ingresses will be created provided you have set the ingressDomain (note this is only a Kubernetes requirement)
Important steps for Kind Clusters
Add the
- --enable-ssl-passthrough
argument to the nginx ingress controllerAdd the
ingress_domain
field in your cluster configuration to your local domain if you are not usingingress_options
Verification steps
Specify your ingress Options in ClusterConfiguration
Run
cluster.up()
after authenticating in a Jupytr NotebookRun
kubectl get ingress
You should get ingresses you specified
upon running
cluster.details()
you should be able to follow the link to the ray dash board provided you created an ingress for it or omitted ingressOptions.running
cluster.down()
will delete the ingress.Checks