Let’s create a template configuration file for monte carlo pi application:
cat <<EoF > ~/environment/monte-carlo-pi-service.yml
---
apiVersion: v1
kind: Service
metadata:
name: monte-carlo-pi-service
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
selector:
app: monte-carlo-pi-service
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: monte-carlo-pi-service
labels:
app: monte-carlo-pi-service
spec:
replicas: 2
selector:
matchLabels:
app: monte-carlo-pi-service
template:
metadata:
labels:
app: monte-carlo-pi-service
spec:
containers:
- name: monte-carlo-pi-service
image: ruecarlo/monte-carlo-pi-service
resources:
requests:
memory: "512Mi"
cpu: "1024m"
limits:
memory: "512Mi"
cpu: "1024m"
securityContext:
privileged: false
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
ports:
- containerPort: 8080
EoF
This should create a monte-carlo-pi-service.yml template file that defines a Service and a Deployment. The configuration instructs the cluster to deploy two replicas of a pod with a single container, that sets up Resource request and limits to a fixed value 1vCPU and 512Mi of RAM. You can read more about the differences between Resource requests and limits here.
The deployment does not include any toleration or affinities. If deployed as is, it will be scheduled to the on-demand nodes that we created during the cluster creation phase!
There are a few best practices for managing multi-tenant dynamic clusters. One of those best practices is adding Admission Controllers such as the ResourceQuota and LimitRanger admission controllers, both supported by EKS
Before we deploy our application and start scaling it, there are two requirements that we should apply and implement in the configuration file:
intent: appsIn the next section we will explore how to implement this requirements.