Dash&Rush Hanbus

StorageClass는 Persistent Volume (PV)와 Persistent Volume Claim (PVC)의 관계를 정의하고 제어하는 방법을 제공하는 리소스Persistent Volume (PV): PV는 클러스터 내에서 스토리지 볼륨을 나타내는 객체입니다. PV는 실제 스토리지 볼륨에 대한 세부 정보 및 속성을 포함하며, 스토리지 프로바이더 (예: 네트워크 스토리지, 클라우드 스토리지 등)와 관련된 구체적인 설정을 포함할 수 있습니다.Persistent Volume Claim (PVC): PVC는 애플리케이션 또는 사용자가 클레임하는 스토리지 볼륨의 요청을 정의합니다. 애플리케이션은 PVC를 생성하고 원하는 스토리지 클래스, 볼륨 크기 등을 지정합니다.StorageClass: Storag..

reclaimPolicy란?Kubernetes에서 **Persistent Volume (PV)**가 삭제되었을 때 스토리지를 어떻게 처리할지 결정하는 정책1. reclaimPolicy 종류reclaimPolicy 값Retain (기본값)PV를 삭제해도 데이터가 남아 있음. 수동으로 정리해야 함.중요한 데이터 (DB, 로그)DeletePVC 삭제 시 PV도 자동으로 삭제됨.임시 데이터 (캐시, 테스트 환경)Recycle (Deprecated)PV 삭제 시 기본적인 데이터 삭제 후 다시 사용 가능더 이상 사용되지 않음2. reclaimPolicy 상세 설명📌 1) Retain (보존)PVC가 삭제되어도 PV가 남아 있음.기존 데이터를 유지해야 하는 경우 사용.관리자가 직접 스토리지를 정리해야 함.데이터베이..

엔드포인트 생성 원리:Service가 Selector를 기반으로 라벨이 일치하는 Pod들을 찾으면, 그 Pod들의 IP와 지정된 포트를 기준으로 엔드포인트를 자동 생성. 예를 들어, 다음과 같이 Service가 설정되어 있을 때:apiVersion: v1kind: Servicemetadata: name: holy-api-servicespec: selector: id: holy-api # 'id: holy-api' 라벨을 가진 Pod 선택 ports: - port: 80 # Service가 외부에 노출하는 포트 targetPort: 8080 # 실제 Pod의 포트 Pod의 IP가 10.28.2.32이고 Pod의 컨테이너가 8080 포트를 사용 중이라면, Servic..

apiVersion: v1kind: Servicemetadata: name: jupiter-crew-svc namespace: jupiter...spec: clusterIP: 10.3.245.70 ports: - name: 8080-80 port: 8080 protocol: TCP targetPort: 80 nodePort: 30100 # add the nodePort selector: id: jupiter-crew sessionAffinity: None #type: ClusterIP type: NodePort # change type 구성 설명Pod: id: jupiter-crew 라벨을 가진 Pod.Service: jupiter-crew-svc라는 Se..

핵심 차이점 비교표                                                          ConfigMap                                                           Secret목적환경 변수, 설정 파일 저장비밀번호, API 키, 인증서 등 민감한 데이터 저장데이터 저장 방식일반 텍스트 (Plaintext)Base64 인코딩 (Opaque)보안 수준낮음 (암호화 X)상대적으로 높음 (Base64 인코딩, RBAC 보호)데이터 크기 제한제한 없음1MiB (기본 제한)Mount 방식환경 변수, 볼륨환경 변수, 볼륨예제 데이터DB 호스트, 로그 레벨, 설정 값DB 비밀번호, API 키, TLS 인증서 ConfigMap vs Secre..

Rolling Update란?Rolling Update는 Kubernetes에서 Deployment를 업데이트하는 기본 전략으로, 애플리케이션을 다운타임 없이 새로운 버전으로 점진적으로 교체하는 방법. Pod을 점진적으로 교체하면서 무중단 배포(Zero Downtime Deployment)를 수행하는 방식strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate✅ 1. type: RollingUpdate업데이트 전략을 Rolling Update(롤링 업데이트) 방식으로 설정.한 번에 모든 Pod을 종료하는 것이 아니라, 새로운 Pod을 점진적으로 생성하고 기존 Pod을 순차적으로 종료함.✅ 2. maxSurg..

ReadinessProbe와 LivenessProbe는 Pod의 상태를 확인하는 헬스 체크 기능 ✅ ReadinessProbe (준비 상태 체크)👉 "내가 지금 트래픽을 받을 준비가 되었나요?"Pod이 정상적으로 실행되었는지 확인하는 기능준비가 완료되면 서비스에서 해당 Pod으로 트래픽을 보냄준비되지 않으면 서비스에서 해당 Pod을 제외함 (트래픽을 받지 않음)readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 10컨테이너가 시작된 후 5초 후 /health 엔드포인트로 체크10초마다 한 번씩 확인하여 트래픽을 받을 준비가 되었는지 검사CKAD에서 출제됐었음 💡 언제 사용하나요?애..

쿠버네티스에서 사용자(User) 는 크게 두 가지로 나눌 수 있음  쿠버네티스 외부 사용자 (Human User)사람이 직접 kubectl이나 API를 사용하여 쿠버네티스를 조작하는 사용자클러스터 내부에 존재하지 않고, 쿠버네티스가 직접 관리하지 않음보통 쿠버네티스 API 서버에 인증서(Certificate) 기반 인증을 통해 접근예시: kubectl --as=alice (alice라는 외부 사용자로 실행)  쿠버네티스 내부 사용자 (ServiceAccount)쿠버네티스 클러스터 내부에서 실행되는 Pod가 API를 호출할 때 사용하는 계정쿠버네티스에서 직접 관리하는 계정이며, 특정 네임스페이스에 속함Pod가 API 요청을 보낼 때 자동으로 사용됨 (예: default 서비스 계정)🔹 User vs Se..