Cloud

지난달부터 현장실습을 나왔는데, 약 한달간 쿠버네티스 공부를 하고이번주부터 CI/CD 시스템을 구축하는 미션을 받았습니다. 일단 CI(지속적 통합)/CD(지속적 배포)가 무엇이냐 예전엔 어떤 팀이 프로그램을 개발하고 이를 실제로 배포하여 서비스를 하는 과정에서개발자에게 많은 일이 과중되었습니다. 개발자가 개발을 하고 여러 개발자들이 만든 코드를 통합하고,통합된 코드를 테스트 하고, 이를 배포하기까지  정말 많은 과정을 개발자가 관여해야 했습니다. 그래서 이 과정을 줄일 수 있는 다양한 도구들이 나왔습니다.대표적으로 git, jenkins, argocd... 그 모든 통합과 배포 도구를 이어서 자동화하는 것이 CI/CD의 실현이라고 할 수 있습니다. 그래서 이 CI/CD를 구축하는 것은 좋지만 어떤 도구를..

emptyDir, hostPath는 컨트롤러의 템플릿이나 파드에 직접 스토리지 볼륨을 정의해야 했습니다. 이는 개발자에게 스토리지에 대한 지식을 요구하고, 볼륨의 생명주기를 파드의 생명주기와 분리할 수 없었습니다. PV, PVC란?PV(PersistentVolume) 및 PVC(PersistentVolumeClaim)는 컨트롤러 및 파드와 별개의 리소스이고, 생명주기 또한 다릅니다. PV 리소스는 클러스터 외부 스토리지와 연결을 담당하고, PVC 리소스는 PV와 파드를 연결하기 위한 리소스입니다. 즉, 클러스터 관리자가 PV 리소스를 생성해 스토리지와 연결해두고, 파드 개발자는 PVC를 생성해 자신의 파드 및 관리자가 제공해 준 PV와 연결해 파드에서 볼륨을 사용할 수 있게 해줍니다. 결국 개발자의 관점..

emptyDir 볼륨은 아무 데이터도 없는 빈 디렉토리를 제공해주는 볼륨입니다.파드가 생성하는 데이터를 저장할 수 있고, 동일한 파드 내의 컨테이너 간에 데이터 공유에 유용하게 사용할 수 있습니다. 최초 볼륨이 생성될 때는 volume의 내용이 비어있기 때문에 emptyDir이라고 부릅니다. emptyDirapiVersion: apps/v1kind: ReplicaSetmetadata: name: myapp-rs-fortunespec: replicas: 1 selector: matchLabels: app: myapp-rs-fortune template: metadata: labels: app: myapp-rs-fortune spec: conta..

파드의 컨테이너는 이미지로부터 파일 시스템을 제공받습니다. 즉, 파드가 종료되면 파드 내에 변경된 데이터 또한 사용할 수 없게 됩니다.새 파드가 생성되면 새 파일 시스템을 제공받게 됩니다.데이터를 유지할수 없기 때문에 상태가 없는 stateless 하다. 라고 합니다. 쿠버네티스의 파드는 새 데이터를 보존하기 위해 외부 저장소 볼륨을 생성하고, 볼륨을 컨테이너에 마운트해서 사용합니다.이 볼륨은 여러 파드에서 동시에도 접근이 가능합니다. 볼륨의 라이프 사이클은 파드의 라이프 사이클과 같아 파드가 생성되면 볼륨이 생성되고 파드가 삭제되면 볼륨도 삭제됩니다.파드가 재시작하는 경우에는 데이터가 유지됩니다. 그러나 새로 도입된 PersisentVolume 및 PVClaim을 사용해 파드와 별개의 라이프 사이클을 ..

apiVersion: apps/v1kind: Deploymentmetadata: name: myapp-rs namespace: default labels: app: myapp-rsspec: selector: matchLabels: app: myapp-rs replicas: 3 template: metadata: labels: app: myapp-rs spec: containers: - name: myapp image: httpd livenessProbe: httpGet: path: / port: 80 startupProbe:..

쿠버네티스에서의 네트워크 환경쿠버네티스의 네트워킹 환경에는 내부용 서비스, 외부용 서비스, 특수한 형태 등이 있습니다. 파드는 클러스터 외부의 요청이나 클러스터 내부의 다른 파드의 요청에 응답하고, 다른 파드의 애플리케이션에 접근하기 위해 파드를 찾을 수 있어야합니다.하지만 쿠버네티스는 기존의 시스템 호스트 이름, 정적 IP 할당 등의 기능을 사용 할 수 없습니다. 1. 파드는 일회성으로 동작하기 위해 설계되어 언제든지 제거될 수 있습니다.2. 특정 노드에 파드가 스케줄링 되고 IP 주소가 동적할당됩니다. 파드의 IP 주소를 예측할 수 없습니다.3. 분산 아키텍처 및 수평 스케줄링의 경우 여러 파드가 같은 애플리케이션을 제공합니다. 각 파드마다 IP가 존재하고, 스케일링될 때마다 클라이언트는 해당 IP를..

데몬셋은 모든 노드의 파드를 실행하도록 하며 systemctl에서 제어하는 모든 것을 의미함.데몬셋이 반드시 하나의 노드에 파드 하나씩 존재하는 것을 보장함따라서 노드가 클러스터에 추가되면 파드가 추가되고, 클러스터에서 제거되면 가비지에 수집됨 ReplicaSets은 각각의 노드에 배치되는 것이 가장 고가용성 구축 방법이지만sched 스케줄러에 의해 제어되어 분산을 보장할 수 없고 노드가 어느 파드에 배치될 지 모름 대표적인 용도론모든 노드에서 클러스터 스토리지 데몬 실행로그 수집 데몬 실행노드 모니터링 데몬 실행SelectormatchExpression가 파드의 label과 AND연산으로 매칭이 되어야 함.metadata의 labels는 matchLabels와는 맞춰줘야 하는 것이 맞고,controll..

워크로드 리소스는 컨트롤러 - 컨트롤러는 파드의 집합 대부분 컨트롤러를 만들고 해당 컨트롤러가 파드를 만들고 파드가 컨테이너를 만듦 쿠버네티스의 빌트인 워크로드 리소스PodControllerReplicationControllerReplicaSetsDaemonSetsJobsCronJobsDeploymentsStatefulSetsHorizontalPodAutoscalerDeployment 및 ReplicaSet.Deployment는 Deployment의 모든 Pod가 필요시 교체 또는 상호 교체 가능한 경우, 클러스터의 스테이트리스 앱 워크로드 관리에 적합함. StatefulSet어떻게든 스테이트를 추적하는 하나 이상의 파드를 동작하게 함 DaemonSet노드-로컬 기능을 제공하는 Pods를 정의함클러스터 ..

파드의 상태파드의 상태는 컨테이너의 상태를 반영한다. 쿠버네티스는 다양한 컨테이너 상태를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를 결정하며, 파드의 status 필드는 phase 필드를 포함하는 PodStatus 오브젝트로 정의phase에 가능한 값Pending : 스케쥴링되기 전, 이미지 받기 전, 컨테이너가 준비 되기 전Running : 컨테이너가 실행 중, 실행 전, 재시작 등Succeeded : 정상종료 : return code 0Failed : 비정상 종료 : return code !0Unknown : 노드의 통신 문제로 상태를 알 수 없음Pending 상태가 지속되는 경우 만족하는(배치 할 수 있는) 노드가 없어(insufficient node) 스케쥴링을 할 수 없는 상태가..

Label Label은 AWS의 TAG와 비슷하여, Label은 리소스에 하나 이상 설정할 수 있고, 중복될 수 있다. Label은 오브젝트의 특성을 식별하는 데 사용한다. metadata의 키를 사용하며, 키는 중복이 가능하다. 권장 레이블 : 권장일 뿐 must는 아니다. 일반적으로 애플리케이션 이름, 버전, 도구, 만든 사용자 등을 붙여준다. 유효한 레이블 조건 63 자 이하(공백일 수도 있음) (공백이 아니라면) 시작과 끝은 알파벳과 숫자([a-z0-9A-Z]) 알파벳과 숫자, 대시(-), 밑줄(_), 점(.)을 중간에 포함 가능 레이블 확인$ kubectl get pods --show-labels$ kubectl get pods -o yaml$ kubectl describe pods  레이블 ..