Operating EKS with AWS Q CLI

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  Summarize the configuration of the siyoung-eks  EKS cluster in ap-southeast-1 region

● use_aws
    ╰ label=Describe siyoung-eks EKS cluster, service_name=eks, operation_name=describe-cluster, region=ap-southeast-1
● use_aws
    ╰ label=List node groups for siyoung-eks, service_name=eks, operation_name=list-nodegroups, region=ap-southeast-1
    {
      "exit_status": "0",
      "stdout": "{\n    \"nodegroups\": []\n}\n",
    ...+2 lines (ctrl+o to toggle)

  Here's a summary of the siyoung-eks cluster configuration:

  General

  - Region: ap-southeast-1 (Singapore)
  - Kubernetes version: 1.35
  - Platform version: eks.13
  - Status: ACTIVE
  - Created: 2026-05-17
  - Tags: Environment=cloudneta-lab, Terraform=true

  Networking

  - VPC: vpc-0d9353d9b7c65bd4e
  - Subnets: 3 subnets across the VPC
  - Service CIDR: 172.20.0.0/16 (IPv4)
  - Endpoint access: Both public (0.0.0.0/0) and private enabled

  Compute (EKS Auto Mode)

  - Auto Mode: enabled with node pools general-purpose and system
  - No managed node groups (Auto Mode handles compute)
  - Block storage: enabled
  - Elastic Load Balancing: enabled
  - Control plane scaling tier: standard

  Security

  - Authentication: API_AND_CONFIG_MAP
  - Secrets encryption: KMS key d72ff1c2-2c99-434b-8ecb-f48fd72bc4c5
  - OIDC issuer configured
  - Deletion protection: disabled

  Logging

  - All control plane log types enabled: api, audit, authenticator, controllerManager, scheduler

  Support

  - Upgrade policy: EXTENDED support

▸ Credits: 0.21 • Time: 12s

  List all pods in the default namespace with their IP addresses along with the host names
  they are running on.                                                                  

● list_k8s_resources
    ╰ cluster_name=siyoung-eks, kind=Pod, api_version=v1, namespace=default
   NAME                                  READY   STATUS    RESTARTS   AGE     IP
    NODE                  NOMINATED NODE   READINESS GATES
    nginx-automode-test-6c9c6f495-9qx6f   1/1     Running   0          5h26m
    10.77.22.80   i-0c995e29805b4388f   <none>           <none>
    nginx-automode-test-6c9c6f495-gnrwr   1/1     Running   0          5h26m
    10.77.22.81   i-0c995e29805b4388f   <none>           <none>
    nginx-automode-test-6c9c6f495-zznd2   1/1     Running   0          5h26m
    10.77.22.82   i-0c995e29805b4388f   <none>           <none>


  Here are the pods in the default namespace:

  ┌─────────────────────────────────────┬─────────────┬─────────────────────┐
  │ Pod                                 │ IP          │ Node (Host)         │
  ├─────────────────────────────────────┼─────────────┼─────────────────────┤
  │ nginx-automode-test-6c9c6f495-9qx6f │ 10.77.22.80 │ i-0c995e29805b4388f │
  ├─────────────────────────────────────┼─────────────┼─────────────────────┤
  │ nginx-automode-test-6c9c6f495-gnrwr │ 10.77.22.81 │ i-0c995e29805b4388f │
  ├─────────────────────────────────────┼─────────────┼─────────────────────┤
  │ nginx-automode-test-6c9c6f495-zznd2 │ 10.77.22.82 │ i-0c995e29805b4388f │
  └─────────────────────────────────────┴─────────────┴─────────────────────┘

  All 3 pods are part of the nginx-automode-test deployment, all running on the same
  node (i-0c995e29805b4388f), and all in Running status.

I have a pod stuck in a pending state in my siyoung-eks cluster in ap-southeast-1.  
  Find the cause of the failure and provide me with a summary of the approach to solve
  it.                                                                                 

● list_k8s_resources
    ╰ cluster_name=siyoung-eks, kind=Pod, api_version=v1

  The suspect is failing-pod. It mounts a PVC called my-pvc. Let me check the pod events
  and the PVC status simultaneously.
● get_k8s_events
    ╰ cluster_name=siyoung-eks, kind=Pod, name=failing-pod, namespace=default
● list_k8s_resources
    ╰ cluster_name=siyoung-eks, kind=PersistentVolumeClaim, api_version=v1,
    namespace=default
    {
      "content": [
        {
    ...+24 lines (ctrl+o to toggle)

  Root cause is clear.

  ──────────────────────────────────────────────────────────────────────────────────────

  Root Cause

  failing-pod is stuck in Pending because it references a PersistentVolumeClaim named
  my-pvc that does not exist in the default namespace. The scheduler cannot place the
  pod until the PVC is present and bound.

  FailedScheduling: PersistentVolumeClaim "my-pvc" not found

    "text": "Successfully listed 0 PersistentVolumeClaim resources in default/all
    namespaces",
            "annotations": null,
            "_meta": null
          }
        ],
        "structuredContent": null,
        "isError": false,
        "kind": "PersistentVolumeClaim",
        "api_version": "v1",
        "namespace": "default",
        "count": 0,
        "items": []
      },
      "isError": false
    }

  Root cause is clear.

  ──────────────────────────────────────────────────────────────────────────────────────

  Root Cause

  failing-pod is stuck in Pending because it references a PersistentVolumeClaim named
  my-pvc that does not exist in the default namespace. The scheduler cannot place the
  pod until the PVC is present and bound.

  FailedScheduling: PersistentVolumeClaim "my-pvc" not found

  ──────────────────────────────────────────────────────────────────────────────────────

  How to fix it

  You need to create the missing PVC before the pod can be scheduled. The approach
  depends on your storage needs:

  1. Create the PVC — Define a PVC named my-pvc in the default namespace with an
  appropriate StorageClass and access mode. For EKS Auto Mode, the ebs.csi.aws.com
   provisioner with ReadWriteOnce is the typical choice:

  apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: my-pvc
    namespace: default
  spec:
    accessModes:
      - ReadWriteOnce
    storageClassName: gp2  # or your cluster's default StorageClass
    resources:
      requests:
        storage: 1Gi       # adjust to your needs

  2. Verify the StorageClass exists — Run kubectl get storageclass to confirm which
  StorageClasses are available in your cluster and pick the right one.
  3. Apply and wait for binding — Once the PVC is created, the dynamic provisioner will
  create the underlying EBS volume and bind the PVC. The scheduler will then place
  failing-pod automatically — no pod restart needed.

  Want me to create the PVC for you? If so, let me know the desired storage size and
  StorageClass (or I can check what's available in the cluster).

▸ Credits: 0.31 • Time: 24s

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  I have a pod called crashloop-pod in the default namespace         
  of siyoung-eks cluster in ap-southeast-1 that is failing to start. 
  Troubleshoot the issue and tell me how to fix it.                  

● get_k8s_events
    ╰ cluster_name=siyoung-eks, kind=Pod, name=crashloop-pod, namespace=default
● manage_k8s_resource
    ╰ operation=read, cluster_name=siyoung-eks, kind=Pod, api_version=v1

  Root cause: missing ConfigMap app-config

  The pod is stuck in CreateContainerConfigError — not actually crashing in a loop, but failing to start. The container uses envFrom
   to load all env vars from a ConfigMap named app-config, but that ConfigMap doesn't exist in the default namespace.

  Fix: Create the missing ConfigMap. Based on the pod's command (echo $DB_HOST), it expects at least a DB_HOST key. Create it with
  the appropriate value:

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: app-config
    namespace: default
  data:
    DB_HOST: <your-database-host>

  Apply it:

  kubectl apply -f app-config.yaml

  Once the ConfigMap exists, the kubelet will automatically retry and the pod will start — no pod restart needed. If you don't know
  the exact keys the app needs, start with DB_HOST (the only one referenced in the command) and add others as required.