Skip to content

09-workload.md

Latest commit

 

History

History
92 lines (59 loc) · 5.34 KB

09-workload.md

File metadata and controls

92 lines (59 loc) · 5.34 KB
Raw

Deploy the workload (ASP.NET Core Docker web app)

The customer now has their prerequisite components, including the Gateway resource and TLS certificate sync. The last step in the process is to deploy the workload, which will demonstrate the system's functions.

Steps

📖 The Contoso workload team is about to conclude this journey, but they need an app to test their new infrastructure. For this task they've picked out the venerable ASP.NET Core Docker sample web app.

  1. Customize the host name of the HTTPRoute resource to match your custom domain. (You can skip this step if domain was left as contoso.com.)

    sed -i "s/contoso.com/${DOMAIN_NAME_AKS_BASELINE}/" workload/02-aspnetapp-httproute.yaml

    Note, that if you are on macOS, you might need to use the following command instead:

    sed -i '' 's/contoso.com/'"${DOMAIN_NAME_AKS_BASELINE}"'/g' workload/02-aspnetapp-httproute.yaml

  2. Deploy the ASP.NET Core Docker sample web app

    The workload definition demonstrates the inclusion of a Pod Disruption Budget rule, HTTPRoute configuration, and pod (anti-) affinity rules for your reference.

    kubectl apply -k workload/

  3. Wait until is ready to process requests running

    kubectl wait -n a0008 --for=condition=ready pod --selector=app.kubernetes.io/name=aspnetapp --timeout=90s

  4. Check your Gateway resource status as a way to confirm the AKS-managed Internal Load Balancer is functioning

    The gateway controller has reconciled the Gateway resource, provisioned an Envoy proxy, and created an internal load balancer on the configured subnet. Verify the Gateway is programmed and has an IP address assigned.

    kubectl wait gateway/bu0001a0008-gateway -n a0008 --for=condition=programmed --timeout=120s
kubectl get gateway bu0001a0008-gateway -n a0008

    At this point, the route to the workload is established, TLS termination is configured on the gateway proxy, and network policies are in place to only allow the Envoy proxy to connect to your workload and to only allow traffic from the Application Gateway subnet to reach the gateway proxy.

  5. Verify that DNS records have been created and reconciled.

    📖 The Application Routing add-on's operator deploys a managed external-dns instance that watches Gateway and HTTPRoute resources in the a0008 namespace and publishes A records to the attached private DNS zone automatically. The ExternalDNS custom resource was deployed via Flux GitOps during cluster bootstrapping as part of the cluster manifests. It authenticates to Azure DNS through the Microsoft Entra Workload Identity chain: a namespace-scoped ServiceAccount bound via federated identity credentials to a user-assigned managed identity with the DNS Zone Contributor role on the target private DNS zone.

    # Confirm the ExternalDNS custom resource was applied by Flux
kubectl get externaldns approuting-gateway-external-dns -n a0008

# Confirm the managed external-dns instance is running
kubectl get pods -l app=external-dns-private -n app-routing-system

# Confirm the A record was published to the private DNS zone
az network private-dns record-set a list -g rg-bu0001a0008 -z "aks-ingress.${DOMAIN_NAME_AKS_BASELINE}" --query "[].{arecords: aRecords[0].ipv4Address, fqdn: fqdn}"

  6. Check the HTTPRoute is accepted by the Gateway.

    kubectl get httproute aspnetapp-route -n a0008 -o jsonpath='{range .status.parents[*]}{.controllerName}{"\t"}{.conditions[*].type}={.conditions[*].status}{"\n"}{end}'

  7. Test direct workload access from unauthorized network locations. Optional.

    You should expect a timeout if you attempt to connect directly to the workload without going through the gateway proxy. The NetworkPolicy restricts ingress to the workload pods to only accept traffic from the Envoy gateway proxy. Likewise, a NetworkPolicy on the gateway proxy restricts its ingress to only the Application Gateway subnet and cluster nodes.

    kubectl run curl -n a0008 -i --tty --rm --image=mcr.microsoft.com/devcontainers/base --overrides='[{"op":"add","path":"/spec/containers/0/resources","value":{"limits":{"cpu":"200m","memory":"128Mi"}}},{"op":"add","path":"/spec/containers/0/securityContext","value":{"readOnlyRootFilesystem": true}}]' --override-type json --env="DOMAIN_NAME=${DOMAIN_NAME_AKS_BASELINE}"

# From within the open shell now running on a container inside your cluster
curl -kI https://bu0001a0008-00.aks-ingress.$DOMAIN_NAME -w '%{remote_ip}\n' --connect-timeout 5
exit

    From this container shell, you could also try to directly access the workload via:

    • curl -I http://aspnetapp-service --connect-timeout 5. This request should timeout since a network policy only allows the Envoy gateway proxy to reach your application.

  8. Because you've finished managing your cluster, close the Azure Bastion tunnel:

    exit

    You can re-open an Azure Bastion tunnel later when you require access to the AKS private cluster's API server.

Next step

▶️ End-to-End Validation