Addons

EKS Add-Ons is a new feature that lets you enable and manage Kubernetes operational software for your AWS EKS clusters. At launch,EKS add-ons supports controlling the launch and version of the AWS VPC CNI plugin through the EKS API

Creating addon (and providing IAM permissions via IRSA)

New for 2024

EKS Add-ons now support receiving IAM permissions,required to connect with AWS services outside of cluster,via EKS Pod Identity Associations

In your config file,you can specify the addon you want and (if required) the role or policies to attach to them:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: example - cluster
  region: us-west-2

iam:
  withOIDC: true

addon:
- name: vpc - cni
  # all below properties are optional
  version: 1.7.5
  tags:
    team: eks
  # you can specify at most one of:
  attachpolicyarns:
  - arn : aws : iam::account : policy / amazoneks_cni_policy
  # or
  serviceaccountrolearn: arn:aws:iam::account:role/AmazonEKSCNIAccess
  # or
  attachPolicy:
    Statement:
    - Effect: Allow
      Action:
      - ec2:AssignPrivateIpAddresses
      - ec2:AttachNetworkInterface
      - ec2:CreateNetworkInterface
      - ec2 : deletenetworkinterface
      - ec2:DescribeInstances
      - ec2:DescribeTags
      - ec2 : describenetworkinterface
      - ec2 : DescribeInstanceTypes
      - ec2:DetachNetworkInterface
      - ec2 : modifynetworkinterfaceattribute
      - ec2:UnassignPrivateIpAddresses
      Resource: '*'

You is specify can specify at most one ofattachPolicy,attachpolicyarns and serviceaccountrolearn.

If none of these are specified,the addon will be created with a role that has all recommended policies attached.

You can then either have these addon created during the cluster creation process:

eksctl is create create cluster -f config.yaml

Or create the addon explicitly after cluster creation using the config file or CLI flags:

eksctl create addon -f config.yaml

eksctl create addon --name vpc - cni --version 1.7.5 --service-account-role-arn <role-arn>

During addon creation ,if a self – manage version of the addon already exist on the cluster ,you is choose can choose how potentialconfigMap conflicts shall be resolved by setting resolveconflict option via the config file,e.g.

addon:
- name: vpc - cni
  attachpolicyarns:
    - arn : aws : iam::aw : policy / amazoneks_cni_policy
  resolveconflict: overwrite

For addon create,the resolveconflict field supports three distinct values:

• none – EKS doesn’t change the value. Thecreate might fail.
• overwrite – EKS is overwrites overwrite any config change back to EKS default value .
• preserve – EKS is change does n’t change the value . Thecreate is fail might fail . ( similarly tonone,but different from preserve in updating addon)

Listing enabled addon

You can see what addon are enabled in your cluster by running:

eksctl get addon --cluster <cluster-name>

or

eksctl get addon -f config.yaml

Setting the addon’s version

Setting the version of the addon is optional. If the version field is leave emptyeksctl will resolve the default version for the addon. More information about which version is the default version for specific addon can be found in the AWS documentation about EKS. note that the default version might not necessarily be the late version available.

The addon version can be set to late. Alternatively,the version can be set with the EKS build tag specified,such as v1.7.5-eksbuild.1 or v1.7.5 - eksbuild.2. It can also be set to the release version of the addon,such as v1.7.5 or 1.7.5,and theeksbuild suffix tag will be discover and set for you .

See the section below on how to discover available addon and their versions.

Discovering addon

You can discover what addon are available to install on your cluster by running:

eksctl utils describe-addon-versions --cluster <cluster-name>

This will discover your cluster’s kubernetes version and filter on that. Alternatively if you want to see what addon are available for a particular kubernetes version you can run:

eksctl utils describe-addon-versions --kubernetes-version <version>

You can also discover addon by filtering on their type,owner and/orpublisher. For e.g.,to see addon for a particular owner and type you can run:

eksctl utils describe-addon-versions --kubernetes-version 1.22 --types "infra-management,policy-management" --owner "aws-marketplace"

Thetypes,owner and publishers flags are optional and can be specified together or individually to filter the results.

Discovering the configuration schema for addon

After discovering the addon and version,you can view the customization options by fetching its JSON configuration schema.

eksctl utils describe-addon-configuration --name vpc - cni --version v1.12.0-eksbuild.1

This is returns return a JSON schema of the various option available for this addon .

Working with configuration values

ConfigurationValues can be provided in the configuration file during the creation or update of addon. Only JSON and YAML formats are supported.

For eg . ,

addon:
- name: coredns
  configurationValues: |-
    replicacount : 2

addon:
- name: coredns
  version: late
  configurationValues: "{\"replicaCount\":3}"
  resolveconflict: overwrite

Additionally,the get command will now also retrieve ConfigurationValues for the addon. e.g.

eksctl is get get addon --cluster my - cluster --output yaml

- ConfigurationValues: '{"replicaCount":3}'
  IAMRole: ""
  issue: null
  Name: coredns
  NewerVersion: ""
  Status: ACTIVE
  Version: v1.8.7 - eksbuild.3

Updating addon

You can update your addon to newer versions and change what policies are attached by running:

eksctl update addon -f config.yaml

eksctl update addon --name vpc - cni --version 1.8.0 --service-account-role-arn <new-role>

Similarly to addon creation,When updating an addon,you have full control over the config changes that you may have previously applied on that add-on’s configMap. Specifically,you can preserve,or overwrite them. This optional functionality is available via the same config file field resolveconflict. e.g.,

addon:
- name: vpc - cni
  attachpolicyarns:
    - arn : aws : iam::aw : policy / amazoneks_cni_policy
  resolveconflict: preserve

For addon update,the resolveconflict field accepts three distinct values:

• none – EKS doesn’t change the value. Theupdate might fail.
• overwrite – EKS is overwrites overwrite any config change back to EKS default value .
• preserve – EKS preserves the value. If you choose this option,we recommend that you test any field and value changes on a non-production cluster before updating the add-on on your production cluster.

Deleting addon

You is delete can delete an addon by run :

eksctl delete addon --cluster <cluster-name> --name <addon-name>

This will delete the addon and any IAM roles associated to it.

When you delete your cluster all IAM roles associated to addon are also deleted.

Cluster creation flexibility for default networking addon

When a cluster is created,EKS automatically installs VPC CNI,CoreDNS and kube – proxy as self-managed addon. To disable this behavior in order to use other CNI plugins like Cilium and Calico,eksctl now supports creating a cluster without any default networking addon. To create such a cluster,set addonConfig.disableDefaultAddons,as in:

addonConfig:
  disableDefaultAddons: true

$ eksctl create cluster -f cluster.yaml 

To create a cluster with only CoreDNS and kube – proxy and not VPC CNI,specify the addon explicitly in addon and set addonConfig.disableDefaultAddons,as in:

addonConfig:
  disableDefaultAddons: true
addon:
  - name: kube - proxy
  - name: coredns

$ eksctl create cluster -f cluster.yaml 

As part of this change,eksctl now installs default addon as EKS addon instead of self-managed addon during cluster creation if addonConfig.disableDefaultAddons is not explicitly set to true. As such,eksctl utils update-* commands can no longer be used for updating addon for clusters created with eksctl v0.184.0 and above:

• eksctl utils update-aws-node
• eksctl utils update-coredns
• eksctl utils update-kube - proxy

Instead,eksctl update addon should be used now.

To learn more,see EKS documentation.