# Stage 4: the two managed node groups, created only once Cilium is installed and its DaemonSet
# is checked to schedule on the sandbox node (setup.sh's preflight-daemonset runs before this
# file is applied; the BTF gate runs after both nodes and their Cilium agents are Ready).
#
# setup.sh fills in the ${...} placeholders and writes the result to the repository's
# gitignored tmp/issue11/run/nodegroups.yaml, then runs:
#
#   eksctl create nodegroup -f tmp/issue11/run/nodegroups.yaml
#
# Each group's labels below are ALSO the labels its node registers with: setup.sh renders them,
# plus eks.amazonaws.com/nodegroup=<name> and, on the sandbox node,
# eks.amazonaws.com/nitro-sandbox=true (a prefix the EKS node group API refuses as a label),
# into kubelet's --node-labels in the launch template's bootstrap user data
# (scripts/cilium_ubuntu.py, node_labels). Both launch templates name an AMI, and Amazon EKS
# adds no user data to a launch template that names an AMI, so that bootstrap line is what
# joins each node to the cluster.
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: ${CLUSTER_NAME}
  region: ${AWS_REGION}
  tags:
    auto-delete: "no"
    Demo: setup-cilium-ubuntu

managedNodeGroups:
  # The ordinary Ubuntu 24.04 node: CoreDNS, the Cilium operator and the comparison workloads
  # this sample runs for contrast with the sandbox node. Its launch template (created by
  # setup.sh) carries the pinned public Ubuntu 24.04 EKS AMI (SYSTEM_AMI_ID), the instance type,
  # disk, tags and the bootstrap user data. It carries neither isolated-sandbox RuntimeClass
  # label, so no sandbox pod is ever scheduled here (validate_nodegroups_config refuses one).
  - name: system
    launchTemplate:
      id: ${SYSTEM_LAUNCH_TEMPLATE_ID}
      version: "1"
    desiredCapacity: 1
    minSize: 1
    maxSize: 1
    privateNetworking: true
    availabilityZones: ["${NODE_ZONE}"]
    iam:
      # The usual node policies MINUS AmazonEKS_CNI_Policy: no pod on this node, and no
      # process on it, can create ENIs with the node's own credentials. Only the Cilium
      # operator can, through its own Pod Identity role (pod-identity.yaml).
      attachPolicyARNs:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    tags:
      auto-delete: "no"
      Demo: setup-cilium-ubuntu

  # The dedicated, tainted Ubuntu Pod Isolation sandbox node: the AMI built and BTF-validated
  # by ../ubuntu-ami (issue #10), referenced only through the local SANDBOX_AMI_ID value, never
  # a published id. The taint keeps every ordinary pod off this node; only a pod that
  # tolerates sandbox.eks-nitro-sandbox.amazonaws.com/dedicated schedules here, as the sandbox
  # pod and the ordinary comparison pod this sample runs beside it both do.
  - name: sandbox
    launchTemplate:
      id: ${SANDBOX_LAUNCH_TEMPLATE_ID}
      version: "1"
    desiredCapacity: 1
    minSize: 1
    maxSize: 1
    privateNetworking: true
    availabilityZones: ["${NODE_ZONE}"]
    labels:
      sandbox.eks-nitro-sandbox.amazonaws.com/dedicated: "true"
      # One of the two labels the isolated-sandbox RuntimeClass schedules on (the GA node-build
      # bundle's UBUNTU.md, sections 4 and 5); a node without both runs no sandbox pod. The other,
      # eks.amazonaws.com/nitro-sandbox=true, cannot be listed here: the EKS node group API
      # refuses any label key containing eks.amazonaws.com/, so kubelet's --node-labels in the
      # user data sets it, as the bundle does for both.
      sandbox.preview/nitro: "true"
    taints:
      - key: sandbox.eks-nitro-sandbox.amazonaws.com/dedicated
        value: "true"
        effect: NoSchedule
    iam:
      attachPolicyARNs:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    tags:
      auto-delete: "no"
      Demo: setup-cilium-ubuntu