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

Install knative #177

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

mckornfield
Copy link
Collaborator

No description provided.

@dadiorchen
Copy link
Contributor

dadiorchen commented Jul 12, 2023

@mckornfield I'm trying to under stand this and doing some test, I got some question.

  1. Do we need a ingest/gateway for knative?

When I check the route resource in dev env by kubectl get -n knative-serving rt hello -o yaml I got a condition like this:

  4014   - lastTransitionTime: "2023-07-05T00:09:36Z"
  4015     message: Ingress has not yet been reconciled.
  4016     reason: IngressNotConfigured
  4017     status: Unknown
  4018     type: IngressReady

Seems we need to set the ingress to make it work, the URL is http://hello.knative-serving.svc.cluster.local for the hello fun, but I don't think we can access it because of some problem?

Some other error log:

ok@iZ6we19crc:treetracker-functionskubectl get -n knative-serving revision
NAME          CONFIG NAME   K8S SERVICE NAME   GENERATION   READY     REASON      ACTUAL REPLICAS   DESIRED REPLICAS
fun-1-00001   fun-1                            1            Unknown
hello-00001   hello                            1            Unknown   Deploying
@iZ6we19crc:treetracker-functions> kubectl get -n knative-serving ksvc
NAME    URL                                              LATESTCREATED   LATESTREADY   READY     REASON
fun-1   http://fun-1.knative-serving.svc.cluster.local   fun-1-00001                   Unknown   RevisionMissing
hello   http://hello.knative-serving.svc.cluster.local   hello-00001                   Unknown   RevisionMissing
@iZ6we19crc:treetracker-functions>
  1. If ingress is nessassary, which one should we use, can we use ambassador for this? This doc is talking about custom the ingress for all traffic in knative? https://knative.dev/docs/serving/setting-up-custom-ingress-gateway/

  2. Comparting knative to openfaas, seems we still need to run the command by knative to deploy functions? But you mentioned that with CRD, we don't need to so?

BTW, knative seems promising, I tried to manually create another fun and deploy it to the dev, everything goes well except the last step to route the traffic, just like your hello fun.

@dadiorchen
Copy link
Contributor

@mckornfield did you try to visit the function by the URL? http://hello.knative-serving.svc.cluster.local

@mckornfield
Copy link
Collaborator Author

  1. I think we should just use the Ambassador mapping files, that way we can add auth etc if need be in the same way... and just talk to the service instead of using the ingress knative makes
  2. I suppose we could follow https://stackoverflow.com/questions/60848031/knative-ambassador-ingress#60854616 if we don't want to use the mapping files
  3. https://github.com/Greenstand/treetracker-infrastructure/pull/177/files#diff-7521fdd64378992a6a44ee7ee6d4cb2f517d72c454ba6742797ef9c23f11ff62R17 Yep this is what I used to install the function. The only thing that has to be done with the cli is generate the function template and upload a docker image

for your last question, I just port forwarded to test, assuming we'd use a mapping file

@dadiorchen
Copy link
Contributor

@mckornfield thank you for the quick response, I think we are close to being able to use faas, once we solve the mapping/ingess problem, right?
For the No.1 of using mapping, I am not sure it is possible, first, let's confirm the idea, you mean, we directly set up the ambassador mapping to point to the function service, right?
I'm not sure if it is okay because currently, knative complains some problem (shown above), the concept as described here: https://knative.dev/docs/concepts/ seems broken. As you said, the system of knative is more complicated, there is a concept called revision I tried to do a deployment by this command: func deploy --registry docker.io -v every time I do this, a new function pod shows up with a new number like: fun-1-0001 fun-1-0002, and the route is trying to route the traffic to different revision. But now, the route is complaining problem. Also, because of the problem, I can not successfully finish the deployment and ended with errors like: the service is not read, timeout.

@mckornfield
Copy link
Collaborator Author

It is definitely more complicated, my port-forwarding might have been over-simplified... I can look at what it takes to hook ambassador up to it

@mckornfield
Copy link
Collaborator Author

wonder if this will work, though 3-4 years old https://github.com/bbrowning/knative-ambassador-ingress

@mckornfield
Copy link
Collaborator Author

@dadiorchen Just trying to install this project above and follow some tutorials lead me to some failed installs... Wonder if there's a semi-recent way to connect ambassador to knative lol

@dadiorchen
Copy link
Contributor

@mckornfield is it possible to use the default ingress ( I guess it is the istio) to make things right as the first step so we can play with to understand the thing, and if it is possible that we use a two level gateway to put the knative+istio behind the ambassador, anyway, it is helpful to just run it successfully

@mckornfield
Copy link
Collaborator Author

🤔 I think that would require setting up an istio ingress too, but I'm not sure we want two of them/ if that's just as much work to set up

@mckornfield
Copy link
Collaborator Author

I'm determined to get it working, just the ambassador docs are really anemic lol https://www.getambassador.io/docs/emissary/latest/howtos/knative

@mckornfield
Copy link
Collaborator Author

part of our problem might be that we're on an old version of ambassdor... it's now called emissary-ingress 😆

NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
ambassador      ambassador      7               2021-05-17 23:20:05.2577394 -0700 PDT   deployed        ambassador-6.7.8        1.13.5     
ambassador-auth ambassador      2               2021-03-19 02:27:43.426919 -0400 -0400  deployed        gh-auth-0.1.0           1.16.0     

@dadiorchen
Copy link
Contributor

@mckornfield I'm okay with upgrading the ambassador, what do you think?

@mckornfield
Copy link
Collaborator Author

Probably something worth doing independent of this, but I worry for backwards incompatible changes hehe

@dadiorchen
Copy link
Contributor

@mckornfield do you mean a sperate env for this? It that's you are saying, I think so too, should we open a new cluster for test goal on this? The dev env is getting more and more heavy and hard to change.

@mckornfield
Copy link
Collaborator Author

Separate env would be part of it, but at some point we'd need to upgrade the older clusters. I just wonder if bumping ambassador to emissary would be a good thing to do first before trying to add knative

@dadiorchen
Copy link
Contributor

I will be happy if we can upgrade the ambassador to a newer version, even pay some cost of learning and fixing work!

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

Successfully merging this pull request may close these issues.

None yet

2 participants