vmware-archive / http-trigger Goto Github PK

Is this a BUG REPORT or FEATURE REQUEST?:
BUG

What happened:
I followed the SOP to create the HTTP trigger; however, the Ingress cannot be created successfully.
The log is as follows:

$ kubectl logs -n kubeless -l kubeless=controller -c http-trigger-controller 
time="2021-01-05T08:43:37Z" level=info msg="Processing update to HTTPTrigger: default/get-python" controller=http-trigger-controller
time="2021-01-05T08:43:37Z" level=info msg="Processing update to HTTPTrigger: default/get-python" controller=http-trigger-controller
time="2021-01-05T08:43:37Z" level=info msg="Adding ingress resource for http trigger Obj: default/get-python " controller=http-trigger-controller
time="2021-01-05T08:43:37Z" level=error msg="Failed to create ingress rule get-python corresponding to http trigger Obj: default/get-python due to: Unable to find the function internal service: &Service{ObjectMeta:k8s_io_apimachinery_pkg_apis_meta_v1.ObjectMeta{Name:get-python,GenerateName:,Namespace:default,SelfLink:/api/v1/namespaces/default/services/get-python,UID:2e51b57a-e1d2-40bc-90b4-d6000c46f1a3,ResourceVersion:1555,Generation:0,CreationTimestamp:2021-01-05 08:43:13 +0000 UTC,DeletionTimestamp:<nil>,DeletionGracePeriodSeconds:nil,Labels:map[string]string{created-by: kubeless,function: get-python,},Annotations:map[string]string{},OwnerReferences:[{kubeless.io/v1beta1 Function get-python f8622c76-5838-4f99-b6cb-d98abbd3e1e8 <nil> <nil>}],Finalizers:[],ClusterName:,Initializers:nil,},Spec:ServiceSpec{Ports:[],Selector:map[string]string{},ClusterIP:,Type:,ExternalIPs:[],SessionAffinity:,LoadBalancerIP:,LoadBalancerSourceRanges:[],ExternalName:,ExternalTrafficPolicy:,HealthCheckNodePort:0,PublishNotReadyAddresses:false,SessionAffinityConfig:nil,},Status:ServiceStatus{LoadBalancer:LoadBalancerStatus{Ingress:[],},},}: " controller=http-trigger-controller

What you expected to happen:
I believe if everything is fine, I can see the result in kubectl get ing

How to reproduce it (as minimally and precisely as possible):
Follow the SOP

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:43:34Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

• Kubeless version (use kubeless version): v1.0.7
• Cloud provider or physical cluster: minikube v1.16.0 and minikube start --kubernetes-version='v1.18.3' --vm=true

Is this a BUG REPORT or FEATURE REQUEST?:
Feature request

What you expect to happen:
Kubeless will support https://www.getambassador.io/ as a gateway.
Following expected to work:

kubeless trigger http create ... --gateway ambassador

Anything else we need to know?:
When using Ambassador we do not create actual Ingress resource. Ambassador uses getambassador.io/config annotation defined as part of the Service manifest. More details here: https://www.getambassador.io/reference/advanced

This is different from all currently supported gateways which create separate Ingress resource to direct HTTP traffic to the function.

In my understanding when new HTTP trigger is created for Ambassador we need to edit existing Service definition by injecting proper getambassador.io/config annotation. When trigger is deleted we need to remove this annotation from Service.

Questions:

• Does this sound correct in terms of HTTP trigger support?
• What's the best place to start implementation?
  So far I'm looking at https://github.com/kubeless/http-trigger/blob/master/pkg/utils/k8sutil.go as a starting point.

Is this a BUG REPORT or FEATURE REQUEST?:

Feature Request

What happened:

From kubeless-cli docs its seems you can secure http-triggers using k8s's secrets. My control plane only provides an annotation for requesting signed certs and key from the CA.

What you expected to happen:

Allow configuring http-trigger resources with cert and key mounted on the resource's pod, possibly by accepting an environmental variables with the filepath to cert and key.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:
Environment:
Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.1", GitCommit:"f31005ab029ab58f05349b193fa2c22bdbe27ad3", GitTreeState:"clean", BuildDate:"2018-07-24T19:50:58Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.1-palantir1", GitCommit:"f31005ab029ab58f05349b193fa2c22bdbe27ad3", GitTreeState:"clean", BuildDate:"2018-07-24T19:46:29Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Kubeless version (use kubeless version):
Kubeless version: v1.0.0-alpha.7
Cloud provider or physical cluster:
AWS

Is this a BUG REPORT or FEATURE REQUEST?:

Feature Request

What happened:

I am deploying kubeless-function-controller to a non-rbac k8s cluster using webhooks for auth/z. My authz policies reject any non-whitelisted serviceaccounts, and I cannot whitelist the controller-acct serviceaccount nor can I use an existing, whitelisted serviceaccount.

https://github.com/kubeless/kubeless's function controller allows mounting a k8s secret containing a bearer token for authz against k8s. See related issue: vmware-archive/kubeless#877

What you expected to happen:

Supply a secret or additional mounted file containing the bearer token and use the bearer token for k8s actions instead of using a serviceaccount.

How to reproduce it (as minimally and precisely as possible):
Use a webhook for k8s authz which rejects the kubeless service account.
Anything else we need to know?:

Environment:
Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.1-palantir1", GitCommit:"f31005ab029ab58f05349b193fa2c22bdbe27ad3", GitTreeState:"clean", BuildDate:"2018-07-24T19:50:58Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.1-palantir1", GitCommit:"f31005ab029ab58f05349b193fa2c22bdbe27ad3", GitTreeState:"clean", BuildDate:"2018-07-24T19:46:29Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Kubeless version (use kubeless version):
Kubeless version: v1.0.0-alpha.7
Cloud provider or physical cluster:
AWS

Is this a BUG REPORT or FEATURE REQUEST?:

Feature Request

What happened:
The HTTP Trigger resource creates ingress resources with a fixed set of annotations without option to customize them.

In our setup (see below) this results in the HTTP Trigger resource being unusable as the resulting ingress resource is not handled by any of our ingress controllers.

What you expected to happen:
An option to add or override annotations of the resulting ingress resource, especially "kubernetes.io/ingress.class".

How to reproduce it (as minimally and precisely as possible):

Create a http trigger.

Anything else we need to know?:
We run several nginx ingress controllers, each responsible for publishing to a different network zone. Each ingress controller handles a separate ingress class. There is no default ingress class and there is no "nginx" ingress class.

Environment:

• Kubernetes version (use kubectl version): Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
• Kubeless version (use kubeless version): Kubeless version: v1.0.0-alpha.8
• Cloud provider or physical cluster: physical cluster