WIP: Roadmap to 1.0

[aledbf]

• Web administration UI

• Kubectl plugin https://gist.github.com/aledbf/db25dbc723fc7d71345a9657abfd766d

• Installation UX (plugin)

• Help debugging Ingress errors

• Monitoring:

  • prometheus Cleanup prometheus metrics after a reload #2726
  • grafana Grafana Dashboard #2771

• Minikube:

  • change from RC to Deployment

• Autoscaling:

  • HPA with custom metrics

• Dynamic Configuration without reload

  • Zero-downtime deployment for upstreams

• Tutorials/guides/examples

• Documentation - technical writer

• GRPC

• Caching

• Routing by HTTP Header and Method

• Canary Releases

• OOTB Cert manager integration

• Extensions (plugins)

  • Provide extensions points during the request lifecycle
  • Like Auth (for OpenID connect)
  • Enhance request
  • Using external resources (serverless functions)

• Migrate to CRDs

• Remove annotations

• Migrate from Ingress/annotation using the kubectl plugin manually (yaml output) or automatically

• Aspirational

  • 65% of coverage of unit tests
  • 100% of e2e for features
  • More ambitious deployment modes https://thenewstack.io/deployment-strategies/

[kfox1111]

Is the web ui something different then kube-dashboard? If so, why?

Is installation ux different then a helm chart?

What does migration to CRD's mean? Likewise, removing annotations?

[aledbf]

Is the web ui something different then kube-dashboard? If so, why?

You only get the same feature than kubectl get ingress, i.e. you don't get information about the service, port, tls, annotations, etc...

Is installation ux different then a helm chart?

Yes, setting up the controller should not require knowledge of go templates or yaml files

What does migration to CRD's mean? Likewise, removing annotations?

Migrate the current configuration in the configmap and annotations to CRDs to provide the semantics we cannot express with annotations where everything is a string.

[kfox1111]

So, is that reason to create a new ui, or a reason to enhance kube-dashboard to support those things?

helm does not require you to know go templates or yaml files. As an op, a proliferation of how to install things can be difficult to handle. When the installation tools are nestable like helm charts are, you can more easily tie all the things together. For example, you could make a helm chart that contains nginx-ingress, prometheus, and grafana subcharts. then out of the box you get all the monitoring stuff all at once. And you don't have to maintain the install code for the other parts. When someone updates the main prometheus chart with a new feature, then nginx-ingress's chart gets that stuff for free.

Ah. So would there be an annotation left that points to the crd for the rest of the settings? or would the crud somehow point at ingress objects that it should be applied to? Are there any other ingress controllers going to take this approach? Currently there are a lot of helm charts that allow end users to specify ingress annotations. Will they all need to be changed to create crd's as well with user specifiable content, or will annotations also be supported for all the things that can be strings still? I kind of like the idea the annotations would become validate-able via crd's though. It does complicate the deployment a bit as you need to load one and only one crd registration before the (possibly multiple) nginx-ingress controller class instances. (I usually use 2 ingress classes, internet & private). And would probably require extra rbac permissions on the end users behalf for the crd's. So, I guess there are a lot of tradeoffs here.... Could both annotations for the things they can work with and crd's be supported so we don't trade off one set of problems for another? Alternately, could we push for an ingress controller specific section in the Ingress object be added instead of a crd?

[aledbf]

So, is that reason to create a new ui, or a reason to enhance kube-dashboard to support those things?

#109
kubernetes/dashboard#1832

Alternately, could we push for an ingress controller specific section in the Ingress object be added instead of a crd?

This requires a change in the Ingress spec located in k8s core. I don't see this happening any time soon.

Ah. So would there be an annotation left that points to the crd for the rest of the settings? or would the crud somehow point at ingress objects that it should be applied to?

For simplicity, the CRD name is the same one than the Ingress so you don't need an annotation. Using an annotation to point to a specific CRD should also be supported.

Are there any other ingress controllers going to take this approach?

This is an example https://github.com/heptio/contour/blob/master/design/ingressroute-design.md

Will they all need to be changed to create crd's as well with user specifiable content, or will annotations also be supported for all the things that can be strings still?

Only for a couple of releases, then we need to deprecate annotations and focus only on the CRD

So, I guess there are a lot of tradeoffs here....

As always :)

[yuyang0]

+1 for Canary Releases

[chenquanzhao]

@aledbf #2560 is just for canary releases and the implementation is also based on nginx split_clients directive, and can achieve the release target.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kfox1111]

/reopen
/remove-lifecycle rotten

[k8s-ci-robot]

@kfox1111: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen
/remove-lifecycle rotten

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale