Cloud Engineering

Pod의 생명주기 Pod는 kubelet에 의해 생성되며, 영구적인 엔티티가 아니라 일시적인 엔티티이다. Pod이 생성되면 UID를 할당받고, node에 스케줄링 되어서 할당된 node 내에서 종료될때까지 남아있는다. Pod은 한번 스케줄링 되어 node에 할당되면 그걸로 끝이라서 일시적이라고 할 수 있는 것이다. 즉, 같은 Pod이 rescheduling 되는 일은 없다. 또한 Pod은 생성되어서 종료될때까지 생명주기를 가진다 Pending Pod이 kube scheduler에 의해서 스케줄링 되기 이전 상태이다. Registry 에서 Image를 pull해오면서 준비하는 상태. 즉, Pod이 만들어지는 단계이다. Running Pod이 만들어져서 Node에 할당이 된 상태이다. Pod 내부서는 하나 ..

Kubernetes Namespace란 쿠버네티스 클러스터를 논리적으로 분할하는 파티션이다. 즉, 클러스터 내에서 오브젝트를 논리적으로 파티셔닝해서 사용할 수 있다. 주의 ) 도커컨테이너의 리눅스 네임스페이스와는 관련이 없다. 쿠버네티스의 네임스페이스 개념은 따로 이해해야 한다. 클러스터의 Namespace 정보 확인하기 $ kubectl get namespace vagrant@kube-control1:~/work/mj$ kubectl get namespace NAME STATUS AGE default Active 24h kube-node-lease Active 24h kube-public Active 24h kube-system Active 24h default : 별도로 네임스페이스를 지정하지 않으면..

Annotation이란 Object에 부가적으로 붙여주고 싶은 정보를 Annotation이라고 한다. Label과 같이 Key: Value 값으로 저장되지만, Label처럼 검색이 되지 않는다. Annotation을 추가하는 방법 1. object에 직접 Annotation을 커맨드로 추가 $ kubectl annotate pods PODNAME ANNOTATION_KEY=VALUE [예시] $ kubectl annotate pods myapp-pod devops-team/developer=Minjee kubectl describe pods 명령어를 통해 다음과 같이 Annotation 필드의 마지막 줄에 내용이 추가 된 것을 확인할 수 있다. 2. Manifest File 생성시에 Annotation ..

Pod 쿠버네티스의 워크로드 리소스 중에서 가장 작은 기본 구성 단위이다. 쿠버네티스에서는 컨테이너 단위로 다루는 도커와 달리 개별 pod 단위로 다룬다. 하나이상의 컨테이너를 포함하는 쿠버네티스의 기본 실행 단위이다. pod가 포함하는 컨테이너는 1개일 수도, 여러개일 수도 있다. pod가 실행하는 컨테이너가 1개이면 pod와 컨테이너를 비슷하게 생각할 수 있다. 그러나 컨테이너가 여러개 실행될 수도 있으므로 구분해야 한다. 네트워크나 Storage에 연결할 때 컨테이너가 아니라, pod 단위와 연결한다. 즉, pod와 연결된 volume storage가 있는 경우 pod 내부의 컨테이너들은 이 공간을 공유해서 사용한다. 네트워크도 동일하게 공유해서 사용한다. pod라는 단위는 하나의 노드에서 실행된다..

Label이란 레이블은 부가적인 정보를 컨테이너에 붙이는 것이며, 레이블을 통해서 오브젝트를 검색/식별할 수 있다. 레이블을 추가한다고 해서 쿠버네티스 클러스터에 직접적으로 영향을 주는 것은 아니지만, 사용자가 쉽게 식별할 수 있다. 컨테이너의 역할에 대해 설명을 레이블로 저장해 놓을 수 있다. 레이블은 key: value 쌍으로 되어 있다. 레이블 형태는 접두어/이름 형식으로 사용가능하다. 단, kubernetes.io/ 와 k8s.io 접두어는 쿠버네티스 환경에서 이미 예약되었으므로 사용할 수 없다. Label은 manifest file 작성시에 metadata 하위에 작성할 수 있다. pod들의 Label을 확인하는 명령어 $ kubectl get pods --show-labels [예시] vagr..

YAML 데이터를 표현하기 위한 언어 흔히 서버에서 데이터를 보낼때 사용하는 JSON 처럼 데이터를 표현하는데 사용된다. 쿠버네티스에서는 YAML 과 JSON 둘 다 사용할 수 있는데, 보통 object를 정의하기 위한 Manifestfile을 작성할 때는 YAML로 작성한다. YAML 자료형 문법 1. 스칼라 / 스트링 : 문자열 데이터를 하나로 묶어서 사용할 수 있다. ‘’ , "" 와 같이 따옴표로 묶지 않아도 YAML에서는 문자열로 사용할 수 있다. kubernetes 'kubernetes' hello kubernetes 2. 리스트 / 배열 리스트의 element들을 - 을 앞에 붙여서 표현한다. - apple - banana - cat 3. 해시 / 딕셔너리 key, value 형식으로 데이터..

API 일반적인 기능들을 코어 그룹의 API에서 다루게 된다. 특정한 종류의 오브젝트들을 API그룹으로 다루게 된다. 오브젝트들 마다 사용할 수 있는 버전과 종류의 API가 있으므로 이에 맞게 사용해야 한다. API를 통해 오브젝트들이 관리되므로 알아두자 API의 종류에는 세가지가 있다. 알파버전 : 실험적인 API버전이다. 실험적인 만큼 불안정하고 버그가 있을 확률이 높다. 따라서 기본적으로 비활성화 되어 있지만 사용할 수는 있다. 버전 이름이 v1alpha 형식으로 되어 있다. 베타버전 : 충분히 코드가 테스트 되어 있고 기본적으로 활성화 되어 있다. 하지만 다음 버전에서 호환성이 변할 수 있다. 그래도 보통 마이그래이션을 할 수 있는 방법이 문서로 제공되므로 알파버전보다는 안전하다고 할 수 있다. ..

모놀리식 아키텍처 단일 프로세스에서 실행되거나 몇몇 시스템에서 몇개의 프로세스로 실행되는 어플리케이션. 전통적인 인프라 환경에서 적용되는 아키텍처이다. 하나의 큰 목적이 있는 서비스 또는 어플리케이션에 여러 기능이 통합되어 있는 구조를 의미한다. → devOps라는 흐름을 적용하기 어렵다 모놀리식 아키텍처의 장점 개발이 간단하고 구성할 때 설계가 간단하다. 또한 배포를 할 때 전체를 한번에 배포하면 되므로 간단하며 확장성 측면에서도 단순하다. 모놀리식 아키텍처의 단점 코드 품질 낮아짐 : 처음 접하는 개발자의 경우 전체 코드를 이해하고 수정하는 것이 어려움 어플리케이션 시작이 오래 걸림 어플리케이션 지속적인 배포가 어려움 : 하나의 컴포넌트를 업데이트하기 위해서 전체 어플리케이션을 다시 배포해야 함 어플..