[Kubernetes] 12. 매니페스트 파일 작성

sorzzzzy·2022년 5월 31일
1

Docker&Kubernetes

목록 보기
12/12
post-thumbnail
post-custom-banner

오늘은 쿠버네티스 정의 파일(매니페스트 파일)을 작성하는 방법에 대해 정리해보도록 하겠다😊

🏷 매니페스트 파일이란?

쿠버네티스는 매니페이스 파일(정의 파일)에 기재된 내용에 따라 파드를 생성한다.
매니페스트 파일의 내용을 쿠버네티스에 업로드하면 그 내용이 데이터베이스(etcd)에 '바람직한 상태'로 등록되며, 서버 환경을 이 바람직한 상태로 유지한다.

✔️ YAML 형식으로 매니페스트 작성

파드나 서비스에 대한 설정을 쿠버네티스에서는 매니페스트라고 한다.
이를 적은 파일을 매니페이스 파일 이라고 하며, 이 파일은 YAML 이나 JSON 형식으로 기재한다.

도커 컴포즈와 달리 쿠버네티스에서는 매니페스트 파일의 이름이 지정돼있지 않다!
어떤 이름이든 상관은 없지만, 다른 사람도 이해할 수 있는 이름으로 짓는 것이 좋다.


✔️ 매니페스트 파일은 리소스 단위로 작성한다.

매니페스트 파일은 리소스 단위로 작성한다.
리소스는 파드, 서비스, 디플로이먼트, 레플리카세트 등을 가리킨다.

🤚🏻 여기서 나와 같은 초보자가 다루게 될 리소스는 서비스디플로이먼트 정도이다!

  • '파드'를 다루지 않는 이유는 '파드' 항목에는 쿠버네티스 최대 특징인 '자동으로 설정된 개수를 유지하는 기능'이 없기 때문이다.
  • 개수를 유지하는 기능은 디플로이먼트나 레플리카세트에서 담당하므로 '디플로이먼트' 를 만들어야 한다.
    ➡️ 요약하자면 '디플로이먼트' 항목에 레플리카세트와 파드가 포함돼 있는 것이다!

✔️ 매니페스트 파일은 여러 파일로 분할할 수 있다.

매니페스트 파일은 리소스 단위로 분할해 작성해도 되고, 한 파일에 합쳐서 작성해도 된다.

  • 한 파일로 작성할 때는 각 리소스를 --- 로 구분한다.
  • 리소스 단위로 파일을 나눌때는 각 리소스를 구 분할 수 있도록 이름을 붙인다.

🏷 매니페스트 파일로 작성할 내용

매니페스트 파일도 내용이 복잡하기 때문에 먼저 간단히 알아보고 실습을 진행하도록 하겠다.

매니페스트 파일에도 컴포즈 파일과 마찬가지로 4가지의 주 항목이 있다.

  • apiVersion : API 그룹 및 버전
  • kind : 리소스 유형
  • metadata : 메타데이터
  • spec : 리소스 내용

✔️ 리소스 설정(API 그룹 및 유형)

리소스를 정의하려면 먼저 API 그룹과 리소스 유형을 지정해야 한다.
지정하는 내용은 아래의 내용을 참고해서 작성한다!

🔍 자주 사용되는 리소스의 API 그룹 및 리소스 유형
(리소스 ➡️ API 그룹/버전 ➡️ 리소스 유형)

  • 파드 ➡️ core/v1(v1으로 축약 가능) ➡️ Pod
  • 서비스 ➡️ core/v1(v1으로 축약 가능) ➡️ Service
  • 디플로이먼트 ➡️ apps/v1 ➡️ Deployment
  • 레플리카세트 ➡️ apps/v1 ➡️ ReplicaSet

변경됐을 가능성이 있으므로 실제로 구축할 때는 공식 사이트를 꼭 확인하자!


✔️ 메타데이터와 스펙

매니페스트 파일에는 메타데이터(metadata)와 스펙(spec)을 기재한다.
매타데이터에는 리소스의 이름이나 레이블을 기재한다.
(초보자 수준에서는 namelabel 항목을 이해하면 됨)

스펙은 리소스의 내용을 정의한다.
이는 '어떤 리소스를 만들 것인가'에 해당하는 부분이다.
스펙에서 설명하는 항목은 리소스의 유형에 따라 달라지므로 나중에 더 보충해서 알아보겠다.

🔍 주요 메타데이터
(항목 ➡️ 내용)

  • name ➡️ 리소스의 이름. 문자열로 된 유일 식별자
  • namespace ➡️ 리소스를 세분화한 DNS 호환 레이블
  • uid ➡️ 유일 식별자
  • resourceVersion ➡️ 리소스 버전
  • generation ➡️ 생성 순서를 나타내는 번호
  • creationTimestamp ➡️ 생성 일지
  • deletionTimestamp ➡️ 삭제 일지
  • labels ➡️ 임의의 레이블
  • anotation ➡️ 리소스에 설정할 값. 선택 대상은 되지 못함

✔️ 레이블과 셀렉터

파드나 서비스같은 리소스에 원하는 레이블을 붙일 수 있다.
레이블key-value 쌍의 형태로 메타데이터로 설정한다.

레이블을 부여하면 셀렉터 기능을 사용해 특정 레이블이 부여된 파드만을 배포하는 등 특정 파드를 선택해 설정할 수 있다.


🏷 매니페스트 파일 작성하기

매니페스트 파일의 API 그룹(apiVersion)이나 리소스 유형(kind)은 작성할 내용이 정형화돼 있지만 메타데이타터(metadata)나 스펙(spec)은 리소스의 유형이나 설정 내용에 따라 작성 내용이 달라진다.

파드, 디플로이먼트, 서비스를 대상으로 메타데이터와 스펙을 작성해보는 실습을 진행하겠다!

1. 파드 작성

apiVersion:
kind:
metadata:
  name:			<- (중항목)파드의 이름
  labels:		<- (중항목)레이블
spec:
  containers:	<- (중항목)컨테이너 구성
    - name: 	<- (소항목)컨테이너 이름
      image: 	<- (소항목)이미지 이름
      ports:	<- (소항목)포트 설정

작성할 내용은 주항목(metadata, spec)과 아래에 들여쓰기로 하위 항목(중항목, 소항목)을 작성한다.

파드는 중항목이 총 3개이다.
메타데이터 아래로 name , labels 스펙 아래의 containers 에 컨테이너 구성을 기재한다.
(원래 volumes 항목도 있지만 작성하지 않는 경우도 많아서 이번에는 생략함)

여기서 주의할 점은 name 이다🤚🏻
containes 항목에서 지정한 이름은 컨테이너의 이름이다.
그 위에 있는 metadata 아래의 name 은 파드의 이름이다.
파드는 '컨테이너와 볼륨' 을 묶은 것이라고 설명했었는데, 아이돌 그룹에 비유하자면, 파드는 그룹명 컨테이너는 멤버 이름이라고 생각하면 쉽다!

이는 최소한의 설정으로 실제로는 좀 더 설정 항목이 늘어난다!


✔️ apa000pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: apa000pod
  labels:
    app: apa000kube
spec:
  containers:
    - name: apa000ex91
      image: httpd
       ports:
      - containerPort: 80

2. 디플로이먼트 작성

이어서 이번에는 디플로이먼트의 매니페스트 파일을 작성하겠다.
파드가 아이돌 그룹이고, 컨테이너가 개인 멤버라면 디플로이먼트는 소속사(?)에 비유할 수 있다🤣

apiVersion:
kind:
metadata:
  name:				<- (중항목)디플로이먼트 이름
spec:
  selector:			<- (중항목)셀렉터 설정
    matchLabels:	<- (소항목)셀렉터가 선택할 관리 대상 레이블
  replicas: 		<- (중항목)레플리카 설정
  template: 		<- (중항목)템플릿-파드의 정보
    metadata:		<- (소항목)파드의 메타데이터를 기재
    spec:			<- (소항목)파드의 스펙을 기재

1. 셀렉터(selector)
디플로이먼트가 특정한 레이블이 부여된 파드를 관리할 수 있도록 하는 설정이다.
matchLabels: 뒤로 레이블을 기재한다.
이 레이블은 template 아래의 metadata 에 기재된 것이다.

2. 레플리카(replica)
파드의 레플리카에 대한 관리다.
파드 수를 '몇 개로 유지' 할 것인지 설정한다.
이 값을 0으로 설정하면 파드가 사라진다.

3. 템플릿(template)
생성할 파드의 정보를 기재한다.
기재 내용은 파드에 기재된 내용(메타데이터 및 스펙)과 거의 같다.


✔️ apa000dep.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apa000dep
spec:
  selector:
    matchLabels:
      app: apa000kube
  replicas: 5
  template:
    metadata:
      labels:
        app: apa000kube
    spec:
      containers:
      - name: apa000ex91
        image: nginx
        ports:
        - containerPort: 80

3. 서비스 작성

서비스 매니페스트 파일을 작성해보자.
디플로이먼트와 서비스는 거의 세트라고 생각해도 된다.
서비스의 역할은 파드로 들어오는 요청을 관리하는 것이므로 설정 내용도 통신과 관련된 것이다!

apiVersion: 
kind: 
metadata:
  name:				<- (중항목)서비스의 이름
spec:				
  type: 			<- (중항목)서비스의 유형
  ports:			<- (중항목)포트 설정
  - port:			<- (중항목)서비스의 포트
    targetPort: 	<- (소항목)컨테이너의 포트
    protocol: 		<- (소항목)통신에 사용되는 프로토콜
    nodePort: 		<- (소항목)워커 노드의 포트
  selector:			<- (중항목)셀렉터 설정

1. 유형(type)
유형은 서비스의 종류를 말한다.
외부로부터 서비스에 어떤 유형의 IP 주소(또는 DNS)로 접근할지를 설정한다.

  • ClusterIP : 클러스터IP를 통해 서비스에 접근하도록 함(외부에서는 접근 불가)
  • NodePort : 워커 노드의 IP를 통해 서비스에 접근하도록 함
  • LoadBalancer : 로드밸런서의 IP를 통해 서비스에 접근하도록 함
  • ExternalName :파드에서 서비스를 통해 외부로 나가기 위한 설정

이번 실습에서는 도커 데스크톱에 로드밸런서가 없기 때문에 NodePort 설정을 사용한다.

2. 포트
port 는 서비스, nodePort 는 워커 노드, targetPort 는 컨테이너 포트를 각각 설정한다.
nodePort 에는 30000과 32767 사이의 값을 설정할 수 있다.
protocol 은 통신 프로토콜을 말한다. 일반적을 TCP 를 사용하므로 TCP 로 설정한다.

3. 셀렉터(selector)
셀렉터는 디플로이먼트에서 설명했듯이 서비스가 특정 레이블이 부여된 파드를 선택적으로 관리하기 위한 설정이다.
레이블은 파드나 디플로이먼트에서 컨테이너 부분의 설정에 지정된 레이블을 사용한다.

다만, 디플로이먼트에서는 matchLabels: 가 필수 항목이지만, 서비스에서는 matchLabels: 를 사용해서는 안 된다.


✔️ apa000ser.yml

apiVersion: v1
kind: Service
metadata:
  name: apa000ser
spec:
  type: NodePort
  ports:
  - port: 8099
    targetPort: 80
    protocol: TCP
    nodePort: 30080
  selector:
    app: apa000kube
profile
Backend Developer
post-custom-banner

0개의 댓글