Creating Deployment Configurations for EKS with Amazon Q

Welcome to another installment of Q-Bits, our regular series showcasing cool ways Amazon employees are leveraging Amazon Q Developer. Today, we're exploring how Q Developer can assist with creating and optimizing EKS deployment configurations.

Amazon Q Developer streamlines EKS deployment workflows by providing intelligent assistance for Kubernetes configurations and best practices.

A Production Deployment Challenge

During my first project migrations to EKS, I needed to create deployment configurations for multiple microservices. With numerous configuration options and best practices to consider, so I had to read a huge number of wikis and api documents to understand and follow the best practices. I need to confess that it took a precious time to understand and write the files. Since 2024, Amazon Q Developer became my assistant for generating and validating deployment manifests, and I would like to share with you what I've learned and how to use Q Developer to create your Kubernetes deployment manifests.

Crafting Deployments with Q Developer

I will start by creating a basic deployment template. Instead of searching through documentation, I simply opened a new YAML file and asked Q Developer to help generate a sample deployment configuration.

Here is my prompt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
I need help creating a Kubernetes manifest for deploying my application. Here are the details:

1. Application requirements:
- Web application running on Node.js
- Container image: my-app:latest from ECR
- Application runs on port 3000
- Needs DATABASE_URL environment variable

2. Deployment requirements:
- 3 replicas for high availability
- Resource limits: 512Mi memory, 500m CPU
- No persistent storage needed
- Need liveness and readiness probes

3. Networking requirements:
- Application should be accessible from internet
- Need LoadBalancer service type
- Expose port 80 externally, mapping to port 3000 internally

Please provide a Kubernetes manifest that includes necessary Deployment and Service configurations.

Amazon Q Developer promptly suggested a production-ready template:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest
        ports:
        - containerPort: 3000
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: database-url
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"
          requests:
            memory: "256Mi"
            cpu: "250m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000

Amazon Q Developer also explained me the key components making sure I have understanding about what I'm creating in my cluster.

Image not found

Key Components Explanation

Optimizing for Production

To ensure our deployment was production-ready, I highlighted the entire file and used "Amazon Q > Fix". Q Developer suggested several improvements:

1. Added comments to the main changes containing explanation about how to use the manifest

2. Added full ECR repository URL pattern

3. Implemented the imagePullPolicy

4. Improved probe configurations

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        # Specify full ECR repository URL
        image: <your-account>.dkr.ecr.<region>.amazonaws.com/my-app:latest
        imagePullPolicy: Always  # Added to ensure latest image is pulled
        ports:
        - containerPort: 3000
          name: http  # Named port for better readability
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: database-url
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"
          requests:
            memory: "256Mi"
            cpu: "250m"
        livenessProbe:
          httpGet:
            path: /health
            port: http  # Using named port
          initialDelaySeconds: 15
          periodSeconds: 10
          timeoutSeconds: 5      # Added timeout
          failureThreshold: 3    # Added failure threshold
        readinessProbe:
          httpGet:
            path: /health
            port: http  # Using named port
          initialDelaySeconds: 5
          periodSeconds: 10
          timeoutSeconds: 3      # Added timeout
          failureThreshold: 3    # Added failure threshold
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
  labels:
    app: my-app    # Added consistent labeling
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: http  # Using named port
    name: http       # Named port for better readability

As an improvement I can also request for Amazon Q Developer to implement a pod anti-affinity rule.

Image not found

Anti-Affinity Rule

1
2
3
4
5
6
7
8
9
10
affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - my-app
              topologyKey: "kubernetes.io/hostname"

Troubleshooting Common Issues

Q Developer also helped identify potential issues before they occurred in production, such as:

Resource quota configurations
Network policy requirements
Service account permissions
Image pull policies

Improving an existing deployment

Q Developer will help to fix, improve, and adapt existing manifests. You can request Q Developer to:

Change the image to a new version
Add storage for stateful applications
Improve replicas distribution around the EKS cluster
Understand the current configuration

Conclusion

Amazon Q Developer has transformed the way I create and manage EKS deployments. It provides intelligent suggestions, validates configurations, and helps maintain best practices across our Kubernetes infrastructure. Whether you're new to EKS or an experienced DevOps engineer, Q Developer serves as an invaluable assistant in your deployment workflow.

Stay tuned for more Q-Bits, where we'll continue to explore how Amazon Q Developer is revolutionizing our development processes.

Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.

Select your cookie preferences

Site Terms, Privacy, and more.