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

A couple minor edits to the VM Architecture Page (#8939)

This commit is contained in:
Sven Mawson 2021-02-09 16:10:33 -08:00 committed by GitHub
parent c22cba7ee7
commit f3a202a392
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
content/en/docs/ops/deployment/vm-architecture/index.md
View File

@ -9,13 +9,13 @@ owner: istio/wg-environments-maintainers
---
Before reading this document, be sure to review [Istio's architecture](/docs/ops/deployment/architecture/) and [deployment models](/docs/ops/deployment/deployment-models/).
This page builds on these pages to explain how Istio can be extended to support joining virtual machines into the mesh.
This page builds on those documents to explain how Istio can be extended to support joining virtual machines into the mesh.
Istio's virtual machine expansion allows connecting workloads outside of a Kubernetes cluster to the mesh.
Istio's virtual machine support allows connecting workloads outside of a Kubernetes cluster to the mesh.
This enables legacy applications, or applications not suitable to run in a containerized environment, to get all the benefits that Istio provides to applications running inside Kubernetes.
For workloads running on Kubernetes, the Kubernetes platform itself provides various functionalities like service discovery, DNS resolution, and health checks which are often missing in virtual machine environments.
Istio enables these features for workloads running on virtual machines, and in addition allows these workloads to utilize Istio functionalities like mutual TLS (mTLS), rich telemetry, and advanced traffic management capabilities.
For workloads running on Kubernetes, the Kubernetes platform itself provides various features like service discovery, DNS resolution, and health checks which are often missing in virtual machine environments.
Istio enables these features for workloads running on virtual machines, and in addition allows these workloads to utilize Istio functionality such as mutual TLS (mTLS), rich telemetry, and advanced traffic management capabilities.
The following diagram shows the architecture of a mesh with virtual machines:
@ -23,7 +23,7 @@ The following diagram shows the architecture of a mesh with virtual machines:
{{< tab name="Single-Network" category-value="single" >}}
In this mesh, there is a single [network](/docs/ops/deployment/deployment-models/#network-models), implying that pods and virtual machines can communicate directly with each other.
In this mesh, there is a single [network](/docs/ops/deployment/deployment-models/#network-models), where pods and virtual machines can communicate directly with each other.
Control plane traffic, including XDS configuration and certificate signing, are sent through a Gateway in the cluster.
This ensures that the virtual machines have a stable address to connect to when they are bootstrapping. Pods and virtual machines can communicate directly with each other without requiring any intermediate Gateway.
@ -39,7 +39,7 @@ This ensures that the virtual machines have a stable address to connect to when
{{< tab name="Multi-Network" category-value="multiple" >}}
In this mesh, there are multiple [networks](/docs/ops/deployment/deployment-models/#network-models), implying that pods and virtual machines are not able to communicate directly with each other.
In this mesh, there are multiple [networks](/docs/ops/deployment/deployment-models/#network-models), where pods and virtual machines are not able to communicate directly with each other.
Control plane traffic, including XDS configuration and certificate signing, are sent through a Gateway in the cluster.
Similarly, all communication between pods and virtual machines goes through the gateway, which acts as a bridge between the two networks.
@ -65,7 +65,7 @@ Istio provides two mechanisms to represent virtual machine workloads:
Creating these resources (`WorkloadGroup` and `WorkloadEntry`) does not result in provisioning of any resources or running any virtual machine workloads.
Rather, these resources just reference these workloads and inform Istio how to configure the mesh appropriately.
When adding a virtual machine workload to the mesh, you will need to create a `WorkloadGroup`, that acts as template for each `WorkloadEntry` instance:
When adding a virtual machine workload to the mesh, you will need to create a `WorkloadGroup` that acts as template for each `WorkloadEntry` instance:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -83,7 +83,7 @@ spec:
port: 8080
{{< /text >}}
Once the virtual machine has been [configured and added to the mesh](/docs/setup/install/virtual-machine/#configure-the-virtual-machine), a corresponding `WorkloadEntry` will be automatically created by the Istio control plane.
Once a virtual machine has been [configured and added to the mesh](/docs/setup/install/virtual-machine/#configure-the-virtual-machine), a corresponding `WorkloadEntry` will be automatically created by the Istio control plane.
For example:
{{< text yaml >}}
@ -105,9 +105,9 @@ spec:
This `WorkloadEntry` resource describes a single instance of a workload, similar to a pod in Kubernetes. When the workload is removed from the mesh, the `WorkloadEntry` resource will
be automatically removed. Additionally, if any probes are configured in the `WorkloadGroup` resource, the Istio control plane automatically updates the health status of associated `WorkloadEntry` instances.
In order for consumers to reliably call your workload, it's recommended to declare a `Service` association. This allows clients to reach a stable hostname, like `product.default.svc.cluster.local`, rather than ephemeral IP addresses. This also enables you to use advanced routing capabilities in Istio via `DestinationRule` and `VirtualService` APIs.
In order for consumers to reliably call your workload, it's recommended to declare a `Service` association. This allows clients to reach a stable hostname, like `product.default.svc.cluster.local`, rather than an ephemeral IP addresses. This also enables you to use advanced routing capabilities in Istio via the `DestinationRule` and `VirtualService` APIs.
Any Kubernetes service can transparently select workloads across pods and virtual machines via the selector fields which are matched with pod and `WorkloadEntry` labels respectively.
Any Kubernetes service can transparently select workloads across both pods and virtual machines via the selector fields which are matched with pod and `WorkloadEntry` labels respectively.
For example, a `Service` named `product` is composed of a `Pod` and a `WorkloadEntry`:
@ -122,7 +122,7 @@ With this configuration, requests to `product` would be load-balanced across bot
Kubernetes provides DNS resolution in pods for `Service` names allowing pods to easily communicate with one another by stable hostnames.
For virtual machine expansion, Istio provides similar functionality via [DNS Proxy](/docs/ops/configuration/traffic-management/dns-proxy/).
For virtual machine expansion, Istio provides similar functionality via a [DNS Proxy](/docs/ops/configuration/traffic-management/dns-proxy/).
This feature redirects all DNS queries from the virtual machine workload to the Istio proxy, which maintains a mapping of hostnames to IP addresses.
As a result, workloads running on virtual machines can transparently call `Service`s (similar to pods) without requiring any additional configuration.