-
Notifications
You must be signed in to change notification settings - Fork 382
docs(blog): add internal load balancer example for approuting-istio Gateway API #5751
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.
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
base: master
Are you sure you want to change the base?
Changes from all commits
f634f33
225457a
dbe71ad
51ead14
da411c9
00a30d9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -178,6 +178,42 @@ curl -s -I -H "Host: httpbin.example.com" "http://$INGRESS_HOST/get" | |
|
|
||
| You should see an `HTTP 200` response. | ||
|
|
||
| ### Internal load balancer | ||
|
|
||
| By default, AKS assigns a public IP to the Gateway's underlying Service. To expose the existing `httpbin-gateway` on an internal (private) IP instead, add Azure load balancer annotations to the Gateway's `spec.infrastructure.annotations` field. You can also target a specific subnet for the internal IP address. | ||
|
|
||
|
rkasture marked this conversation as resolved.
|
||
| ```yaml | ||
| apiVersion: gateway.networking.k8s.io/v1 | ||
| kind: Gateway | ||
| metadata: | ||
| name: httpbin-gateway | ||
| spec: | ||
| gatewayClassName: approuting-istio | ||
| infrastructure: | ||
| annotations: | ||
| service.beta.kubernetes.io/azure-load-balancer-internal: "true" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this isn't exactlyyyy best practice, as it results in the annotations being propagated to ALL resources provisioned for the gateway, including the deployment, hpa, etc.. However, I'm realizing that this is also the approach advised by our documentation, so I'm fine with it. May just be worth adding a disclaimer though, and that if users want to apply the annotation ONLY to the LB, they can use the approach described here: https://learn.microsoft.com/en-us/azure/aks/istio-gateway-api#configmap-customizations |
||
| # Optional: place the internal LB on a dedicated subnet | ||
| service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "my-ilb-subnet" | ||
| listeners: | ||
| - name: http | ||
| port: 80 | ||
| protocol: HTTP | ||
| allowedRoutes: | ||
| namespaces: | ||
| from: Same | ||
| ``` | ||
|
|
||
| AKS propagates these annotations onto the Kubernetes Service it creates for the Gateway. After the Gateway is programmed, its `status.addresses` will contain a private IP from the specified subnet (or the cluster's default subnet if the subnet annotation is omitted): | ||
|
|
||
| ```bash | ||
| kubectl wait --for=condition=programmed gateways.gateway.networking.k8s.io httpbin-gateway --timeout=120s | ||
| kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -ojsonpath='{.status.addresses[0].value}' | ||
| ``` | ||
|
|
||
| > **Note**: The subnet must exist in the cluster's virtual network and must be delegated or available for Azure Load Balancer use. See [Use an internal load balancer with AKS](https://learn.microsoft.com/azure/aks/internal-lb) for networking prerequisites. | ||
|
|
||
| Any Azure Load Balancer annotation supported by AKS can be used in `spec.infrastructure.annotations`. For the full list of supported annotations, see the [Azure Load Balancer annotations reference](https://learn.microsoft.com/azure/aks/load-balancer-standard#additional-customizations-via-kubernetes-annotations). | ||
|
rkasture marked this conversation as resolved.
|
||
|
|
||
| ### Upgrades | ||
|
|
||
| The Istio control plane version is tied to your AKS cluster's Kubernetes version — AKS automatically reconciles the latest supported Istio revision that is compatible with your cluster's Kubernetes version. Patch version upgrades happen automatically as part of AKS releases. Minor version upgrades happen in-place when you upgrade your cluster's Kubernetes version, or automatically when a new Istio minor version is released for your AKS version. To see which Istio revision your cluster will receive, consult the [service mesh add-on release calendar](https://learn.microsoft.com/azure/aks/istio-support-policy#service-mesh-add-on-release-calendar). You can also follow the [AKS release notes](https://github.com/azure/aks/releases) to stay current. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.