Consistency edits.

Author: pgasca

latest/ug/automode/create-storage-class.adoc

@@ -1,15 +1,15 @@
 [.topic]
 [#create-storage-class]
-= Create a Storage Class
-:info_titleabbrev: Create storage class
+= Create a storage class
+:info_titleabbrev: Create StorageClass
 
 include::../attributes.txt[]
 
-A StorageClass in Amazon EKS Auto Mode defines how Amazon EBS volumes are automatically provisioned when applications request persistent storage. This page explains how to create and configure a StorageClass that works with the Amazon EKS Auto Mode to provision EBS volumes.
+A `StorageClass` in Amazon EKS Auto Mode defines how Amazon EBS volumes are automatically provisioned when applications request persistent storage. This page explains how to create and configure a `StorageClass` that works with the Amazon EKS Auto Mode to provision EBS volumes.
 
-By configuring a StorageClass, you can specify default settings for your EBS volumes including volume type, encryption, IOPS, and other storage parameters. You can also configure the StorageClass to use {aws} KMS keys for encryption management.
+By configuring a `StorageClass`, you can specify default settings for your EBS volumes including volume type, encryption, IOPS, and other storage parameters. You can also configure the `StorageClass` to use {aws} KMS keys for encryption management.
 
-EKS Auto Mode does not create a StorageClass for you. You must create a StorageClass referencing `ebs.csi.eks.amazonaws.com` to use the storage capability of EKS Auto Mode.
+EKS Auto Mode does not create a `StorageClass` for you. You must create a `StorageClass` referencing `ebs.csi.eks.amazonaws.com` to use the storage capability of EKS Auto Mode.
 
 First, create a file named `storage-class.yaml`:
 
@@ -40,7 +40,7 @@ kubectl apply -f storage-class.yaml
 - `provisioner: ebs.csi.eks.amazonaws.com` - Uses EKS Auto Mode
 - `volumeBindingMode: WaitForFirstConsumer` - Delays volume creation until a pod needs it
 - `type: gp3` - Specifies the EBS volume type
-- `encrypted: "true"` - EBS will encrypt any volumes created using the StorageClass. EBS will use the default `aws/ebs` key alias. For more information, see link:ebs/latest/userguide/how-ebs-encryption-works.html["How Amazon EBS encryption works",type="documentation"] in the Amazon EBS User Guide. This value is optional but suggested. 
+- `encrypted: "true"` - EBS will encrypt any volumes created using the `StorageClass`. EBS will use the default `aws/ebs` key alias. For more information, see link:ebs/latest/userguide/how-ebs-encryption-works.html["How Amazon EBS encryption works",type="documentation"] in the Amazon EBS User Guide. This value is optional but suggested. 
 - `storageclass.kubernetes.io/is-default-class: "true"` - Kubernetes will use this storage class by default, unless you specify a different volume class on a persistent volume claim. This value is optional. Use caution when setting this value if you are migrating from a different storage controller. 
 
 == Use self-managed KMS key to encrypt EBS volumes
@@ -60,8 +60,8 @@ link:IAM/latest/UserGuide/access_policies_job-functions_create-policies.html["Cr
 
 Update the following values in the policy below:
 
-* `<account-id>` -- Your {aws} account ID, such as `111122223333`
-* `<aws-region>` -- The {aws} region of your cluster, such as `us-west-2`
+* `<account-id>` – Your {aws} account ID, such as `111122223333`
+* `<aws-region>` – The {aws} region of your cluster, such as `us-west-2`
 
 [source,json]
 ----
@@ -104,7 +104,7 @@ Update the following values in the policy below:
 }
 ----
 
-=== Sample self-managed KMS StorageClass
+=== Sample self-managed KMS `StorageClass`
 
 [source,yaml]
 ----
@@ -115,7 +115,7 @@ parameters:
 ----
 
 
-== StorageClass Parameters Reference
+== `StorageClass` Parameters Reference
 
 For general information on the Kubernetes `StorageClass` resources, see https://kubernetes.io/docs/concepts/storage/storage-classes/[Storage Classes] in the Kubernetes Documentation.
 
@@ -124,67 +124,87 @@ THe `parameters` section of the `StorageClass` resource is specific to {aws}. Us
 [role="no-scroll"]
 [cols="4*", options="header"]
 |===
-|Parameters |Values |Default |Description
+
+|Parameters
+|Values
+|Default
+|Description
+
 |"csi.storage.k8s.io/fstype"
 |xfs, ext2, ext3, ext4
 |ext4
 |File system type that will be formatted during volume creation. This parameter is case sensitive!
+
 |"type"
 |io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1
 |gp3
 |EBS volume type.
+
 |"iopsPerGB"
 |
 |
 |I/O operations per second per GiB. Can be specified for IO1, IO2, and GP3 volumes.
+
 |"allowAutoIOPSPerGBIncrease"
 |true, false
 |false
 |When `"true"`, the CSI driver increases IOPS for a volume when `iopsPerGB * <volume size>` is too low to fit into IOPS range supported by {aws}. This allows dynamic provisioning to always succeed, even when user specifies too small PVC capacity or `iopsPerGB` value. On the other hand, it may introduce additional costs, as such volumes have higher IOPS than requested in `iopsPerGB`.
+
 |"iops"
 |
 |
 |I/O operations per second. Can be specified for IO1, IO2, and GP3 volumes.
+
 |"throughput"
 |
 |125
 |Throughput in MiB/s. Only effective when gp3 volume type is specified. 
+
 |"encrypted"
 |true, false
 |false
 |Whether the volume should be encrypted or not. Valid values are "true" or "false".
+
 |"blockExpress"
 |true, false
 |false
 |Enables the creation of io2 Block Express volumes.
+
 |"kmsKeyId"
 |
 |
 |The full ARN of the key to use when encrypting the volume. If not specified, {aws} will use the default KMS key for the region the volume is in. This will be an auto-generated key called `/aws/ebs` if not changed.
+
 |"blockSize"
 |
 |
 |The block size to use when formatting the underlying filesystem. Only supported on linux nodes and with fstype `ext2`, `ext3`, `ext4`, or `xfs`.
+
 |"inodeSize"
 |
 |
 |The inode size to use when formatting the underlying filesystem. Only supported on linux nodes and with fstype `ext2`, `ext3`, `ext4`, or `xfs`.
+
 |"bytesPerInode"
 |
 |
 |The `bytes-per-inode` to use when formatting the underlying filesystem. Only supported on linux nodes and with fstype `ext2`, `ext3`, `ext4`.
+
 |"numberOfInodes"
 |
 |
 |The `number-of-inodes` to use when formatting the underlying filesystem. Only supported on linux nodes and with fstype `ext2`, `ext3`, `ext4`.
+
 |"ext4BigAlloc"
 |true, false
 |false
 |Changes the `ext4` filesystem to use clustered block allocation by enabling the `bigalloc` formatting option. Warning: `bigalloc` may not be fully supported with your node's Linux kernel. 
+
 |"ext4ClusterSize"
 |
 |
 |The cluster size to use when formatting an `ext4` filesystem when the `bigalloc` feature is enabled. Note: The `ext4BigAlloc` parameter must be set to true. 
+
 |===
 
 For more information, see the https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md[{aws} EBS CSI Driver] on GitHub.
@@ -199,7 +219,7 @@ The block storage capability of EKS Auto Mode is different from the EBS CSI Driv
 ** You cannot use the node startup taint feature to prevent pod scheduling before storage capability readiness
 * Custom Tags on Dynamically Provisioned Volumes
 ** You cannot use the extra-tag CLI flag to configure custom tags on dynamically provisioned EBS volumes
-** You can use StorageClass Tagging to add custom tags. EKS Auto Mode will add tags to the associated {aws} resources. You will need to update the Cluster IAM Role for custom tags. For more information, see <<tag-prop>>.
+** You can use `StorageClass` tagging to add custom tags. EKS Auto Mode will add tags to the associated {aws} resources. You will need to update the Cluster IAM Role for custom tags. For more information, see <<tag-prop>>.
 * EBS Detailed Performance Metrics
 ** You cannot access Prometheus metrics for EBS detailed performance 
 

latest/ug/automode/migrate-auto.adoc

@@ -47,19 +47,19 @@ Use the following migration reference to configure Kubernetes Resources to be ow
 
 | Capability | Resource | Field | Self Managed | EKS Auto Mode
 
-| Block Storage | StorageClass | provisioner | kubernetes.io/aws-ebs | ebs.csi.eks.amazonaws.com
+| Block Storage | `StorageClass` | `provisioner` | `kubernetes.io/aws-ebs` | `ebs.csi.eks.amazonaws.com`
 
-| Load Balancing | Service | loadBalancerClass | service.k8s.aws/nlb | eks.amazonaws.com/nlb
+| Load Balancing | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb`
 
-| Load Balancing | IngressClass | controller | ingress.k8s.aws/alb | eks.amazonaws.com/alb
+| Load Balancing | `IngressClass` | controller | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb`
 
 
 
-|Load Balancing | IngressClassParams |apiversion |elbv2.k8s.aws/v1beta1 |eks.amazonaws.com/v1
+| Load Balancing | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1`
 
-|Load Balancing | TargetGroupBinding |apiversion |elbv2.k8s.aws/v1beta1 |eks.amazonaws.com/v1
+| Load Balancing | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1`
 
-| Compute | NodeClass | apiVersion | karpenter.sh/v1alpha5 | eks.amazonaws.com/v1
+| Compute | NodeClass | `apiVersion` | `karpenter.sh/v1alpha5` | `eks.amazonaws.com/v1`
 
 |===
 

latest/ug/automode/sample-storage-workload.adoc

@@ -32,9 +32,9 @@ aws eks update-kubeconfig --name "${CLUSTER_NAME}"
 
 ## Step 2: Create the storage class
 
-The StorageClass defines how EKS Auto Mode will provision EBS volumes.
+The `StorageClass` defines how EKS Auto Mode will provision EBS volumes.
 
-EKS Auto Mode does not create a StorageClass for you. You must create a StorageClass referencing `ebs.csi.eks.amazonaws.com` to use the storage capability of EKS Auto Mode.
+EKS Auto Mode does not create a `StorageClass` for you. You must create a `StorageClass` referencing `ebs.csi.eks.amazonaws.com` to use the storage capability of EKS Auto Mode.
 
 . Create a file named `storage-class.yaml`:
 +
@@ -52,7 +52,7 @@ parameters:
   type: gp3
   encrypted: "true"
 ----
-. Apply the StorageClass:
+. Apply the `StorageClass`:
 +
 [source,bash]
 ----
@@ -69,7 +69,7 @@ kubectl apply -f storage-class.yaml
 
 ## Step 3: Create the persistent volume claim
 
-The PVC requests storage from the StorageClass.
+The PVC requests storage from the `StorageClass`.
 
 . Create a file named `pvc.yaml`:
 +
@@ -98,7 +98,7 @@ kubectl apply -f pvc.yaml
 
 - `accessModes: ReadWriteOnce` - Volume can be mounted by one node at a time
 - `storage: 8Gi` - Requests an 8 GiB volume
-- `storageClassName: auto-ebs-sc` - References the StorageClass we created
+- `storageClassName: auto-ebs-sc` - References the `StorageClass` we created
 
 ## Step 4: Deploy the Application
 
@@ -200,7 +200,7 @@ kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-
 
 ## What's Happening Behind the Scenes
 
-. The PVC requests storage from the StorageClass
+. The PVC requests storage from the `StorageClass`
 . When the Pod is scheduled:
 .. EKS Auto Mode provisions an EBS volume
 .. Creates a PersistentVolume

latest/ug/quickstart.adoc

@@ -182,7 +182,7 @@ parameters:
   type: gp3
   encrypted: "true"
 ----
-. Apply the StorageClass:
+. Apply the `StorageClass`:
 +
 [source,bash]
 ----

latest/ug/security/iam-reference/security-iam-awsmanpol.adoc

@@ -369,7 +369,7 @@ View details about updates to {aws} managed policies for Amazon EKS since this s
 
 Added the ability for the EBS CSI Driver to modify tags on existing volumes. The EBS CSI Driver can modify tags of existing volumes via a parameters in Kubernetes VolumeAttributesClasses.
 
-Added the ability for the EBS CSI Driver to enable Fast Snapshot Restore (FSR) on EBS volumes. The EBS CSI Driver can enable FSR on new volumes via parameters in Kubernetes StorageClasses.
+Added the ability for the EBS CSI Driver to enable Fast Snapshot Restore (FSR) on EBS volumes. The EBS CSI Driver can enable FSR on new volumes via parameters in Kubernetes storage classes.
 |January 13, 2025
 
 |Added permissions to <<security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy>>.

latest/ug/storage/ebs-csi-migration-faq.adoc

@@ -118,7 +118,7 @@ Yes, but volume operations requiring the Amazon EBS CSI driver will fail after y
 The default `StorageClass` behavior remains unchanged. With each new cluster, Amazon EKS applies a `kubernetes.io/aws-ebs` based `StorageClass` named `gp2`. We don't plan to ever remove this `StorageClass` from newly created clusters. Separate from the cluster default `StorageClass`, if you create an `ebs.csi.aws.com` based `StorageClass` without specifying a volume type, the Amazon EBS CSI driver will default to using `gp3`.
 
 [#csi-migration-faq-existing-storageclasses]
-== Will Amazon EKS make any changes to `StorageClasses` already present in my existing cluster when I update my cluster to version `1.23`?
+== Will Amazon EKS make any changes to storage classes already present in my existing cluster when I update my cluster to version `1.23`?
 
 No.
 
@@ -136,7 +136,7 @@ The new https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/m
 [#csi-migration-faq-windows]
 == Is migration supported for Windows workloads?
 
-Yes. If you're installing the Amazon EBS CSI driver using the open source Helm chart, set `node.enableWindows` to `true`. This is set by default if installing the Amazon EBS CSI driver as an Amazon EKS add-on. When creating `StorageClasses`, set the `fsType` to a Windows file system, such as `ntfs`. Volume operations for Windows workloads are then migrated to the Amazon EBS CSI driver the same as they are for Linux workloads.
+Yes. If you're installing the Amazon EBS CSI driver using the open source Helm chart, set `node.enableWindows` to `true`. This is set by default if installing the Amazon EBS CSI driver as an Amazon EKS add-on. When creating storage classes, set the `fsType` to a Windows file system, such as `ntfs`. Volume operations for Windows workloads are then migrated to the Amazon EBS CSI driver the same as they are for Linux workloads.
 
 
 📝 https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23ebs-csi-migration-faq%5D&type=code[Edit this page on GitHub]

latest/ug/what-is/kubernetes-concepts.adoc

@@ -212,7 +212,7 @@ When you define a Pod, you assign a set of attributes to it. Those attributes mu
 
 
 
-* *Storage* -- When a running container is stopped and deleted, data storage in that container will disappear, unless you set up more permanent storage. [.noloc]`Kubernetes` supports many different storage types and abstracts them under the umbrella of https://kubernetes.io/docs/concepts/storage/volumes/[Volumes]. Storage types include https://kubernetes.io/docs/concepts/storage/volumes/#cephfs[CephFS], https://kubernetes.io/docs/concepts/storage/volumes/#nfs[NFS], https://kubernetes.io/docs/concepts/storage/volumes/#iscsi[iSCSI], and others. You can even use a https://kubernetes.io/docs/concepts/storage/volumes/#local[local block device] from the local computer. With one of those storage types available from your cluster, you can mount the storage volume to a selected mount point in your container's file system. A https://kubernetes.io/docs/concepts/storage/persistent-volumes/[Persistent Volume] is one that continues to exist after the Pod is deleted, while an https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/[Ephemeral Volume] is deleted when the Pod is deleted. If your cluster administrator created different https://kubernetes.io/docs/concepts/storage/storage-classes/[StorageClasses] for your cluster, you might have the option for choosing the attributes of the storage you use, such as whether the volume is deleted or reclaimed after use, whether it will expand if more space is needed, and even whether it meets certain performance requirements. 
+* *Storage* -- When a running container is stopped and deleted, data storage in that container will disappear, unless you set up more permanent storage. [.noloc]`Kubernetes` supports many different storage types and abstracts them under the umbrella of https://kubernetes.io/docs/concepts/storage/volumes/[Volumes]. Storage types include https://kubernetes.io/docs/concepts/storage/volumes/#cephfs[CephFS], https://kubernetes.io/docs/concepts/storage/volumes/#nfs[NFS], https://kubernetes.io/docs/concepts/storage/volumes/#iscsi[iSCSI], and others. You can even use a https://kubernetes.io/docs/concepts/storage/volumes/#local[local block device] from the local computer. With one of those storage types available from your cluster, you can mount the storage volume to a selected mount point in your container's file system. A https://kubernetes.io/docs/concepts/storage/persistent-volumes/[Persistent Volume] is one that continues to exist after the Pod is deleted, while an https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/[Ephemeral Volume] is deleted when the Pod is deleted. If your cluster administrator created different https://kubernetes.io/docs/concepts/storage/storage-classes/[storage classes] for your cluster, you might have the option for choosing the attributes of the storage you use, such as whether the volume is deleted or reclaimed after use, whether it will expand if more space is needed, and even whether it meets certain performance requirements. 
 * *Secrets* -- By making https://kubernetes.io/docs/concepts/configuration/secret/[Secrets] available to containers in Pod specs, you can provide the permissions those containers need to access file systems, data bases, or other protected assets. Keys, passwords, and tokens are among the items that can be stored as secrets. Using secrets makes it so you don't have to store this information in container images, but need only make the secrets available to running containers. Similar to Secrets are https://kubernetes.io/docs/concepts/configuration/configmap/[ConfigMaps]. A `ConfigMap` tends to hold less critical information, such as key-value pairs for configuring a service. 
 * *Container resources* -- Objects for further configuring containers can take the form of resource configuration. For each container, you can request the amount of memory and CPU that it can use, as well as place limits of the total amount of those resources that the container can use. See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/[Resource Management for Pods and Containers] for examples. 
 * *Disruptions* -- Pods can be disrupted involuntarily (a node goes down) or voluntarily (an upgrade is desired). By configuring a https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets[Pod disruption budget], you can exert some control over how available your application remains when disruptions occur. See https://kubernetes.io/docs/tasks/run-application/configure-pdb/[Specifying a Disruption Budget] for your application for examples.