## demo_010o: Deploying a TiDB Cluster Using TiDB Operator on AWS EKS

This lab demonstrates how to deploy TiDB on **AWS EKS (Elastic Kubernetes Service)** using TiDB Operator, instead of TiUP on EC2 (demo_010) or k3s.

### Architecture

- **EKS Cluster**: Created by CloudFormation with a managed node group (2+ worker nodes)
- **Bastion Host**: Single Ubuntu EC2 instance with kubectl, Helm, and AWS CLI; connects to EKS via `aws eks update-kubeconfig`
- **TiDB**: Deployed as pods on EKS worker nodes; exposed via internal Network Load Balancer (NLB)
- **Connection**: Bastion connects to TiDB at `${TIDB_HOST}:4000` (internal NLB hostname)

### Prerequisites for Lab Platform

The setup content must be in the `tidb-course-labs` repository at:
`tidb-course-labs/labs/demo_010o/`

Contents:

- `install-operator-env.sh` - Installs kubectl, Helm, AWS CLI (no k3s)
- `solution-tidb-cluster.yaml` - TidbCluster CR with LoadBalancer service for EKS

### IAM: Role That Runs Stack Creation (e.g. lab-control-service-role)

The identity that creates/updates the CloudFormation stack (e.g. `lab-control-service-role`) must have:

1. **iam:PassRole** on the IAM roles that this stack creates (EKS cluster role, node group role, EBS CSI driver role). The template does **not** set explicit role names, so CloudFormation assigns auto-generated names; you do **not** need `CAPABILITY_NAMED_IAM` to create the stack. Grant PassRole in line with your security policy (e.g. scope by resource or use a condition such as `iam:PassedToService` for `eks.amazonaws.com`, `ec2.amazonaws.com`, `pods.eks.amazonaws.com`).

2. **EKS and EKS addon actions**. The stack creates the cluster and two addons (`eks-pod-identity-agent`, `aws-ebs-csi-driver`). The stack creator must be allowed to create and describe addons, for example:
   - `eks:CreateCluster`, `eks:DescribeCluster`, `eks:DeleteCluster`, …
   - **`eks:CreateAddon`**, **`eks:DescribeAddon`**, **`eks:UpdateAddon`**, **`eks:DeleteAddon`** (required for PodIdentityAgentAddon and EBSCSIAddon; without these you get 403 on addon creation).

   If your policy uses `"Action": "eks:*"` with `"Resource": "*"`, addons are already covered. If you scope by resource, include addon resources, e.g.:
   `arn:aws:eks:region:ACCOUNT_ID:cluster/ao-pingcap-com-demo-010o-*` and addon sub-resources as needed.

3. **Other actions** used by the template (EC2, autoscaling, IAM role creation, etc.). Example broad set:

   ```json
   {
     "Effect": "Allow",
     "Action": [
       "eks:*",
       "ec2:*",
       "autoscaling:*",
       "iam:CreateRole",
       "iam:AttachRolePolicy",
       "iam:PutRolePolicy",
       "iam:GetRole",
       "iam:PassRole"
     ],
     "Resource": "*"
   }
   ```

   (Tighten `Resource` to your stack-owned resources when possible.)

### Bastion IAM Requirements

The bastion uses `course-303-node-role`. For EKS access, this role needs:

- `eks:DescribeCluster` - to run `aws eks update-kubeconfig`

### CloudFormation

The stack creates:

- VPC, subnets, security groups
- EKS cluster (tidb-demo-eks)
- EKS managed node group (2 nodes, c5.large)
- EBS CSI driver addon (for PersistentVolumes)
- Bastion EC2 (depends on EKS being ready)

### Lab Structure

- Module 0: Overview
- Module 1: Connect to AWS EKS and familiarize with environment
- Module 2: Deploy TiDB cluster on EKS using TiDB Operator
- Module 3: Check cluster status
- Module 4: Connect to TiDB via LoadBalancer
- Module 5: Review TidbCluster configuration
- Module 6: Conclusion