Skip to content

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 ​

  1. Storage Monitoring
  2. Storage Troubleshooting
  3. Storage Cost Optimization
  4. Storage Security
  5. 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 の例:

bash
aws cloudwatch get-dashboard --dashboard-name EBSVolumeMonitoring

EFS 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 できます。

  1. Prometheus と Grafana をインストールします。
bash
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
  1. storage 関連 metrics collection のために ServiceMonitor を設定します。
yaml
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
  1. 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 を実装できます。

  1. Volume usage monitoring pod:
yaml
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: /
  1. Alert rules configuration:
yaml
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 ​

  1. PVC status を確認します。
bash
kubectl get pvc
kubectl describe pvc <pvc-name>
  1. storage class を確認します。
bash
kubectl get sc
kubectl describe sc <storage-class-name>
  1. provisioner pod logs を確認します。
bash
kubectl -n kube-system get pods | grep csi
kubectl -n kube-system logs <csi-controller-pod-name>
  1. 一般的な原因と 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 ​

  1. pod status を確認します。
bash
kubectl get pods
kubectl describe pod <pod-name>
  1. node availability zones を確認します。
bash
kubectl get nodes -L topology.kubernetes.io/zone
  1. Solutions:
    • pod scheduling issues を解決します
    • node selector と affinity rules を確認します
    • node pool が PVC と同じ availability zone にあることを確認します

Volume Mount Issues ​

Issue: Pod Stuck in ContainerCreating State ​

  1. pod events を確認します。
bash
kubectl describe pod <pod-name>
  1. node kubelet logs を確認します。
bash
kubectl get nodes
ssh ec2-user@<node-ip>
sudo journalctl -u kubelet
  1. 一般的な原因と 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 ​

  1. security groups を確認します。

    • EFS: TCP port 2049 を許可します
    • FSx for Lustre: TCP port 988 を許可します
  2. network connectivity を確認します。

bash
kubectl debug node/<node-name> -it --image=amazon/aws-cli
ping <efs-dns-name>
telnet <efs-dns-name> 2049
  1. mount helper pod を作成します。
yaml
apiVersion: v1
kind: Pod
metadata:
  name: mount-helper
spec:
  containers:
  - name: mount-helper
    image: amazonlinux:2
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true
  1. mount を手動で test します。
bash
kubectl exec -it mount-helper -- bash
yum install -y nfs-utils
mkdir -p /mnt/efs
mount -t nfs4 <efs-dns-name>:/ /mnt/efs

Performance Issues ​

Issue: Slow I/O Performance ​

  1. volume performance metrics を確認します。
bash
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
  1. file system performance を test します。
bash
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
  1. 一般的な原因と 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 ​

  1. EFS performance mode と throughput mode を確認します
  2. client mount options を最適化します。
yaml
mountOptions:
  - nfsvers=4.1
  - rsize=1048576
  - wsize=1048576
  - timeo=600
  - retrans=2
  - noresvport
  1. access patterns を最適化します。
    • 小さな files ではなく大きな files を使用します
    • sequential access patterns を使用します
    • metadata operations を最小化します

Storage Cost Optimization ​

EKS clusters で storage costs を最適化するための strategies を見ていきましょう。

Volume Type and Size Optimization ​

  1. Select appropriate volume type:

    • 一般的な workloads: gp3 (gp2 より cost-effective)
    • Throughput-intensive workloads: st1
    • アクセス頻度の低い data: sc1
  2. Optimize volume size:

    • 必要量より少し大きめに volumes を provision します
    • volume usage を monitoring し、必要に応じて拡張します
    • 不要な data を clean up または archive します
  3. Migrate to gp3 volumes:

yaml
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: true

Storage Lifecycle Management ​

  1. Data tiering:

    • 頻繁にアクセスされる data: EBS または EFS
    • アクセス頻度の低い data: S3 または S3 Glacier
  2. Automated snapshot policy:

    • regular snapshots を作成します
    • 古い snapshots を自動的に削除します
yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-snapshot-class
driver: ebs.csi.aws.com
deletionPolicy: Delete
  1. PV reclaim policy:
    • 一時 data には Delete policy を使用します
    • 重要な data には Retain policy を使用します

EFS Cost Optimization ​

  1. Select appropriate throughput mode:

    • 予測可能な workloads: Provisioned throughput
    • 変動する workloads: Bursting mode
  2. Lifecycle management:

    • アクセス頻度の低い files を IA (Infrequent Access) storage class に自動的に移動します
    • lifecycle policy を設定します。
bash
aws efs put-lifecycle-configuration \
  --file-system-id fs-1234567890abcdef0 \
  --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"}]'
  1. Use access points:
    • application-specific access points を使用して file system を共有します

FSx for Lustre Cost Optimization ​

  1. Select appropriate deployment type:

    • 一時的な workloads: SCRATCH_2
    • 長期 workloads: PERSISTENT_1 または PERSISTENT_2
  2. Enable data compression:

    • storage costs を削減するために LZ4 data compression を使用します
  3. Integration with S3:

    • data tiering のために S3 bucket を FSx for Lustre に接続します

Cost Monitoring and Analysis ​

  1. Use AWS Cost Explorer:

    • storage cost trends を分析します
    • resource ごとの costs を分析します
  2. Kubernetes cost allocation:

    • namespaces と labels を使用して costs を配賦します
    • Kubecost などの tools を使用します
  3. Cost anomaly detection:

    • AWS budgets と alerts を設定します
    • 異常な cost increases に対する alerts を設定します

Storage Security ​

EKS clusters 内の storage resources を保護するための security best practices を見ていきましょう。

Data Encryption ​

  1. Data at rest encryption:
    • EBS volume encryption:
yaml
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:
bash
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:
bash
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
  1. Data in transit encryption:
    • EFS in-transit encryption:
yaml
mountOptions:
  - tls
  • S3 in-transit encryption:
bash
aws s3 cp --sse AES256 file.txt s3://my-bucket/

Access Control ​

  1. IAM roles and policies:
    • least privilege の原則を適用します
    • service accounts には IAM roles を使用します
bash
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
  1. Security groups:
    • 必要な ports のみを許可します
    • source IPs を制限します
bash
aws ec2 authorize-security-group-ingress \
  --group-id sg-1234567890abcdef0 \
  --protocol tcp \
  --port 2049 \
  --source-group sg-0987654321fedcba0
  1. Kubernetes RBAC:
    • PVs と PVCs への access を制限します
yaml
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.io

Pod Security Context ​

  1. Read-only root filesystem:
yaml
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
  1. Limited privileges:
yaml
securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  allowPrivilegeEscalation: false
  1. SELinux, AppArmor, or seccomp profiles:
yaml
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"
  seccompProfile:
    type: RuntimeDefault

Security Policy Enforcement ​

  1. OPA Gatekeeper or Kyverno:
    • encrypted volumes のみを許可します
yaml
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"
  1. Pod Security Standards:
    • Pod Security Standards を namespaces に適用します
yaml
apiVersion: v1
kind: Namespace
metadata:
  name: secure-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted

Storage Management Best Practices ​

EKS clusters で storage を効果的に管理するための best practices を見ていきましょう。

Storage Planning and Design ​

  1. Requirements analysis:

    • Performance requirements (IOPS、throughput)
    • Capacity requirements
    • Access patterns (read/write ratio、concurrency)
    • Availability と durability requirements
  2. 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
  3. Capacity planning:

    • 現在の requirements + growth margin
    • auto-scaling mechanisms を実装します
    • regular capacity reviews

Backup and Disaster Recovery ​

  1. Regular backups:
    • volume snapshots を自動化します
    • backup retention policies を定義します
bash
# Create snapshot daily at midnight
0 0 * * * kubectl create -f snapshot.yaml
  1. Disaster recovery plan:

    • Multi-AZ または cross-region replication
    • Recovery Time Objective (RTO) と Recovery Point Objective (RPO) を定義します
    • regular recovery testing
  2. Cluster backup with Velero:

bash
velero backup create daily-backup --include-namespaces=default,app-namespace

Automation and IaC (Infrastructure as Code) ​

  1. Use Terraform or CloudFormation:
    • storage resources の宣言的な定義
    • Version control と change tracking
hcl
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"
  }
}
  1. Use Helm charts:
    • storage classes と PVCs を templatize します
yaml
# values.yaml
storage:
  class: ebs-gp3
  size: 10Gi
  encrypted: true
  1. GitOps workflow:
    • ArgoCD または Flux で storage configuration を管理します

Performance and Cost Optimization ​

  1. Regular performance review:

    • bottlenecks を特定して解決します
    • workloads の変化に応じて storage configuration を調整します
  2. Cost optimization review:

    • 使用されていない volumes を特定して削除します
    • cost-effective な storage types に移行します
    • Reserved Instances または Savings Plans を検討します
  3. 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 ​

Quiz ​

この章で学んだ内容を確認するには、topic quiz に挑戦してください。

ドキュメントに質問する

Enter で送信、Shift+Enter で改行します。