Cluster/쿠버네티스(k8s)

kubernetes(k8s) 기본 사용법 배우기

제이Lee 2023. 9. 26. 10:55

앞 글들에서 쿠버네티스에 대한

기초적인 이해와 구성요소들에 대해 알아봤다.

이제 파드도 생성해보고,

쿠버네티스 기본 사용법에 대해 알아보자.

만약 앞글을 따라한 사람이라면,

이미 설치되어 있는 파드를 삭제해야 된다.

kubectl delete -f ~/_Book_k8sInfra/ch3/3.1.6/nginx-pod.yaml

이제 파드를 생성해보자.

먼저 nginx-pod를 설치할건데, 이미지는 nginx를 사용할거다.

pod 생성에는 3가지 방법이 있다.

 

첫번째는 kubectl run, 아래와 같이 사용한다.

kubectl run nginx-pod --image=nginx

두번째는 kubectl create, 아래와 같이 사용하고, dpy-nginx는 이름이다.

kubectl create deployment dpy-nginx --image=nginx

세번째는 kubectl apply 인데,

apply는 생성도 되긴 하지만, 기존 생성된 파드를 수정하는 경우에 많이 사용한다.

그래서 일단은 빼고 나중에 예시를 통해 사용해보겠다.

 

두 명령다 잘 생성된 모습이다. create를 써서 만든 파드에는 이름 뒤에 뭐가 붙는데,

이부분은 Hash값 같은 값들이 자동으로 붙는다.

 

두 파드의 상태를 확인해보자.

 

- 172.16.132.2

- 172.16.221.129

둘다 잘 실행된다.

굳이 두 방식을 다 사용한 이유는, 특정 버전 이후 쿠버네티스에서는

run의 사용을 권장하지 않고 있기 때문에 두 가지 방법에 대한 차이를 설명하기 위해서다.

두 방식의 차이점은
run의 경우 단일 파드 1개만 생성되고 관리.

create deployment의 경우,
Deployment라는 관리 그룹내에서 파드가 생성된다.

딱 들어봐도 뭔가 단일 파드라고 하면 자신 외에는 다른게 필요하지 않으니 생성이나 이런 측면에서 더 나을 것이고,
그룹내에서 파드가 생성된다는건 생성되는 속도는 느릴지언정, 관리면에 있어서 훨씬 더 편할 것 같은 느낌이 든다.

실제로도 이러한 장, 단점들을 가지고 있다.

내가 참고하는 글에서는 굉장히 좋은 비유가 있는데,
run의 경우는 초코파이 1개이고,
deployment의 경우는 초코파이 상자 안에 들어 있는 초코파이 1개라고 보면 된다.

 

쿠버네티스를 공부하다 보니 알아야할 용어들이 정말 많은 것 같다..

그래서 뒤에 내용을 하기 전에 또 한번 용어들에 대해 정리해둔다.

 

  1. 파드(Pod)
    • 쿠버네티스에서 실행되는 최소 단위(웹 서비스를 구동하는데 필요한 최소 단위)
    • 독립적인 공간과 사용 가능한 IP를 가진다
    • 하나의 파드는 1개 이상이 컨테이너를 가지기 때문에 여러 기능을 묶어 하나의 목적으로 사용할 수도 있다.
    • 범용으로 사용할 때는 대부분 1개의 파드에 1개의 컨테이너를 적용한다.
  2. 네임스페이스(Namespaces)
    • 쿠버네티스 클러스터에 사용되는 리소스들을 구분해 관리하는 그룹
    • 이번 포스팅엔 3가지 네임스페이스를 사용한다. 특별히 지정하지 않으면 기본으로 할당되는 default, 쿠버네티스 시스템에 사용되는 kube-system, 온프레미스에서 쿠버네티스를 사용할 경우 외부에서 쿠버네티스 클러스터 내부로 접속하게 도와주는 컨테이너들이 속해 있는 metallb-system이 있다.
  3. 볼륨(Volume)
    • 파드가 생성될 때 파드에서 사용할 수 있는 디렉터리를 제공
    • 기본적으로 파드는 영속되는 개념이 아니라서 제공되는 디텍토리도 임시로 사용
    • 파드가 사라지더라도 저장과 보존이 가능한 디렉토리를 볼륨 오브젝트를 통해 생성하고 사용 가능
  4. 서비스(Service)
    • 파드는 클러스터 내에서 유동적이기 때문에 접속 정보가 고정일 수 없다
    • 파드 접속을 안정적으로 유지하도록 서비스를 통해 내/외부로 연결된다
    • 새로 파드가 생성될 때 부여되는 새로운 IP를 기존에 제공하는 기능과 연결해준다
    • 쿠버네티스 외부에서 내부로 접속할 때 내부가 어떤 구조로 돼 있는지, 파드가 살았는지 죽었는지 신경 쓰지 않아도 이를 논리적으로 연결하는 것
    • 기존 인프라에서 로드밸런서, 게이트웨이와 비슷한 역할

 

- deployment

기본 오브젝트 + 기능 조합 및 추가해 구현한 것이 deployment이다.

출처에 가보면 여러 설명이 있는데, 솔직히 지금 상태에서는 무슨말인지 잘 모르겠다.

그래서 일단은 실습을 먼저 해보겠다.

그리고 나서 이해한 후 다시 정리해보겠다.

 

 

출처 : https://velog.io/@moey920/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EC%9D%B8%ED%94%84%EB%9D%BC-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%952

 

쿠버네티스의 개념과 기본 사용법

컨테이너를 다루는 표준 아키텍처, 쿠버네티스본 게시물은 "컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 조훈,심근우,문성주 지음(2021)" 기반으로 작성되었습니다.

velog.io

* Deployment 사용해보기

kubectl create deployment dpy-hname --image=sysnet4admin/echo-hname Deployment 생성, image 뒤에 부분(sysnet4admin/echo-hname)은 docker hub의 저장소이다.
https://hub.docker.com/
kubectl delete deployment dpy-hname Deployment 삭제

 

* 레플리카셋

웹 서비스를 하려면 다수의 파드가 필요한데, 이러한 다수의 파드를 만드는 레플리카셋 오브젝트를 제공.

예를 들면, 여러개의 파드를 만들겠다고 레플리카셋에 선언하면 컨트롤러 매니저와 스케줄러가 작업 노드에 파드를 여러개 만들도록 선언한다. 그러나 레플리카셋은 파드 수를 보장하는 기능만 제공하기 때문에 롤링 업데이트 기능 등이 추가된 Deployment를 사용해 파드 수를 관리하기를 권장한다.

뭔가 대강 이해는 하겠는데, 말이 점점 어려워지고 있다..이럴땐 역시 실습이다.

 

kubectl scale pod nginx-pod --replicas=3
: 파드의 수를 3개로.

위의 명령 실행 시 오른쪽 스크린샷처럼 에러가 발생하는데,

여기가 바로 run으로 실행했을 때와 deployment로 실행했을 때의 차이점이고,

왜 deployment를 권장하는지에 대한 이유다.

에러가 발생하는 이유는 단일 파드를 생성하는 run으로 실행했기 때문에

파드의 수를 늘릴 수 없기 때문이다.

 

그러면 아까 deployment를 사용해 만든 파드는 어떨까

kubectl scale deployment dpy-nginx --replicas=3
: 파드의 수를 3개로. Deployment로 만든 파드.

위와 같이 정상 실행되고, 파드의 수도 3개로 늘어난걸 확인할 수 있다.

*  YAML(YAML Ain't Markup Language)

deployment를 생성할 때 명령어로는 한번에 여러개를 생성할 수 없다. 그럴때 야믈을 통해 스펙을 정리하여 deployment를 만들면 여러개의 파드를 한번에 생성할 수 있다.

실제로 지금까지 파드를 만들때, 특정 경로에 있는 .yaml 파일을 사용했다.

kubectl create -f ~/_Book_k8sInfra/ch3/3.1.6/nginx-pod.yaml

이런식으로다. 그럼 저 경로에 있는 yaml 파일을 살펴보자.

이런식으로 되어 있다. 스펙에 대한 정의가 없고, 레플리카셋에 대한 정보도 없다.

그러면 예제에 있는 3개의 레플리카셋을 만드는 yaml파일의 내용을 확인해보자.

(~/_Book_k8sInfra/ch3/3.2.4/echo-hname.yaml)

뭔가 spec이라는 단어도 추가되어 있고,

레플리카에 대한 정보도 3으로 들어가 있다.

 

nginx.yaml 이용해서 만드는건 앞에서 여러번 해봤으니,

이번엔 echo-hname.yaml을 이용해서 한번 deployment를 만들어보자.

아 이전에 이미 만들어져 있는 dpy-nginx 들을 삭제하려면,

kubectl delete deployment dpy-nginx

위의 명령어를 실행하면 된다. 참고로 삭제되는데 약간의 시간이 걸리는 것 같다.

 

이제 만들어보자.

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

명령어 한번으로 3개의 echo-hname 파드가 만들어진걸 확인할 수 있다.

여기서 yaml파일을 수정해 네임은 동일한 파드들을 업데이트 하려면 어떻게 해야할까?

앞에서 언급했는데, 이럴때 바로 apply를 사용하면 된다.

 

일단 vi를 통해 해당 yaml 파일을 수정해보자.

나는 일단 replicas만 3에서 5로 변경했다.

이후 다시 생성 명령어를 치면 아래와 같이 나온다.

이미 존재한다는 거다.

이럴때 apply를 쓰면 된다.

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

위의 명령을 실행하면 경고문구가 뜨긴 하지만, 변경된다는데...

나는 안된다........

확인해보니 엉뚱한 위치에 있는 yaml파일을 바꿨다..

다시 수정 후에 위의 명령어 실행했다.

파드가 5개로 변경된 걸 확인할 수 있다.

 

위의 작업을 통해 yaml 파일을 통한 deployment 생성과

apply를 통해 현재 생성된 파드의 내용도 변경할 수 있다는 걸 확인할 수 있었다.

 

마지막으로 run과 create와 apply의 차이점에 대한 표로 이번 글은 마친다.

구분 run create apply
명령 실행 제한적 O X
파일 실행 X O O
변경 가능 X X O
실행 편의성 매우 좋은 매우 좋음 좋음
기능 유지 제한적 지원 다양하게 지원

 

*추가로 .yaml 파일을 직접 만들어보다가 찾은 방법인데,

kubectl create deployment python --image=python -o yaml --dry-run=client

해당 명령을 실행하면

이런 식으로 기본 틀을 만들어 준다. 이걸 그대로 복사해서 .yaml 파일을 만들어 사용해도 되고,

수정해서 사용해도 된다.

참고로 create deployment 부분은 run 같이 다른 커맨드로 바꿔서 사용해도 된다.

ex) kubectl run python --image=python -o yaml --dry-run=client