Pod

Container

하나의 독립적인 서비스를 구동할 수 있는 컨테이너가 존재
각 컨테이너는 port를 갖고 있으며, 한 pod 안의 컨테이너들은 중복 된 port를 갖을 수 없다.
pod은 외부에서 접속을 하지 못하고 클러스터 내부에서만 접속을 할 수 있는 ip를 갖고 있다.
해당 ip는 pod이 생성되면 자동적으로 할당되고 재생성 됐을땐 변경이 되는 가변적인 ip다.

Label

pod를 포함한 모든 오브젝트에 사용 가능하나 pod에서 가장 많이 사용된다.
목적에 따라 오브젝트를 분류하고 그 분류된 오브젝트들만 따로 골라서 연결하기 위함
Key와 value 한쌍으로 구성
한 pod에는 여러개의 label을 다는 것이 가능
service에서 원하는 pod만 선택하는 것이 가능

Node Schedule

pod이 어떤 node에 생성될지 결정하는 것, 수동과 자동 둘다 가능하다

• 수동: pod 생성 시 'nodeSelector'에 node에 해당하는 라벨의 key와 value를 넣어주면 된다.
• 자동: node의 메모리와 pod이 사용 될 메모리를 스케쥴러가 확인 후 자동으로 스케쥴링

Service

ClusterIp

service는 clusterIP를 갖고 있어 pod을 접속할 수 있게해준다
pod의 ip는 가변적인 반면 cluserIP는 직접 지우지 않는 이상 계속 유지된다.
cluster 내의 object에서는 접근 가능하나 외부에선 접근 불가

NodePort

외부 트래픽이 node로 들어오면 해당 node는 nodePort에 해당하는 service에 접근, 해당 service가 다시 pod에 접근하는 방식
한 node에서 nodePort를 접근 시 다른 node에 있는 pod에 접근할 수 도 있는데 'externalTrafficPolicy' 설정을 'local'로 하여 같은 node 내 pod만 접근하게 설정할 수 도 있다.

Load Balencer

같은 개념이나 외부에서 접근 시 어떤 노드에 접근할찌 지정해주는 리버스 프록시
내부 ip가 노출되지 않기 때문에 직접 서비스를 할때 사용한다

Volume

EmptyDir

한 팟 안의 컨테이너끼리 데이터를 주고 받을 때 사용
pod 생성 시 만들어지고 삭제시 같이 삭제된다.

hostPath

node 안에 위치하며 해당 node 안에 있는 pod들이 data를 주고 받을 때 사용
pod이 죽더라도 emptydir과 다르게 유지

PVC/ PV

pod에 영속성 있는 volume을 제공하기 위해 사용
pv를 통해 volume에 연결
pod은 pvc를 사용하여 pv에 연결

ConfigMap, Secret

개발과 상용에 동일한 설정이 다른 동일한 컨테이너가 있을때 컨테이너의 설정 값들은 컨테이너 안에서 설정이 되기 때문에 각 환경별 이미지 파일을 관리해야하고 이는 비효율적이다.
pod 생성 시 configMap과 secret을 연결하여 해당 pod 안의 container는 이 값을 참도한다.

ENV

키와 밸류로 구성 된 configMap과 secret을 memory에 저장하고 있는다

ENV(File)

키는 파일명 밸류는 값으로 저장하고 있는다
한번 주입하면 끝으로 수정을 해도 pod의 설정은 변하지 않는다

Volume Mount

file 방식과 동일하나 'mountPath' 값을 yml 파일에서 설정
계속 참조를 하고 있기 때문에 configMap이나 secret 값이 변하게 된다면 pod의 설정도 같이 변하게 된다.

Namespace, ResourceQuota, LimitRange

한 쿠버네티스 클러스터는 여러개의 namespace로 구성되어있다.
쿠버네티스 클러스터의 자원은 한정 될 수 밖에 없다.
각 namespace별 resourceQuota를 줘 한 namespace서 사용할 수 있는 최대 메모리를 설정
limitRange를 통해 한 nameSpace안에 생성 될 수 있는 pod의 최대 메모리를 제한

Controller

Controller의 기능은 크게 auto healing, software udpate, auto scaling, job이다.

• AutoHealing: pod가 죽었을때 다른 노드에 같은 pod을 생성해 준다.
• AutoScaling: 하나의 pod에 너무 많은 부하가 걸렸을때 트래픽을 분산시켜줘 pod이 죽지 않게 해준다.
• SoftwareUpdate: 버전 업데이트와, 버전 업데이트시 장애가 생겼을때 롤백을 도와준다.
• 일시적인 작업을 해야할때 필요할때 pod을 생성해 작업을 하고 pod을 죽여 효율적 자원 활용 가능
  Controller과 pod은 label과 selector로 연결

Replication Controller, ReplicaSet

Template

selector에 pod의 label에 해당하는 값을 넣는다
pod이 죽었을때 controller 안의 template값에 일치하는 pod을 만들어준다
template을 update하고 pod을 죽이면 새로운 pod을 생성할때 해당 template 속성을 갖고있는 pod을 생성해준다

Replicas

controller 안에 replicas 숫자만큼 pod을 생성
이걸 활용해 scale in, scale out이 가능하다

Selector

ReplicaSet에만 존재
matchLabels: 키와 밸류가 모두 같아야 pod과 연결
matchExpressions: 키와 밸류 값이 일치하지 않아도 조금은 유동적으로 pod과 연결이 가능

Deployment

크게 recreate, rolling update, blue/green, canary 4가지 방식이 있다.

• recreate: 이전 버전의 pod을 죽이고 새 버전의 pod 배포, 자원을 효율적으로 사용 가능하나 downtime이 발생
• rolling update: 이전 버전의 pod을 하나 죽이고 새 버전의 팟을 하나 생기고 순차적으로 진행한다. Downtime은 발생하지 않으나 많은 리소스가 필요
• blue/green: 새로운 버전의 controller을 만들어 pod을 생성 후 서비스에서 새로운 버전의 pod과만 연결하게 한다. Downtime은 발생하지 않고 롤백이 쉬우나 순간적으로 많은 리소스가 필요하다
  
• canary: 마찬가지로 새로운 버전의 controller을 생성하여 불특정 다수에게 일종의 실험식으로 배포를 해보고 이상이 없을 시 새로운 버전의 controller만 남기고 기존의 controller은 삭제하는 방식. Down time은 역시 없고 롤백도 쉬우나 새로운 버전에 이상이 있을 경우 실 사용자가 이를 겪는 경우가 발생
  

DaemonSet, Job, Cronjob

DaemonSet

모든 node에 daemonSet pd가 한개씩 생성

• 사용처: 노드의 성능 확인, 로깅,노드들을 스토리지에 활용할때
  selector과 template으로 구성 되어있고, template 안에 'nodeSelector'을 통해 어떤 node에 pod을 생성할지 세부적으로 지정이 가능하다
  

Job, Cronjob

pod이 죽었을때 replicaSet과 job을 통해 만들어진 pod들은 다른 node에 pod이 생성된다.
ReplicaSet을 통해 만들어진 node들은 recreate되고 다른 node에서 restart가 되는 반면, job을 통해 만들어진 node들은 recreate 된 후 restart하지 않고 finish 된다
'completion'은 총 생성 되는 pod의 갯수, 'parallelism'은 동시에 생성되는 pod의 갯수, 'activeDeadlineSeconds'는 생성 된 pod 이 살아있는 기간이다
Cronjob은 특정 job을 반복적으로 실행(사용처: db백업, 메세지 보내기 등등)