Cloud Engineering

Persistent Volume 과 Persistent Volume Claim PV는 쿠버네티스 클러스터의 외부 공간과 연결하여 저장공간을 제공하는 볼륨이며 pod에 영구적인 저장 방법을 제공한다. Persistent Volume 을 사용하기 위해서는 Pod 과 직접적으로 연결되는 Persistent Volume Claim 이 필요하다. PV와 PVC로 분리한 이유는 클러스터에서 어플리케이션을 배포하고 싶어하는 개발자가 스토리지에 대한 지식이 없어도 쿠버네티스에서 저장공간을 필요한 만큼 가져다 쓸 수 있도록 하기 위해서이다. PV 와 PVC의 life cycle Provisioning : PV가 생성되는 단계이다. PV의 종류에는 정적 프로비저닝과 동적 프로비저닝이 있다. Binding : PVC 를 만..

Ingress 컨트롤러 Ingress 컨트롤러는 NodePort, LoadBalancer 서비스 타입처럼 서비스를 외부에 노출시키는 방법 중 하나이다. NodePort, LoadBalancer와 다른점은, NodePort, LoadBalancer는 Layer 4 (UPT/TCP) 에서 작동하는 반면, Ingress 는 Layer 7 (HTTP/HTTPS) 에서 로드밸런싱을 제공한다는 점이다. Ingress 컨트롤러는 요청이 왔을 때, 어플리케이션이 사용하는 프로토콜(HTTP/HTTPS) , 서버 주소, 어플리케이션이 구체적으로 접근하고자 하는 리소스의 경로를 보고 특정한 어플리케이션에 요청을 전달해주게 된다. Layer 4 이하의 헤더의 정보들만으로는 이러한 트래픽 요청 사항을 처리할 수 없어서 Laye..

쿠버네티스 Volume 쿠버네티스에서 Pod는 이미지로부터 파일 시스템을 제공받아 사용한다. 따라서 Pod가 삭제되면 저장공간도 같이 삭제된다. 이러한 쿠버네티스 컨테이너 상태를, 데이터를 유지하지 않으므로 Stateless 하다고 한다. 따라서 쿠버네티스 클러스터 환경에서는 데이터를 영구적으로 보존하기 위해서 외부 볼륨을 사용할 수 있다. 상황에 따라 간단히 테스트 해보기 위한 간단한 볼륨을 사용할 수 도 있다. 쿠버네티스 볼륨의 종류 emptyDir : 아무 데이터도 없는 빈 디렉토리를 제공한다. 동일한 Pod 내에서 다른 컨테이너들끼리 공유하여 접근할 수 있는 공간이다. hostPath : 각 노드들마다 분리된 저장공간을 제공하는 볼륨이다. gitRepo : 현재는 depreciated 되었다. G..

1. 쿠버네티스 네트워크 아키텍처 보통 쿠버네티스 아키텍처에서는 노드가 여러개인 구조를 가진다. 쿠버네티스 클러스터 환경에서 같은 대역의 네트워크 (192.168.56.0/24) 로 묶여져 있을 것이며, 노드들마다 IP가 할당된다. 그런데 이는 노드에 부여한 IP이지, Pod에 바로 접근할 수는 없다. 각각의 Pod들이 서로 통신을 할 수 있도록 하는 것이 CNI (Container Network Interface)의 역할이다. Pod와 호스트의 인터페이스를 연결해준다. CNI를 통해서 Pod에 할당되는 IP주소로 통신할 수 있게 한다. 그런데 이 Pod라는 것은 일회성으로 사용되는 목적으로 운영된다. 따라서 Pod에 문제가 생기거나 삭제되어버리면 IP가 변동되어 클라이언트 측에서는 Pod의 IP를 예측..

Jobs Job 은 하나 이상의 pod들이 성공적으로 종료되기 전까지 실행을 반복하는 오브젝트 컨트롤러이다. 작업을 수행하는 pod 이 성공적으로 완료되면 pod이 맡은 임무를 성공적으로 완료한 것으로 간주하여 pod을 종료시킨다. 또한 Job은 pod들을 병렬적으로 수행하도록 설정할 수 있다. Job은 데몬셋, 레플리카셋과 달리 레이블 셀렉터를 사용자가 직접 지정하지 않으며, 컨트롤러에 의해 부여된 고유값인 UID를 레이블 셀렉터로 사용한다. Job은 pod 1. 직렬적으로 작업 처리하기 (Non-parallel Job) apiVersion: batch/v1 ## batch 그룹의 v1 api 사용 kind: Job # Job object 선언 metadata: name: myapp-job spec: ..

데몬셋 (Daemon Set) 데몬셋은 레플리카셋이나 레플리케이션 컨트롤러처럼 object controller의 한 종류로 pod들을 관리하는 컨트롤러이다. 데몬셋은 Node Label 이 일치하는 노드들 에 pod 복제본이 각 1개씩 실행되도록 관리한다. 만약 Node Label에 대해서 따로 설정을 해주지 않는다면 기본적으로 control plane을 제외한 워커로드에서 pod가 1개씩 실행되도록 관리하는 컨트롤러이다. 레플리카셋 또는 레플리케이션 컨트롤러와 차이점은 별도로 pod 복제본 수를 제어하지 않는다는 점이다. 즉, 처음에 생성한 pod에 문제가 생겨서 삭제가 되면 레플리카셋이나 레플리케이션 컨트롤러는 복제본 pod을 스스로 생성해 준다. 그렇지만 데몬셋은 pod이 삭제가 되더어도 다시 po..

Replication Controller 쿠버네티스의 컨트롤러는 파드 복제본 (replicas)들의 숫자를 보장해주는 역할을 한다. 레플레케이션 컨트롤러는 이용가능한 상태의 pod을 원하는 수 만큼으로 관리해 주는데, pod가 원하는 수 보다 많은 경우 줄여주고, 원하는 수 보다 적은 경우 자동으로 늘려준다. 레플리케이션 컨트롤러를 구성하는데 필요한 요소는 레이블 셀렉터, 파드 템플릿, 복제본의 수가 있다. 레이블 셀렉터는 key :value 형식으로 설정되며, 생성 및 관리를 할 파드에 대해 지정하는 것이다. 파드 템플릿은 파드를 어떤식으로 구성할 것인지 설정 내용에 대한 것이다. 이 파드 템플릿과 동일하게 복제본들이 만들어 진다. 복제본의 수는 지정해 주지 않으면 디폴트 값이 1 이며, 지정해 주면 ..

컨테이너 프로브 실제 서비스를 운영하게 되면 쿠버네티스의 컨테이너를 배포해서 운영하게 될 것이다. 그런데 컨테이너가 정상적으로 동작하지 않으면 서비스에 장애가 발생할 것이므로, 컨테이너의 상태를 확인해야 할 것이다. 컨테이너 프로브는 컨테이너가 제대로 실행되고 있는지 진단한다. 컨테이너 프로브에는 세가지 종류가 있으며, 이를 Manifest File 작성 시에 설정해 줄 수 있다. 프로브는 컨테이너의 상태에 따라 startupProbe, readinessProbe, livenessProbe 순서로 동작한다. 프로브는 설정하지 않을 수도 있으며, 원하는 프로브들을 여러개 설정할 수 있다. 1. startupProbe 컨테이너 내의 어플리케이션이 시작되었는지 확인한다. 프로브들 중에서 가장 먼저 실행되는 프..