[CKAD] 시험 미흡 사항

PV(Persistent Volume)

명령어를 사용한 생성 방법 없음.

spec

  capacity:

    storage : 1Gi

  accessModes:

  - ReadWriteMany

  persistentVolumeReclaimPolicy : Retain

  hostPath:

    path: "/mnt/data" 

accessModes

다음과 같은 세 가지 유형이 있습니다. 각 모드는 PV가 Pod에 어떻게 연결될 수 있는지를 정의합니다.

"X"는 특정 액세스 모드에서 "Many"를 의미합니다. 즉, 여러 노드 또는 여러 Pod가 동시에 접근할 수 있음을 나타냅니다.

1. ReadWriteOnce (RWO):
   • 하나의 노드에서 읽기 및 쓰기 액세스가 가능합니다.
   • 단일 Pod 또는 동일한 노드 내 여러 Pod에서만 동시에 마운트할 수 있습니다.
   • 대부분의 클라우드 프로바이더의 기본적인 디스크 모드입니다.
2. ReadOnlyMany (ROX):
   • 여러 노드에서 읽기 전용 액세스가 가능합니다.
   • 여러 Pod에서 동시에 읽기만 할 수 있습니다.
   • 공유 데이터가 필요한 애플리케이션에서 사용될 수 있습니다.
3. ReadWriteMany (RWX):
   • 여러 노드에서 읽기 및 쓰기 액세스가 가능합니다.
   • 여러 Pod에서 동시에 읽기와 쓰기를 할 수 있습니다.
   • NFS(Network File System) 또는 클라우드 파일 스토리지 솔루션에서 주로 지원합니다

persistentVolumeReclaimPolicy

Retain(유지)

PersistentVolumeClaim이 삭제되면 해당 PersistentVolume은 자동으로 삭제되지 않습니다. 대신 "Released" 상태로 이동하고 Volume의 Data는 그대로 유지됩니다.

Delete

PersistentVolumeClaim이 삭제되면 해당 PersistentVolume도 자동으로 삭제됩니다. 이는 PersistentVolumeClaim이 삭제되면 데이터를 유지할 필요가 없는 경우에 유용합니다. 이를 지원하는 볼륨의 경우, 기본 스토리지도 삭제됩니다 (예: AWS의 EBS 볼륨).

 

Deployment에서 Volume

containers와 같은 Level에 존재해야한다. 

containers에서 volume 사용법

volumeMounts에 readOnly: true 옵션도 존재함

spec:
  containers:
    - name: example-container
      image: nginx
      volumeMounts:
        - name: test_volume
          mountPath: /var
        - name: pvc
          mountPath: /pvc
        - name: env
          mountPath: /env
        - name: host_path
          mountPath: /host
        - name: share_dir
          mountPath: /shared
  volumes:
    - name: test_volume
      hostPath:
        path: /var  # 노드의 절대 경로
    - name: pvc
      persistentVolumeClaim:
        claimName: my-pvc
    - name: env
      configMap:
        name: test-config
    - name: host_path
      hostPath:
        path: /absolute/path/to/test  # 노드의 절대 경로로 수정 필요
        type: DirectoryOrCreate  # 해당 경로가 없으면 생성합니다.
    - name: share_dir
      emptyDir: {}  # container가 공유할 directory를 생성합니다.

 

Pod Command 사용 

command만 사용시 

    command:
    - "/bin/sh"
    - "-c"
    - "while true; do date; sleep $TIME_FREQ;done > /opt/time/time-check.log"

 

command와 args 사용시 

command ["/bin/sh"]

args[ "-c", " "while true; do date; sleep $TIME_FREQ; done >> /log/filed"] 이렇게 사용해야됨. 

args[ "-c", " "while true; do date; sleep $TIME_FREQ; done", ">",  "/log/filed"] 이건 안됨.

• args 섹션은 쉘이 아닌 실행 파일과 인수를 그대로 전달하기 때문에 >> 같은 리다이렉션 연산자는 지원되지 않습니다.

NetworkPolicy

아래 처럼 되어있으면 Netwwork Policy는 기본이 deny이다. 그래서 Netowkr Policy를 추가해서 이걸 뚫어줘야 한다.

Pod 검색시 Label 같이 표시 하는 방법

kubectl get pod --show-labels

readinessProbe  vs livenessProbe  

readinessProbe

• traffic관련 문제면 readinessProbe를 사용하여 문제를 푼다.
• Kubernetes에서 ReadinessProbe의 포트는 일반적으로 컨테이너에서 열려 있는 포트와 일치해야 합니다. ReadinessProbe는 애플리케이션의 준비 상태를 확인하는 데 사용되며, 지정된 포트에서 애플리케이션이 제대로 응답하는지 확인합니다.

livenessProbe

• container 재시작 관련 문제이면 livenessProbe를 사용하여 문제를 푼다.
• LivenessProbe가 실패하면 Kubernetes는 해당 컨테이너를 자동으로 재시작하므로, 애플리케이션의 안정성을 강화하고 지속적인 가용성을 유지하는 데 중요한 역할을 합니다.

CronJob 다시 공부

completions: Job이 완료되기 위해 실행해야 하는 작업의 개수를 지정하는 필드입니다

backoffLimit : Job 내에서 실패한 작업(Pod)을 재시도하는 횟수의 제한을 설정하는 필드입니다.

activeDeadlineSeconeds: Job의 총 실행 시간을 초 단위로 제한하는 설정입니다.

 

Kubernetes의 CronJob에서 두 스케줄 표현식의 차이는 다음과 같습니다:

 

• 첫 번째 * : 분 (Minute) - 0에서 59 사이의 분을 나타냅니다.
• 두 번째 * : 시간 (Hour) - 0에서 23 사이의 시간을 나타냅니다.
• 세 번째 * : 일 (Day of Month) - 1에서 31 사이의 일을 나타냅니다.
• 네 번째 * : 월 (Month) - 1에서 12 사이의 월을 나타냅니다.
• 다섯 번째 * : 요일 (Day of Week) - 0에서 7 사이의 요일을 나타내며, 0과 7은 모두 일요일입니다.

 

1 * * * *

• 매 시간의 1분마다 실행됩니다.
• 예를 들어, 12:01, 13:01, 14:01 등에 실행됩니다.

*/1 * * * *

• 매 분마다 실행됩니다.
• 즉, 모든 시간이든 분 단위로 반복 실행됩니다. 예를 들어, 12:00, 12:01, 12:02, 12:03, ... 이렇게 계속해서 매 분마다 실행됩니다.

Ingress공부

ingress 생성시 아래 옵션이 들어가면

status:
  loadBalancer: {}

 

이런 오류가난다. 그럼으로 해당   loadBalancer: {} 가 없어야 한다.

Error from server (InternalError): error when creating "4.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": failed to call webhook: Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s": dial tcp 10.102.226.160:443: connect: connection refused

 

Ingress의 port

Service의 port를 의미합니다. Ingress 리소스는 외부 요청을 특정 서비스로 라우팅하는 역할을 하며, backend의 service 필드에 지정된 port 번호는 Service에서 정의된 포트로 설정됩니다.

Service 리소스에서의 port와 targetPort는 다음과 같이 다릅니다:

• port: 클러스터 외부(또는 다른 서비스)에서 접근할 때 사용할 서비스의 포트 번호입니다.
• targetPort: 실제로 Pod에서 애플리케이션이 리스닝 중인 포트입니다

 

Path types

Ingress의 각 경로에는 해당하는 pathType이 필요합니다. 명시적으로 pathType이 포함되지 않은 경로는 유효성 검사에서 실패합니다. 지원되는 경로 유형은 다음 세 가지입니다:

1. ImplementationSpecific: 이 경로 유형을 사용할 경우, 일치 방식은 IngressClass에 따라 달라집니다. 구현에 따라 이를 별도의 pathType으로 처리하거나 Prefix 또는 Exact 경로 유형과 동일하게 처리할 수 있습니다.
2. Exact: URL 경로와 정확하게 일치하는 경우에만 매칭됩니다. 대소문자를 구분합니다.
3. Prefix: URL 경로 접두사를 기준으로 매칭됩니다. /로 분리된 경로 요소별로 일치 여부를 확인하며, 대소문자를 구분합니다. 경로 요소는 / 구분자로 분리된 경로의 각 레이블을 의미합니다. 요청 경로의 각 요소가 경로 p의 요소별 접두사(prefix)인 경우에 요청이 경로 p와 일치하는 것으로 간주됩니다.

RS로 생성된 Pod한번에 지우기 

labels을 사용해서 지우면된다.

kubectl delete -l name=busy-box

 

NodePort Service 만드는 방법

kubectl expose deployment {deployment name} --type=NodePort --port-=80 --target-port=8080 --node-port=30007 --name=my-nodeport-service 

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
    - port: 80             # Service의 포트 (클러스터 내부에서 접근할 때 사용)
      targetPort: 8080      # 실제 Pod에서 애플리케이션이 리스닝 중인 포트
      nodePort: 30007       # 노드 포트 (지정하지 않으면 Kubernetes가 자동으로 30000-32767 범위에서 할당)

 

https://www.tistory.com/event/write-challenge-2024

작심삼주 오블완 챌린지