Donate Contour to CNCF (#330)

* Create contour.adoc

Co-authored-by: Timothy Hinderliter <hinderlitert@vmware.com>

proposals/contour.adoc

@@ -0,0 +1,96 @@
+== Contour Proposal
+
+*Name of project:* Contour
+
+*Description:* Contour is an open source Kubernetes ingress controller providing the control plane for the Envoy edge and service proxy. Contour supports dynamic configuration updates and multi-team ingress delegation out of the box, while maintaining a lightweight profile.
+
+=== Alignment with CNCF - Why does CNCF need an ingress controller?
+
+The CNCF has an impressive portfolio of projects that can be leveraged to build and run complex distributed systems; our team believes Contour to be a great fit for the CNCF. Contour's core mission aligns well with Kubernetes and Envoy and the container and networking ecosystem. The CNCF's mission is to “create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems environments capable of scaling to tens of thousands of self-healing multi-tenant nodes.” Modern distributed systems rely on networking and connectivity. As a result, ingress controllers for the compute platform, Kubernetes, are an essential piece of this architecture. Contour is a logical complement to Envoy in this architecture, making it easier to consume Envoy in a cloud native multi-team environment.
+
+=== Contour Overview
+
+==== Features
+
+ * Envoy Inside - Contour is built as the control plane for Envoy, the high performance L7 proxy and load balancer
+ * Flexible Architecture - Contour can be deployed as either a Kubernetes Deployment or DaemonSet
+ * Multi-team support - Safely support ingress in multi-team Kubernetes clusters
+ * TLS Certificate Delegation - Administrators can delegate wildcard certificate access securely
+ * Support for outputting HTTP request logs in a configurable structured JSON format
+ * One service per route can be nominated as a read-only mirror. The mirror service will receive a copy of the read traffic sent to any non-mirror service
+
+To learn more about Contour's features, read and view the following resources:
+
+ * https://projectcontour.io/announcing-contour-1.0/[Intro to Contour]
+ * https://projectcontour.io/routing-traffic-to-applications-in-kubernetes-with-contour/[Routing Traffic to Applications in Kubernetes with Contour]
+ * https://projectcontour.io/httpproxy-in-action/[HTTPProxy in Action]
+ * https://projectcontour.io/resources/[Contour Resources]
+
+=== Project Timeline and Snapshot
+ * Heptio launched and open sourced Contour in October 2017 as an ingress controller for Kubernetes based on Envoy
+ * Contour 1.0 shipped in November 2019, signaling to the community a commitment to a stable set of APIs 
+ * Since then, Contour has had a monthly release, with the latest being Contour v1.5.1 in June 2020
+
+== Production Users
+ * Adobe
+ * DS hostnet
+ * PayIt
+ * PhishLabs
+ * Kintone.io
+ * Replicated
+ * Kinvolk
+
+== In-Flight Features
+
+The Contour team is currently working on the following feature improvements:
+ * Involved in the [Service APIs](https://github.com/kubernetes-sigs/service-apis) work to incorporate and support them in Contour
+ * Using Contour to redirect requests to locations other than Pods, rewriting the ExternalName in the host header for proxied requests
+ * Migration tooling for IngressRoute to HTTPProxy
+
+The direction of the project has generally been guided by our open source community and users. There are a plethora of GitHub issues requesting various features that we prioritize based on popularity of user requests and engineering capacity. 
+
+A roadmap for future features, including those listed above and our detailed project board, can be found in GitHub at https://github.com/projectcontour/community/blob/master/ROADMAP.md. 
+The project welcomes contributions of any kind: code, documentation, bug reporting via issues, and project management to help track and prioritize workstreams.
+
+== Use Cases
+The following is a list of common use-cases for Contour users:  
+
+ * High performance ingress controller for Kubernetes 
+ * Multi-team and multi-tenant ingress controller for Kubernetes 
+ * Blue/Green and canary deployments
+
+== CNCF Donation Details
+ * *Preferred Maturity Level:* Incubation
+ * *Sponsors:* @monadic, @mattklein123
+ * *License:* Apache 2
+ * *Source control repositories / issue tracker:* https://github.com/projectcontour, with a GitHub board tracking engineering work.
+ * *Infrastructure Required:* N/A
+ * *Website:* https://projectcontour.io
+ * *Release Methodology and Mechanics:* Documented at https://projectcontour.io/resources/release-process/
+
+== Social Media Accounts:
+
+ * *Twitter:* https://twitter.com/projectcontour
+ * *Google Groups:* https://groups.google.com/forum/#!forum/projectcontour-announce
+ * *Slack:* https://kubernetes.slack.com/messages/contour
+
+== Contributor Statistics (valid as of Nov 2019)
+ * 2k GitHub Stars
+ * 1120 PRs
+ * 689 Issues Opened
+ * 77 Contributors
+ * 40 releases
+
+== Asks from CNCF
+ * A vendor-neutral home for Contour to facilitate growth and community involvement
+ * Logistics – General access to resource and staff to provide advice, and help optimize our growth
+ * Infrastructure for CI / CD
+ * Integration with CNCF devstat
+
+== Appendix
+
+=== Architecture
+Contour is cleanly architected as a client of the Kubernetes API, leveraging Envoy. You can learn more about its architecture at https://projectcontour.io/docs/v1.0.1/architecture/
+
+== Landscape
+There are numerous ingress controllers available for developers and platform architecture teams to leverage. An analysis of the various options will be performed at a future time.