EKS PV issues

kubectl describe configmap my-configmap-name -n my-namespace

Event:
  Normal   NotTriggerScaleUp  9m14s   cluster-autoscaler  pod didn't trigger scale-up: 9 max node group size reached, 1 pod has unbound immediate PersistentVolumeClaims
  Normal   NotTriggerScaleUp  4m12s (x27 over 9m4s)  cluster-autoscaler  pod didn't trigger scale-up: 1 pod has unbound immediate PersistentVolumeClaims, 9 max node group size reached
  Warning  FailedScheduling   4s (x10 over 9m16s)    default-scheduler   0/8 nodes are available: 8 pod has unbound immediate PersistentVolumeClaims.

 

말그대로 bound 되지 않은 PVC가 존재한다는 뜻이다.

Interpret this error(상세설명):

The first two log messages indicate that the cluster-autoscaler pod did not trigger a scale-up of the cluster because the maximum node group size has been reached and there are pods with unbound immediate PVCs. This means that there are no available nodes to schedule the new pods with unbound PVCs.
The third log message indicates that the default scheduler failed to schedule the pods because all nodes have unbound immediate PVCs.

To do:
investigate why the PVCs are not binding to any available storage resources. Check the status of your storage classes, persistent volumes, and persistent volume claims to ensure that they are configured correctly and have available capacity. You may also need to adjust the resource requests and limits for your pods to ensure they fit within the available resources. Once you have resolved the PVC binding issue, the cluster-autoscaler should be able to trigger a scale-up of the cluster to accommodate the new pods.

 

재생성을 위하여 PV가 삭제되는 중이었으나 계속 Terminating 상태로 삭제가 안되고 있었다.

모든 작업 완료 및 세션 만료 후 정리중이라 원래 확인과는 다를 수 있다. 아래는 terminating 상태의 예이다.

pod는 삭제했고 (replicas 0) 관련 pvc를 get해보니 이전 네임스페이스에 있던 pvc가 pending 상태였고 새로 생성한 네임스페이스에 생성된 삭제대상 pvc가 물려있는 상태였다. 

관련 pvc 둘을 모두 삭제하니 바로 해당 pv가 제대로 삭제됐다.

kubectl delete pvc [pvc-name]

 

그후 다시 pv를 할당하고 재 배포하여 정상 배포되었다.

 

pv 생성은 yaml로 생성하거나 명령어로 생성할 수 있다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: grafana-pvc
  namespace: your-namespace
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

명령어 예시:

kubectl create pvc grafana-pvc --size=1Gi -n <namespace>

storage class는 standard, gp2 등 원하는 것으로 설정한다.

한번 storage class를 설정하여 배포한 후 수정하려고 하면 바꿀수 없는(immutable) 항목이라 PersistentVoluemClain is invalid 에러가 발생하며 반영이 안된다. (Forbidden: spec is immutable after creation except resources.requests for bound claims)

 

compare standard with gp2:

In Kubernetes, standard and gp2 are storage classes that refer to different types of cloud storage volumes that can be attached to the cluster.
standard is a default storage class that uses pd-standard persistent disks in Google Cloud or gp2 in AWS. These volumes provide balanced performance and cost, and they are suitable for general-purpose workloads.
On the other hand, gp2 is an AWS-specific storage class that uses gp2 EBS volumes. These volumes are optimized for transactional workloads and offer higher performance than standard volumes. They also cost more per GB than standard volumes.
Therefore, when choosing between standard and gp2, it depends on your workload requirements, budget, and the cloud provider you are using.

 

 

작업중 configmap not found와 함께 마운트 실패가 난다면

  Warning  FailedMount             62s (x13 over 11m)  kubelet                  MountVolume.SetUp failed for volume "grafana-ini-cm" : configmap "grafana.ini" not found

아래 명령어로 콘피그 맵을 확인한다.

kubectl describe configmap configmap-name -n my-namespace

또한 해당 볼륨이 제대로 yaml file에 명시 되었는지도 확인한다.

예: 아래는 그라파나 관련 서비스 yaml이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: my-namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - name: grafana
        image: grafana/grafana:[lastest]
        volumeMounts:
        - name: grafana-ini-cm
          mountPath: /etc/grafana/grafana.ini
          subPath: grafana.ini
        ...
      volumes:
      - name: grafana-ini-cm
        configMap:
          name: grafana-config

 

콘피그 맵이 제대로 생성 안된 경우 아래 명령어를 참고한다.

kubectl create configmap grafana-config --from-file=/path/to/grafana.ini
kubectl get configmaps grafana-config

다음 명령어로도 새 콘피그맵 리소스를 생성 가능하다.

kubectl create cm grafana.ini --from-file=grafana.ini -n my-namespace
kubectl get cm -n my-namespace

pod 에서 eks 의 ec2 노드그룹 매칭은 nodeSelector로 EKS label 을 지정하여 설정했다.

참고로 쿠베 definition에서 그냥 selector 필드는 서비스를 해당 라벨이 있는 파드로 매칭하는 작업을 한다고 한다.

selector:
  app.kubernetes.io/name: grafana
  app.kubernetes.io/instance: grafana

 

 

그리고 NLB로 배포하였다.

apiVersion: v1
kind: Service
metadata:  
  name: grafana
  namespace: my-namespace
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-name: "grafana"
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip"
    service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-id,subnet-id
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
  labels:
    helm.sh/chart: grafana-x.x.x   
    app.kubernetes.io/name: grafana
    app.kubernetes.io/instance: grafana
    app.kubernetes.io/version: "x.x.1"
    app.kubernetes.io/managed-by: Helm
spec:  
  type: LoadBalancer
  ports:    
    - name: service
      port: 80
      protocol: TCP
      targetPort: 3000
  selector:
    app.kubernetes.io/name: grafana
    app.kubernetes.io/instance: grafana

 

해당 방식으로 했을 시 NLB 의 타겟그룹에 배포 전 아이피가 draining되면서 새로 apply 된 아이피가 자동 등록된다.

 

이외에 배포된 파드에 직접 들어가서 확인해보려면 아래 명령어를 이용한다.

kubectl exec -it <pod-name> -- /bin/bash

해당 파드에 배포된 컨피그파일 (예:grafana.ini)을 수정하려고 하면 "Read-only file system" 에러가 발생할 수 있다.

해당 경우 read only 파일인 grafana.ini 를 수정하려면,

kubectl cp <pod-name>:/etc/grafana/grafana.ini ./grafana.ini

하여 로컬로 갖고와서 아래 항목을 포함한 docker file을 생성하고,

FROM grafana/grafana:latest
COPY grafana.ini /etc/grafana/grafana.ini

아래 명령어로 빌드 후 푸시하고,

docker build -t my-grafana-image .

새로운 이미지를 이용해 새 파드를 띄워 확인할 수 있다.

kubectl run my-grafana-pod --image=my-grafana-image --restart=Never

 

이외 참고할 명령어:

라벨 별로 pod들을 필터링 하는 명령어 (두번째 줄은 example이다.)

kubectl get pods -l <label-selector>
kubectl get pods -l app.kubernetes.io/name=grafana

라벨과 함께 pod들 리스팅하는 명령어는 다음이다.

kubectl get pods --show-labels

pv를 강제 삭제처리 할때 명령어는 다음이다. (강제 삭제할 경우 데이터 손실 및 corruption 발생할 수 있으므로 삭제해도 될 상태일 때만 수행)

kubectl delete pv <pv-name> --grace-period=0 --force

pv edit

kubectl edit pv <pv-name>