[Kubernetes] Kubernetes의 구성요소 ! (Object)

Kubernetes 구성요소 

kubernetes를 구성하는 객체(Object)와 객체를 관리하는 컨트롤러(Controller)로 구성된다.

 

객체에는 Pod, Service, namespace, volume 이 있고

컨트롤러에는 DemonSet, Deployment, ReplicaSet, StatefulSet, Job 이 있다.

 

 

kubernetes는 객체 생성을 위해 kubernetes API를 사용할 때, JSON형식으로 데이터를 제공해야 하는데, kubectl에서 yaml파일의 형식을 JSON으로 변환시켜 준다.

 

Kubernetes는 이러한 객체와 컨트롤러를 Yaml 파일의 형식으로 템플릿을 작성하고 배포한다.

Yaml파일 템플릿을 작성하는 기본적인 구조는 다음과 같다. 아래 4개는 꼭 들어가야함!

 

 

• apiVersion:  사용하는 쿠버네티스 api 버전을 명시
• Kind: 사용할 객체나 컨트롤러 지정
• metadata: 객체의 이름이나 레이블 설정
• spec: 파드가 어떤 컨테이너를 가지고 실행하며, 어떤식으로 동작하는지 명시

 

* 대,소문자 가리니까 오타주의!!!!!

* Tab키 지원 안하니까 주의!!!!!!

 

 

예시)

 

example.yaml

 

apiVersion: v1

Kind: Pod

metadata:

  name: nginx

spec: 

  container:

  - name: nginx

    image: nginx:1.8

 

이런식으로 Yaml 파일을 만들어 컨테이너를 배포할 템플릿을 작성한다!

---

1. 객체 (Object)

Kubernetes를 구성하는 오브젝트는 리소스들의 가장 기본적인 구성 단위이다. 

 

 

1-1. Pod

Pod는 Kubernetes의 가장 기본적인 배포 단위이다. (컨테이너)

 

Kubernetes는 컨테이너를 직접적으로 관리하는 것이 아니라 이러한 Pod를 관리하게 된다.

Pod는 컨테이너 이미지 하나만 올리는 것이 아니라 컨테이너와 네트워크 및 스토리지가 포함된 Pod로 배포할 수 있고, 기본적으로 하나의 Pod의 1개의 컨테이너를 올리지만 하나 이상의 컨테이너를 배포할 수도 있다.

 

만약, 웹서버를 구성한다고 하면 APM을 각각 1개의 Pod를 따로 올리는 것이 아니라 하나의 Pod에서 3개의 컨테이너를 넣을 수 있다.

 

(예시)

 

apiVersion: v1

kind: Pod

metadata:

  name: Test-Pod

spec:

  containers:

   - name: apache

     image: httpd:latest

     ports:

     - containerPort: 80

  containers:

   - name: mysql

     image: mysql:latest

     ports:

     - containerPort: 3306

 

이런식으로 하나의 Pod에 여러개의 container 를 명시 가능!

 

이렇게 작성되는 Pod는 하나의 노드에만 배치될 수 있고, Pod 내의 컨테이너가 각각 다른 노드에 배치될 수는 없다.

때문에, Pod 내부의 컨테이너가 전부 실행되어야 Pod의 상태가 Running이 된다. 

 

 

그러면 각각의 다른 컨테이너들이 서로 어떻게 통신을 할 수 있는걸까??? 

 

1. Pod 내의 컨테이너들은 서로 IP와 Port를 공유한다

 

2. Pod 내의 모든 컨테이가 공유하는 볼륨을 설정할 수 있다.

 

이러한 장점때문에 Kubernetes는 Pod를 통해 컨테이너를 쉽게 관리할 수 있다.

---

1-2. Service

pod는 삭제되고 재생성되는 작업이 빈번하며, 그 때마다  IP가 고정적이지 않고 계속해서 바뀌게 된다. 이처럼 계속해서 바뀌는 IP를 고정적으로 하고 내부,외부에서 Pod로 접근하기 쉽게끔 하기 위해서 사용한다.

만약 Service를 사용하지 않으면 IP는 수시로 변하고 그때마다 일일히 수정해줘야 하기 때문에 번거로울 것이다.

 

Service는 Label과 Label Selector를 사용하며, 일치하는 Label을 가진 Pod에 접근할 수 있다. 이외에도 Service는 로드밸런싱을 지원하기 때문에 통신하는데 있어서 이점을 준다.

 

 

 

이러한 Service에는 4가지의 타입이 존재한다. 각 타입별 특징에 대해서 알아보자

 

• Load Balancer
• Cluster IP
• Node Port
• External Name

 

 

1. Load Balancer

Load Balancer를 통해서 쿠버네티스 외부에서 접근할 때 부하 분산 기능을 제공한다.

 

2. Cluster IP

Cluster IP는 Service의 기본값이다. 이름처럼 클러스터 내부에서 파드끼리 통신하기 위한 기능으로 Cluster IP를 이용해 Service에 연결된 각 파드들에 접근할 수 있다.

하지만, 클러스터 내부의 IP이기 때문에 External IP가 존재하지 않아서 외부에서는 이 IP를 통해서 접근할 수 없다.

 

3. Node Port

Service에 포트를 지정해서 할당하는 방식으로 클러스터 외부,내부 모두 통신이 가능하다.

port와 targetPort를 사용해서 트래픽을 포트포워딩 하게 된다.

 

 

port:80

targetPort:8080

NodePort:30080

같이 지정할 경우 Port 80을 통해 파드들의 targetPort 8080으로 접근하는 방식이다.

NodePort를 통해 외부에서 접근또한 가능하게 한다.

 

4. External Name

External Name은 주로 클러스터 내부에서 외부의 특정 주소로 접근할때 사용한다.

 

type: ExternalName

externalName: www.naver.com   

 

같이 지정할 경우 Service를 www.naver.com으로 연결해준다 

 

---

1-3. Volume

컨테이너는 삭제되면 안에 있던 데이터들까지 모두 삭제하게 되는데 컨테이너가 삭제 되더라도 데이터가 사라지지 않고 보존되어야 하는 경우가 있다. 이러한 경우에 사용하는것이 Volume 기능이다. 

Volume을 사용하면 컨테이너가 재시작 하더라도 데이터가 사라지지 않고 유지해주는 저장소의 역할

 

 

Volume의 종류

 

• emptyDir 
• hostPath
• PV/PVC

 

emptyDir

emptyDir은 컨테이너들끼리 데이터를 공유하기 위해 사용한다. emptyDir은 임시저장소이기 때문에 pod가 삭제될때 같이 삭제된다. 때문에 중요한 데이터를 emptyDir에 저장해서는 안된다.

 

hostPath

host의 path를 volume으로 사용한다. emptyDir과는 다르게 path를 각각의 pod들이 mount해서 공유하기 때문에 pod가 삭제되어도 데이터는 해당 path에 계속 유지된다.

 

PV/PVC

Local volume 또는 외부 Volume (aws, azure,git 등등...)들을 PV(persistent volume)에 정의하고 연결한다.

이러한 PV는 pod에 바로 연결하지 않고 PVC를 통해서 연결시킨다.

 

---

1-4. Namespace

namespace는 쿠버네티스 클러스터 내의 논리적인 분리 단위이다. namespace를 지정해서 pod,service같은 리소스들을 가상의 그룹으로 만들어 관리할 수 있게 한다.

 

주의할 점은 namespace는 논리적으로 분리한 것이기 때문에, 물리적 분리가 아님.!! 다른 namespace간에도 통신가능하고 서로 영향을 끼칠 수 있음!

 

 

 

 

 

Kubernetes의 구성요소인 오브젝트에 대해서 알아보았다.. 컨트롤러는 다음 글에서 정리해봐야겠다.