k8s (22) 썸네일형 리스트형 [k8s] Volume - PV/PVC(퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임) 쿠버네티스에서 볼륨(Volume)을 사용하는 구조는 PV라고 하는 퍼시스턴트 볼륨(PersistentVolume)과 PVC라고 하는 퍼시스턴트 볼륨 클레임(PersistentVolumeClaim) 2개로 분리되어 있습니다. PV/PVC PV는 볼륨 자체를 뜻합니다. 클러스터 안에서 자원으로 다룹니다. 파드와는 별개로 관리되며 별도의 생명 주기가 있습니다. PVC는 사용자가 PV에 하는 요청입니다. 사용하고 싶은 용량은 얼마인지, 읽기/쓰기는 어떤 모드로 설정하고 싶은지 등을 정해서 요청합니다. 쿠버네티스 볼륨을 파드에 직접 할당하는 방식이 아니라 중간에 PVC를 두어 파드와 파드가 사용할 스토리지를 분리했습니다. 이런 구조는 파드 각각의 상황에 맞게 다양한 스토리지를 사용할 수 있게 합니다. 클라우드 서.. [k8s] Service - 헤드리스 서비스(Headless Service) 헤드리스 서비스(Headless Service) 쿠버네티스 서비스 생성 시 .spec.clusterIP 필드 값을 None으로 설정하면 클러스터 IP가 없는 서비스를 만들 수 있습니다. 이런 서비스를 '헤드리스 서비스(Headless Service)'라고 합니다. 헤드리스 서비스의 경우 클러스터 IP가 할당되지 않고, kube-proxy가 이렇나 서비스를 처리하지 않으며, 로드 밸런싱 또는 프록시 동작을 수행하지 않습니다. DNS가 자동으로 구성되는 방법은 서비스에 셀렉터가 정의되어 있는지 여부에 달려있습니다. 헤드리스 서비스에 셀렉터(.spec.selector) 필드를 설정하면 쿠버네티스 API로 확인할 수 있는 엔드포인트(endpoint)가 만들어집니다. 서비스와 연결된 파드를 직접 가리키는 DNA .. [k8s] Service - ExternalName 사용하기 쿠버네티스에서 ExternalName 유형의 서비스는 일반적인 셀렉터에 대한 서비스가 아니라 DNS 이름에 대한 서비스에 매핑합니다. ExternalName 서비스 생성 다음은 ExternalName 타입의 서비스를 설정하는 예시 입니다. 1 2 3 4 5 6 7 8 # externalname.yaml apiVersion: v1 kind: Service metadata: name: externalname1 spec: type: ExternalName externalName: google.com cs 6번 라인에서 .spec.type을 ExternaName으로 지정했으며, .spec.externalName 필드를 google.com으로 설정하였습니다. 연결할려는 외부 도메인 값을 설정한 것입니다. exte.. [k8s] 노드 스케쥴링 - Taints와 Toleratioin(테인트와 톨러레이션) 테인트(Taints)와 톨러레이션(Toleration) 쿠버네티스 클러스터의 특정 노드에 테인트(Taint)를 설정할 수 있습니다. Node Affinity는 Pod가 특정 노드를 선택하게 하는 Pod의 속성이었다면 테인트(Taint)는 반대로 노드가 파드 셋을 제외하도록하는 노드에 설정하는 속성입니다. 기본적으로 테인트를 설정한 노드는 파드들을 스케줄링하지 않습니다. 테인트를 설정한 노드에 파드들을 스케줄링하려면 파드에 톨러레이션(Toleration)을 설정해야 합니다. 그럼 테인트는 톨러레이션에서 설정한 특정 파드들만 실행하고 다른 파드는 실행하지 못하게 합니다. 테인트와 톨러레이션은 주로 노드를 특정 역할만 하도록 만들 때 사용합니다. 예를 들어 데이터베이스용 파드를 실행한 후 노드 전체의 CPU나.. [k8s] Probe - Pod Health Checks(readiness Probe vs liveness Probe) 쿠버네티스 클러스터 상에는 많은 파드가 가동됩니다. 이것들이 정상적으로 움직이고 있는지 아닌지를 체크해서 만일 문제가 있으면 재빨리 복구해야 합니다. 쿠버네티스에서는 컨테이너 애플리케이션이 올바르게 움직이고 있는지 아닌지를 항상 감시하여 문제가 있으면 파드를 자동으로 재시작하는 장치가 있습니다. 위 장치를 Probe라고 합니다. 즉 프로브(Probe)는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단(diagnostic)입니다. 진단 방식(Probe)에는 다음 두가지 가 있습니다. livenessProbe 컨테이너가 실행됐는지 확인합니다. 이 진단이 실패하면 kubelet은 컨테이너를 종료시키고, restart 정책에 따라 컨테이너를 재시작합니다. 컨테이너에 liveness Probe를 어떻게.. [k8s] Job/CronJob Job/CronJob은 웹 서버와 같은 상주 서비스가 아니라 집계 등과 같은 배치 처리 또는 기계학습이나 수치해석과 같은 프로그램의 시작부터 종료까지로 완료되는 작업을 실행하기 위한 리소스입니다. Job(잡) 잡은 실행된 후 종료해야 하는 성격의 작업을 실행시킬 때 사용하는 컨트롤러입니다. 특정 개수만큼의 파드를 정상적으로 실행 종료함을 보장합니다. 예를 들어 데이터베이스 마이그레이션과 같이 한 번의 잡으로 처리가 끝나는 것에 이용합니다. 잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때 까지 계속해서 파드의 실행을 재시도합니다. 지정된 수 만큼 파드가 성공적으로 완료되면, 작업(즉, 잡)이 완료됩니다. 잡을 삭제하게되면 생성한 파드가 정리되며, 일시 중지하게 되면 작업이 다시.. [k8s] 디플로이먼트(Deployment) 디플로이먼트 디플로이먼트(Deployment)는 쿠버네티스에서 상태가 없는(stateless) 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러입니다. 쿠버네티스가 처음 등장했을 때는 Replication Controller에서 앱을 배포했는데 최근에는 디플로이먼트를 기본적적인 앱 배포에 사용합니다. Stateless Application이란? 클라이언트와 서버의 연결 구조에서 불필요한 상태의 반영을 위한 데이터나 리소스가 사용되지 않는 형태의 서비스 구조 파드와 레플리카셋은 '이력'이라는 개념이 없기 때문에 릴리스 후에 변경이 없는 애플리케이션을 관리하는데 적합합니다. 디플로이먼트는 이름처럼 배포 기능을 세분화 한 것으로 파드와 레플리카셋에 버전 관리 기능을 추가한 것이라고 생각하면 이해가 쉽습니다. 단.. [k8s] RelicaSet(레플리카셋) 정리 ReplicaSet 레플리카셋은 클러스터 안에서 움직이는 파드의 수를 유지하는 장치입니다. 클러스터의 파드의 실행을 항상 안정적으로 유지하는 것을 목표로 명시된 파드 개수에 대한 가용성을 보증하는데 사용됩니다. 만약 애플리케이션 오류나 노드 장애 등으로 파드가 정지된 경우 레플리카셋이 자동으로 새로운 파드를 시작합니다. 레플리카셋은 labelSelector의 조건에 따라 파드를 검색하여 가동 중인 파드의 수가 매니페스트 파일의 replicas의 수와 일치하는지 아닌지를 확인합니다. 만약 가동중인 파드의 수가 부족한 경우 새로 파드를 추가하고, 파드의 수가 많을 때는 여분의 파드를 정지시킵니다. 따라서 가동 중인 애플리케이션의 파드 수를 변경하고 싶을 때는 레플리카셋의 replicas의 값을 수정하기만 하.. [k8s] 매니페스트 파일 작성 방법 매니페스트 파일 쿠버네티스에서는 클러스터 안에서 움직이는 컨테이너 애플리케이션이나 네트워크 설정, 배치 실행을 하는 잡 등과 같은 리소스를 작성합니다. 이와 같은 구체적인 설정 정보를 파일로 관리하는데, 이것이 매니페스트 파일(manifest file)입니다. 예를 들어 'Nginx가 움직이는 컨테이너 이미지를 바탕으로 한 웹 프론트 서버를 클러스터 안에서 10개 실행' 하는 경우 다음과 같이 매니페스트 파일을 작성합니다. #webserver.yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: webserver spec: replicas: 10 selector: matchLabels: app: webfront template: metadata: labe.. [k8s] 애플리케이션 설정 정보 관리(ConfigMap/Secrets) 쿠버네티스를 사용하면 컨테이너 애플리케이션이 클러스터 안의 어디에서 움직이고 있는지를 의식할 필요가 없어집니다. 그런데 애플리케이션이 공통으로 이용하는 환경변수 등을 컨테이너 안에 넣어버리면 환경이 바뀔 때 마다 이미지를 만들어야 하므로 번거롭습니다. 쿠버네티스에서는 이런 애플리케이션 정보를 일원 관리하는 장치가 있습니다. 컨피그맵(ConfigMap) 컨피그맵은 애플리케이션의 설정 정보, 구성 파일, 명령 인수, 포트 번호, 애플리케이션 고유의 식별 정보 등을 포드에서 참조할 수 있도록 해 주는 장치입니다. Key-Value 형으로 정보를 관리할 수 있습니다. 예를 들어 Nignx의 설정 파일 등 각 컨테이너에서 공통으로 만들고 싶은 것을 등록하여 일원 관리합니다. 컨피그맵의 정보는 볼륨으로서 마운트할 .. 이전 1 2 3 다음