스낵 코드

볼륨컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 어플리케이션에 몇 가지 문제가 발생합니다.첫 번째 문제는 컨테이너가 Crash되더라도 kubelet은 컨테이너를 초기화된 상태로 재시작하기 때문에 파일이 손실되는 문제가 발생합니다. 두 번째 문제는 pod에서 같이 실행되는 컨테이너간에 파일을 공유할 때 발생합니다. 이러한 문제로 마운트하여 볼륨을 사용하기도 합니다.    1. 컨피그맵(ConfigMap)컨피그맵은 구성 데이터를 파드에 주입하는 방법을 제공합니다. 컨피그에 저장된 데이터는 configMap 유형의 볼륨에서 참조된 후 파드에서 사용합니다. 컨피그맵을 참조할 때, 볼륨에 ConfigMap의 이름을 명시합니다. 컨피그맵의 특정 항목에 사용할 경로를 사용자 정의할 수 있습..

1. 서비스란? - 파드를 통해 사용자에게 서비스를 제공하다가 장애가 발생하면 가용성을 보장할 수 없기 때문에 Service를 통해 가용성을 보장한다. - Service를 통해 파드의 로드밸런싱이 가능하며, 만약 파드가 정상적인 구동이 불가능할 경우에는 해당 파드가 Service의 Endpoint에서 제외된다. - 문제가 된 파드는 deployment에 의해 다른 IP, Name으로 다시 구동되고 Service의 Endpoint에 자동으로 추가된다. - 따라서 파드가 외부와 통신할 수 있도록 클러스터 내부에서 고정적인 IP를 갖는 역할을 하고 있다. - Service를 정의할 때는 spec.ports 아래에 연결하고자 하는 항목 별로 각각 2개씩의 포트가 지정되어야한다. 1) targetPort : 파드..

PV (PersistentVolume) - 관리자가 프로비저닝 했거나 스토리지 클래스를 사용해 동적으로 프로비저닝한 클러스터의 스토리지 - 볼륨과 같은 볼륨 플러그인이지만 PV를 사용하는 개별 Pod와 독립적인 수명 주기를 가짐 PVC (PersistentVolumeClaim) - 사용자가 볼륨을 사용하기 위해 PV에 하는 스토리지 요청 - Pod는 노드 리소스를 소모하고 PVC는 PV 리소스를 소모한다. 1. PV의 Lifecycle 1) Provisioning : PV를 생성하는 단계로 동적 프로비저닝과 정적 프로비저닝이 있다. - 동적 프로비저닝 : 미리 적정 용량의 PV를 만들어두고 사용자의 요청 시, 미리 만들어 둔 PV를 할당함. 제한된 스토리지 용량일 때 유용 - 정적 프로비저닝 : 사용자가..

1. Request / Limit - 파드를 어느 노드에 배포할지 스케쥴링할 때, 해당 노드에서는 충분한 자원이 파드에 할당되어야 함 - cpu/memory와 같은 컴퓨트 리소스 외에도 gpu/storage 리소스에 대한 필요한 양을 명시할 수 있음 - CPU는 ms(밀리세컨드) 단위로 지정하며 CPU 1000ms 가 1vCore(가상 CPU 코어)이며 메모리는 Mb를 사용 apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "12..

1. ReplicaSet - 파드를 생성 및 복제하고, 복제된 파드 수를 yaml 파일에서 생성된 개수만큼 항상 유지 apiVersion: apps/v1 kind: Replicaset metadata: name: nginx-rs labels: app: nginx-rs tier: nginx-rs spec: replicas: 3 selector: matchLabels: tier: nginx-rs template: metadata: labels: tier: nginx-rs spec: containers: - name: nginx-rs image: nginx - selector: 어떤 label의 파드를 선택하여 관리할지에 대해 설정한다. 위에서는 tier: nginx-rs 라는 라벨을 가진 파드들을 식별하여 ..

Label & Selector 1) Label - 객체에 연결된 key-value 쌍 값 - 리소스를 논리적인 그룹으로 나누거나 식별하기 위해 붙이는 이름 - 객체 생성 시 첨부할 수 있으며 언제든지 추가 및 수정 가능 2) Selector - 특정 Label에 해당하는 객체를 식별하거나 검색할 수 있음 # Node Label 확인 kubectl get nodes --show-labels # Node Label 추가 kubectl label nodes k8s-worker01 svc=web apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPol..

1. Pod 란? - 쿠버네티스 노드 내에 최소 한 개 이상의 컨테이너를 가진 파드가 실행되고 있으며, 파드마다 다른 IP를 가지고 있고 컨테이너끼리 통신이 가능함 - 파드 내 컨테이너끼리 볼륨(저장소)을 공유하며, 컨테이너가 죽고 재시작해도 파드가 살아있는 한 Shared volume은 유지 됨 - init-container 가 기본적으로 생성되며, 해당 컨테이너의 네트워크 인터페이스(CNI)를 파드 내 다른 컨테이너에서도 공유하여 사용 2. Pod의 Lifecycle - Pending: 파드가 클러스터에 승인되었지만 한 개 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않은 상태 - Running: 파드가 노드에 바인딩(할당)되고 모든 컨테이너가 생성된 상태 - Succeeded: 파드에 있는..

1. Control Plane 1) kube-apiserver - 클러스터로 들어오는 요청을 가장 앞에서 접수한다. - kubectl을 사용하여 명령을 수행할 경우 kube-apiserver로 전송한다. 2) kube-scheduler - 새로 생성된 파드 감지 후, 어떤 노드에 배치할지 판단한다. - 파드 스케쥴링 결정을 위해 요구사항, 정책제어, 어피니티(스케쥴링에 관한 조건), 라벨 등을 요소를 고려한다. 3) kube-controller-manager - 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트 - 노드 컨트롤러 : 노드가 다운되었을 때, 통지와 대응에 관한 책임을 가진다. - 잡 컨트롤러 : 일회성 작업인 Job 오브젝트를 감시하여 해당 작업을 완료할 때 까지 동작하는 파드를 생성한다..

[ 쿠버네티스란? ] 컨테이너화된 워크로드와 서비스를 관리하기 위한 오케스트레이션 도구 [ 쿠버네티스를 관리하는 방법 ] 1.관리형 쿠버네티스 - 퍼블릭 클라우드 업체에서 제공하는 관리형 쿠버네티스 (EKS, AKS, GKE) - 구성이 이미 모두 갖춰져있고, 마스터 노드는 클라우드 업체에서 관리한다. - 사용자는 필요한 부분들을 애플리케이션에 올려놓고 애플리케이션을 배포하여 사용한다. 2.설치형 쿠버네티스 - 직접 설치할 수 있도록 패키지화 된 쿠버네티스를 사용한다. (Rancher, Redhat OpenShift) 3.구성형 쿠버네티스 - 사용하는 시스템에 패키지화 된 쿠버네티스를 자동으로 구성해주는 구성형 쿠버네티스 (kubeadm, kops, KRIB, Kuberspray) - 관리형/설치형 쿠버..

- 컨테이너는 OS의 기능을 활용해서 프로세스를 격리하고, 격리된 프로세스가 리소스를 쉽게 공유할 수 있도록 해준다. - 게다가 격리된 프로세스 형태로 실행되므로, 환경에 상관없이 안정적이며 일관된 배포를 제공한다. 1. VM 과 차이점 VM은 하이퍼바이저(가상화 소프트웨어 계층) 을 통해 하드웨어를 가상화한다. 컨테이너는 시스템 커널 OS를 공유하기 때문에 각 애플리케이션마다 OS가 필요하지 않는다. 2. 컨테이너의 이점 시스템 OS 커널을 공유함으로써 애플리케이션마다 OS가 필요하지 않아 크기가 작고 가볍다. 이식성 및 플랫폼 독립성 : 컨테이너가 모든 종속 항목들을 자신과 함께 전달하므로, 호스트 운영체제와 상관없이 동일하게 유지되며 이를 재구성하지 않고 바로 실행할 수 있다. 유지관리 효율 : 컨..