feat(rolling-update): add hyperpod-patching subchart with RBAC for pod eviction

[divincode]

This PR introduces the hyperpod-patching Helm subchart that installs the required RBAC for SageMaker HyperPod rolling updates.
Specifically, it grants the hyperpod-service-linked-role permission to:

List pods

Evict pods via the pods/eviction subresource

These permissions are required to safely drain nodes during a rolling update without expanding the IAM permissions of the service-linked role beyond the cluster.

Testing details -

Created the eks cluster with -

https://github.com/aws-samples/awsome-distributed-training/blob/5c4f1ead0711050ea570f4791f70abee325f5a37/1.architectures/7.sagemaker-hyperpod-eks/cfn-templates/nested-stacks/main-stack.yaml

Replaced aws/sagemaker-hyperpod-cli with divincode/sagemaker-hyperpod-cli with my forked repo. And created a eks cluster .

vinaydev@bcd07465539f helm_chart % aws cloudformation deploy \                                   
  --template-file main-stack.yaml \      
  --stack-name main-stack \
  --capabilities CAPABILITY_NAMED_IAM

vinaydev@bcd07465539f helm_chart % aws eks update-kubeconfig \            
  --name sagemaker-hyperpod-eks-cluster \
  --region us-west-2

vinaydev@bcd07465539f helm_chart % kubectl get clusterrolebinding | grep patching
hyperpod-patching                                               ClusterRole/hyperpod-patching                                               11h
vinaydev@bcd07465539f helm_chart % kubectl describe clusterrole hyperpod-patching

Name:         hyperpod-patching
Labels:       app.kubernetes.io/managed-by=Helm
Annotations:  meta.helm.sh/release-name: hyperpod-dependencies
              meta.helm.sh/release-namespace: kube-system
PolicyRule:
  Resources      Non-Resource URLs  Resource Names  Verbs
  ---------      -----------------  --------------  -----
  pods/eviction  []                 []              [create]
  pods           []                 []              [list]

Ran the command -

vinaydev@bcd07465539f helm_chart % helm upgrade --install hyperpod-dependencies HyperPodHelmChart --namespace kube-system

Release "hyperpod-dependencies" has been upgraded. Happy Helming!
NAME: hyperpod-dependencies
LAST DEPLOYED: Fri May 16 09:18:12 2025
NAMESPACE: kube-system
STATUS: deployed
REVISION: 2
TEST SUITE: None

Re ran the commands -

vinaydev@bcd07465539f helm_chart % kubectl get clusterrolebinding | grep patching
hyperpod-patching                                               ClusterRole/hyperpod-patching                                               11h
vinaydev@bcd07465539f helm_chart % kubectl describe clusterrole hyperpod-patching
Name:         hyperpod-patching
Labels:       app.kubernetes.io/managed-by=Helm
Annotations:  meta.helm.sh/release-name: hyperpod-dependencies
              meta.helm.sh/release-namespace: kube-system
PolicyRule:
  Resources      Non-Resource URLs  Resource Names  Verbs
  ---------      -----------------  --------------  -----
  pods/eviction  []                 []              [create]
  pods           []                 []              [list]
vinaydev@bcd07465539f helm_chart % 

PR Approval Steps

For Requester

1. Description
   • [ .] Check the PR title and description for clarity. It should describe the changes made and the reason behind them.
   • [ . ] Ensure that the PR follows the contribution guidelines, if applicable.
2. Security requirements
   • [ . ] Ensure that a Pull Request (PR) does not expose passwords and other sensitive information by using git-secrets and upload relevant evidence: https://github.com/awslabs/git-secrets
   • Ensure commit has GitHub Commit Signature
3. Manual review
   1. Click on the Files changed tab to see the code changes. Review the changes thoroughly:
      • [ .] Code Quality: Check for coding standards, naming conventions, and readability.
      • [ . ] Functionality: Ensure that the changes meet the requirements and that all necessary code paths are tested.
      • [ . ] Security: Check for any security issues or vulnerabilities.
      • [ . ] Documentation: Confirm that any necessary documentation (code comments, README updates, etc.) has been updated.
4. Check for Merge Conflicts:
   • [. . ] Verify if there are any merge conflicts with the base branch. GitHub will usually highlight this. If there are conflicts, you should resolve them.

For Reviewer

1. Go through For Requester section to double check each item.
2. Request Changes or Approve the PR:
   1. If the PR is ready to be merged, click Review changes and select Approve.
   2. If changes are required, select Request changes and provide feedback. Be constructive and clear in your feedback.
3. Merging the PR
   1. Check the Merge Method:
      1. Decide on the appropriate merge method based on your repository's guidelines (e.g., Squash and merge, Rebase and merge, or Merge).
   2. Merge the PR:
      1. Click the Merge pull request button.
      2. Confirm the merge by clicking Confirm merge.

[sai-sankalp-reddy]

Code LGTM!