You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently outlined a proposal for the implementation of eksctl apply, this can be found here. This proposal has WIP status so changes may occur, but the general goal of being able to reconcile your cluster config will most likely remain the same. This discussion is about how we should start implementing apply.
Scope of work
eksctl has a quite a large amount of resources it's responsible for managing, as well as a large amount of customization of those resources. Here's an example config that utilises the majority of eksctl resources (note: there are a large amount of customizations not present here):
This config shows that there are a large amount of resources that we need to be able to reconcile. There are also some eksctl functionality that cannot be defined in the config file such as:
--install-vpc-controller when deploying a windows node
--install-neuron-plugin
--install-nvidia-plugin
A large amount of the config file also corresponds to immutable resources in AWS, for example the VPC configuration for the cluster cannot be changed without deleting the cluster and recreating, the same goes for a large amount of the nodegroup configuration too. The config file currently doesn’t really have a clear way of distinguishing this and doesn’t document what resources are immutable. We outlined in the proposal that recreation should be the default response to the change of immutable resources, so the implementation of apply needs to clearly show to the user what actions will occur, so that the user is aware of any deletions and recreations that will occur.
Breaking down the work
eksctl apply is a large piece of work that will take a while to implement, so we should try to break it down into achievable features. The proposal outlines adding apply has an experimental flag, so we can release functionality incrementally and document that the behaviour can/will change as we receive new feedback.
Vertical Slicing
We can start to tackle apply by working on adding support for each sub-resource:
Fargate Profiles
Addons
IAMServiceAccounts
OIDC Providers
Cloudwatch (currently updated via eksctil utils update-cluster-logging)
Cluster & nodegroup versions
Currently tracked via the top level metadata.Version
Managed Nodegroups
Nodegroups
We will most likely find as we tackle each resource that there are a number of desirable config file changes and additions that would improve the experience, we should open a new proposal/discussion for config file changes and document them as we go along. I think the most likely outcome is that a large amount of the apply functionality makes it into v0, with the "completion" of eksctl apply coming alongside a new config file layout in v1
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We recently outlined a proposal for the implementation of
eksctl apply
, this can be found here. This proposal hasWIP
status so changes may occur, but the general goal of being able to reconcile your cluster config will most likely remain the same. This discussion is about how we should start implementing apply.Scope of work
eksctl has a quite a large amount of resources it's responsible for managing, as well as a large amount of customization of those resources. Here's an example config that utilises the majority of eksctl resources (note: there are a large amount of customizations not present here):
This config shows that there are a large amount of resources that we need to be able to reconcile. There are also some eksctl functionality that cannot be defined in the config file such as:
--install-vpc-controller
when deploying a windows node--install-neuron-plugin
--install-nvidia-plugin
A large amount of the config file also corresponds to immutable resources in AWS, for example the VPC configuration for the cluster cannot be changed without deleting the cluster and recreating, the same goes for a large amount of the nodegroup configuration too. The config file currently doesn’t really have a clear way of distinguishing this and doesn’t document what resources are immutable. We outlined in the proposal that recreation should be the default response to the change of immutable resources, so the implementation of apply needs to clearly show to the user what actions will occur, so that the user is aware of any deletions and recreations that will occur.
Breaking down the work
eksctl apply is a large piece of work that will take a while to implement, so we should try to break it down into achievable features. The proposal outlines adding apply has an experimental flag, so we can release functionality incrementally and document that the behaviour can/will change as we receive new feedback.
Vertical Slicing
We can start to tackle apply by working on adding support for each sub-resource:
eksctil utils update-cluster-logging
)metadata.Version
We will most likely find as we tackle each resource that there are a number of desirable config file changes and additions that would improve the experience, we should open a new proposal/discussion for config file changes and document them as we go along. I think the most likely outcome is that a large amount of the apply functionality makes it into
v0
, with the "completion" of eksctl apply coming alongside a new config file layout inv1
Beta Was this translation helpful? Give feedback.
All reactions