istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix broken knative link. (#5009)

This commit is contained in:
Martin Taillefer 2019-09-16 15:25:03 -07:00 committed by GitHub
parent 35ba46ae3f
commit b81e5a8ccb
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
content/en/blog/2019/evolving-istios-apis/index.md
View File

@ -34,7 +34,13 @@ It sounds complicated, but not everyone needs to interact with those concepts. S
Another example of composability in the networking space can be found in the [Google Cloud HTTP(S) Load Balancer](https://cloud.google.com/load-balancing/docs/https/) (GCLB). To correctly use an instance of the GCLB, six different infrastructure objects need to be created and configured. This design is the result of our 20 years of experience in operating distributed systems and [there is a reason why each one is separate from the others](https://www.youtube.com/watch?v=J5HJ1y6PeyE). But the steps are simplified when you’re creating an instance via the Google Cloud console. We provide the more common end-user/role-specific configurations, and you can configure less common settings later. Ultimately, the goals of infrastructure APIs are to offer the most flexibility without sacrificing functionality.
[Knative](http://knative.dev) is a platform for building, running, and operating serverless workloads that provides a great real-world example of role-centric, higher-level APIs. [Knative Serving](https://knative.dev/docs/serving/), a component of Knative that builds on Kubernetes and Istio to support deploying and serving serverless applications and functions, provides an opinionated workflow for application developers to manage routes and revisions of their services. Thanks to that opinionated approach, Knative Serving exposes a subset of Istio’s networking APIs that are most relevant to application developers via a simplified [Routes](https://github.com/knative/serving/blob/master/docs/spec/spec.md#route) object that supports revisions and traffic routing, abstracting Istio’s [virtual service](/docs/reference/config/networking/v1alpha3/virtual-service/)s and [destination rule](/docs/reference/config/networking/v1alpha3/destination-rule/)s resources.
[Knative](http://knative.dev) is a platform for building, running, and operating serverless workloads that provides a great real-world example of role-centric,
higher-level APIs. [Knative Serving](https://knative.dev/docs/serving/), a component of Knative that builds on Kubernetes and Istio to support deploying and
serving serverless applications and functions, provides an opinionated workflow for application developers to manage routes and revisions of their services.
Thanks to that opinionated approach, Knative Serving exposes a subset of Istio’s networking APIs that are most relevant to application developers via a simplified
[Routes](https://github.com/knative/docs/blob/master/docs/serving/spec/knative-api-specification-1.0.md#route) object that supports revisions and traffic routing,
abstracting Istio’s [`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/) and [`DestinationRule`](/docs/reference/config/networking/v1alpha3/destination-rule/)
resources.
As Istio has matured, we’ve also seen production users develop workload- and organization-specific abstractions on top of Istio’s infrastructure APIs.