Feature requests and a couple suggestions.

[sarkistlt]

Great project really like it, thanks for sharing it! After using it for a wile with my current setup, I found some minor limitations, and possible improvements that could really be helpful. Would like to contribute but Go is not my stack.

1.

Security concerns, ideally function should have full isolation from the cluster or pod where it's running, for example when working with large team it's really important. Currently it is possible to:

• limit access to k8s API by adding: automountServiceAccountToken: false to deployment object.
• limiting network access with NetworkPolicies

The only part left that I can't figure out how to solve, is that function has access to all env. vars. so if you will list everything from process.env there bunch of stuff that ideally function developer should not see, and should only access variables that they passed. Any possible solution to this problem?

2.

When deploying using remote URL, it works only with .zip, doesn't work with .tar.gz, this makes a huge difference, larger the function bigger gap in performance between .zip and .tar.gz. Is there any plans to implement .tar.gz support?

3.

Scheduled task currently running deployment + cronjob that sends http request to trigger the function. This is not optimal solution. Let's say I'm running job 1 a day or week, deployment will consume cluster resources 24hr a day, when it can just be combined into one CronJob object, and start with the schedule then scale back to 0. Any plans to update current behavior?

4.

Current way of running function is by using the same runtime container, that will pull function from remote url (or configMap), then will install dependancies (if provided), then will start container. That's fine for small functions, but as an example. One script in nodeJs with 1 additional package request-promise in node_modules folder, it takes almost 5m, to start up container. Main issue here is scaling, on every new replications it has to download, unzip, install deps. then run container. Would be great to have an option like with OpenFaas when you can build your container with runtime before deployment, then you will deploy separate container for each function, in that case scaling and starting deployment will takes seconds no matter of function size, when right now times incrementally goes up with number of dependencies. Is it something you may consider implementing?

5.

Looks like currently health-check and readiness prob done on runtime container, and it doesn't wait for function to be ready. I'm consistently getting Bad Getaway error for 5-10 second on each deployment because LB sending traffic to deployment that passes readiness check, but it's actually not ready. This can be fixed by creating hook, that will try to trigger function, as soon as it gets response it can fallback to old logic and just keep sending readiness prob from runtime container, but this will insure that deployment will be added to load balancer only when function is ready.

In my use case the biggest drawbacks, is item 2, 4 and 5, would like to know if it's something that could be fixed or improved? Thanks!

[andresmgot]

Thanks for all the feeback! It will be really useful for others.

1.

Security concerns, ideally function should have full isolation from the cluster or pod where it's running, for example when working with large team it's really important. Currently it is possible to:

• limit access to k8s API by adding: automountServiceAccountToken: false to deployment object.
• limiting network access with NetworkPolicies

The only part left that I can't figure out how to solve, is that function has access to all env. vars. so if you will list everything from process.env there bunch of stuff that ideally function developer should not see, and should only access variables that they passed. Any possible solution to this problem?

Unfortunately no. If that needs to be implemented, it needs to be done in a runtime basis. For the example of NodeJS, that env needs to be process before calling the function: https://github.com/kubeless/runtimes/blob/master/stable/nodejs/kubeless.js#L96

2.

When deploying using remote URL, it works only with .zip, doesn't work with .tar.gz, this makes a huge difference, larger the function bigger gap in performance between .zip and .tar.gz. Is there any plans to implement .tar.gz support?

For the moment we don't have support for tar.gz but we are open to contributions there.

3.

Scheduled task currently running deployment + cronjob that sends http request to trigger the function. This is not optimal solution. Let's say I'm running job 1 a day or week, deployment will consume cluster resources 24hr a day, when it can just be combined into one CronJob object, and start with the schedule then scale back to 0. Any plans to update current behavior?

Unfortunately no. Scaling to 0 is not something supported in this project. My recommendation here is to set the function memory and cpu requests and limits to a low value so even if the pod is running all day, the resource consumption is minimal.

4.

Current way of running function is by using the same runtime container, that will pull function from remote url (or configMap), then will install dependancies (if provided), then will start container. That's fine for small functions, but as an example. One script in nodeJs with 1 additional package request-promise in node_modules folder, it takes almost 5m, to start up container. Main issue here is scaling, on every new replications it has to download, unzip, install deps. then run container. Would be great to have an option like with OpenFaas when you can build your container with runtime before deployment, then you will deploy separate container for each function, in that case scaling and starting deployment will takes seconds no matter of function size, when right now times incrementally goes up with number of dependencies. Is it something you may consider implementing?

Yes, that's supported. It's called function builder: https://kubeless.io/docs/building-functions/

5.

Looks like currently health-check and readiness prob done on runtime container, and it doesn't wait for function to be ready. I'm consistently getting Bad Getaway error for 5-10 second on each deployment because LB sending traffic to deployment that passes readiness check, but it's actually not ready. This can be fixed by creating hook, that will try to trigger function, as soon as it gets response it can fallback to old logic and just keep sending readiness prob from runtime container, but this will insure that deployment will be added to load balancer only when function is ready.

The problem with that is that it may trigger functions that are not supposed to be executed yet. In theory, once the server start replying to readiness checks, the function is already loaded and should be ready to reply normal requests. 5-10 seconds sounds a lot to me, are you sure you are not sending traffic before the pod is Ready?

[sarkistlt]

Thanks for quick reply!

1. it can be done by spawning new process or running function in the worker pool. This else will prevent function developer from accessing main process. But yes any of those solutions require runtime container updates.

2. if runtime container can support some additional flag, or env. var. something like EXEC_ON_START, and will trigger function on a runtime, then u don't need deployment + cronjob, and can have only cronjob.

3. great, will try it today!

4. it's not up to me, k8s won't send traffic to container if it's not passing readiness check, you can't force it. Agree executing function not an ideal, but it can be some global var. like let funcIsReady; and as soon as function is registered it will set it to true, and healthcheck endpoint will check that variable, if it's not true send code 500, and as soon as it is true send 200, it will insure that readiness prob is passed when function is registered. Delay depends on container resources, it takes 5-10s when I will set minimum cpu: 0.01 and mem: 32Mi

[sarkistlt]

Also is it possible to provide some build or initial script instructions? Similar to fission? that could be very useful, for example to run build after dependencies were installed.

[sarkistlt]

In kubeless-controller logs I do see error Unable to build function: Unable to locate registry credentials to build function image: secrets \"kubeless-registry-credentials\" not found", but kubeless-registry-credentials secret does exist, I tried both as documented, creating secret in default namespace, and in kubeless namespace, still keep getting this error.

Ok looks like secrete must be in the same namespace as function deployment, not kubeless.

Also for everyone who uses google cloud registry, the correct way to create secrete is:

cat ./secret.json | kubectl create secret docker-registry kubeless-registry-credentials -n[namespace of deplyed function] \
  --docker-server=https://us.gcr.io/v2/ \
  --docker-username=_json_key \
  --docker-password=-stdin

Where secret.json is a service account with admin access to google storage. And us.gcr.io should be whatever registry you are using.

With current secret it does start build job, but it is crashing, and there 2 problems:

1. image name, generated as us.gcr.io/[username]/[function_name]:[sha256], the problem here is that username is populated as _json_key, and with google cloud it should actually parse password, and use project_id as a user name.
2. this kind of weird bug, in build container logs, I see the following error:

   Error determining manifest MIME type for docker://us.gcr.io/[proejct_id]/kubeless/nodejs@sha256:1c45cda56384adc7deae9bf99e221b8e159ec25980c05b947939096bf91800e6: unexpected http code: 400, URL: https://us.gcr.io/v2/token?scope=repository%3A[project_id]%2Fkubeless%2Fnodejs%3Apull&service=us.gcr.io

   But if I will try to manually access url: https://us.gcr.io/v2/token?scope=repository%3A[project_id]%2Fkubeless%2Fnodejs%3Apull&service=us.gcr.io it does generate and return token, not 400.