Pod

쿠버네티스에서 Pod를 정의하는 정의하는 yaml의 형태는 다음과 같다.

(Pod 뿐만 아니라 다른 오브젝트도 동일)

# pod-definition.yml

apiVersion:

kind:

metadata:

spec:
	containers:
		- name:   # - before the name indicates, its first item in the list
			image:

Pod 관련 명령어

kubectl create -f [FILE NAME].yml

kubectl create -f [FILE NAME].yml --record 또는 kubectl apply -f [FILE NAME].yml

kubectl get pods

kubectl describe pod [POD NAME]

Labels, Selectors 개념

  • Labels and Selectors act as a filter, filtering pods for ReplicsSet
  • Labels와 Selectors는 필터로서의 기능을 함. ReplicaSet 뿐만 아니라 추후 다룰 Deployment, Service 등에서도 사용됨.

필터링 또는 파드를 선택하기 위한 용도로도 많이 사용 됨

  • 파드에 label을 부여하고 selector를 통해 매치. 추후 파드가 수십 수백개가 되는 상태에서도 매니징을 가능케 함
  • type 유형 별 (파드, 레플리카셋, 디플로이먼트, 서비스 등등)
  • app 애플리케이션 별
  • function 기능 별

ReplicaSet

Replication Controllers (OLD)

  • High Availability
    • 레플리카 Pod instance를 생성하고 관리함
    • Pod가 하나인 상황에서도, 만약 죽으면 새로 다시 올리는 역할을 함
  • Load Balancing & Scaling
    • multiple pod , multiple node 상황에서도 관리

Replication controller 예시

# rc-definition.yml

apiVersion: v1 # v1에서는 여전히 replication controller 지원함

kind: ReplicationController

metadata:
	name: myapp-rc
	labels:
		app: myapp
		type: front-end

spec: 
	template: 
		
		# Pod 생성 때 사용했던 정보를 다 가져옴 
		metadata:
			name:
			labels:
				app:
				type:
		spec:
			containers:
				- name: 
					image: 
	
	# template 과 같은 레벨에서 정의함
	replicas: 3

kubectl create -f [RC FILE NAME].yml

kubectl get replicationcontroller

kubectl get pods

ReplicaSet 정의

  • Replicaiton Controller 는 deprecated 되어 대부분 ReplicaSet 으로 대체됨
  • 생성된 복수개의 Pod 를 모니터하며, fail이 생길 경우 새 Pod를 생성함.

ReplicaSet 예시

# replicaset-definition.yml

apiVersion: apps/v1 # apps/v1 에서부터 지원

kind: ReplicaSet

metadata:
	name: myapp-replicaset
	labels:
		app: myapp
		type: front-end

spec: 	
	# 갯수
	replicas: 3

	# ReplicaSet에서는 어떤 Pod를 쓸지 정의 
	selector: 
		
		matchLabels: # Pod에서 명시한 label과 같은 label에서만 레플리카를 만든다
			type: front-end			

	# replicas와 같은 레벨에서 정의
	template: 
		# Pod 생성 때 사용했던 정보를 그대로 다 가져옴 
		metadata:
			name: myapp-pod
			labels:
				app: myapp   # labels가 위와 매칭하도록 주의!!!!!!
				type: front-end
		spec:
			containers:
				- name: nginx-container
					image: nginx

kubectl create -f replicaset-definitnion.yml

kubectl get replicaset

kubectl get pods

ReplicaSet 스케일링 방식

  1. 레플리카 갯수 업데이트
    • kubectl replace -f replicaset-definition.yml
  2. 이미 정의된 replica의 파라미터를 수정하기
    • kubectl scale --replicas=6 -f replicaset-definition.yml
    • kubectl scale —-kubekreplicas=6 replicaset(TYPE) myapp-replicaset(NAME)

주의: 정의된 내용을 수정한다고 바로 스케일링이 되는 건 아님

변경사항을 바로 적용하고 싶다면

  • kubectl edit replicaset myapp-relicaset 으로 수정(k8s가 자체로 생선한 설정파일이므로, 여기는 수정을 주의해야 함)
  • kubectl scale replicaset myapp-replicaset —-replicas=2 바로 얄짤 없이 적용

가장 적절한 방식은 definition yaml 파일을 수정한 후, kubectl apply를 통해 적용하는 것. (정의 파일과 현상태가 sync 된 상태를 유지할 수 있음)

Deployment

  • 상황
    • 여러 개의 인스턴스를 배포한 상황일 때, 인스턴스를 업그레이드 해야 한다면, 한꺼번에 업데이트 하는 것은 바람직하지 않음 → 다운 타임 등으로 유저가 영향을 받을 수 있음
  • Deployment 사용
    • Deployment는 ReplicaSet보다 더 상위의 객체이며
    • 배포된 여러 개의 Pod 들을 seamlessly 하게 업데이트하고 끄고 닫을 수 있게 함

Deployment 정의

# deployment-definition.yml

apiVersion: apps/v1

kind: Deployment

metadata:
	name: myapp-deployment
	lables:
		apps: myapp
		type: front-end

spec:
	template:
		metadata:
			name: myapp-pod
			labels:
				app: myapp
				type: front-end

		spec:
			containers:
				- name: nginx-2container
					image: nginx

	replicas: 3
	selector:
			matchLabels:
				type: front-end

	strategy:
		# strategy를 명시하지 않으면 default는 RollingUpdate 이다.
		type: RollingUpdate
		rollingUpdate:
			maxUnavailable: 1
  • kubectl create -f deployment-definition.yml
  • kubectl get deployment
  • kubectl explain deployment

Rollout Deployment & Rollback

Rollout

Rollout and Versioning

  • 새로운 버전의 컨테이너가 생성되면 rollout 을 시행
  • deployment 생성 → rollout 실행 → 새로운 revision 생성
  • 애플리케이션이 새 컨테이너로 업데이트되면 → 새로운 rollout 실행 → 새로운 revision 생성
    • Rollout history tracking 가능
    • Rollback도 가능

Rollout commands

  • kubectl rollout status deploymnet/myapp-deployment
  • kubectl rollout history deployment/myapp-deployment
  • kubectl rollout history deployment <deployment-name> --revision=<revision-no>
    • 특정 revision number를 통해 히스토리를 선택해서 조회할 수 있음.

Rollback 하는 방법

롤아웃을 취소하는 방식으로 롤백함.

  • kubectl rollout undo deployment/<deployment-name>
  • kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-no>
    • 특정 revision으로 롤백 -

Deployment Strategy - Recreate & RollingUpdate

  1. Recreate Strategy

    • 실행되는 인스턴스 다 내림
    • 새 인스턴스 올림

  2. One-by-one (Rolling update) - default strategy

    • 하나씩 내리고 하나씩 올림
    • 디폴트 설정

Recreate, RollingUpdate 업데이트하는 법

  • kubectl edit -f deployment-definition.yml --record
  • kubectl apply -f deployment-definition.yml

Blue-Green

  • 우선 배포 하고 나서, 라우팅 트래픽을 한번에 새 버전으로 옮기는 방법
  • 현행 deployment (blue) 가 띄워져 있는 상태로 업데이트 된 deployment (green)을 생성함.
  • 이후 로드밸런서가 Green deployment를 가리키게 하여 업데이트를 완료함.
  • 리소스가 Blue deployment만큼 배로 필요함.

적용하는 방법

예시)

  1. service 가 blue에 연결되어 있는 상태. version: v1 이라는 label을 통해 서비스와 deployment가 연결되어 있음.
  2. version: v2 라는 label이 지정된 green을 배포함
  3. green 이 모두 배포된 이후에는 service의 label을 version: v2 으로 변경시켜서 service가 green 과 연결되게끔 함

Canary

일정한 작은 비율을 새 버전으로 배포하고, 일정 테스트를 거치고 괜찮다 판단되면 나머지를 배포함

적용 방법

예시)

  1. service 가 blue에 연결되어 있는 상태. version: v1 이라는 label을 통해 서비스와 deployment가 연결되어 있음.
  2. old와 new 에게 공동퇴는 label을 부여하여 서비스가 new에도 연결되도록 함.
    1. 이 때, new에는 replica를 최소한의 수로 지정함.
    2. 이렇게 되면 old의 배포는 유지하며, new 는 작은 비율을 차지하게 됨 (canary)
  3. new로 업그레이드 해도 되겠다 판단되면, primary를 업데이트하고, canary는 지움.
    • 또는 primary를 scale down to 0 하고, canary의 replica를 기존 갯수대로 scale up 함 → 그리고 primary를 삭제

Reference