Back in the SSH shell, run these commands to deploy the application:
cd ~/aws-modernization-dt-orders-setup/app-scripts
./start-k8.sh
The start-k8.sh script automates a number of kubectl
commands:
staging
where all these resources will residestaging
namespacedeployment
and service
Kubernetes objects for each of the sampleRerun this command until all the pods are in Running
status with all pods as 1/1
.
kubectl -n staging get pods
The output should look like this:
NAME READY STATUS RESTARTS AGE
browser-traffic-5b9456875d-ks9vw 1/1 Running 0 30h
catalog-7dcf64cc99-hfrpg 1/1 Running 0 2d8h
customer-8464884799-vljdx 1/1 Running 0 2d8h
frontend-7c466b9d69-9ql2g 1/1 Running 0 2d8h
load-traffic-6886649ddf-76pqf 1/1 Running 0 2d8h
order-6d4cd477cb-9bvn4 1/1 Running 0 2d8h
In Kubernetes, every pod is associated with a service account which is used to authenticate the pod’s requests to the Kubernetes API. If not otherwise specified the pod uses the default service account of its namespace.
Every namespace has its own set of service accounts and thus also its own namespace-scoped default service account. The labels of each pod for which the service account has view permissions will be imported into Dynatrace automatically.
In order for Dynatrace to read the Kubernetes properties and annotations, you need to grant the Kubernetes default service account a viewer role into the staging
namespace to enable this. We only have one namespace, but you will need to repeat these steps for all service accounts and namespaces you want to enable for Dynatrace within your environments.
For the workshop, we already updated the required file with the staging
namespace. Next you will run the setup script that will apply it to your cluster. Go ahead and open this folder and look at the dynatrace-oneagent-metadata-viewer.yaml
file.