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

[master] [release-1.9] Add blog for zero configuration Istio (#9073) 

* Add blog for zero configuration Istio

The intent here is to show off what Istio provides out of the box, to
attempt to counteract some of the reputation Istio has gotten for being
over complicated/requiring too many CRDs.

* fix links

* Address comments

* Apply suggestions from code review

Co-authored-by: craigbox <craigbox@google.com>

Co-authored-by: John Howard <howardjohn@google.com>
Co-authored-by: craigbox <craigbox@google.com>
This commit is contained in:
Istio Automation 2021-02-26 09:17:37 -08:00 committed by GitHub
parent 3709431b6a
commit d26e87dbe4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
content/en/blog/2021/zero-config-istio/index.md
View File

@ -5,8 +5,8 @@ publishdate: 2021-02-25
attribution: "John Howard (Google)"
---
Often times when a new user encounters Istio for the first time, they are overwhelmed by the vast feature
set exposed by Istio. Unfortunately, this occasionally gives the impression that Istio is needlessly complex
When a new user encounters Istio for the first time, they are sometimes overwhelmed by the vast feature
set it exposes. Unfortunately, this can give the impression that Istio is needlessly complex
and not fit for small teams or clusters.
One great part about Istio, however, is that it aims to bring as much value to users out of the box without any configuration at all.
@ -40,7 +40,7 @@ For more information about the observability Istio provides, check out the [obse
## Traffic Management
While Kubernetes provides a lot of networking functionality, such as service discovery and DNS, this is done at the L4 connection level causing a lot of potential functionality to be lost.
While Kubernetes provides a lot of networking functionality, such as service discovery and DNS, this is done at Layer 4, which can have unintended inefficiencies.
For example, in a simple HTTP application sending traffic to a service with 3 replicas, we can see unbalanced load:
{{< text bash >}}
@ -60,11 +60,11 @@ Hostname=echo-cb96f8d94-879sn
Hostname=echo-cb96f8d94-879sn
{{< /text >}}
The problem here is Kubernetes will determine the backend to send at connection establishment, then all future requests on the same connection will be sent to the same backend.
The problem here is Kubernetes will determine the backend to send to when the connection is established, and all future requests on the same connection will be sent to the same backend.
In our example here, our first 5 requests are all sent to `echo-cb96f8d94-2ssll`, while our next set (using a new connection) are all sent to `echo-cb96f8d94-879sn`.
Our third instance never receives any requests.
With Istio, HTTP (including HTTP2 and gRPC) traffic is automatically detected, and our services will automatically be load balanced per request, rather than per connection:
With Istio, HTTP traffic (including HTTP/2 and gRPC) is automatically detected, and our services will automatically be load balanced per _request_, rather than per _connection_:
{{< text bash >}}
$ curl http://echo/{0..5} -s | grep Hostname
@ -78,4 +78,4 @@ Hostname=echo-cb96f8d94-cgmxr
Here we can see our requests are [round-robin](/docs/concepts/traffic-management/#load-balancing-options) load balanced between all backends.
In addition to these better defaults, Istio offers customization of a [variety of traffic management settings](/docs/concepts/traffic-management/), including timeouts, retries, and much more.
In addition to these better defaults, Istio offers customization of a [variety of traffic management settings](/docs/concepts/traffic-management/), including timeouts, retries, and much more.