Skip to content

Latest commit

 

History

History
62 lines (39 loc) · 3.63 KB

09-workload.md

File metadata and controls

62 lines (39 loc) · 3.63 KB
Raw

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

The cluster now has an Traefik configured with a TLS certificate. The last step in the process is to deploy the workload, which will demonstrate the system's functions.

Steps

📖 The Contoso app 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 Ingress 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/aspnetapp-ingress-patch.yaml

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

    The workload definition demonstrates the inclusion of a Pod Disruption Budget rule, ingress 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 Ingress resource status as a way to confirm the AKS-managed Internal Load Balancer is functioning

    In this moment your Ingress Controller (Traefik) is reading your ingress resource object configuration, updating its status, and creating a router to fulfill the new exposed workloads route. Please take a look at this and notice that the address is set with the Internal Load Balancer IP from the configured subnet.

    kubectl get ingress aspnetapp-ingress -n a0008

    At this point, the route to the workload is established, SSL offloading configured, a network policy is in place to only allow Traefik to connect to your workload, and Traefik is configured to only accept requests from App Gateway.

  5. Test direct workload access from unauthorized network loactions. Optional.

    You should expect a 403 HTTP response from your ingress controller if you attempt to connect to it without going through the App Gateway. Likewise, if any workload other than the ingress controller attempts to reach the workload, the traffic will be denied via network policies.

    kubectl run curl -n a0008 -i --tty --rm --image=mcr.microsoft.com/azure-cli --limits='cpu=200m,memory=128Mi'

# From within the open shell now running on a container inside your cluster
DOMAIN_NAME="contoso.com" # <-- Change to your custom domain value if a different one was used
curl -kI https://bu0001a0008-00.aks-ingress.$DOMAIN_NAME -w '%{remote_ip}\n'
exit

    🪲 You might receive a message about --limits being deprecated, you can safely ignore that message if you are using kubectl 1.22. However, if you are running kubectl 1.23+, you will need to use the following command instead.

    kubectl run curl -n a0008 -i --tty --rm --image=mcr.microsoft.com/azure-cli --overrides='[{"op":"add","path":"/spec/containers/0/resources","value":{"limits":{"cpu":"200m","memory":"128Mi"}}}]' --override-type json

    From this container shell, you could also try to directly access the workload via curl -I http://<aspnetapp-service-cluster-ip>. Instead of getting back a 200 OK, you'll receive a network timeout because of the allow-only-ingress-to-workload network policy that is in place.

Next step

▶️ End-to-End Validation