Amazon EKS Storage - Part 3: Monitoring, Troubleshooting, Cost Optimization, and Security
このドキュメントは Amazon EKS storage series の第 3 部かつ最終部であり、storage monitoring、troubleshooting、cost optimization、および security を扱います。
Table of Contents
- Storage Monitoring
- Storage Troubleshooting
- Storage Cost Optimization
- Storage Security
- Storage Management Best Practices
Storage Monitoring
EKS cluster 内の storage resources を効果的に monitoring することは、performance issues を早期に検出し、capacity planning を確立するために重要です。
Monitoring with CloudWatch
AWS CloudWatch を使用して、EBS、EFS、および FSx for Lustre volumes の performance metrics を monitoring できます。
EBS Volume Metrics
主要な EBS metrics:
- VolumeReadBytes/VolumeWriteBytes: 読み取り/書き込み throughput
- VolumeReadOps/VolumeWriteOps: 読み取り/書き込み operations の数
- VolumeTotalReadTime/VolumeTotalWriteTime: 読み取り/書き込み latency
- VolumeQueueLength: 保留中の I/O requests の数
- BurstBalance: Burst credit balance (gp2 volumes)
CloudWatch dashboard の例:
aws cloudwatch get-dashboard --dashboard-name EBSVolumeMonitoringEFS File System Metrics
主要な EFS metrics:
- TotalIOBytes: 合計 I/O bytes
- DataReadIOBytes/DataWriteIOBytes: 読み取り/書き込み throughput
- ClientConnections: 接続中の clients の数
- PermittedThroughput: 許可された throughput
- BurstCreditBalance: Burst credit balance
FSx for Lustre Metrics
主要な FSx for Lustre metrics:
- DataReadBytes/DataWriteBytes: 読み取り/書き込み throughput
- DataReadOperations/DataWriteOperations: 読み取り/書き込み operations の数
- FreeDataStorageCapacity: 利用可能な storage capacity
- NetworkThroughputUtilization: Network throughput utilization
Monitoring with Prometheus and Grafana
Prometheus と Grafana を使用して、Kubernetes level で storage resources を monitoring できます。
- Prometheus と Grafana をインストールします。
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--create-namespace- storage 関連 metrics collection のために ServiceMonitor を設定します。
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: csi-metrics
namespace: monitoring
spec:
selector:
matchLabels:
app: ebs-csi-controller
endpoints:
- port: metrics
interval: 30s- Grafana dashboard を設定します。
以下の metrics を含む dashboard を Grafana で作成します。
- PVC usage と capacity
- Volume provisioning status
- CSI driver operation latency
- Volume mount/unmount operations
Custom Monitoring Solutions
特定の要件に合わせて custom monitoring solutions を実装できます。
- Volume usage monitoring pod:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: volume-usage-exporter
namespace: monitoring
spec:
selector:
matchLabels:
app: volume-usage-exporter
template:
metadata:
labels:
app: volume-usage-exporter
spec:
containers:
- name: exporter
image: quay.io/prometheus/node-exporter:v1.3.1
args:
- --path.procfs=/host/proc
- --path.sysfs=/host/sys
- --collector.filesystem
volumeMounts:
- name: proc
mountPath: /host/proc
readOnly: true
- name: sys
mountPath: /host/sys
readOnly: true
- name: root
mountPath: /host/root
readOnly: true
mountPropagation: HostToContainer
volumes:
- name: proc
hostPath:
path: /proc
- name: sys
hostPath:
path: /sys
- name: root
hostPath:
path: /- Alert rules configuration:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: storage-alerts
namespace: monitoring
spec:
groups:
- name: storage
rules:
- alert: VolumeUsageHigh
expr: kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes > 0.85
for: 10m
labels:
severity: warning
annotations:
summary: "Volume usage high ({{ $value | humanizePercentage }})"
description: "PVC {{ $labels.persistentvolumeclaim }} is using {{ $value | humanizePercentage }} of its capacity."
- alert: VolumeFullIn24Hours
expr: predict_linear(kubelet_volume_stats_used_bytes[6h], 24 * 3600) > kubelet_volume_stats_capacity_bytes
for: 10m
labels:
severity: warning
annotations:
summary: "Volume will fill in 24 hours"
description: "PVC {{ $labels.persistentvolumeclaim }} is predicted to fill within 24 hours."Storage Troubleshooting
EKS clusters で発生する可能性がある一般的な storage issues とその solutions を見ていきましょう。
Volume Provisioning Issues
Issue: PVC Remains in Pending State
- PVC status を確認します。
kubectl get pvc
kubectl describe pvc <pvc-name>- storage class を確認します。
kubectl get sc
kubectl describe sc <storage-class-name>- provisioner pod logs を確認します。
kubectl -n kube-system get pods | grep csi
kubectl -n kube-system logs <csi-controller-pod-name>- 一般的な原因と solutions:
- Storage class が存在しない: 正しい storage class を作成します
- CSI driver がインストールされていない: driver をインストールします
- IAM permissions が不足している: 必要な IAM permissions を付与します
- Volume limit を超過している: service limit increase をリクエストします
Issue: Volume Not Provisioned with WaitForFirstConsumer Binding Mode
- pod status を確認します。
kubectl get pods
kubectl describe pod <pod-name>- node availability zones を確認します。
kubectl get nodes -L topology.kubernetes.io/zone- Solutions:
- pod scheduling issues を解決します
- node selector と affinity rules を確認します
- node pool が PVC と同じ availability zone にあることを確認します
Volume Mount Issues
Issue: Pod Stuck in ContainerCreating State
- pod events を確認します。
kubectl describe pod <pod-name>- node kubelet logs を確認します。
kubectl get nodes
ssh ec2-user@<node-ip>
sudo journalctl -u kubelet- 一般的な原因と solutions:
- Volume ID が見つからない: AWS console で volume の存在を確認します
- Device mount failure: device path と file system を確認します
- Permission issues: IAM roles と security groups を確認します
Issue: EFS or FSx Mount Failure
security groups を確認します。
- EFS: TCP port 2049 を許可します
- FSx for Lustre: TCP port 988 を許可します
network connectivity を確認します。
kubectl debug node/<node-name> -it --image=amazon/aws-cli
ping <efs-dns-name>
telnet <efs-dns-name> 2049- mount helper pod を作成します。
apiVersion: v1
kind: Pod
metadata:
name: mount-helper
spec:
containers:
- name: mount-helper
image: amazonlinux:2
command: ["sleep", "infinity"]
securityContext:
privileged: true- mount を手動で test します。
kubectl exec -it mount-helper -- bash
yum install -y nfs-utils
mkdir -p /mnt/efs
mount -t nfs4 <efs-dns-name>:/ /mnt/efsPerformance Issues
Issue: Slow I/O Performance
- volume performance metrics を確認します。
aws cloudwatch get-metric-statistics \
--namespace AWS/EBS \
--metric-name VolumeReadOps \
--dimensions Name=VolumeId,Value=vol-1234567890abcdef0 \
--start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 300 \
--statistics Average- file system performance を test します。
kubectl exec -it <pod-name> -- bash
dd if=/dev/zero of=/data/test bs=1M count=1000 oflag=direct
dd if=/data/test of=/dev/null bs=1M count=1000 iflag=direct- 一般的な原因と solutions:
- 不適切な volume type: workload に適した volume type を選択します (例: gp3、io2)
- IOPS または throughput limits: volume performance parameters を調整します
- Instance limitations: EBS-optimized instances を使用します
- File system fragmentation: file system を最適化または再作成します
Issue: EFS Performance Degradation
- EFS performance mode と throughput mode を確認します
- client mount options を最適化します。
mountOptions:
- nfsvers=4.1
- rsize=1048576
- wsize=1048576
- timeo=600
- retrans=2
- noresvport- access patterns を最適化します。
- 小さな files ではなく大きな files を使用します
- sequential access patterns を使用します
- metadata operations を最小化します
Storage Cost Optimization
EKS clusters で storage costs を最適化するための strategies を見ていきましょう。
Volume Type and Size Optimization
Select appropriate volume type:
- 一般的な workloads: gp3 (gp2 より cost-effective)
- Throughput-intensive workloads: st1
- アクセス頻度の低い data: sc1
Optimize volume size:
- 必要量より少し大きめに volumes を provision します
- volume usage を monitoring し、必要に応じて拡張します
- 不要な data を clean up または archive します
Migrate to gp3 volumes:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-gp3
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com
parameters:
type: gp3
encrypted: "true"
allowVolumeExpansion: trueStorage Lifecycle Management
Data tiering:
- 頻繁にアクセスされる data: EBS または EFS
- アクセス頻度の低い data: S3 または S3 Glacier
Automated snapshot policy:
- regular snapshots を作成します
- 古い snapshots を自動的に削除します
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: ebs-snapshot-class
driver: ebs.csi.aws.com
deletionPolicy: Delete- PV reclaim policy:
- 一時 data には Delete policy を使用します
- 重要な data には Retain policy を使用します
EFS Cost Optimization
Select appropriate throughput mode:
- 予測可能な workloads: Provisioned throughput
- 変動する workloads: Bursting mode
Lifecycle management:
- アクセス頻度の低い files を IA (Infrequent Access) storage class に自動的に移動します
- lifecycle policy を設定します。
aws efs put-lifecycle-configuration \
--file-system-id fs-1234567890abcdef0 \
--lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"}]'- Use access points:
- application-specific access points を使用して file system を共有します
FSx for Lustre Cost Optimization
Select appropriate deployment type:
- 一時的な workloads: SCRATCH_2
- 長期 workloads: PERSISTENT_1 または PERSISTENT_2
Enable data compression:
- storage costs を削減するために LZ4 data compression を使用します
Integration with S3:
- data tiering のために S3 bucket を FSx for Lustre に接続します
Cost Monitoring and Analysis
Use AWS Cost Explorer:
- storage cost trends を分析します
- resource ごとの costs を分析します
Kubernetes cost allocation:
- namespaces と labels を使用して costs を配賦します
- Kubecost などの tools を使用します
Cost anomaly detection:
- AWS budgets と alerts を設定します
- 異常な cost increases に対する alerts を設定します
Storage Security
EKS clusters 内の storage resources を保護するための security best practices を見ていきましょう。
Data Encryption
- Data at rest encryption:
- EBS volume encryption:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-encrypted
provisioner: ebs.csi.aws.com
parameters:
type: gp3
encrypted: "true"
kmsKeyId: arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab- EFS file system encryption:
aws efs create-file-system \
--encrypted \
--kms-key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab- FSx for Lustre encryption:
aws fsx create-file-system \
--file-system-type LUSTRE \
--storage-capacity 1200 \
--subnet-ids subnet-1234567890abcdef0 \
--lustre-configuration DeploymentType=SCRATCH_2 \
--security-group-ids sg-1234567890abcdef0 \
--kms-key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab- Data in transit encryption:
- EFS in-transit encryption:
mountOptions:
- tls- S3 in-transit encryption:
aws s3 cp --sse AES256 file.txt s3://my-bucket/Access Control
- IAM roles and policies:
- least privilege の原則を適用します
- service accounts には IAM roles を使用します
eksctl create iamserviceaccount \
--name ebs-csi-controller-sa \
--namespace kube-system \
--cluster my-cluster \
--attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--approve- Security groups:
- 必要な ports のみを許可します
- source IPs を制限します
aws ec2 authorize-security-group-ingress \
--group-id sg-1234567890abcdef0 \
--protocol tcp \
--port 2049 \
--source-group sg-0987654321fedcba0- Kubernetes RBAC:
- PVs と PVCs への access を制限します
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: app-namespace
name: pvc-manager
rules:
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pvc-manager-binding
namespace: app-namespace
subjects:
- kind: ServiceAccount
name: app-service-account
namespace: app-namespace
roleRef:
kind: Role
name: pvc-manager
apiGroup: rbac.authorization.k8s.ioPod Security Context
- Read-only root filesystem:
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
containers:
- name: app
image: nginx
securityContext:
readOnlyRootFilesystem: true
volumeMounts:
- name: data-volume
mountPath: /data
readOnly: false- Limited privileges:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
allowPrivilegeEscalation: false- SELinux, AppArmor, or seccomp profiles:
securityContext:
seLinuxOptions:
level: "s0:c123,c456"
seccompProfile:
type: RuntimeDefaultSecurity Policy Enforcement
- OPA Gatekeeper or Kyverno:
- encrypted volumes のみを許可します
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-ebs-encryption
spec:
validationFailureAction: enforce
rules:
- name: check-ebs-encryption
match:
resources:
kinds:
- PersistentVolumeClaim
validate:
message: "EBS volumes must be encrypted"
pattern:
spec:
storageClassName: "ebs-*"
+(storageClassName): "ebs-encrypted"- Pod Security Standards:
- Pod Security Standards を namespaces に適用します
apiVersion: v1
kind: Namespace
metadata:
name: secure-ns
labels:
pod-security.kubernetes.io/enforce: restrictedStorage Management Best Practices
EKS clusters で storage を効果的に管理するための best practices を見ていきましょう。
Storage Planning and Design
Requirements analysis:
- Performance requirements (IOPS、throughput)
- Capacity requirements
- Access patterns (read/write ratio、concurrency)
- Availability と durability requirements
Storage type selection:
- Block storage (EBS): Databases、stateful applications
- File storage (EFS): Shared files、web servers、CMS
- High-performance file storage (FSx for Lustre): HPC、ML training
- Object storage (S3): Backups、archives、static content
Capacity planning:
- 現在の requirements + growth margin
- auto-scaling mechanisms を実装します
- regular capacity reviews
Backup and Disaster Recovery
- Regular backups:
- volume snapshots を自動化します
- backup retention policies を定義します
# Create snapshot daily at midnight
0 0 * * * kubectl create -f snapshot.yamlDisaster recovery plan:
- Multi-AZ または cross-region replication
- Recovery Time Objective (RTO) と Recovery Point Objective (RPO) を定義します
- regular recovery testing
Cluster backup with Velero:
velero backup create daily-backup --include-namespaces=default,app-namespaceAutomation and IaC (Infrastructure as Code)
- Use Terraform or CloudFormation:
- storage resources の宣言的な定義
- Version control と change tracking
resource "aws_efs_file_system" "example" {
creation_token = "example"
performance_mode = "generalPurpose"
throughput_mode = "bursting"
encrypted = true
lifecycle_policy {
transition_to_ia = "AFTER_30_DAYS"
}
tags = {
Name = "ExampleFileSystem"
}
}- Use Helm charts:
- storage classes と PVCs を templatize します
# values.yaml
storage:
class: ebs-gp3
size: 10Gi
encrypted: true- GitOps workflow:
- ArgoCD または Flux で storage configuration を管理します
Performance and Cost Optimization
Regular performance review:
- bottlenecks を特定して解決します
- workloads の変化に応じて storage configuration を調整します
Cost optimization review:
- 使用されていない volumes を特定して削除します
- cost-effective な storage types に移行します
- Reserved Instances または Savings Plans を検討します
Auto scaling:
- demand に基づいて storage を自動的に scale します
- usage-based alerts を設定します
Conclusion
このドキュメントでは、Amazon EKS storage の monitoring、troubleshooting、cost optimization、および security について扱いました。効果的な storage management は、EKS cluster の performance、reliability、および cost-effectiveness を確保するために重要です。
Storage requirements は application によって異なるため、workload の特性を理解し、適切な storage solution を選択することが重要です。さらに、regular monitoring、troubleshooting、cost optimization、および security reviews を通じて storage resources を効果的に管理する必要があります。
References
- Amazon EKS Storage Best Practices
- Kubernetes Storage Troubleshooting
- AWS Storage Cost Optimization
- Kubernetes Storage Security
Quiz
この章で学んだ内容を確認するには、topic quiz に挑戦してください。