lifelog and tech

EFS 를 동적 프로비저닝 및 iam option 을 통한 IRSA 로 EFS 접근 시 구성

PVC 에 iam 마운트 옵션을 정의하고 동적 프로비저닝에 의해 자동 생성된 PV는 이를 상속받습니다.

해당 구성은 EKS Fargate 가 아닌 EKS EC2 Node 사용 시 동적 프로비저닝 예시입니다.

Sample of storageclass.yaml

allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true" # true or false
  name: default-efs
mountOptions:
  - iam
  - tls
parameters:
  directoryPerms: "755" # directory permission value of 755 allows the directory user owner to list files, create files, and mount, and all other users to list files and mount.
  fileSystemId: fs-xxxxxxxx # replace this with the efs id actually created on your env
  provisioningMode: efs-ap
  gidRangeStart: "1000"
  gidRangeEnd: "2000"
  basePath: "/data" # whatever you want
  encrypted: "true" # in case you use encryption on your EFS
provisioner: efs.csi.aws.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

tls option 은 deprecated 되었다고 로그가 확인되어, tls 는 뺐고 (default 가 tls enabled) EFS 가 암호화 되어있어 encrypted: true 를 넣었습니다.

Sample of pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-pvc-test
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: default-efs
  resources:
    requests:
      storage: 1Gi # adjust this depending on your requirement

Sample of serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<account number>:role/<iam role name>
  name: test
  namespace: <your namespace>

테스트 시에는 IAM 역할 없이 마운트 잘 되었고 eks node(ec2) 역할에 권한이 있었다.

Sample of efs-test-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: efs-testpod-01
spec:
  serviceAccountName: test
  containers:
    - name: alpine
      image: alpine
      command: ["/bin/sh"]
      args: ["-c", "echo 'Starting Nginx'; echo 'Log entry: $(date)' >> /usr/share/nginx/html/log.txt; sleep infinity"]
      volumeMounts:
        - name: efs-volume
          mountPath: /usr/share/nginx/html
  volumes:
    - name: efs-volume
      persistentVolumeClaim:
        claimName: efs-pvc-test

Pod 아웃바운드 보안그룹에 NFS 포트(port 2049) 허용, EFS 보안그룹에 pod 보안그룹 인입에 대한 NFS 포트 허용이 되어있어야 하고,

IRSA 용 IAM 역할의 권한에 해당 서비스(EFS)에 접근할 권한이 포함되어 있어야 합니다.

velero 가 설치되지 않은 클러스터에서 배포된 자원 manifest 정보를 txt 파일에 저장하는 bash shell script 코드. 

kubectl ... -o yaml 과 함께 아래 neat 를 설치 및 조합하면 기타 타임스탬프 등 불필요한 정보를 제외한 readable 버전으로 저장이 가능합니다.

해당 조합으로 저장 시 txt 대신 yaml 로 저장하고 배포가능한 형식으로 테스트할 수 있습니다.

kubectl krew install neat # neat 설치 명령어.

그 전에 krew 가 설치되어있지 않다면 다음을 이용해 미리 설치해 둡니다.

# run a script by copy and paste to your command line
(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e
 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew.tar.gz" &&
  tar zxvf krew.tar.gz &&
  KREW=./krew-"${OS}_${ARCH}" &&
  "$KREW" install krew
)

# set the path env of krew
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

< Code Sample >

#!/bin/bash

# 백업할 네임스페이스 지정
NAMESPACES=("apples" "bananas" "grapes" "strawberries" "melons")

# 각 네임스페이스의 리소스 정보를 txt 파일로 저장
for namespace in "${NAMESPACES[@]}"
do
    echo "네임스페이스 $namespace 리소스 정보 저장 중..."
    
    # 네임스페이스의 모든 리소스 정보 가져오기
    kubectl get all -n "$namespace" -o yaml > "$namespace-resources.txt"
done

# gp2, gp3, default-efs StorageClass 정보 저장
echo "StorageClass 정보 저장 중..."
kubectl get storageclass gp2 -o yaml > gp2-storageclass.txt
kubectl get storageclass gp3 -o yaml > gp3-storageclass.txt
kubectl get storageclass default-efs -o yaml > default-efs-storageclass.txt

echo "모든 정보가 txt 파일로 저장되었습니다."

python3이상, boto3 설치 필요

import boto3
import time

aws_profile = "your aws profile"
aws_region = "your region"

session = boto3.Session(
    profile_name=aws_profile,
    region_name=aws_region
)

eks_client = session.client('eks')

cluster_name = 'your cluster name'

# 해당 클러스터의 모든 Fargate 프로필 이름 가져오기
response = eks_client.list_fargate_profiles(clusterName=cluster_name)
profiles = response['fargateProfileNames']

# 각 Fargate 프로필 삭제
for profile in profiles:
    print(f"Deleting Fargate profile: {profile}")
    eks_client.delete_fargate_profile(clusterName=cluster_name, fargateProfileName=profile)
    
    # 삭제 상태 확인
    while True:
        try:
            eks_client.describe_fargate_profile(clusterName=cluster_name, fargateProfileName=profile)
            print(f"Waiting for {profile} to be deleted...")
            time.sleep(10)  
        except eks_client.exceptions.ResourceNotFoundException:
            print(f"{profile} deleted.")
            break

print("All Fargate profiles have been deleted.")

※ 쿠버네티스 컨피그('~/.kube/config') 에 여러 계정의 여러 클러스터가 저장되어있고 컨텍스트(context) 전환할 때

어떤 클러스터 컨텍스트를 사용하고 있는지 표시하고 싶은 경우 사용

• Bash 쉘에서의 설정

'~/.bashrc' 또는 '~/.bash_profile' 파일에 아래 줄 추가

export PS1='\[\e]0;\u@\h: \w\a\]\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] \[\033[01;36m\]($(kubectl config current-context))\[\033[00m\] $ '

설정 파일 적용

source ~/.bashrc

Context Name은 AWS 서비스의 경우 꼭 Arn을 다 입력하지 않고 클러스터 명 정도만 간편하게 적어 사용할 수 있다.

ETCDCTL version 2

etcdctl backup
etcdctl cluster-health
etcdctl mk
etcdctl mkdir
etcdctl set

ETCDCTL version 3

etcdctl snapshot save 
etcdctl endpoint health
etcdctl get
etcdctl put

Setting API version 

export ETCDCTL_API=<number>

Setting path to certificate files for ETCDCTL to authenticate ETCD API server

--cacert /etc/kubernetes/pki/etcd/ca.crt     
--cert /etc/kubernetes/pki/etcd/server.crt     
--key /etc/kubernetes/pki/etcd/server.key

An example command with kubectl pa

kubectl exec etcd-master01 -n kube-system -- sh -c "ETCDCTL_API=3 etcdctl get / --prefix --keys-only --limit=10 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt  --key /etc/kubernetes/pki/etcd/server.key"

1. Local env: Ubuntu CLI, terraform

2. Error messages: sts get caller identity error, "signature does not match"

2.1 with terraform

soyi@SOYI /mnt/c/Users/SOYI/tf-test/fundamental-aws-infra/terraform $ terraform init

Initializing the backend...
Initializing modules...
╷
│ Error: error configuring S3 Backend: error validating provider credentials: error calling sts:GetCallerIdentity: SignatureDoesNotMatch: Signature expired: 20230807T110917Z is now earlier than 20230808T053756Z (20230808T055256Z - 15 min.)
│       status code: 403, request id: 557xxxx-xxxx-xxxx-xxxx-7b40xxxxxxxxx
│
│
╵

2.2 check aws sts command (same error)

soyi@SOYI /mnt/c/Users/SOYI/tf-test/fundamental-aws-infra/terraform $ aws sts get-caller-identity

An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Signature expired: 20230807T110934Z is now earlier than 20230808T053813Z (20230808T055313Z - 15 min.)

3. resolve: 

3.1 check the aws configure credentials first

3.2 if 3.1 is ok, then synchronize the ntpdate if the env is Ubuntu like -

# run following command if it's Ubuntu
$ sudo ntpdate ntp.ubuntu.com
 8 Aug 14:55:29 ntpdate[1292]: step time server 91.189.91.157 offset +67418.817306 sec
 
# the result means it's done.

# if ntpdate command is not found, then install ntp as below.
sudo apt install ntp && ntpdate -y

-. 쿠버네티스에서 기본적으로 파드들을 배포, 업데이트 등 관리하기 위해 사용하는 yaml 템플릿 종류에 대한 정리입니다.

1. DaemonSet

• Purpose: 각 노드에 특정 파드를 실행하고 싶을 때 이용. A DaemonSet ensures a specific pod runs on each nodes in the Kubernetes cluster. 주로 모니터링 에이전트, 로그 수집, 백그라운드로 돌아가는 작업들 등 각 노드에 특정 파드의 복제본 파드를 실행시키거나 하는 상황에서 사용. it's commonly used for log collection, monitoring agents, and background tasks, so on.
• Advantage: 데몬셋은 각 노드 별로 해당 파드를 동일하게 복제하여 일치성을 유지하는데 도움이 되는 방식. 해당 방법으로 동일 클러스터 내의 모든 호스트로부터 데이터를 수집하고 워크로드를 분산하는데 도움이 된다. DaemonSets help maintain consistency across nodes by running a pod on each node. easy to distribute workloads and collect data from every host in the cluster.

데몬셋으로 서비스 생성하는 예: yaml 방식 배포

하기 방식으로 서비스에 맞게 yaml 파일을 생성하고, kind는 DaemonSet으로 생성하여 create 또는 apply로 명령하여 데몬셋을 실행한다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: servicename-daemonset
spec:
  selector:
    matchLabels:
      app: servicename
  template:
    metadata:
      labels:
        app: appname
    spec:
      containers:
      - name: example
        image: example:latest

2. StatefulSet

• Purpose: Stateful 한 어플리케이션 배포에 사용한다. 즉 배포대상 파드가 유일무이한 특성을 가지거나 네트워크 안정성이 필요한 서비스일때 사용한다. Although ReplicaSets are not typically used directly, this can manage stateful applications where each pod has a unique identity and stable network identity, for databases like MySQL, messaging systems like Kafka or  any application which needs stable and persistent network identities.
• Advantage: StatefulSet 은 파드가 생성될때 순서대로 고유의 서비스를 유지하면서 스케일링 되도록 한다. StatefulSets ensure pods are created and scaled in order, preserving their identities, which required data needs to be retained and moved with the pods. 데이터 손실없이 pod 변경이 필요한 stateful 어플리케이션에 적합하다.

StatefulSet으로 서비스 생성하는 예: yaml 방식 배포

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: yourservice-name
spec:
  selector:
    matchLabels:
      app: service-name
  serviceName: "example"
  replicas: 3
  template:
    metadata:
      labels:
        app: service-name
    spec:
      containers:
      - name: service-name
        image: service-name:latest
        ports:
        - containerPort: 00
        volumeMounts:
        - name: service-name-persistent-storage
          mountPath: /var/lib/service-name
  volumeClaimTemplates:
  - metadata:
      name: service-name-persistent-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "standard"
      resources:
        requests:
          storage: 1Gi

3. ReplicaSet

• Purpose: 동일 클러스터 내 동일한 파드들을 원하는 숫자만큼 유지하기 위해 사용하여 배포 순서가 중요하지 않은 stateless 어플리케이션 배포 및 스케일링에 이용한다. maintain a desired number of identical pods in the cluster, ensuring high availability and fault tolerance. scale and manage stateless applications where the order of pod creation and termination does not matter. useful to ensure a specific number of replicas are running, regardless of the underlying nodes' availability.
• Selector and Labels: 관리할 파드를 구별하기 위해 보통 label selector을 이용하며 매칭되는 라벨을 가진 파드가 명시된 숫자만큼 항상 실행되도록 관리할 수 있다. it uses a label selector to identify the pods it needs to manage, and ensures the specified number of pods with matching labels are always running.
• Pod Template: 파드 업데이트 및 새 파드를 생성할 때 파드 템플릿을 이용한다. 즉 새로운 변경을 포함하여 업데이트시 해당 변경된 템플릿을 참조하여 새 파드가 생성된다. updating the pod template will apply the changes to the ReplicaSet and it'll create new pods based on the updated template.
• Automatic Scaling: 스케일 업 시, 해당 리플리카 숫자 만큼 쿠버네티스에 의해 파드가 증가된다. 또한 리플리카 수를 더 작게 변경하면 존재하던 파드 중 일부가 종료되어 해당 숫자만큼 줄어든다.

4. Job: 데이터 처리 및 백업같은 수명이 짧은 배치성 jobs 에 쓰인다. used for short-lived tasks or batch jobs that run to completion such as data processing or backups.

예시: 크론 잡 만들기 an example command to create a cronjob

kubectl create cronjob my-cronjob --image=my-image:latest --schedule="* * * * *"

일반 job 생성 creating a typical job

kubectl create job my-job --image=my-image:latest

-. kubectl 명령어를 이용한 파드 재시작(재배포) 방법

1. Restarting a Pod:

단일 파드를 재시작하는 방법은 단순하게 running중인 현재의 pod를 삭제하여 연결된 replica 정의에 따라 새로 자동 생성되도록 하는 방법이 있다.

# Replace "your-pod-name" with the name of your pod
kubectl delete pod your-pod-name

2. Restarting a Deployment:

또한 좀더 stateful 한 서비스를 위해 점진적인 배포 및 재시작을 원하는 경우 rollout을 사용하면 된다.

kubectl rollout restart deployment your-deployment-name

3. Restarting a StatefulSet:

마찬가지로 statefulset으로 정의된 배포에 대하여 점진적인 롤아웃 방식 재 배포를 원하는 경우 아래와 같이 하면 된다.

kubectl rollout restart statefulset your-statefulset-name

4. Restarting a DaemonSet:

• Rolling update

쿠버네티스 버전 1.5 와 그 이전 버전은 데몬셋 템플릿을 수정하여 업데이트 시, 매뉴얼하게 직접 데몬셋 파드를 삭제하여 새 파드가 생성되는 on Delete 방식이며, 1.6부터는 디폴트로 롤링 업데이트를 사용할 수 있는 것으로 공식 문서에 기재되어 있다. (롤링 업데이트: 템플릿 수정시 이전 수정 전 파드들이 자동 종료되고 새 버전 템플릿을 반영한 새 파드들이 생성되는 방식)

롤링 업데이트를 사용하려면 DaemonSet 템플릿에 아래 부분을 명시한다.

.spec.updateStrategy.type to RollingUpdate

Any updates to a RollingUpdate DaemonSet ".spec.template" will trigger a rolling update. you can update the DaemonSet by applying a new YAML file.

공식문서 참조: https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/

• Cascading deletion

공식문서 참조: https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/

& foreground, background cascading deletion: https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/

리소스를 삭제 시 해당 리소스 및 리소스와 연관된 리소스 (configmap 등)를 함께 삭제하는 것과 관련된 것이며 이 때, foreground 또는 background 로 진행할지 사전 정의가 가능하다. 디폴트는 foreground이며 background 삭제는 opt-in 옵션이다.

When you delete a DaemonSet using the kubectl delete command without the --cascade=false flag or simply use kubectl delete daemonset your-daemonset-name, Kubernetes will perform a cascading delete by default. This means that not only the DaemonSet resource will be deleted, but also all the pods managed by that DaemonSet will be terminated.

Issue example:

Reason:         Evicted
Message:        Pod The node had condition: [DiskPressure].

멀쩡하게 running 중이던 Pod 의 상태가 Evicted 로 여러 Pod로 늘어나 있는 경우, 어떤 이유에 의해 새  Pod를 예약할 수 없는 상태일 때 발생한다.

여기서 Message 를 보면 DiskPressure 조건에 의해 실패하였으며 해당 경우에는 노드의 사용 가능한 디스크 공간이 부족하거나 소진되어 쿠버네티스 시스템에서 해당 노드에 새 포드를 예약할 수 없어 포드가 해당 노드에서 제거된 것을 알 수 있다.

시스템은 디스크 공간을 확보하고 클러스터의 전반적인 안정성을 보장하기 위해 노드의 기존 포드를 제거할 수 있다.

해당 DiskPressure 조건에 미치려면 몇가지 경우의 수가 있다.

1. 해당 노드의 disk usage 문제
   1. 노드의 디스크 공간 체크, 부족시 불필요한 파일 삭제 및 더 많은 스토리지 용량 추가 등으로 해결
2. 해당 노드의 사용중인 inode usage 문제
   1. df -i 로 inode 용량 확인
3. 처리되는 파일 갯수의 문제 (Max open files)
   
   1. 아래 명령어로 확인

cat /proc/$(pgrep kubelet)/limits | grep "Max open files"

             결과 값:

# cat /proc/$(pgrep kubelet)/limits | grep "Max open files"
Max open files            1000000              1000000              files

            2. 높은 경우, kubelet 프로세스의 최대 열린 파일 수를 늘려본다. 해당 노드의 kubelet conf 파일에 적절한 Limit 값을 설정하면 된다.

                설정 파일 위치: /etc/systemd/system/kubelet.service.d/

                추가 값 예시: LimitNOFILE=1000000

[Service] 섹션에 해당 값을 추가한다. 추가 후에는 데몬을 리로드하고 kubelet 을 재기동한다.

sudo systemctl daemon-reload
sudo systemctl restart kubelet

kubelet 의 eviction threshold 를 확인하려면 해당 워커노드의 /etc/kubernetes/ 에 kubelet 관련 파일의 "evictionHard" 부분을 확인할 수 있다.

  "evictionHard": {
    "memory.available": "100Mi",
    "nodefs.available": "10%",
    "nodefs.inodesFree": "5%"
  },

nodefs.available은 disk pressure과 관련있고 위에서는 10%로 설정되어있다. 즉, 해당 노드에서 사용 가능한 파일 시스템 공간의 비율이 10% 미만으로 떨어지면 Kubernetes가 노드에서 포드를 evicted한다.

공식문서 참고:

Minimum eviction reclaim

In some cases, pod eviction only reclaims a small amount of the starved resource. This can lead to the kubelet repeatedly hitting the configured eviction thresholds and triggering multiple evictions.

You can use the --eviction-minimum-reclaim flag or a kubelet config file to configure a minimum reclaim amount for each resource. When the kubelet notices that a resource is starved, it continues to reclaim that resource until it reclaims the quantity you specify.

For example, the following configuration sets minimum reclaim amounts:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "1Gi"
  imagefs.available: "100Gi"
evictionMinimumReclaim:
  memory.available: "0Mi"
  nodefs.available: "500Mi"
  imagefs.available: "2Gi"

이외 기존 Evicted Pod들을 아래 명령어로 Running 상태인 pod 제외하고 제거할 수 있다.

kubectl get pods -n <namespace> --field-selector=status.phase=Failed | grep Evicted | awk '{if($3!="Running") print $1}' | xargs kubectl delete pod -n <namespace>

또는 깔끔하게 해당 포드의 deployment 파일 replica 수롤 조정하여 재 배포한다.

replicas 를 0개로 했다가 다시 증가시킨다.

kubectl scale deployment <your-deployment-name> --replicas=0 -n monitoring

재 배포 전에 Back-off 에러가 발생하여 로그를 확인해보니 아래 에러가 발생하였다.

msg="Error loading config (--config.file=/etc/config/prometheus.yml)" err="parsing YAML file /etc/config/prometheus.yml: yaml: unmarshal errors:\n  line 14: field metrics_path not found in type struct { Targets []string \"yaml:\\\"targets\\\"\"; Labels model.LabelSet \"yaml:\\\"labels\\\"\" }"

컨테이너 두개중 컨피그맵을 통째로 /etc/config 에 맵핑한 것은 정상인데 두번째 컨테이너의 /etc/config/blahblah.yml 로 마운트한 부분 값과 관련하여 yaml: unmarshal 에러가 발생했다.

관련 서비스 컨피그맵의 해당 yml 아래 metrics_path 를 확인하여 syntax 에러를 수정하고 재 배포 후 해결되었다.

Before:

      - job_name: actuator
        static_configs:
          - targets: [eap-was.eap.svc:30001]
            metric_path: '/actuator/prometheus'

After: (metrics_path 위치 변경)

- job_name: actuator
  metrics_path: /actuator/prometheus
  static_configs:
  - targets:

이외 추가로 알게된 Tip:

• DaemonSet YAML 을 이전 generation 버전으로 롤백하려고 할때 -

1. 롤백 가능한 버전을 아래 명령어를 이용해 확인한다.

kubectl rollout history daemonset <daemonset-name> -n <namespace>

2. 해당 원하는 버전으로 롤백한다.

kubectl rollout undo daemonset <daemonset-name> -n <namespace> --to-revision=1

--to-revision 에 원하는 버전 값을 입력할 수 있다.

• 기존 중복된 리소스로 인해 helm install 이 실패시 

에러 메시지 예:

helm install <serviced> <service>/<serviced>  --namespace <your namespace>
Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: ClusterRoleBinding "serviced" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation

해당 리소스 삭제 후 재 설치한다.

kubectl delete clusterrolebinding <servicd name> -n <your namespace>

Pod selection for kubelet eviction: https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

Pod selection for kubelet eviction 
If the kubelet's attempts to reclaim node-level resources don't bring the eviction signal below the threshold, the kubelet begins to evict end-user pods.
The kubelet uses the following parameters to determine the pod eviction order:
Whether the pod's resource usage exceeds requestsPod PriorityThe pod's resource usage relative to requests
As a result, kubelet ranks and evicts pods in the following order:
BestEffort or Burstable pods where the usage exceeds requests. These pods are evicted based on their Priority and then by how much their usage level exceeds the request.Guaranteed pods and Burstable pods where the usage is less than requests are evicted last, based on their Priority.
Note: The kubelet does not use the pod's QoS class to determine the eviction order. You can use the QoS class to estimate the most likely pod eviction order when reclaiming resources like memory. QoS does not apply to EphemeralStorage requests, so the above scenario will not apply if the node is, for example, under DiskPressure.

+

Node conditions 

The kubelet reports node conditions to reflect that the node is under pressure because hard or soft eviction threshold is met, independent of configured grace periods.

The kubelet maps eviction signals to node conditions as follows:

ETC.

kube-controller-manager.service

ExecStart=/usr/local/bin/kube-controller-manater \\
	--address=0.0.0.0 \\
    --cluster-cidr=x.x.x.x/x \\
    --cluster-name=<name> \\
    ....
    
    --node-monitor-period=5s
    --node-monitor-grace-period=40s
    --pod-eviction-timeout=5m0s
    
    ...