mirror of https://github.com/istio/istio.io.git
Waypoint doc updates (#15051)
* WIP * Waypoint doc updates. * lint & rebase * space * fix broken links * final fix up of architecture section * improvements from code review * Update content/en/docs/ambient/usage/waypoint/index.md Co-authored-by: Ian Rudie <ilrudie@gmail.com> * Update content/en/docs/ambient/usage/troubleshoot-waypoint/index.md Co-authored-by: Ian Rudie <ilrudie@gmail.com> * Update content/en/docs/ambient/usage/l7-features/index.md Co-authored-by: Ian Rudie <ilrudie@gmail.com> * lint lint lint * policy => policy or routing rule * change heading --------- Co-authored-by: Ian Rudie <ilrudie@gmail.com>
This commit is contained in:
Craig Box
GitHub
parent
e8a54d0063
commit
a1d71c28e5
|
|
@ -6,50 +6,5 @@ aliases:
|
|||
- /docs/ops/ambient/architecture
|
||||
- /latest/docs/ops/ambient/architecture
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: n/a
|
||||
test: table-of-contents
|
||||
---
|
||||
|
||||
## Ambient APIs
|
||||
|
||||
To enforce L7 policies, add the `istio.io/use-waypoint` label to your resource to use waypoint for the labeled resource.
|
||||
- If a namespace is labeled with `istio.io/use-waypoint` with its default waypoint for the namespace, the waypoint will apply to all pods in the namespace.
|
||||
- The `istio.io/use-waypoint` label can also be set on individual services or pods when using a waypoint for the entire namespace is not desired.
|
||||
- If the `istio.io/use-waypoint` label exists on both a namespace and a service, the service waypoint takes
|
||||
precedence over the namespace waypoint as long as the service waypoint can handle service or all traffic.
|
||||
Similarly, a label on a pod will take precedence over a namespace label
|
||||
|
||||
### Layer 7 policy attachment to waypoints
|
||||
|
||||
You can attach Layer 7 policies (such as `AuthorizationPolicy`, `RequestAuthentication`, `Telemetry`, `WasmPlugin`, etc) to your waypoint using `targetRefs`.
|
||||
|
||||
- To attach a L7 policy to the entire waypoint, set `Gateway` as the `targetRefs` value. The example below shows how to attach the `viewer` policy
|
||||
to the waypoint named `waypoint` for the `default` namespace:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: viewer
|
||||
namespace: default
|
||||
spec:
|
||||
targetRefs:
|
||||
- kind: Gateway
|
||||
group: gateway.networking.k8s.io
|
||||
name: waypoint
|
||||
{{< /text >}}
|
||||
|
||||
- To attach a L7 policy to a specific service within the waypoint, set `Service` as the `targetRefs` value. The example below shows how to attach
|
||||
the `productpage-viewer` policy to the `productpage` service in the `default` namespace:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: productpage-viewer
|
||||
namespace: default
|
||||
spec:
|
||||
targetRefs:
|
||||
- kind: Service
|
||||
group: ""
|
||||
name: productpage
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ This diagram illustrates how encrypted traffic flows between pods in the ambient
|
|||
|
||||
## Observing and debugging traffic redirection in ambient mode
|
||||
|
||||
If traffic redirection is not working correctly in ambient mode, some quick checks can be made to help narrow down the problem. To demonstrate traffic redirection in action, first follow the steps described in the [ztunnel debugging guide](/docs/ambient/usage/debugging).
|
||||
If traffic redirection is not working correctly in ambient mode, some quick checks can be made to help narrow down the problem. We recommend that troubleshooting begin with the steps described in the [ztunnel debugging guide](/docs/ambient/usage/troubleshoot-ztunnel/).
|
||||
|
||||
### Check the ztunnel proxy logs
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Add workloads to the mesh
|
||||
description: Understand how to add workloads to an ambient mesh.
|
||||
weight: 1
|
||||
weight: 10
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
|
@ -14,6 +14,10 @@ To add an applications or namespaces to the mesh in ambient mode, add the label
|
|||
|
||||
Ambient mode can be seamlessly enabled (or disabled) completely transparently as far as the application pods are concerned. Unlike the {{< gloss >}}sidecar{{< /gloss >}} data plane mode, there is no need to restart applications to add them to the mesh, and they will not show as having an extra container deployed in their pod.
|
||||
|
||||
### Layer 4 and Layer 7 functionality
|
||||
|
||||
The secure L4 overlay supports authentication and authorization policies. [Learn about L4 policy support in ambient mode](/docs/ambient/usage/l4-policy/). To opt-in to use Istio's L7 functionality, such as traffic routing, you will need to [deploy a waypoint proxy and enroll your workloads to use it](/docs/ambient/usage/waypoint/).
|
||||
|
||||
## Communicating between pods in different data plane modes
|
||||
|
||||
There are multiple options for interoperability between application pods using the ambient data plane mode, and non-ambient endpoints (including Kubernetes application pods, Istio gateways or Kubernetes Gateway API instances). This interoperability provides multiple options for seamlessly integrating ambient and non-ambient workloads within the same Istio mesh, allowing for phased introduction of ambient capability as best suits the needs of your mesh deployment and operation.
|
||||
|
|
@ -22,7 +26,7 @@ There are multiple options for interoperability between application pods using t
|
|||
|
||||
You may have namespaces which are not part of the mesh at all, in either sidecar or ambient mode. In this case, the non-mesh pods initiate traffic directly to the destination pods without going through the source node's ztunnel, while the destination pod's ztunnel enforces any L4 policy to control whether traffic should be allowed or denied.
|
||||
|
||||
For example, setting a `PeerAuthentication` policy with mTLS mode set to `STRICT`, in an ambient-enabled namespace, will cause traffic from outside the mesh to be denied.
|
||||
For example, setting a `PeerAuthentication` policy with mTLS mode set to `STRICT`, in a namespace with ambient mode enabled, will cause traffic from outside the mesh to be denied.
|
||||
|
||||
### Pods inside the mesh using sidecar mode
|
||||
|
||||
|
|
@ -62,7 +66,7 @@ The following labels control if a resource is included in the mesh in ambient mo
|
|||
| Name | Feature Status | Resource | Description |
|
||||
| --- | --- | --- | --- |
|
||||
| `istio.io/dataplane-mode` | Beta | `Namespace` or `Pod` (latter has precedence) | Add your resource to an ambient mesh. <br><br> Valid values: `ambient` or `none`. |
|
||||
| `istio.io/use-waypoint` | Beta | `Namespace`, `Service` or `Pod` | Use a waypoint for traffic to the labeled resource for L7 policy enforcement. <br><br> Valid values: `{waypoint-name}`, `{namespace}/{waypoint-name}`, or `#none` (with hash). |
|
||||
| `istio.io/use-waypoint` | Beta | `Namespace`, `Service` or `Pod` | Use a waypoint for traffic to the labeled resource for L7 policy enforcement. <br><br> Valid values: `{waypoint-name}` or `none`. |
|
||||
| `istio.io/waypoint-for` | Alpha | `Gateway` | Specifies what types of endpoints the waypoint will process traffic for. <br><br> Valid values: `service`, `workload`, `none` or `all`. This label is optional and the default value is `service`. |
|
||||
|
||||
In order for your `istio.io/use-waypoint` label value to be effective, you have to ensure the waypoint is configured for the endpoint which is using it. By default waypoints accept traffic for service endpoints. For example, when you label a pod to use a specific waypoint via the `istio.io/use-waypoint` label, the waypoint should be labeled `istio.io./waypoint-for` with the value `workload` or `all`.
|
||||
In order for your `istio.io/use-waypoint` label value to be effective, you have to ensure the waypoint is configured for the resource types it will be handling traffic for. By default waypoints accept traffic for services. For example, when you label a pod to use a specific waypoint via the `istio.io/use-waypoint` label, the waypoint should be labeled `istio.io./waypoint-for` with the value `workload` or `all`.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,88 @@
|
|||
---
|
||||
title: Use Layer 4 security policy
|
||||
description: Supported security features when only using the secure L4 overlay.
|
||||
weight: 20
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
The layering of {{< gloss >}}ztunnel{{< /gloss >}} and {{< gloss >}}waypoint{{< /gloss >}} proxies in Istio's ambient mode gives you a choice on whether or not you want to enable Layer 7 (L7) processing for a given workload.
|
||||
|
||||
The Layer 4 (L4) features of Istio's [security policies](/docs/concepts/security) are supported by ztunnel, and are available in ambient mode. [Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) also continue to work if your cluster has a {{< gloss >}}CNI{{< /gloss >}} plugin that supports them, and can be used to provide defense-in-depth.
|
||||
|
||||
To use L7 policies, and Istio's traffic routing features, you can [deploy a waypoint](/docs/ambient/usage/waypoint) for your workloads.
|
||||
|
||||
## Layer 4 authorization policies
|
||||
|
||||
The ztunnel proxy performs authorization policy enforcement when a workload is enrolled in secure overlay mode.
|
||||
|
||||
The actual enforcement point is at the receiving (server-side) ztunnel proxy in the path of a connection.
|
||||
|
||||
A basic L4 authorization policy looks like this:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-sleep-to-httpbin
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals:
|
||||
- cluster.local/ns/ambient-demo/sa/sleep
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
The behavior of the L4 `AuthorizationPolicy` API has the same functional behavior in Istio ambient mode as in sidecar mode. When there is no `AuthorizationPolicy` provisioned, then the default action is `ALLOW`. Once a policy is provisioned, pods matching the selector in the policy only allow traffic which is explicitly allowed. In this example, pods with the label `app: httpbin` only allow traffic from sources with an identity principal of `cluster.local/ns/ambient-demo/sa/sleep`. Traffic from all other sources will be denied.
|
||||
|
||||
### Layer 7 authorization policies without waypoints installed
|
||||
|
||||
{{< warning >}}
|
||||
If an `AuthorizationPolicy` has been configured that requires any traffic processing beyond L4, and if no waypoint proxies are configured for the destination of the traffic, then ztunnel proxy will simply drop all traffic as a defensive move. Hence, check to ensure that either all rules involve L4 processing only or else if non-L4 rules are unavoidable, that waypoint proxies are configured.
|
||||
{{< /warning >}}
|
||||
|
||||
This example adds a check for the HTTP GET method:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-sleep-to-httpbin
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals:
|
||||
- cluster.local/ns/ambient-demo/sa/sleep
|
||||
to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
Even though the identity of the pod is otherwise correct, the presence of a L7 policy, and the traffic not originating from a waypoint proxy, causes the ztunnel to deny the connection:
|
||||
|
||||
{{< text plain >}}
|
||||
command terminated with exit code 56
|
||||
{{< /text >}}
|
||||
|
||||
## Peer authentication
|
||||
|
||||
Istio's [peer authentication policies](/docs/concepts/security/#peer-authentication), which configure mutual TLS (mTLS) modes, are supported by ztunnel.
|
||||
|
||||
As ztunnel and {{< gloss >}}HBONE{{< /gloss >}} implies the use of mTLS, it is not possible to use the `DISABLE` mode in a policy. Such policies will be ignored.
|
||||
|
||||
If you need to disable mTLS for an entire namespace, you will have to disable ambient mode:
|
||||
|
||||
{{ text bash }}
|
||||
$ kubectl label namespace default istio.io/dataplane-mode-
|
||||
{{ /text }}
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
---
|
||||
title: Use Layer 7 features
|
||||
description: Supported features when using a L7 waypoint proxy.
|
||||
weight: 50
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
By adding a waypoint proxy to your traffic flow you can enable more of [Istio's features](/docs/concepts).
|
||||
|
||||
Ambient mode supports configuring waypoints using the Kubernetes Gateway API. Configurations that apply to a Gateway API are called _policies_.
|
||||
|
||||
{{< warning >}}
|
||||
The Istio classic traffic management APIs (virtual service, destination rules etc) remain at Alpha in the ambient data plane mode.
|
||||
|
||||
Mixing Istio classic API and Gateway API configuration is not supported, and will lead to undefined behavior.
|
||||
{{< /warning >}}
|
||||
|
||||
## Traffic routing
|
||||
|
||||
With a waypoint proxy deployed, you can use the following API types:
|
||||
|
||||
| Name | Feature Status | Attachment |
|
||||
| --- | --- | --- |
|
||||
| `HTTPRoute` | Beta | `parentRefs` |
|
||||
| `TCPRoute` | Alpha | `parentRefs` |
|
||||
| `TLSRoute` | Alpha | `parentRefs` |
|
||||
|
||||
Refer to the [traffic management](/docs/tasks/traffic-management/) documentation to see the range of features that can be implemented using these routes.
|
||||
|
||||
## Security
|
||||
|
||||
Without a waypoint installed, you can only use [Layer 4 security policies](/docs/ambient/usage/l4-policy/). By adding a waypoint, you gain access to the following policies:
|
||||
|
||||
| Name | Feature Status | Attachment |
|
||||
| --- | --- | --- |
|
||||
| `AuthorizationPolicy` (including L7 features) | Beta | `targetRefs` |
|
||||
| `RequestAuthentication` | Beta | `targetRefs` |
|
||||
|
||||
## Observability
|
||||
|
||||
The [full set of Istio traffic metrics](/docs/reference/config/metrics/) are exported by a waypoint proxy.
|
||||
|
||||
## Extension
|
||||
|
||||
As the waypoint proxy is a deployment of {{< gloss >}}Envoy{{< /gloss >}}, the extension mechanisms that are available for Envoy in {{< gloss >}}sidecar{{< /gloss >}} mode are also available to waypoint proxies.
|
||||
|
||||
| Name | Feature Status | Attachment |
|
||||
| --- | --- | --- |
|
||||
| `WasmPlugin` | Alpha | `targetRefs` |
|
||||
| `EnvoyFilter` | Alpha | `targetRefs` |
|
||||
|
||||
## Targeting policies or routing rules
|
||||
|
||||
### Attach to the entire waypoint proxy
|
||||
|
||||
To attach a policy or routing rule to the entire waypoint — so that it applies to all traffic enrolled to use it — set `Gateway` as the `parentRefs` or `targetRefs` value, depending on the type.
|
||||
|
||||
For example, to apply an `AuthorizationPolicy` policy to the waypoint named `waypoint` for the `default` namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: viewer
|
||||
namespace: default
|
||||
spec:
|
||||
targetRefs:
|
||||
- kind: Gateway
|
||||
group: gateway.networking.k8s.io
|
||||
name: waypoint
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
namespaces: ["default", "istio-system"]
|
||||
to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
### Attach to a specific service
|
||||
|
||||
You can also attach a policy or routing rule to a specific service within the waypoint. Set `Service` as the `parentRefs` or `targetRefs` value, as appropriate.
|
||||
|
||||
The example below shows how to apply the `reviews` HTTPRoute to the `reviews` service in the `default` namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: gateway.networking.k8s.io/v1beta1
|
||||
kind: HTTPRoute
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
parentRefs:
|
||||
- group: ""
|
||||
kind: Service
|
||||
name: reviews
|
||||
port: 9080
|
||||
rules:
|
||||
- backendRefs:
|
||||
- name: reviews-v1
|
||||
port: 9080
|
||||
weight: 90
|
||||
- name: reviews-v2
|
||||
port: 9080
|
||||
weight: 10
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
---
|
||||
title: Enable policy in ambient mode
|
||||
description: The two enforcement points for policy in an ambient mesh.
|
||||
weight: 20
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
The ztunnel proxy performs authorization policy enforcement when a workload is enrolled in secure overlay mode (i.e. with no waypoint proxy configured).
|
||||
The actual enforcement point is at the receiving (or server-side) ztunnel proxy in the path of a connection.
|
||||
|
||||
## Layer 4 authorization policies
|
||||
|
||||
A basic L4 authorization policy looks like this:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-sleep-to-httpbin
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals:
|
||||
- cluster.local/ns/ambient-demo/sa/sleep
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
The behavior of the `AuthorizationPolicy` API has the same functional behavior in Istio ambient mode as in sidecar mode. When there is no `AuthorizationPolicy` provisioned, then the default action is `ALLOW`. Once a policy is provisioned, pods matching the selector in the policy only allow traffic which is explicitly allowed. In this example, pods with the label `app:httpbin` only allow traffic from sources with an identity principal of `cluster.local/ns/ambient-demo/sa/sleep`. Traffic from all other sources will be denied.
|
||||
|
||||
## Layer 7 authorization policies without waypoints installed
|
||||
|
||||
{{< warning >}}
|
||||
If an `AuthorizationPolicy` has been configured that requires any traffic processing beyond L4, and if no waypoint proxies are configured for the destination of the traffic, then ztunnel proxy will simply drop all traffic as a defensive move. Hence, check to ensure that either all rules involve L4 processing only or else if non-L4 rules are unavoidable, that waypoint proxies are configured.
|
||||
{{< /warning >}}
|
||||
|
||||
This example adds a check for the HTTP GET method.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-sleep-to-httpbin
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals:
|
||||
- cluster.local/ns/ambient-demo/sa/sleep
|
||||
to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
Even though the identity of the pod is otherwise correct, the presence of a L7 policy causes the ztunnel to deny the connection.
|
||||
|
||||
{{< text plain >}}
|
||||
command terminated with exit code 56
|
||||
{{< /text >}}
|
||||
|
||||
You can also confirm by viewing logs of specific ztunnel proxy pods (not shown in the example here) that it is always the ztunnel proxy on the node hosting the destination pod that actually enforces the policy.
|
||||
|
|
@ -0,0 +1,107 @@
|
|||
---
|
||||
title: Troubleshoot issues with waypoints
|
||||
description: How to investigate problems routing through waypoint proxies.
|
||||
weight: 70
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
This guide describes what to do if you have enrolled a namespace, service or workload in a waypoint proxy, but you are not seeing the expected behavior.
|
||||
|
||||
## Problems with traffic routing or security policy
|
||||
|
||||
To send some requests to the `reviews` service via the `productpage` service from the `sleep` pod:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec deploy/sleep -- curl -s http://productpage:9080/productpage
|
||||
{{< /text >}}
|
||||
|
||||
To send some requests to the `reviews` `v2` pod from the `sleep` pod:
|
||||
|
||||
{{< text bash >}}
|
||||
$ export REVIEWS_V2_POD_IP=$(kubectl get pod -l version=v2,app=reviews -o jsonpath='{.items[0].status.podIP}')
|
||||
$ kubectl exec deploy/sleep -- curl -s http://$REVIEWS_V2_POD_IP:9080/reviews/1
|
||||
{{< /text >}}
|
||||
|
||||
Requests to the `reviews` service should be enforced by the `reviews-svc-waypoint` for any L7 policies.
|
||||
Requests to the `reviews` `v2` pod should be enforced by the `reviews-v2-pod-waypoint` for any L7 policies.
|
||||
|
||||
1. If your L7 configuration isn't applied, run `istioctl analyze` first to check if your configuration has a validation issue.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl analyze
|
||||
✔ No validation issues found when analyzing namespace: default.
|
||||
{{< /text >}}
|
||||
|
||||
1. Determine which waypoint is implementing the L7 configuration for your service or pod.
|
||||
|
||||
If your source calls the destination using the service's hostname or IP, use the `istioctl experimental ztunnel-config service` command to confirm your waypoint is used by the destination service. Following the example earlier, the `reviews` service should use the `reviews-svc-waypoint` while all other services in the `default` namespace should use the namespace `waypoint`.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental ztunnel-config service
|
||||
NAMESPACE SERVICE NAME SERVICE VIP WAYPOINT
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default details 10.43.160.119 waypoint
|
||||
default kubernetes 10.43.0.1 waypoint
|
||||
default notsleep 10.43.156.147 waypoint
|
||||
default productpage 10.43.172.254 waypoint
|
||||
default ratings 10.43.71.236 waypoint
|
||||
default reviews 10.43.162.105 reviews-svc-waypoint
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
If your source calls the destination using a pod IP, use the `istioctl experimental ztunnel-config workload` command to confirm your waypoint is used by the destination pod. Following the example earlier, the `reviews` `v2` pod should use the `reviews-v2-pod-waypoint` while all other pods in the `default` namespace should not have any waypoints, because by default [a waypoint only handles traffic addressed to services](/docs/ambient/usage/waypoint/#waypoint-traffic-types).
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental ztunnel-config workload
|
||||
NAMESPACE POD NAME IP NODE WAYPOINT PROTOCOL
|
||||
default bookinfo-gateway-istio-7c57fc4647-wjqvm 10.42.2.8 k3d-k3s-default-server-0 None TCP
|
||||
default details-v1-698d88b-wwsnv 10.42.2.4 k3d-k3s-default-server-0 None HBONE
|
||||
default notsleep-685df55c6c-nwhs6 10.42.0.9 k3d-k3s-default-agent-0 None HBONE
|
||||
default productpage-v1-675fc69cf-fp65z 10.42.2.6 k3d-k3s-default-server-0 None HBONE
|
||||
default ratings-v1-6484c4d9bb-crjtt 10.42.0.4 k3d-k3s-default-agent-0 None HBONE
|
||||
default reviews-svc-waypoint-c49f9f569-b492t 10.42.2.10 k3d-k3s-default-server-0 None TCP
|
||||
default reviews-v1-5b5d6494f4-nrvfx 10.42.2.5 k3d-k3s-default-server-0 None HBONE
|
||||
default reviews-v2-5b667bcbf8-gj7nz 10.42.0.5 k3d-k3s-default-agent-0 reviews-v2-pod-waypoint HBONE
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
If the value for the pod's waypoint column isn't correct, verify your pod is labeled with `istio.io/use-waypoint` and the label's value is the name of a waypoint that can process
|
||||
workload traffic. For example, if your `reviews` `v2` pod uses a waypoint that can only process service traffic, you will not see any waypoint used by that pod.
|
||||
If the `istio.io/use-waypoint` label on your pod looks correct verify that the Gateway resource for your waypoint is labeled with a compatible value for `istio.io/waypoint-for`. In the case of a pod, suitable values would be `all` or `workload`.
|
||||
|
||||
1. Check the waypoint's proxy status via the `istioctl proxy-status` command.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-status
|
||||
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
|
||||
bookinfo-gateway-istio-7c57fc4647-wjqvm.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
reviews-svc-waypoint-c49f9f569-b492t.default Kubernetes SYNCED SYNCED SYNCED NOT SENT NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
reviews-v2-pod-waypoint-7f5dbd597-7zzw7.default Kubernetes SYNCED SYNCED NOT SENT NOT SENT NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
waypoint-6f7b665c89-6hppr.default Kubernetes SYNCED SYNCED SYNCED NOT SENT NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
1. Enable Envoy's [access log](/docs/tasks/observability/logs/access-log/) and check the logs of the waypoint proxy after sending some requests:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl logs deploy/waypoint
|
||||
{{< /text >}}
|
||||
|
||||
If there is not enough information, you can enable the debug logs for the waypoint proxy:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl pc log deploy/waypoint --level debug
|
||||
{{< /text >}}
|
||||
|
||||
1. Check the envoy configuration for the waypoint via the `istioctl proxy-config` command, which shows all the information related to the waypoint such as clusters, endpoints, listeners, routes and secrets:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-config all deploy/waypoint
|
||||
{{< /text >}}
|
||||
|
||||
Refer to the [deep dive into Envoy configuration](/docs/ops/diagnostic-tools/proxy-cmd/#deep-dive-into-envoy-configuration) section for more
|
||||
information regarding how to debug Envoy since waypoint proxies are based on Envoy.
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: Debug connectivity issues with ztunnel
|
||||
title: Troubleshoot connectivity issues with ztunnel
|
||||
description: How to validate the node proxies have the correct configuration.
|
||||
weight: 50
|
||||
weight: 60
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
||||
This section describes some options for monitoring the ztunnel proxy configuration and datapath. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems. Additional advanced monitoring of ztunnel internals and advanced troubleshooting is out of scope for this guide.
|
||||
This guide describes some options for monitoring the ztunnel proxy configuration and datapath. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems.
|
||||
|
||||
## Viewing ztunnel proxy state
|
||||
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Configure waypoint proxies
|
||||
description: Gain the full set of Istio features with optional Layer 7 proxies.
|
||||
weight: 10
|
||||
weight: 30
|
||||
aliases:
|
||||
- /docs/ops/ambient/usage/waypoint
|
||||
- /latest/docs/ops/ambient/usage/waypoint
|
||||
|
|
@ -10,17 +10,20 @@ test: no
|
|||
---
|
||||
|
||||
A **waypoint proxy** is an optional deployment of the Envoy-based proxy to add Layer 7 (L7) processing to a defined set of workloads.
|
||||
Waypoint proxies are installed, upgraded and scaled independently from applications; an application owner should be unaware of their existence. Compared to the sidecar data plane mode, which runs an instance of the Envoy proxy alongside each workload, the number of proxies required can be substantially reduced.
|
||||
|
||||
Waypoint proxies are installed, upgraded and scaled independently from applications; an application owner should be unaware of their existence. Compared to the sidecar {{< gloss >}}data plane{{< /gloss >}} mode, which runs an instance of the Envoy proxy alongside each workload, the number of proxies required can be substantially reduced.
|
||||
|
||||
A waypoint, or set of waypoints, can be shared between applications with a similar security boundary. This might be all the instances of a particular workload, or all the workloads in a namespace.
|
||||
|
||||
As opposed to {{< gloss >}}sidecar{{< /gloss >}} mode, in ambient mode policies are enforced by the **destination** waypoint. In many ways, the waypoint acts as a gateway to a resource (a namespace, service or pod). Istio enforces that all traffic coming into the resource goes through the waypoint, which then enforces all policies for that resource.
|
||||
|
||||
## Do you need a waypoint proxy?
|
||||
|
||||
This layered approach of ambient allows users to adopt Istio in a more incremental fashion, smoothly transitioning from no mesh, to the secure overlay, to full L7 processing. If your applications require any of the following L7 mesh functions, you will need to use waypoint proxy for your applications:
|
||||
The layered approach of ambient allows users to adopt Istio in a more incremental fashion, smoothly transitioning from no mesh, to the secure L4 overlay, to full L7 processing.
|
||||
|
||||
Most of the features of ambient mode are provided by the ztunnel node agent. Ztunnel is scoped to only process traffic at Layer 4 (L4), so that it can safely operate as a shared component.
|
||||
Most of the features of ambient mode are provided by the ztunnel node proxy. Ztunnel is scoped to only process traffic at Layer 4 (L4), so that it can safely operate as a shared component.
|
||||
|
||||
When you add a waypoint proxy for a workload, traffic will be forwarded from the ztunnel to that waypoint. This enables the following features:
|
||||
When you configure redirection to a waypoint, traffic will be forwarded by ztunnel to that waypoint. If your applications require any of the following L7 mesh functions, you will need to use a waypoint proxy:
|
||||
|
||||
* **Traffic management**: HTTP routing & load balancing, circuit breaking, rate limiting, fault injection, retries, timeouts
|
||||
* **Security**: Rich authorization policies based on L7 primitives such as request type or HTTP header
|
||||
|
|
@ -28,7 +31,9 @@ When you add a waypoint proxy for a workload, traffic will be forwarded from the
|
|||
|
||||
## Deploy a waypoint proxy
|
||||
|
||||
Waypoint proxies are deployed declaratively using Kubernetes Gateway resources or the helpful istioctl command. By default, a waypoint will only handle `service` traffic. It is possible for the bundled Istio waypoint class to handle `workload` traffic. Istio also recognizes a convenient `all` value which includes both previously mentioned traffic types. Finally, a waypoint may be configured for testing to handle no traffic at all by using the `none` value.
|
||||
Waypoint proxies are deployed declaratively using Kubernetes Gateway resources. You can use istioctl experimental subcommands to generate, apply or list these resources.
|
||||
|
||||
After the waypoint is deployed, the entire namespace (or whichever services or pods you choose) must be [enrolled](#useawaypoint) to use it.
|
||||
|
||||
Before you deploy a waypoint proxy for a specific namespace, confirm the namespace is labeled with `istio.io/dataplane-mode: ambient`:
|
||||
|
||||
|
|
@ -39,9 +44,7 @@ istio-system Active 24h
|
|||
default Active 24h ambient
|
||||
{{< /text >}}
|
||||
|
||||
Before you deploy a waypoint proxy, you can preview the generated Kubernetes Gateway
|
||||
resource, for example, the command below generates a waypoint proxy named `waypoint` for the
|
||||
`default` namespace that can process traffic for services in the namespace:
|
||||
`istioctl` can generate a Kubernetes Gateway resource for a waypoint proxy. For example, to generate a waypoint proxy named `waypoint` for the `default` namespace that can process traffic for services in the namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental waypoint generate --for service -n default
|
||||
|
|
@ -59,18 +62,16 @@ spec:
|
|||
protocol: HBONE
|
||||
{{< /text >}}
|
||||
|
||||
Note the Gateway resource has `istio-waypoint` as `gatewayClassName` which indicates it is a waypoint provided by Istio. The
|
||||
Gateway resource is labeled with `istio.io/waypoint-for: service`, indicating the waypoint can process traffic for services,
|
||||
which is the default.
|
||||
Note the Gateway resource has the `istio-waypoint` label set to `gatewayClassName` which indicates it is a waypoint provided by Istio. The Gateway resource is labeled with `istio.io/waypoint-for: service`, indicating the waypoint can process traffic for services, which is the default.
|
||||
|
||||
To deploy a waypoint proxy for the `default` namespace, use the command below:
|
||||
To deploy a waypoint proxy directly, use `apply` instead of `generate`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental waypoint apply -n default
|
||||
waypoint default/namespace applied
|
||||
{{< /text >}}
|
||||
|
||||
Or, you can deploy the generated Gateway resource from the `istioctl experimental waypoint generate` command to your Kubernetes cluster:
|
||||
Or, you can deploy the generated Gateway resource:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -89,43 +90,34 @@ spec:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
To config your waypoint to process traffic differently than the default `service`, you can modify the `istio.io/waypoint-for` label
|
||||
value to the desired value (`workload`, `all`, or `none`). For example, the command below deploys a waypoint proxy for the
|
||||
`default` namespace that can process `all` traffic in the namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
kind: Gateway
|
||||
metadata:
|
||||
labels:
|
||||
istio.io/waypoint-for: all
|
||||
name: waypoint
|
||||
namespace: default
|
||||
spec:
|
||||
gatewayClassName: istio-waypoint
|
||||
listeners:
|
||||
- name: mesh
|
||||
port: 15008
|
||||
protocol: HBONE
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
You can also use the `--for` parameter to `istioctl experimental waypoint apply`:
|
||||
|
||||
{{< text bash>}}
|
||||
$ istioctl experimental waypoint apply -n default --for all
|
||||
{{< /text >}}
|
||||
|
||||
After the Gateway resource is applied, Istiod will monitor the resource, deploy and manage the corresponding waypoint deployment and service for users automatically.
|
||||
|
||||
### Waypoint traffic types
|
||||
|
||||
By default, a waypoint will only handle traffic destined for **services** in its namespaces. This choice was made because traffic directed at a pod alone is rare, and often used for internal purposes such as Prometheus scraping, and the extra overhead of L7 processing may not be desired.
|
||||
|
||||
It is also possible for the waypoint to handle all traffic, only handle traffic sent directly to **workloads** (pods or VMs) in the cluster, or no traffic at all. The types of traffic that will be redirected to the waypoint are determined by the `istio.io/waypoint-for` label on the `Gateway` object.
|
||||
|
||||
The `--for` parameter to `istioctl experimental waypoint apply` can be used to change the [traffic type](#waypoint-traffic-types) redirected to the waypoint:
|
||||
|
||||
| `waypoint-for` value | Traffic type |
|
||||
| -------------------- | ------------ |
|
||||
| `service` | Kubernetes services |
|
||||
| `workload` | Pod or VM IPs |
|
||||
| `all` | Both service and workload traffic |
|
||||
| `none` | No traffic (useful for testing) |
|
||||
|
||||
## Use a waypoint proxy {#useawaypoint}
|
||||
|
||||
When a waypoint proxy is deployed, it is not used by any resources until you they are explicitly configured to use it.
|
||||
When a waypoint proxy is deployed, it is not used by any resources until you explicitly configure those resources to use it.
|
||||
|
||||
To enable a namespace, service or Pod to use a waypoint, add the `istio.io/use-waypoint` label with a value of the waypoint name.
|
||||
We recommend to start with namespace waypoint proxy first as it can be used by any resources in the namespace.
|
||||
|
||||
If you use `istioctl` to deploy your namespace waypoint, you can use the `--enroll-namespace` parameter to automatically label a namespace for you.
|
||||
{{< tip >}}
|
||||
Most users will want to apply a waypoint to an entire namespace, and we recommend you start with this approach.
|
||||
{{< /tip >}}
|
||||
|
||||
If you use `istioctl` to deploy your namespace waypoint, you can use the `--enroll-namespace` parameter to automatically label a namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental waypoint apply -n default --enroll-namespace
|
||||
|
|
@ -140,14 +132,18 @@ $ kubectl label ns default istio.io/use-waypoint=waypoint
|
|||
namespace/default labeled
|
||||
{{< /text >}}
|
||||
|
||||
After a namespace is enrolled to use a waypoint, any requests from any pods in ambient to any service running in that namespace will be routed through the waypoint for L7 processing and policy enforcement.
|
||||
After a namespace is enrolled to use a waypoint, any requests from any pods using the ambient data plane mode, to any service running in that namespace, will be routed through the waypoint for L7 processing and policy enforcement.
|
||||
|
||||
If you prefer more granularity than running a waypoint for an entire namespace, you can label a specific service or pod to use a waypoint. This may be useful if you want a `WasmPlugin` resource to apply only on a specific service, or if you are calling a Kubernetes
|
||||
If you prefer more granularity than using a waypoint for an entire namespace, you can enroll only a specific service or pod to use a waypoint. This may be useful if you only need L7 features for some services in a namespace, if you only want an extension like a `WasmPlugin` to apply to a specific service, or if you are calling a Kubernetes
|
||||
[headless service](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services) by its pod IP address.
|
||||
|
||||
{{< tip >}}
|
||||
If the `istio.io/use-waypoint` label exists on both a namespace and a service, the service waypoint takes precedence over the namespace waypoint as long as the service waypoint can handle `service` or `all` traffic. Similarly, a label on a pod will take precedence over a namespace label.
|
||||
{{< /tip >}}
|
||||
|
||||
### Configure a service to use a specific waypoint
|
||||
|
||||
Deploy a waypoint called `reviews-svc-waypoint` for the `reviews` service:
|
||||
Using the services from the sample [bookinfo application](/docs/examples/bookinfo/), we can deploy a waypoint called `reviews-svc-waypoint` for the `reviews` service:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental waypoint apply -n default --name reviews-svc-waypoint
|
||||
|
|
@ -161,11 +157,15 @@ $ kubectl label service reviews istio.io/use-waypoint=reviews-svc-waypoint
|
|||
service/reviews labeled
|
||||
{{< /text >}}
|
||||
|
||||
Any requests from pods in the ambient mesh to the `reviews` service will now be routed through the `reviews-svc-waypoint` waypoint.
|
||||
Any requests from pods in the mesh to the `reviews` service will now be routed through the `reviews-svc-waypoint` waypoint.
|
||||
|
||||
### Configure a pod to use a specific waypoint
|
||||
|
||||
Deploy a waypoint called `reviews-v2-pod-waypoint` for the `reviews-v2` pod:
|
||||
Deploy a waypoint called `reviews-v2-pod-waypoint` for the `reviews-v2` pod.
|
||||
|
||||
{{< tip >}}
|
||||
Recall the default for waypoints is to target services; as we explicitly want to target a pod, we need to use the `istio.io/waypoint-for: workload` label, which we can generate by using the `--for workload` parameter to istioctl.
|
||||
{{< /tip >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental waypoint apply -n default --name reviews-v2-pod-waypoint --for workload
|
||||
|
|
@ -179,176 +179,4 @@ $ kubectl label pod -l version=v2,app=reviews istio.io/use-waypoint=reviews-v2-p
|
|||
pod/reviews-v2-5b667bcbf8-spnnh labeled
|
||||
{{< /text >}}
|
||||
|
||||
Any requests from pods in the ambient mesh to the `reviews-v2` pod IP will now be routed through the `reviews-v2-pod-waypoint` waypoint.
|
||||
for L7 processing and policy enforcement.
|
||||
|
||||
## Attach L7 policies to waypoint proxies {#attachl7policies}
|
||||
|
||||
The following L7 policies are supported for waypoint proxy:
|
||||
|
||||
| Name | Feature Status | Policy Attachment |
|
||||
| --- | --- | --- |
|
||||
| `HTTPRoute` | Beta | `parentRefs` |
|
||||
| `TCPRoute` | Alpha | `parentRefs` |
|
||||
| `TLSRoute` | Alpha | `parentRefs` |
|
||||
| `AuthorizationPolicy` | Beta | `targetRefs` |
|
||||
| `RequestAuthentication` | Beta | `targetRefs` |
|
||||
| `Telemetry` | Alpha | `targetRefs` |
|
||||
| `WasmPlugin` | Alpha | `targetRefs` |
|
||||
| `EnvoyFilter` | Alpha | `targetRefs` |
|
||||
|
||||
### Attach a L7 policy to the entire waypoint proxy
|
||||
|
||||
To attach a L7 policy to the entire waypoint, set `Gateway` as the `parentRefs` or `targetRefs` value, depending on your policy type.
|
||||
The example below shows how to apply an `AuthorizationPolicy` policy to the waypoint named `waypoint` for the `default` namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: viewer
|
||||
namespace: default
|
||||
spec:
|
||||
targetRefs:
|
||||
- kind: Gateway
|
||||
group: gateway.networking.k8s.io
|
||||
name: waypoint
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
namespaces: ["default", "istio-system"]
|
||||
to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
### Attach a L7 policy to a specific service
|
||||
|
||||
To attach a L7 policy to a specific service within the waypoint, set `Service` as the `parentRefs` or `targetRefs` value. The example below shows how to apply
|
||||
the `reviews` HTTPRoute to the `reviews` service in the `default` namespace:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: gateway.networking.k8s.io/v1beta1
|
||||
kind: HTTPRoute
|
||||
metadata:
|
||||
name: reviews
|
||||
spec:
|
||||
parentRefs:
|
||||
- group: ""
|
||||
kind: Service
|
||||
name: reviews
|
||||
port: 9080
|
||||
rules:
|
||||
- backendRefs:
|
||||
- name: reviews-v1
|
||||
port: 9080
|
||||
weight: 90
|
||||
- name: reviews-v2
|
||||
port: 9080
|
||||
weight: 10
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
## Debug your waypoint proxies
|
||||
|
||||
The debugging guide below assume you have followed the ambient get started [guide](/docs/ambient/getting-started/) to install [Istio with
|
||||
the ambient profile](/docs/ambient/getting-started/#download) and the sample [bookinfo application](/docs/ambient/getting-started/#bookinfo), [added your application to the ambient mesh](/docs/ambient/getting-started/#addtoambient) and followed all the commands in the [use a waypoint](#useawaypoint) and [attach L7 policies to waypoint proxies](#attachl7policies) sections earlier.
|
||||
|
||||
To send some requests to the `reviews` service via the `productpage` service from the `sleep` pod:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec deploy/sleep -- curl -s http://productpage:9080/productpage
|
||||
{{< /text >}}
|
||||
|
||||
To send some requests to the `reviews` `v2` pod from the `sleep` pod:
|
||||
|
||||
{{< text bash >}}
|
||||
$ export REVIEWS_V2_POD_IP=$(kubectl get pod -l version=v2,app=reviews -o jsonpath='{.items[0].status.podIP}')
|
||||
$ kubectl exec deploy/sleep -- curl -s http://$REVIEWS_V2_POD_IP:9080/reviews/1
|
||||
{{< /text >}}
|
||||
|
||||
Requests to the `reviews` service should be enforced by the `reviews-svc-waypoint` for any L7 policies.
|
||||
Requests to the `reviews` `v2` pod should be enforced by the `reviews-v2-pod-waypoint` for any L7 policies.
|
||||
|
||||
1. If your L7 policy isn't enforced, run `istioctl analyze` first to check if your policy has any validation issue.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl analyze
|
||||
✔ No validation issues found when analyzing namespace: default.
|
||||
{{< /text >}}
|
||||
|
||||
1. Determine which waypoint is enforcing the L7 policy for your service or pod.
|
||||
|
||||
If your source calls the destination using the service's hostname or IP, use the `istioctl experimental ztunnel-config service` command to confirm your waypoint is used by the destination service. Following the example earlier, the `reviews` service should use the `reviews-svc-waypoint` while all other services in the `default` namespace should use the namespace `waypoint`.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental ztunnel-config service
|
||||
NAMESPACE SERVICE NAME SERVICE VIP WAYPOINT
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default bookinfo-gateway-istio 10.43.164.194 waypoint
|
||||
default details 10.43.160.119 waypoint
|
||||
default kubernetes 10.43.0.1 waypoint
|
||||
default notsleep 10.43.156.147 waypoint
|
||||
default productpage 10.43.172.254 waypoint
|
||||
default ratings 10.43.71.236 waypoint
|
||||
default reviews 10.43.162.105 reviews-svc-waypoint
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
If your source calls the destination using a pod IP , use the `istioctl experimental ztunnel-config workload` command to confirm your waypoint is used by the destination pod. Following the example earlier, the `reviews` `v2` pod should use the `reviews-v2-pod-waypoint` while all other pods in the `default` namespace should not have any waypoints because by default only services use the namespace `waypoint`.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl experimental ztunnel-config workload
|
||||
NAMESPACE POD NAME IP NODE WAYPOINT PROTOCOL
|
||||
default bookinfo-gateway-istio-7c57fc4647-wjqvm 10.42.2.8 k3d-k3s-default-server-0 None TCP
|
||||
default details-v1-698d88b-wwsnv 10.42.2.4 k3d-k3s-default-server-0 None HBONE
|
||||
default notsleep-685df55c6c-nwhs6 10.42.0.9 k3d-k3s-default-agent-0 None HBONE
|
||||
default productpage-v1-675fc69cf-fp65z 10.42.2.6 k3d-k3s-default-server-0 None HBONE
|
||||
default ratings-v1-6484c4d9bb-crjtt 10.42.0.4 k3d-k3s-default-agent-0 None HBONE
|
||||
default reviews-svc-waypoint-c49f9f569-b492t 10.42.2.10 k3d-k3s-default-server-0 None TCP
|
||||
default reviews-v1-5b5d6494f4-nrvfx 10.42.2.5 k3d-k3s-default-server-0 None HBONE
|
||||
default reviews-v2-5b667bcbf8-gj7nz 10.42.0.5 k3d-k3s-default-agent-0 reviews-v2-pod-waypoint HBONE
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
If the value for the pod's waypoint column isn't correct, verify your pod is labeled with `istio.io/use-waypoint` and the label's value is the name of a waypoint that can process
|
||||
workload traffic. For example, if your `reviews` `v2` pod uses a waypoint that can only process service traffic, you will not see any waypoint used by that pod.
|
||||
|
||||
1. Check the waypoint's proxy status via the `istioctl proxy-status` command.
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-status
|
||||
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
|
||||
bookinfo-gateway-istio-7c57fc4647-wjqvm.default Kubernetes SYNCED SYNCED SYNCED SYNCED NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
reviews-svc-waypoint-c49f9f569-b492t.default Kubernetes SYNCED SYNCED SYNCED NOT SENT NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
reviews-v2-pod-waypoint-7f5dbd597-7zzw7.default Kubernetes SYNCED SYNCED NOT SENT NOT SENT NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
waypoint-6f7b665c89-6hppr.default Kubernetes SYNCED SYNCED SYNCED NOT SENT NOT SENT istiod-795d55fc6d-vqtjx 1.23-alpha.75c6eafc5bc8d160b5643c3ea18acb9785855564
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
1. Enable Envoy's [access log](/docs/tasks/observability/logs/access-log/) and check the logs of the waypoint proxy after sending some requests:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl logs deploy/waypoint
|
||||
{{< /text >}}
|
||||
|
||||
If there is not enough information, you can enable the debug logs for the waypoint proxy:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl pc log deploy/waypoint --level debug
|
||||
{{< /text >}}
|
||||
|
||||
1. Check the envoy configuration for the waypoint via the `istioctl proxy-config` command, which shows all the information related to the waypoint such as clusters, endpoints, listeners, routes and secrets:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-config all deploy/waypoint
|
||||
{{< /text >}}
|
||||
|
||||
Refer to the [deep dive into Envoy configuration](/docs/ops/diagnostic-tools/proxy-cmd/#deep-dive-into-envoy-configuration) section for more
|
||||
information regarding how to debug Envoy since waypoint proxies are based on Envoy.
|
||||
Any requests from pods in the ambient mesh to the `reviews-v2` pod IP will now be routed through the `reviews-v2-pod-waypoint` waypoint for L7 processing and policy enforcement.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
title: CNI
|
||||
test: n/a
|
||||
---
|
||||
|
||||
The [Container Network Interface (CNI)](https://www.cni.dev/) is the standard used by Kubernetes for configuring cluster networking. It is implemented using *plugins*, of which there are two types:
|
||||
|
||||
* *interface* plugins, which create a network interface, and are provided by the cluster operator
|
||||
* *chained* plugins, which can configure the created interface, and can be provided by software installed on the cluster
|
||||
|
||||
Istio works with all CNI implementations that follow the CNI standard, in both sidecar and ambient mode.
|
||||
|
||||
In order to configure mesh traffic redirection, Istio includes [a chained CNI plugin](/docs/setup/additional-setup/cni/), which runs after all configured CNI interface plugins.
|
||||
|
||||
The CNI plugin is optional for {{< gloss >}}sidecar{{< /gloss >}} mode and required for {{< gloss >}}ambient{{< /gloss >}} mode.
|
||||
|
|
@ -306,12 +306,6 @@ spec:
|
|||
|
||||
## Mesh Traffic
|
||||
|
||||
{{< warning >}}
|
||||
Configuring internal mesh traffic using the Gateway API is an
|
||||
[experimental feature](https://gateway-api.sigs.k8s.io/geps/overview/#status)
|
||||
currently under development.
|
||||
{{< /warning >}}
|
||||
|
||||
The Gateway API can also be used to configure mesh traffic.
|
||||
This is done by configuring the `parentRef` to point to a service, instead of a gateway.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue