Why is NodeGroupScalingConfigArgs.desired_size a r...
# general
s
Why is NodeGroupScalingConfigArgs.desired_size a required field in https://www.pulumi.com/registry/packages/aws/api-docs/eks/nodegroup/#desired_size_python? I’d like to be able to update the min/max node counts of a ManagedNodeGroup without pulumi ever trying to change the desired_size. Asking after my team suffered an outage due to this.
s
you can add
desired_size
to the
ignore_changes
field: https://www.pulumi.com/docs/intro/concepts/resources/options/ignorechanges/
AWS itself requires specifying a desired size when creating a node group so Pulumi needs to follow that
w
I believe ManagedNodeGroup is a Component Resource hence ignorechanges might not work with it
s
Hmm, thanks for following up, Sushant. I believe I indeed tried ignore_changes and it didn’t work (pulumi still applied changes to the desired count). Two resulting thoughts: 1. Should I look in the direction of applying the ignore_changes config to the underlying NodeGroup pulumi resource? Not sure if that makes sense - not sure if users can interact at all with the underlying resources inside a component resource or not. 2. How are people supposed to manage an autoscaling EKS cluster with pulumi? Maybe I’m doing something in a nonstandard way? The cluster-autoscaler takes over modifying desired_count outside of pulumi, and thus I need pulumi not to fight against that.
w
Hi Beni ! I ended up using the vanilla pulumi_aws package and then implementing the functionalities of pulumi_eks package.
2. How are people supposed to manage an autoscaling EKS cluster with pulumi? Maybe I’m doing something in a nonstandard way? The cluster-autoscaler takes over modifying desired_count outside of pulumi, and thus I need pulumi not to fight against that.
This was a major deal breaker for us as we had nodegroups which would start with desired as 0 but have workloads running on it later on. We also had a requirement where the aws auth ConfigMap was not being provisioned according to our requirements. Hence the re implementation.
1. Should I look in the direction of applying the ignore_changes config to the underlying NodeGroup pulumi resource? Not sure if that makes sense - not sure if users can interact at all with the underlying resources inside a component resource or not.
I have tried this using transformations and it ends up giving the same warning so it wont help.
🙌 1
s
Thanks for the response - with vanilla pulumi_aws how do you avoid pulumi from messing with post-autoscaling desired_size? Does ignore_changes work there?
w
avoid pulumi from messing with post-autoscaling desired_size
It does but you would need to hand roll functions such as • Creation of the IAM role for the EKS Cluster • aws auth config map • Installation of the VPC CNI addon • Generate the kubeconfig • Creation of a provider for any further k8s operations Eventually after all the above operations are done the nodegroup generation function would look something like this:
Copy code
eks_node_group = NodeGroup(
            node_group["name"],
            node_group_name=node_group["name"],
            cluster_name=self.eks_cluster.name,
            node_role_arn=self.eks_ec2_role.arn,
            subnet_ids=nodegroup_azs,
            capacity_type=capacity_type,
            taints=taints,
            labels=node_group.get("labels", None),
            instance_types=node_group["instance_types"],
            scaling_config=nodegroup_scaling_args,
            launch_template=launch_template_args,
            tags=tag_args,
            opts=ResourceOptions(
                ignore_changes=["scalingConfig"],
                depends_on=[self.aws_auth_configmap],
            ),
        )