Configuration File (YAML format), Label, Selector

Kubernetes 기초

Cluster에 원하는 서비스를 구동하는 방법은 이에 대한 원하는 상태를

• 직접 요구하거나
• 해당 내용을 파일로 정리하여

API server를 통해 파일에 기술한 정보대로 Master내의 etcd에 원하는 상태정보를 표현한 Object(Resource)를 만들게 하는 것이다.

 

YAML(YAML Ain’t Markup Language)

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx-deployment
  labels:
    app: nginx
spec: 
  replicas: 2
    selector: 
      matchLabels:
        apps: nginx
    template: 
      metadata: 
        labels:
          app: nginx
      spec: 
        containers: 
        - name: nginx
          image: nginx:1.16
          ports:
          - containerPort: 8080

이런 식으로 사람이 읽기 쉬운 데이터 직렬화 양식으로 작성한다.

5 Fields of Kubernetes Definition File

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx-deployment
  labels:
    app: nginx
spec: 
  replicas: 2
    selector: 
      matchLabels:
        apps: nginx
    template: 
      metadata: 
        labels:
          app: nginx
      spec: 
        containers: 
        - name: nginx
          image: nginx:1.16
          ports:
          - containerPort: 8080

1. apiVersion : 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전
2. Kind: 어떤 종류의 쿠버네티스 리소스인지 서술
3. Metadata: 오브젝트를 구별해줄 수 있는 데이터 (name, label, namespace, annotations..)
4. Spec: 오브젝트로 생성하고자 하는 리소스의 구체적인 정보
5. Status: 현재 오브젝트의 상태, 쿠버네티스에 의해 자동으로 생성

*오브젝트: 원하는 상태가 저장된 쿠버네티스 API server상의 객체

각각에 대해서 더 자세히 알아보자.

1. apiVersion

그냥 쿠버네티스 api version을 쓴다.

2. kind

어떤 종류의 쿠버네티스 오브젝트 리소스인지 기술한다.

• pod: 쿠버네티스에서 배포할 수 있는 가장 작은 컴퓨팅 단위
• replicaset: pod의 replica 개수 유지를 보장하는 컨트롤러
• deployment: pod와 replicaset에 대한 업데이트를 가능하게 하는 컨트롤러
• pod, replicaset, deployment 에 대해 자세히 알아볼까?1. Pod
  • Pod는 Kubernetes에서 배포되는 가장 작은 단위야. 기본적으로 하나 이상의 컨테이너가 포함될 수 있어.
  • 보통은 단일 컨테이너로 이루어져 있지만, 여러 컨테이너가 동일한 네트워크와 스토리지 리소스를 공유하면서 서로 상호작용하는 방식으로 하나의 Pod에 포함되기도 해.
  • Pod는 각기 고유한 IP 주소를 가지며, 같은 Pod에 있는 컨테이너들끼리는 localhost를 통해 통신해.
  • 일반적으로 Pod는 임시적인 존재라서, 어떤 문제가 생기면 죽고 사라질 수 있는데, 이를 자동으로 복구하거나 여러 개를 유지하려면 추가적인 설정이 필요해.
  2. ReplicaSet
  • ReplicaSet은 동일한 Pod의 복제본(Replica)을 여러 개 실행시키기 위한 오브젝트야.
  • 목표는 항상 특정 수의 Pod가 실행되도록 유지하는 거야. 만약 Pod가 죽거나 삭제되면, ReplicaSet은 그 수를 보장하기 위해 새로운 Pod를 자동으로 생성해.
  • 예를 들어, ReplicaSet에 3개의 복제본을 설정하면, 언제나 3개의 Pod가 실행되고 있어야 해. 하나가 다운되면 즉시 새로운 Pod가 생성돼.
  • 직접적으로 ReplicaSet을 사용하는 경우는 드물고, 보통은 Deployment와 함께 사용돼.
  3. Deployment
  • Deployment는 애플리케이션 배포를 위한 고급 오브젝트로, 애플리케이션의 상태를 선언적으로 정의할 수 있어.
  • Deployment는 ReplicaSet을 관리해. 즉, 사용자가 Deployment를 정의하면, Kubernetes가 필요한 수의 Pod가 항상 실행되도록 하고, 이를 관리하는 ReplicaSet을 자동으로 생성해줘.
  • Deployment의 장점 중 하나는 Rolling Update와 Rollback 기능이야.
    • Rolling Update: 새로운 버전의 애플리케이션을 배포할 때 기존 Pod를 하나씩 새로운 Pod로 대체하면서 무중단으로 업데이트할 수 있어.
    • Rollback: 문제가 생기면 이전 버전으로 되돌릴 수 있어.
  • 사용자는 애플리케이션의 원하는 상태(desired state)를 Deployment에 정의하고, Kubernetes는 실제로 그 상태를 유지하기 위해 Pod의 수를 조정하거나 업데이트를 관리해.
  예시

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

  • 위 YAML 파일은 nginx라는 컨테이너를 포함한 Pod를 5개 생성하고, 이를 관리하는 Deployment를 정의한 예야.
  • Deployment는 내부적으로 5개의 복제본을 유지하기 위해 ReplicaSet을 생성하고, 각 복제본은 하나의 Pod로 이루어져 있어.
  요약
  • Pod: Kubernetes의 가장 작은 배포 단위로, 하나 이상의 컨테이너가 포함될 수 있음.
  • ReplicaSet: 동일한 Pod의 복제본을 여러 개 생성하고 유지하는 역할.
  • Deployment: 애플리케이션 배포와 관리의 상위 개념으로, ReplicaSet을 관리하고 애플리케이션의 업데이트와 복구를 쉽게 할 수 있도록 지원.
  Kubernetes의 이 구조 덕분에 확장성과 가용성, 복구 가능성을 갖춘 애플리케이션을 쉽게 배포하고 관리할 수 있어!
• 만약 사용자가 nginx라는 웹 서버를 5개의 복제본으로 배포하려고 한다면, Deployment를 통해 이를 정의할 수 있어.
• Kubernetes(k8s)의 Deployment, Replica, Pods는 모두 애플리케이션을 배포하고 관리하기 위한 핵심 개념이야. 하나씩 자세하게 설명해볼게.

3. Metadata

오브젝트를 구별해줄 수 있는 데이터, 말그대로 데이터에 대한 데이터? 이다.

• name: 해당 오브젝트의 이름
• label: 해당 오브젝트의 label 값
• namespace: 지정한 네임스페이스에 오브젝트 리소스 생성
• annotations: 임의의 키/값을 추가하는 일종의 주석 역할

4. Spec

오브젝트로 생성하고자 하는 구체적인 정보를 담고 있다. 다음과 같은 항목을 가진다고 한다!

• selector: matchLabels와 동일한 label 값을 가진 리소스를 선택
• replicas: 리소스를몇 개의 복제본으로 생성할지
• Template: 해당 오브젝트의 구체적인 형식
• metadata: 생성할 리소스의 기본 정보
• spec: 생성할 리소스의 구체적인 스펙정보

5. Status

쿠버네티스에 의해서 자동으로 생성된다. **의도하는 상태(desired status)**와 **현재 상태(actual status)**를 꾸준히 비교하고 업데이트한다.

desired status는 사용자가 배포하고자하는 오브젝트에 대해 원하는 상태이다. yaml파일을 이용하고나 run, create와 같은 명령어를 이용하여 명시한다.

actual status는 해당 쿠버네티스 오브젝트의 실제 상태이다.

아하! 만약 desired status ≠ actual status이면, 쿠버네티스는 desired status로 바꾸기 위해 관리를 시작한다.

Labels & Selectors

Kubernetes 내부에서의 객체간 연결을 위한 방법이라고 할 수 있다.

 

먼저 Labels의 특징을 간단하게 알아보자.

1. 조직화와 리소스 식별: 리소스를 조직화해준다는거지. 나중에 라벨 별로 뭐 묶어보거나 할 수 있다.
2. Key/Value 쌍: 라벨은 키-값 쌍으로 객체에 붙인다.
3. 핵심 시스템에 영향을 주지 않는다: 라벨이 그냥 리소스 설명하는 메타데이터니까 전체 시스템 동작에는 영향을 안 미친다. 예를 들어, app=my-app을 가진 pod가 있어도 그냥 식별!!! 목적이다.
4. metadata: labels: app: my-app environment: production

Selector에 대해 알아보쟝

라벨을 이용하는 거다. 그니까 라벨을 기반으로 리소스를 선택하기 위한 도구이다. 뭐 특정 서비스가 트래픽을 전달한다 치면, 셀렉터를 통해서 특정 라벨을 가진 파드를 선택한다. 먼말알? 두가지 유형이 있는데

1. Equality-based: 라벨이 주어진 값과 동일한지 여부를 기준으로 선택한다.
2. Set-based: 라벨 값이 특정 집합에 포함되는지를 기준으로 선택한다.

selector:
  matchLabels:
    app: my-app