KEP 18 - Simplify installer - do not install istio nor nginx-ingress

[christian-kreuzberger-dtx]

This Draft provides some information on why we should simplify the Keptn installer to no longer install istio nor nginx-ingress.

FYI, I believe that implementing this KEP will make the following Keptn Issues obsolete:

• Keptn Installer: OpenShift installation does not allow to reuse Istio keptn#1820
• Improve Error handling when "IP of Istio Ingressgateway could not be derived" keptn#1003
• Possibility to change ingress gateway keptn#568
• setupIstio.sh pretends to install Istio minimal profile while it is a mixture of minimal and default  keptn#1406
• Use a newer istio version (e.g., 1.5.4) keptn#1825

Please consider the open questions on the bottom of the markdown file

[jetzlstorfer]

for convenience, here is the link to the formatted doc: https://github.com/keptn/enhancement-proposals/blob/1a6f3e2b3f4d4dc697c12a622e223c4862fd7afc/text/0018-simplify-installer.md

[agrimmer]

Thanks, lgtm! I only have two minor comments.

[agrimmer]

I would propose that neither the CLI nor the API can change the service type because this should be handled by an administrator.
The administrator has then the rights to execute e.g.
kubectl patch svc api-gateway-nginx -n keptn -p '{"spec": {"type": "LoadBalancer"}}'
However, configure bridge should allow to set the basic auth password.

[christian-kreuzberger-dtx]

I would propose that neither the CLI nor the API can change the service type because this should be handled by an administrator.

I agree with that proposal. We should document the command, and remove the funcionality from our API.

[bacherfl]

In addition to Problem notifications, the KEPTN_COMAIN is currently used during the dashboard setup (to provide links to the onboarded services, and to the bridge), as well as to provide deep links to the bridge in dynatrace events.

For the first two cases, we could pass the URL of the API/Bridge as parameter(s) for the configure monitoring command.
For adding the deep links to the bridge in deployment events, we will have to rely on the INGRESS_HOSTNAME_SUFFIX env var (as we also do in the helm-service)

[christian-kreuzberger-dtx]

Thanks for bringing this up, I've added it to the KEP.
Basically, with the proposed change in this KEP deep links to Keptn Bridge will not work anymore, as Keptn does not expose Bridge via a VirtualService or alike.

[bacherfl]

lgtm

[grabnerandi]

Hi. I would like to know what it takes for a user to get Keptn running on e.g: GKE, Microk8s and k3s.
I think the goal must be to make this as simple as possible - and - describing this in the doc and showing the commands that need to be executed would help understand how the "end user experience" would look like

Here is an example. Assume we have a GKE cluster, an nginx-ingress and I am using Istio that is offered with GKE. What are the recommended installation commands to install Keptn? is it somethign like this?

keptn install
kubectl apply -f keptn_bridge_ingress.yaml
kubectl apply -f keptn_api_inrgress.yaml

So - for me to accept this proposal I would like to know what the user needs to execute in order to cover the most common use cases we have seen. Maybe this is already explained in the doc - but - it would be helpful to add a section with "How to install Keptn on these common deployment scenarios"

[christian-kreuzberger-dtx]

Thanks Andi, I'll add a section that describes what the installation feels like for the user in terms of a full installation.

[christian-kreuzberger-dtx]

I've added instructions for GKE, OpenShift and K3s.

[checkelmann]

Hi,

I understand the need to simplify the installer and that not every flavor of different ingress and virtual service types could be covered.

As @christian-kreuzberger-dtx also mentioned within the KEP is that different cloud providers got different types of LoadBalancer Annotations. This is the same for ingresses.

Perhaps it would be an idea instead of creating the ingress or virtual service to print out a default ingress yaml with preconfigured services hosts and ports, which could be then adjusted by the administrator or by a CI/CD Tool when installing keptn automatically.

Something like

keptn describe ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
  name: kubernetes-api-ingress
spec:
  rules:
  - host: api.kubernetes.keptn.dev.ert.com
    http:
      paths:
      - backend:
          serviceName: kubernetes
          servicePort: 443
        path: /
  tls:
  - hosts:
    - api.kubernetes.keptn.dev.ert.com

[christian-kreuzberger-dtx]

Perhaps it would be an idea instead of creating the ingress or virtual service to print out a default ingress yaml with preconfigured services hosts and ports, which could be then adjusted by the administrator or by a CI/CD Tool when installing keptn automatically.

We will be trying to cover this with tutorials and docs with examples for now, which we believe is more than sufficient. Users should know their way around Kubernetes services and ingress if they want to use it. In fact, we have plenty of users that know what they are doing and overwrite the ingress gateway anyway, and we have plenty of users that struggle in determining the correct hostname for the ingress gateway on their Kubernetes setup.