쿠버네티스 기본 사용법

쿠버네티스 기본 사용법 배우기

파드 생성 법

쿠버네티스를 사용한다는 것은 결국 사용자에게 효과적으로 파드를 제공한다는 뜻!

 

kubectl run

명령을 실행하면 쉽게 파드 생성이 가능함

kubectl run nginx-pod --image=nginx

run 뒤의 nginx는 파드 이름, —image=nginx는 생성할 이미지 이름.

 

 

create 파드 생성법과 run의 비교

kubectl create nginx --image=nginx

를 하면 에러메세지가 나온다!

create로 파드를 생성하려면 kubectl create에 deployment를 추가해서 실행해야 한다.

중복되지 않게 dpy-nginx 로 파드 이름을 지정해서 생성하면

kubectl create deployment dpy-nginx --image=nginx

이렇게 하면 생성 된다.

생성된 파드를 확인하려면

kubectl get pods

명령어로 확인!

이름에서 지정한 dpy-nginx를 제외한 뒷 부분은 무작위로 생성된다.

 

무슨 차이가 있을까?

run으로 생성하면 단일 파드 1개만 생성, 관리된다.

create deployment로 생성하면 티플로이먼트라는 관리 그룹 내에서 파드가 생성된다.

즉 run으로 생성된 파드는 초코파이 한개, create deployment로 생성된 파드는 초코파이 상자 안에 든 초코파이 한개의 차이다!

 

생성된 파드가 제대로 동작하는지 확인해보자!

우선 파드의 ip를 확인해야 한다.

 

kubectl get pods -o wide

명령어를 사용하면 ip주소 등의 다양한 정보를 확인할 수 있다.

확인된 ip주소를 curl 명령어 뒤에 붙여 실행한다.

→웹페이지 정보(코드)가 출력되면 정상 작동되는 것!

 

오브젝트란?

스펙, 상태 등의 값을 가지고 있는 파드와 디플로이먼트를 개별 속성을 포함해 부르는 단위.

 

 

기본 오브젝트

 

파드 : 쿠버네티스에서 실행되는 최소 단위. 웹 서비스를 구동하는데 필요한 최소단위임.

독립적인 공간과 사용 가능한 ip를 가지고 있음.

하나의 파드는 1개이상의 컨테이너를 가지고 있기 때문에 여러 기능을 묶어 하나의 목적으로 사용할 수 있음. 그러나 범용 사용시에는 보통 1개 파드에 1개 컨테이너 적용.

 

네임스페이스 : 쿠버네티스 클러스터에서 사용되는 리소스들을 구분해 관리하는 그룹.

기본으로 할당되는 default, 쿠버네티스 시스템에서 사용되는 kube-system, 온프레미스에서 쿠버네티스를 사용할 경우 외부에서 쿠버네티스 클러스터 내부로 접속하게 도와주는 컨테이너들이 속한 metallb-system 이 있음

 

볼륨 : 파드가 생성될 때 파드에서 사용할 수 있는 디렉터리를 제공.

기본적으로 파드는 영속되는 개념이 아니라 제공되는 디렉터리도 임시로 사용됨. 하지만 파드가 사라지더라도 저장과 보존이 가능한 디렉터리를 볼륨 오브젝트를 통해 생성하고 사용할 수 있음.

 

서비스 : 파드 접속을 안정적으로 유지하도록 서비스를 통해 내/외부로 연결됨.

서비스는 새로 파드가 생성될 때 부여되는 새로운 ip를 기존에 제공하던 기능과 연결해줌. 쿠버네티스 외부에서 내부로 접속할때 내부 구조를 신경쓰지 않아도 논리적으로 연결해주는 것이 서비스!

 

디플로이먼트

기본 오브젝트 만으로도 쿠버네티스 사용이 가능하지만, 한계가 있어서 좀 더 효율적으로 작동하도록 기능을 조합, 추가해 구현한 것.

가장 많이 쓰이는 디플로이먼트 오브젝트는 파드에 기반을 두고, 레플리카 셋(레플리케이션 컨트롤러가 발전한 형태) 오브젝트를 합쳐놓은 형태

 

디플로이먼트 오브젝트 계층구조

디플로이먼트→레플리카 셋→←파드

실제 api서버와 컨트롤러 매니저는 단순히 파드가 생성되는 걸 감시하는 것이 아니라 디플로이먼트처럼 레플리카셋을 포함하는 오브젝트 생성을 감시함.

 

디플로이먼트 생성하기

저자의 저장소에서 필요한 이미지를 내려받아 디플로이먼트 생성!

이미지 경로는 계정이름/이미지 이름

kubectl create deployment dpy-hname --image=sysnet4admin/echo-hname

디플로이먼트 삭제하기

kubectl delete deployment dpy-hname

해당 명령어를 사용하면 생성했던 디플로이먼트가 삭제 됨.

현재 생성된 디플로이먼트는 마찬가지로 kubectl get pods 로 확인할 수 있음.

 

레플리카셋으로 파드 수 관리하기

다수의 파드를 만드는 레플리케셋 오브젝트가 제공됨.

레플리카셋은 파드 수를 보장하는 기능만 제공. 롤링 업데이트(파드 인스턴스 수를 점진적으로 업데이트하여 디플로이먼트 업데이트가 서비스 중단 없이 이루어지게 해줌)기능이 추가된 디플로이먼트를 사용해 파드 수를 관리하는 걸 권장!

 

파드 수 변경하기

scale 명령어로 파드 수를 증가시킬 수 있지만, 파드로 생성된, 즉 디플로이먼트 오브젝트에 속하지 않는 파드는 리소스를 찾을 수 없다는 에러가 뜸.

kubectl scale deployment dpy-nginx --replicas=3

명령어로 파드를 추가할 수 있음.(총 3개로 만들기)

명령어는 단수나 복수로 표현해도 동일하게 동작함

 

스펙을 지정해 오브젝트 생성하기

디플로이먼트를 생성할때 따라 생성되는 파드는 1개 뿐!

생성 시에 여러개의 파드를 한번에 만들 수는 없을까?

*create에서는replicas 옵션을 사용할 수 없고, scale은 이미 만들어진 디플로이먼트에서만 사용 가능함

이런 설정을 적용하려면 필요 내용을 파일로 작성해야 함.

이때 작성하는 파일이 오브젝트 스펙 이라고 함.일반적으로 야믈 문법으로 작성.

 

오브젝트 스펙 파일은 api 버전과 여러 종류의 kind(오브젝트) 중 무엇을 쓸지, metadata와spec내용(replicas로 레플리카셋은 몇개의 파드로 결정할지 내용을 가지고 있음.

사용되는 이미지도 지정해줌.)을 가지고 있음.

파드의 스펙과 비교하면 디플로이먼트의 템플릿 하위의 metadata와 spec이 파드 스펙이 동일하게 사용되는 것을 확인할 수 있음!

 

현재 replicas는 3으로 파드를 3개 생성하기로 지정됨!

이 echo-hname 파일로 디플로이먼트를 생성하면 3개의 파드가 한번에 생성됨

kuvectl create -f ~/_Book_k8sInfra/ch3/3.2.4/echo-hame.yaml

파일에서 이 replicas의 값을 6으로 변경해보자

 

sed 명령어 사용.(-i 옵션은 —in-place의 약어. 변경한 내용을 현재 파일에 바로 적용하겠다는 의미!, s/는 주어진 패턴을 원하는 패턴으로 변경하겠다는 의미) 사용이 어렵다면 직접 변경해도 됨.

sed -i 's/replicas: 3/replicas: 6/' ~/_Book_k8sInfra/sh3/3.2.4/echo-hname.yaml

명령어로 파일을 변경해주자.

cat ~/_Book_k8sInfra/ch3/3.2.4/echo-hname.yaml | grep replicas

해당 명령어로 값이 변경되었는지 확인하자!

변경된 파일로 다시 디플리먼트를 생성하자!

kuvectl create -f ~/_Book_k8sInfra/ch3/3.2.4/echo-hame.yaml

→ 이미 해당 파일이 존재한다는 에러메세지가 나온다.

 

scale 명령 이외에 파일로 이미 배포된 오브젝트의 스펙을 변경하고 싶을때는 어떻게 해야할까?

apply 라는 명령어를 사용하면 된다!

 

apply로 오브젝트 생성하고 관리하기.

아까 replicas를 수정한 echo-hname.yaml 파일을 kubectl apply 명령으로 적용 시키기

kubectl apply -f ~/_Book_k8sInfra/ch3/3.2.4/echo-hname.yaml

오브젝트를 apply로 처음부터 만든 것이 아니기 때문에 경고가 뜸. 작동에는 문제 없지만 나중에 일관성 문제가 생길 수 있다.

kubectl get pods 명령어로 파드를 확인한다. age로 최근에 추가된 파드를 구별 할 수 있다.

apply를 사용하면 파일 변경사항도 쉽게 적용할 수 있지만, 일관성 문제가 생길 수 있으니

일회성 사용 오브젝트인 경우는 create를 사용하고, 변경이 생길 가능성이 있는 복잡한 오브젝트는 apply로 적용하는것이 좋다!

 

세가지 명령어의 차이 정리