현대 오토에버 SW 스쿨 - 클라우드/쿠버네티스

[쿠버네티스] - Deployment 와 service 사용 & ConfigMap

yongyongMom 2024. 11. 4. 10:42
SMALL

1. Deployment 와 Service 사용

1)Deployment

  • 파드 배포에 관한 객체
  • 단순히 파드를 배포하는 것 뿐 아니라 몇 개의 파드를 실행할 지 결정하는 것도 가능
  • Deployment를 이용해서 pod 배포
  • nginx-deploy.yml 파일을 생성하고 작성
  • yaml 파일의 정보를 가지고 파드를 생성
    • Deployment로 배포한 replicas 에 설정한 파드의 개수를 유지할려고 하기 때문에 파드를 삭제하면 다시 생성해서 파드의 개수를 유지
    • Pod로 만들면 삭제해도 복구가 되지 않음
  • labels
  • 레이블이란 오브젝트에 키-값 쌍으로 리소스를 식별하고 속성을 지정하는데 사용을 하는데 일종의 카테고리라고 할 수 있음
  • 아래 처럼 사용
release: v1, v2
environment: dev, production
tier: frontend, backend
app: webapp, middleware
  • 다른 객체와 연결을 할 때 label이 매핑이 되어야 함
  • Deployment 나 ReplicaSet은 파드를 직접적인 관계를 맺지 않고 자신의 레이블과 일치하는 파드가 개수만 맞게 존재하면 됨
    • 수동으로 레이블을 변경하게 되면 그 레이블에 맞게 파드가 생성되어야 된다고 판단
  • 파드 확인: 파드가 2개 추가 된 것을 확인할 수 있습니다.
    • Deployment 나 ReplicaSet은 pod를 직접 관리하지 않기 때문에 레이블이 변경되면 변경된 레이블 아래 pod가 존재해야 한다고 판단
  • 파드 확인: 새로 만들어진 파드 2개가 소멸됨
    • 맨 처음 nginx가 Deployment로 레이블을 생성해서 2개의 파드를 만들고 nginx-1로 labels를 수정하면 이 경우는 Deployment가 새로 만들어지는 것이 아니고 labels만 추가가 되서 Deployment 1개 와 새로운 labels 1개가 존재해서 총 4개의 파드가 존재하지만 변경한 labels를 nginx로 변경을 하면 labels에 nginx-1이 사라지기 때문에 다시 2개의 파드만 있으면 됩니다.
  • Deployment가 자신의 내부 객체를 직접 관리하지 않고 이름을 통해서 연결되는 구조를 느슨한 결합이라고 합니다.

2) Service

    • 기본적으로 파드는 같은 노드에 떠 있는 파드끼리만 통신이 가능
    • 다수의 노드에 떠 있는 파드 간의 통신이나 외부와의 통신을 위해서는 CNI 플러그 인이 필요한데 이 때 파드에 위치한 서비스를 외부에서 접속할려면 서비스를 이용해야 합니다.
    • 외부에서 파드에 접근하기 위해서는 포트포워딩 하는 방법이 있습니다.
      • kubectl port-forward 파드이름 외부포트:내부포트
    • 하나의 노드 안에 있는 파드끼리는 통신이 가능
    • 파드 와 파드끼리 IP를 안다면 통신이 가능
      • 파드는 고정된 위치에 있는 것이 아니고 소멸되었다가 다른 곳에서 만들어지는 동적인 개념
    • 파드 간의 통신: IP 이용
    • 외부에서 서비스 이름으로 접근할 수 있도록 포트를 외부로 개방하기
    • type
  • ClusterIP: 기본값으로 클러스터 내부의 다른 리소스들과 통신이 가능합니다. 이 때 IP 뿐 아니라 Service 이름으로도 통신이 가능
  • NodePort: 외부에서 노드 IP의 특정 포트로 들어오는 요청을 감지해서 해당 포트와 연결된 파드로 트래픽을 전달하는 것으로 이를 설정하면 ClusterIP 도 자동으로 설정됩니다.
  • LoadBalancer: LoadBalancer를 제공하는 Public Cloud 와 연결할 때 사용하는데 NodePort 와 ClusterIP는 자동 설정
  • ExternalName: selector 부분에 lables를 사용하지 않고 Domain Name을 직접 사용하고자 하는 경우 사용

3) 롤백

  • 디플로이먼트는 기본적으로 롤링 업데이트 와 함께 롤백도 지원
  • 롤백은 업데이트에 문제가 생겼을 때 이전 버전으로 바꿀 수 있는 기능

4) ReplicaSet

    • 일정한 개수의 동일한 파드가 항상 실행되도록 관리해주는 객체
    • 필요한 이유는 서비스의 지속성 때문
    • 노드의 하드웨어에서 발생하는 장애 등의 이유로 파드를 사용할 수 없을 때 다른 노드에서 다시 생성해서 사용자에게 중단없는 서비스를 제공할 수 있습니다.

5) Daemon Set

  • 모든 노드에 파드를 실행할 때 사용
  • 레플리카셋이 특정 개수의 파드를 유지하고자 할 때 사용하는 것이라면 데몬셋은 모든 노드에 파드를 배포할 때 사용
  • 모니터링이나 로그 수집에 이용
  • kind는 DaemonSet을 적용하면 되고 tier label을 이용해서 어떤 목적인지를 밝히는 경우가 많습니다.
  • prom/node-exporter 이미지를 가지고 DaemonSet 생성

6)Job

  • 종류
  • job: 하나 이상의 파드가 특정한 파드의 정상적인 상태를 유지할 수 있도록 관리
    • 노드에 문제가 발생해서 특정 파드에 문제가 발생하면 정상적인 서비스를 할 수 있도록 새로운 파드를 다시 만드는 역할을 수행
  • cronjob: 주기적으로 어떤 액션을 발생시키는 잡
    • 어떤 액션을 얼마나 자주 발생시킬 지는 매니페스트에서 정의
  • cronjob의 매니페스트에는 schedule 과 command 라는 항목이 추가가 됩니다.
  • 이미지를 사용할 때 아무런 옵션도 주지 않으면 이미지를 계속 다운로드 받을 수 있기 때문에 cronjob의 경우는 imagePullPolicy 속성을 이용해서 없을 때만 다운로드 받도록 해주어야 합니다.
    • pod를 생성하는 작업은 pod를 만들 때는 이미지를 다운로드 받기 때문에 별문제가 없습니다.
    • schedule 속성의 값을 설정하는 방법은 linux 의 crontab 가 동일
      • 5개의 항목(분 시 요일(0-6) 월 일)을 설정
    • 크론잡
      • NAME   SCHEDULE      TIMEZONE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
        hi           */1 * * * *          <none>         False           3              50s                          3m27s
  • NAME: cronjob의 이름
  • SCHEDULE: 스케쥴링 내용
  • TIMEZONE: 타임 존 설정 내용
  • SUSPEND: 지연 여부
  • ACTIVE: 수행한 횟수
  • LAST SCHEDULE: 마지막으로 수행되고 경과된 시간
  • AGE: 만들어져서 서비스된 시간

 

2. ConfigMap 과 Secret

1) 개요

  • kubenetes 객체가 사용하기 위한 데이터를 저장하기 위한 객체
  • 환경 변수와 같은 데이터는 대부분 실행 중에는 변하지 않음
    • 실행하기 직전에 변할 수 있는 문자열
    • 또는 외부로 노출되어서는 안되는 데이터
  • ConfigMap 이나 Secrets 은 스스로 기능을 하지는 않고 적은 양의 데이터를 저장하는 것이 목적

2) ConfigMap

  • 문자열 상수를 이용해서 만들 수 있고 파일의 내용을 읽어서 만들 수 있음
  • 문자열 상수 (리터럴)을 가지고 생성
kubectl create configmap [map name] --from-literal=[키]=[값]

kubectl create configmap my-config --from-literal=JAVA_HOME=/usr/java

kubectl delete configmap my-config

kubectl create configmap my-config --from-literal=JAVA_HOME=/usr/java --from-literal=URL=http://localhost:8000

 kubectl get configmap my-config

kubectl describe configmap my-config
  • 파일에서 읽어서 만들기
    • 데이터를 저장하는 yaml 파일 생성하고 작성 
      echo Hello Config >> configmap_test.html
kubectl create configmap configmap-file --from-file configmap_test.html
    • 다른 yaml 파일에서 가져다 사용할 떄는 최상단에 작성 
      envFrom:
  - configMapRef:
	name: ConfigMap 이름
  • 이후부터는 ConfigMap 이름에 해당하는 데이터를 사용할 때에는 key 만 입력하면 됨

3) secret 만들기

kubectl create secret generic “secret이름” --from-literal=키=값…
  • kubectl create secret generic: Kubernetes에서 일반적인 Secret 객체를 생성하는 명령어
  • <secret-name>: 생성할 Secret의 이름을 지정
  • --from-literal=<key>=<value>: key-value 쌍으로 Secret 데이터를 직접 입력합니다. 여러 쌍을 지정할 수 있음
  • 이유
    • 민감한 데이터 저장: 비밀번호, API 키, 토큰 등의 민감한 정보를 Kubernetes 클러스터 내에 안전하게 저장
       
    • 데이터 분리: 애플리케이션 코드와 설정에서 민감한 정보를 분리하여 보안을 강화
       

    • 접근 제어: Kubernetes의 RBAC(Role-Based Access Control)을 통해 Secret에 대한 접근을 제어
    • 데이터 인코딩: Secret 데이터는 base64로 인코딩되어 저장
       

    • 다양한 사용: 생성된 Secret은 Pod의 환경 변수나 볼륨으로 마운트되어 사용될 수 있음
반응형
LIST