In the following lab we will set up our local development environment, provision the workshop cluster and roll out a static nginx page. Your deployment will be exposed by corresponding pod-service and wait for incoming traffic through our GCE Ingress-Controller (http://<external-lb-ip>).
The created LB will utilize Container Native Load Balancing to send traffic directly to the Pods.
- Run deployment
kubectl apply -f .- Check current ingress state (address)
this step can take up to 3 Minutes
kubectl get ingress -n doit-lab-06 --watch- Confirm that a Load Balancer was created on the cloud
gcloud compute forwarding-rules list --filter='description~doit-lab-06'- You can check the state of Pods at any time with the following kubectl command:
kubectl get pods -n doit-lab-06- You can check your ingress target service with the following kubectl command:
kubectl get service -n doit-lab-06- You can get some more detailed information about your ingress resource by the following kubectl command:
kubectl describe ingress static-web-app-ingress -n doit-lab-06- A couple of minutes after your ingress resource, ingress controller and the corresponding loadBalancer is provisioned (3-4 minutes):
4.1 You can check the benchmark of your web-application using apache-bench command as shown below:
ab -n 20 http://<external-ip-of-your-ingress-load-balancer>/4.2 You can simulate some traffic to your ingress facing loadBalancer by the following ab-command:
ab -n 500 -c 25 http://<external-ip-of-your-ingress-load-balancer>/4.3 Or just visit the application by hitting your load-balancers external-IP:
-> http://<external-ip-of-your-ingress-load-balancer>/Now we can set the current k8s context to our lab exercise namespace doit-lab-06 to make sure that every command set is run against this lab resources.
kubectl config set-context --current --namespace=doit-lab-06kubectl delete -f .