Skip to content

[release-1.3] Fix broken knative link. #5010

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
geeknoid merged 1 commit into from
Sep 16, 2019
Merged

[release-1.3] Fix broken knative link. #5010

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion content/en/blog/2019/evolving-istios-apis/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down