Kubernetes field management
Amazon EKS add-ons are installed to your cluster using standard, best practice configurations. For more information about adding an Amazon EKS add-on to your cluster, see Amazon EKS add-ons.
You may want to customize the configuration of an Amazon EKS add-on to enable advanced
features. Amazon EKS uses the Kubernetes server-side apply feature to enable management of an
add-on by Amazon EKS without overwriting your configuration for settings that aren't managed
by Amazon EKS. For more information, see Server-Side
Applykube-controller-manager
, without issue.
Modifying a field managed by Amazon EKS prevents Amazon EKS from managing the add-on and may result in your changes being overwritten when an add-on is updated.
View field management status
You can use kubectl
to see which fields are managed by Amazon EKS for any Amazon EKS
add-on.
To see the management status of a field
-
Determine which add-on that you want to examine. To see all of the
deployments
andDaemonSets
deployed to your cluster, see View Kubernetes resources. -
View the managed fields for an add-on by running the following command:
kubectl get
type
/add-on-name
-nadd-on-namespace
-o yamlFor example, you can see the managed fields for the CoreDNS add-on with the following command.
kubectl get deployment/coredns -n kube-system -o yaml
Field management is listed in the following section in the returned output.
... managedFields: - apiVersion: apps/v1 fieldsType: FieldsV1 fieldsV1: ...
Note If you don't see
managedFields
in the output, add
to the command and run it again. The version of--show-managed-fields
kubectl
that you're using determines whether managed fields are returned by default.
Understanding field management syntax in the Kubernetes API
When you view details for a Kubernetes object, both managed and unmanaged fields are returned in the output. Managed fields can be either of the following types:
-
Fully managed – All keys for the field are managed by Amazon EKS. Modifications to any value causes a conflict.
-
Partially managed – Some keys for the field are managed by Amazon EKS. Only modifications to the keys explicitly managed by Amazon EKS cause a conflict.
Both types of fields are tagged with manager: eks
.
Each key is either a .
representing the field itself, which always
maps to an empty set, or a string that represents a sub-field or item. The output
for field management consists of the following types of declarations:
-
f:
, wherename
is the name of a field in a list.name
-
k:
, wherekeys
is a map of a list item's fields.keys
-
v:
, wherevalue
is the exact JSON formatted value of a list item.value
-
i:
, whereindex
is position of an item in the list.index
For more information, see FieldsV1 v1 meta
The following portions of output for the CoreDNS add-on illustrate the previous declarations:
-
Fully managed fields – If a managed field has an
f:
(field) specified, but nok:
(key), then the entire field is managed. Modifications to any values in this field cause a conflict.In the following output, you can see that the container named
coredns
is managed byeks
. Theargs
,image
, andimagePullPolicy
sub-fields are also managed byeks
. Modifications to any values in these fields cause a conflict.... f:containers: k:{"name":"coredns"}: .: {} f:args: {} f:image: {} f:imagePullPolicy: {} ... manager: eks ...
-
Partially managed fields – If a managed key has a value specified, the declared keys are managed for that field. Modifying the specified keys cause a conflict.
In the following output, you can see that
eks
manages theconfig-volume
andtmp
volumes set with thename
key.... f:volumes: k:{"name":"config-volume"}: .: {} f:configMap: f:items: {} f:name: {} f:name: {} k:{"name":"tmp"}: .: {} f:name: {} ... manager: eks ...
-
Adding keys to partially managed fields – If only a specific key value is managed, you can safely add additional keys, such as arguments, to a field without causing a conflict. If you add additional keys, make sure that the field isn't managed first. Adding or modifying any value that is managed causes a conflict.
In the following output, you can see that both the
name
key andname
field are managed. Adding or modifying any container name causes a conflict with this managed key.... f:containers: k:{"name":"coredns"}: ... f:name: {} ... manager: eks ...