Data Scientist

9 분 소요

데브옵스(DevOps)를 위한 쿠버네티스 마스터 강의 정리

1. Pod

1.1 속성

  • 쿠버네티스는 컨테이너를 개별적으로 배포하지 않고 컨테이너의 포드를 배포 및 운영
  • 일반적으로 포드는 단일 컨테이너만 포함하지만 다수의 컨테이너 포함 가능
    • 스케일링을 위해 단일 컨테이너를 권장
    • 두가지의 컨테이너가 밀접한 관계일 경우에만 한 포드에 넣음
  • 여러 노드에 걸쳐서 생성되지 않고 단일 노드에서만 생성 및 실행
  • 다수 컨테이너일 경우 컨테이너간 자원 공유 가능


1.2 장점

  • 연관된 프로세스를 하나의 환경에서 동작하는 것처럼 함께 실행
  • 그러나 다소 격리된 상태로 유지


1.3 네트워크 구조

  • pod가 할당받은 네트워크 대역대에서 순차적으로 증가하는 형태
    • 클러스터에서 각 pod는 고유한 IP를 할당 받음
    • pod IP 주소는 클러스터 내 사전 정의된 네트워크 대역대에서 할당 됨
  • NAT 게이트웨이가 따로 존재하지 않음
    • k8s 네트워크 핵심 원칙 중 하나는 모든 pod가 서로를 직접 접근할 수 있어야 한다는 것
    • 따라서 VM이나 물리적 네트워크에서 흔히 볼 수 있는 NAT 게이트웨이가 필요하지 않음
  • 외부에서 해당 IP로 접근하는 것은 불가능하며 서비스라는 객체를 생성해야함
    • pod는 클러스터 내부에서만 라우팅 될 수 있음
    • 클러스터 외부 네트워크에서는 접근할 수 없음


1.4 Yaml 파일 구성요소

  • apiVersion: 쿠버네티스의 api 가 일치해야 통신 가능 일종의 프로토콜
    • kind: 리소스의 유형 결정 (pod, replica, service …)
  • metadata: apiversion과 kind를 만들 때, 어떤 식으로 데이터를 생성할 것인지 정의
  • spec: 어떤 컨테이너를 배치하고 볼륨을 설정하고 등등 자세한 정보 (주요 정보 포함)
  • status: 포드의 일반적인 상태 외에 기본정보 같은 것이 들어가 있음, 쿠버네티스가 해주는 것
    • 쿠버네티스가 작성해주는 영역

🌈 예시

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80


📍 쿠버네티스 리소스 종류

  • Pod (파드): 쿠버네티스 애플리케이션의 기본적인 빌딩 블록으로, 하나 이상의 컨테이너가 포함된 그룹입니다. 파드는 스케일링, 네트워킹, 스토리지 리소스를 공유합니다.
  • Service (서비스): 파드 집합에 대한 안정적인 네트워크 주소를 제공합니다. 서비스는 파드에 도달하기 위한 내부 네트워크에서의 고정 IP 주소와 포트를 정의하며, 로드 밸런싱을 제공합니다.
  • ReplicaSet (레플리카셋): 지정된 수의 파드 복제본이 항상 실행되도록 보장합니다. ReplicaSet은 파드의 스케일링과 장애 복구를 관리합니다.
  • Deployment (디플로이먼트): 파드와 ReplicaSet의 선언적 업데이트를 제공합니다. 디플로이먼트를 사용하면 애플리케이션의 배포, 롤백, 업데이트를 쉽게 관리할 수 있습니다.


📍 서비스 유형

  • ClusterIP: 기본 서비스 유형으로, 클러스터 내부에서만 접근할 수 있는 내부 IP를 생성합니다.
  • NodePort: 클러스터의 모든 노드에 특정 포트를 개방하고, 이 포트를 통해 서비스에 접근할 수 있게 합니다. 이를 통해 클러스터 외부에서도 서비스에 접근할 수 있습니다.
  • LoadBalancer: 클라우드 제공업체의 로드 밸런서를 사용하여 서비스에 외부 IP 주소를 할당합니다. 이를 통해 클러스터 외부에서 서비스에 접근할 수 있으며, 트래픽을 자동으로 파드에 분산시킵니다.


1.5 Pod 실습

cd ~
mkdir yaml
cd yaml
  • YAML 파일 저장소 설정
vi go-http-pod.yaml
  • yaml 파일 생성
apiVersion: v1
kind: Pod
metadata:
  name: http-go	# pod name
spec:
  containers:
  - name: http-go # container name (pod name과 겹쳐도 상관 없음)
    image: sigirace/http-go
    ports:
    - containerPort: 8080
  • pod yaml descriptor
kubectl create -f go-http-pod.yaml
  • 파일에 정의된 내용을 기반으로 쿠버네티스 리소스를 생성
kubectl get pod http-go
kubectl get pod http-go -o wide
  • 생성 확인
kubectl describe pod
kubectl describe pod -o yaml
  • 디테일하게 확인
kubectl annotate pod http-go test1234=test1234
  • 주석생성
kubectl port-forward http-go 8080:8080
  • 포트포워딩
kubectl delete -f go-http-pod.yaml
  • 삭제
kubectl delete pod --all
  • 모두삭제


2. Probe

2.1 속성

  • 각각의 기능들이 포드를 보조하는 역할을 수행
  • 포드 내부에 설정파일 작성


2.2 Liveness Probe

  • 살아있는지 판단하고 살아있지 않다면 다시 시작 ☞ 가용성
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
  • 먼저 pod가 올라갈때 healthy파일을 생성하고 30초 대기
  • 이후 healthy 파일이 있는지 체크함
  • Probe에서 만약 healthy 파일이 없다면 에러를 반환하니 코드 값을 보고 판단 (정상일 경우 0)
  • 0이 아니면 포드를 부수고 다시 재시작함
  • 5초 후에 시작해서 5초 마다 점검함
  • 웹서버의 리턴 코드를 통해서도 수행 가능


2.3 Readiness Probe

  • 포드가 준비된 상태에 있는지 확인하고 정상 서비스를 시작
  • 포드가 준비되지 않은 경우 로드밸런싱을 하지 않음
    • 서비스가 포드로 로드밸런싱을 할텐데 레디니스 체크 후 로드밸런싱 리스트 생성
readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5


2.4 Startup Probe

  • 애플리케이션 시작 시기를 확인해서 가용성을 높임
  • Liveness와 Readiness를 비활성화하고 컨테이너가 시작할 수 있는 시간을 벌어줌


2.5 참고 사이트


3. 레이블과 셀렉터

  • 모든 서비스에 레이블과 셀렉터 없이는 돌아갈 수 없음


3.1 레이블

  • 리소스의 목적에 따라 검색을 수행할 수 있게 됨
    • 다수의 레이블을 가질 수 있음
    • 만드는 시점에 레이블을 첨부하나 수정, 추가 가능
  • 리소스에 키/값 쌍으로 첨부하여 사용 ex) app:test
  • 체계적인 시스템 구축
    • app: 애플리케이션 구성요소, 마이크로서비스 유형 지정
    • rel: 애플리케이션 버전 지정 (release, 버전)


📍 포드 생성 시 레이블 지정 예시

  • metadata의 labels에 지정 > 여러개 가능
metadata:
	name: app_name
	labels:
		key1: value1
		key2: value2


3.2 레이블 및 셀렉터 명령어

kubectl label pod [name] [key]=[value]
  • 레이블을 추가 및 수정
kubectl label pod [name] [key]=[value] --overite
  • 기존 레이블 수정
kubectl label pod [name] [key]-
  • 레이블 삭제
kubectl get pod --show-lables
  • 레이블 확인
kubectl get pod -L [key1],[key2]
  • 특정 레이블 컬럼으로 확인
kubectl get pod --show-lables -l ['key']
kubectl get pod --show-lables -l ['key' = or != 'value']
  • 필터링하여 검색


3.3 참고 사이트


4. Replication Controller

4.1 속성

  • replicaset의 구버전 (v1.8 이전)
  • 포드가 잘 생성되었는지 감시하고, 장애가 났다면 재생성
  • 지속적으로 모니터링하고 실제 포드수가 원하는 포드수와 맞는지 체크


📍 Controller

  • 컨테이너를 감시하고 Pod의 수를 보장해주는 기능을 수행
  • Replication Controller, Replica Set, Deployment


📍Controller 역할

  • Auto Healing: Pod 또는 Node에 문제가 생겼을 대 자동 복구
  • Software Update: Pod를 업데이트 및 롤백하는 기능 ☞ Deployment만 지원
  • Auto Scaling: Pod의 리소스가 부족할 때, Pod를 추가 생성
  • Job: 일시적인 작업을 위해 필요한 순간에만 Pod를 만들었다가 삭제 ex) cron job


4.2 구성 요소

  • 레이블 셀렉터: 포드의 범위를 결정 ☞ 어떤 레이블을 가진 pod를 복제할 것인가
  • 복제본 수: 포드의 복제 수를 결정
  • 포드 템플릿: 포드의 모양을 설명, 포드의 정보


4.3 장점

  • 포드가 없는 경우 새 포드를 실행
  • 노드 장애 발생시 다른 노드에 복제본 생성
  • 수동, 자동으로 수평 스케일링


4.4 Replication Controller 실습

# replication.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
  • pod의 템플릿이 가지고 있는 label과 셀렉터 부분의 label이 동일해야함
kubectl create -f replication.yaml
  • replication controller 생성
kubectl get pod
  • 생성 확인
kubectl delete pod [pod_name]
kubectl get pod
  • 삭제 후 rc에 의해 신규 파드 생성 확인
kubectl label pod [pod_name] app-
kubectl get pod
  • 라벨 삭제 및 rc에 의해 신규 파드 생성 확인
kubectl get pod -o wide
  • Node 확인
kubectl get nodes -w
  • 😗 worker2를 정지 시켜보자
  • 노드의 상태가 Ready로 변경
kubectl get pod -w
  • 5분 후에 변경사항 반영됨
  • 컨테이너를 빠르게 반응하면 자원 문제가 발생할 수 있기에 시간 텀을 둠
  • 5분 뒤에 terminating > pending 상태를 거쳐 worker1에 생성됨
kubectl get nodes -w
  • 😗 worker2를 시작 시켜보자
  • worker2가 ready로 변경
kubectl get pod -o wide
  • 장애가 났을때 만들어졌던 파드들은 삭제됨
  • 쿠버네티스 자체 리소스가 충분하기에 worker1에만 배치됨
    • 리소스가 부족하면 분산배치함


📍 레플리케이션 수정

kubectl scale rc [name] --replicas=[num]
kubectl edit rc [name]
  • 직접 수정
cp [old_yaml] [new_yaml]
kubectl apply -f [new_yaml]
  • yaml 파일 신규 생성 및 수정 후 configure


📍 레플리케이션 삭제

kubectl delete rc [name]


5. ReplicaSet

5.1 속성

  • 레플리케이션 컨트롤러와 거의 동일하게 동작
  • 레플리케이션 컨트롤러는 레이블을 유연하게 선택하기 어려운 단점이 있음
  • 레플리카셋은 이를 극복


📍Replication Controller vs ReplicaSet

  • Replication Controller는 template에 Pod selector를 지정하여 특정 label에 속한 Pod만 관리
  • Replica Set은 특정 label을 조건으로 설정하여 다양한 군집으로 Pod들을 관리
# replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-2
spec:
  replicas: 2
  selector:
    matchExpressions:
      - key: app
        operator: In
        values: 
          - blue
          - yellow
  template:
    metadata:
      labels:
        app: yellow
    spec:
      containers:
      - name: nginx
        image: nginx
  • Replica Set 예시
  • matchExpression을 통해 다양한 표현 생성


5.2 Replica Set 생성 및 명령어

kubectl create -f replicaset.yaml
kubectl get rs
kubectl describe rs [name]
kubectl delete rs [name]


6. Deployment

6.1 속성

  • 배포를 위한 리소스
  • 레플리카셋을 다룰 수 있는 객체
    • 다수의 레플리카 셋을 컨트롤 할 수 있음
  • 레플리카셋의 업데이트를 좀 더 원활하게 도와줌


📍 vs Replica Set

  • Pod를 배포함에 있어 Replica Set은 업데이트 기능 제공하지 않음


6.2 Pod 업데이트 방법

  • recreate: 잠깐의 다운 타임 발생, 포드가 삭제되고 올라옴
  • rolling update: 포드 여러개 중에 낮은 버전을 삭제하고 높은 버전을 하나씩 교체하며 올림


📍 Rolling Update

  • 장점: 무중단 배포가 가능
  • 단점: V1과 V2의 Pod가 공존하는 순간이 있음


📍 Recreate

  • 단점: Pod가 존재하지 않는 순간이 존재함


📍 Blue/Green

  • 장점: V1, V2가 공존하는 순간이 없음
  • 단점: 자원을 2배로 사용


📍 Rolling 업데이트 전략 세부 설정

  • maxSurge
    • 최대 몇개까지의 pod를 배포할 수 있게 할 것이냐
    • 기본값은 25% ex) 10개 생성시 2~3 더 만들어짐
  • maxUnavailable
    • 최소 몇개의 pod를 유지할 것인가
    • 기본값은 25% ex) 10개 생성시 7~8개는 유지됨
  • 값이 클 수록 빠르게 배포될 수 있으나 자원 문제가 있을 수 있음


6.3 Deployment Scaling

kubectl edit deploy [name]
kubectl scale deploy [name] --replicas=[num]


6.4 Deployment 실습

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-jenkins
  labels:
    app: jenkins-test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: jenkins-test
  template:
    metadata:
      labels:
        app: jenkins-test
    spec:
      containers:
      - name: jenkins
        image: jenkins/jenkins
        ports:
        - containerPort: 8080

kubectl create -f http-go-deployment.yaml --record=true
  • record를 통해 history에 명령어를 기록
kubectl get all
  • deployment > replicates > pod 순으로 랜덤 스트링이 뒤에 붙음을 알 수 있음
kubectl rollout history deployment [name]
  • history가 최대 10개까지 저장 ☞ 레플리카셋이 10개까지 가능
kubectl get all
  • deployment > replicates > pod 순으로 랜덤 스트링이 뒤에 붙음을 알 수 있음
kubectl delete pod [pod_name]
kubectl describe rs [replicaset_name]
  • 삭제, 생성에 대한 내용 확인


📍 배포 관련 명령어

kubectl patch deployment [name] -p '{"spec": {"mainReadySeconds": [sec]}}'
  • 업데이트 속도 조절
kubectl rollout pause deployment [name]
  • 업데이트 중에 일시정지
kubectl rollout undo deployment [name]
  • 업데이트 일시중지 중 취소
kubectl rollout resume deployment [name]
  • 업데이트 재시작


6.5 Rolling update 실습

# http-go-deploy-v1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-go
  labels:
    app: http-go
spec:
  replicas: 3
  selector:
    matchLabels:
      app: http-go
  template:
    metadata:
      labels:
        app: http-go
    spec:
      containers:
      - name: http-go
        image: gasbugs/http-go:v1
        ports:
        - containerPort: 8080

kubectl create -f http-go-deploy-v1.yaml --record=true
  • 배포
kubectl rollout status deploy http-go
  • 상태 확인
kubectl rollout history deploy http-go
  • history 확인
kubectl patch deploy http-go -p '{"spec":{"minReadySeconds":10}}'
  • 10초 간격으로 업데이트 수행
  • 모니터링을 위한 명령어
kubectl expose deploy http-go
  • 로드밸런싱을 위한 서비스 생성
kubectl get svc
  • 서비스 ip 확인
kubectl run -it --rm --image busybox -- bash
  • busybox라는 이미지로 bash를 실행시킴 like docker
while true; do wget -O- -q 10.106.1.87:8080; sleep 1; done
  • 쉘 명령어
  • 신규 터미널 생성
kubectl set image deploy [deployment_name] [container_name]=[new_image] --record=true
  • 업데이트 수행
kubectl rollout history deploy [deployment_name]
  • history 확인 가능
  • replicaset의 내용이 바뀌지 않으면 덮어씌워짐
kubectl rollout undo deploy http-go
  • 이전 버전으로 rollback
kubectl rollout undo deploy http-go --to-revision=1
  • 특정 revision으로 변경


7. Namespaces

7.1 속성

  • 하나의 클러스터에서도 권한을 나누어 자신만의 공간에 원하는 포드나 자원들을 배치하고 통신을 할 수 있게함

  • 자원을 한정되게 하여 안정적으로 서비스를 관리하게 만들어줌

  • 리소스를 각각의 분리된 영역으로 나누기좋은 방법
  • 여러 네임스페이스를 사용하면 복잡한 쿠버네티스 시스템을 더 작은 그룹으로 분할
  • 멀티 테넌트 환경을 분리하여 리소스를 생산, 개발, QA 환경 등으로 사용
  • 리소스 이름은 네임스페이스 내에서만 고유 명칭 사용
    • 아이디는 게임 서버 내에서만 유일한 개념


7.2 Namespace 확인 실습

kubectl get ns
  • 현재 클러스터의 기본 네임스페이스 확인
  • 기존에 사용하는 것은 default
  • kubectl get시에 옵션 없이 사용하면 default 네임스페이스에 질의
kubectl get po --namespace [namespace_name]
  • 특정 namespace에 질의
kubectl get [resource] --all-namespaces
  • 전체 네임스페이스 대상으로 질의


7.3 Namespace 생성 실습

kubectl create ns [ns_name]
  • namespae 생성 방식 1
kubectl create ns [ns_name] --dry-run=client -o yaml > [ns_name.yaml]
  • namespae 생성 방식 2
  • –dry-run: 문법 검사
  • -o yaml: yaml 파일 생성
  • yaml 파일로 저장
kubectl create -f [ns_name.yaml]
kubectl get ns
  • 생성 및 확인
kubectl create deploy nginx --image nginx --port 80 -n [ns_name]
  • nginx 배포
kubectl get pod -n office
  • 조회
kubectl delete ns [ns_name]
  • 네임스페이스에서 삭제한 모든 것들이 삭제됨


📍 default 수정

vim ~/.kube/config
  • kubernetes config file
# 수정전
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
    
# 수정후
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
    namespace: [ns_name]

태그:

카테고리:

업데이트:

댓글남기기

참고

Llama 3.1 한국어 Finetuning

7 분 소요

이번 포스트를 통해 unsloth 라이브러리를 사용하여 llama 3.1 모델 finetuning을 실습한다.

LLM의 활용 방법

8 분 소요

이번 포스트를 통해 기업에서 LLM을 사용하기 위한 방법들에 대해 알어본다.