Gom3rye

Kubernetes- Prune, 로그 확인 본문

현대 오토에버 클라우드 스쿨

Kubernetes- Prune, 로그 확인

Gom3rye 2025. 7. 1. 17:48
728x90
반응형

쿠버네티스 우분투에 설치: https://hostnextra.com/learn/tutorials/how-to-install-kubernetes-k8s-on-ubuntu

kubeadm join 192.168.56.100:6443 --token ggdlhb.6mt3begtotrjpqrk \\
        --discovery-token-ca-cert-hash sha256:91b5605c7c84970ed2708d0c7e553d3b19af41abf88c20a3581e575e70ea892c

쿠버네티스 기본 명령어

리소스 상태 체크와 대기

  • kubectl 명령어를 연속적으로 실행하여 리소스를 조작하는 경우 다음 명령어를 실행하기 전에 그 때까지 작업한 리소스가 의도한 상태가 된 후 다음 명령어를 실행해야 하는 경우가 있는데 이때 사용할 수 있는 명령이 kubectl wait 명령이고 --for 옵션에 지정한 상태가 되기까지 대기하고 --timeout 옵션에는 시간을 지정할 수 있는데 기본이 30초이다.
  • 실습
    • sample-pod가 ready 상태가 될 때까지 대기
    kubectl wait --for=condition=Ready pod/sample-pod
    • 모든 파드가 전부 스케쥴링 될 때까지 대기
    kubectl wait --for=condition=PodScheduled pod --all
    • 모든 파드를 삭제하는데 파드마다 5초씩 대기
    kubectl wait --for=delete pod --all --timeout=5s
# 바로 지우기
kubectl delete pod --all --wait=false
    • 파드 이름 대신에 yaml 파일 경로를 넣어도 된다.
    kubectl wait --for=condition=Ready -f sample-pod.yaml

매니페스트 파일 설계

  • 하나의 매니페스트 파일에 여러 리소스를 정의한다.
    • 파드를 기동하는 워크로드 API 카테고리의 리소스와 외부에 공개하는 서비스 API 카테고리의 리소스를 매니페스트에 통합하여 작성할 수 있다.
    • 실행 순서를 정확하게 지켜야 하거나 리소스 간의 결합도를 높이고 싶다면 하나의 매니페스트를 사용하는 것이 좋지만 공통으로 사용하는 설정 파일(configmap 리소스)이나 패스워드(시크릿 리소스) 등은 여러 리소스에서 사용되는 경우가 있기 때문에 공통으로 사용하는 리소스는 별도 매니페스트로 분리하는 것이 좋다.
  • 실습
    • Pod를 Deployment로 배포하고 Service를 동일한 매니페스트 파일에 작성
    ---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order1-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.16
---
apiVersion: v1
kind: Service
metadata:
  name: order2-service
spec:
  type: LoadBalancer
  ports:
    - name: "http-port"
      protocol: "TCP"
      port: 8080
      targetPort: 80
  selector:
    app: sample-app
  • 여러 매니페스트 파일을 동시에 적용
    • 여러 매니페스트 파일을 동시에 적용하려면 디렉토리 안에 적용하고 싶은 여러 매니페스트 파일을 배치해두고 kubectl apply 명령어를 실행할 때 디렉토리를 지정하면 된다.
    • 파일명 순으로 매니페스트 파일이 적용되기 때문에 순서를 제어하고자 하면 파일명 앞에 인덱스 번호 같은 것을 추가
    • -R 옵션을 이용하면 디렉토리 안에 디렉토리가 존재하는 경우 재귀적으로 수행한다.
    • 실습
      • dir 디렉토리를 생성하고 안에 sample-pod1.yaml, sample-pod2.yaml 파일을 넣기
      apiVersion: v1
kind: Pod
metadata:
  name: sample-pod1 # sample-pod2.yaml은 여기만 2로 바꾸기
spec:
  containers:
  - name: nginx-container
    image: nginx:1.16
      • dir 디렉토리 안에 innerdir 디렉토리를 또 만들어서 sample-pod3.yaml 파일 넣기 (위의 yaml 파일에서 이름만 3으로 바꾸고)

                        → 안에 있는 거까지 만들어지게 하려면 -R 옵션 주기

# 현재 디렉토리의 yaml 파일만 실행
kubectl apply -f ./dir
# 재귀적으로 현재 디렉토리의 모든 yaml 파일을 실행
kubectl apply -f ./dir -R
  • 설계 방침
    • 아주 규모가 크지 않을 때는 시스템 전체를 구성하기 위한 모든 마이크로서비스의 매니페스트 파일을 하나의 디렉토리로 통합하여 사용한다.
    • 한 개의 디렉토리에 파일 통합이 어려울 정도로 거대한 시스템인 경우 분리가 가능하다면 서브 시스템이나 부서별로 디렉토리를 나누어서 사용한다.
    • 마이크로서비스마다 디렉토리로 구분해서 리소스 종류 별로 생성할 수도 있는데 가독성이 높아진다는 장점은 있지만 적용 순서 제어가 어렵다는 단점도 있다.

어노테이션과 레이블

  • 쿠버네티스에서는 각 리소스에 대해 어노테이션과 레이블이라는 메타데이터를 부여할 수 있는데 둘 다 쿠버네티스가 리소스를 관리할 때 사용한다는 점에서는 비슷하지만 용도가 다르다.
  • 차이점
    • 어노테이션: 시스템 구성 요소가 사용하는 메타 데이터
    • 레이블: 리소스 관리에 사용하는 메타 데이터
  • 어노테이션과 레이블은 [접두사]/키:값 으로 구성되는데 접두사는 옵션이어서 지정하는 경우에는 DNS 서브 도메인 형식이어야 한다.
  • 명명 규칙
    • 접두사: 253 문자 이하여야 하고 영문 소문자와 숫자만 사용 가능하다.
    • 키 이름이나 값은 63문자 이하이며 영문 대소문자 및 숫자를 사용한다.
  • 어노테이션
    • metadata.annotations 로 설정
    • 리소스에 대한 메모 같은 것으로 어노테이션 자체는 단순한 key-value라서 이 값으로 어떤 처리를 하는 시스템 구성 요소가 없다면 아무런 일도 하지 않는다.
      • 값에 숫자만 사용하는 경우 큰 따옴표로 묶어줘야 한다.
    • 리소스 생성하면서 부여: kubectl apply -f .\dir\sample-annotations.yaml
    apiVersion: v1
kind: Pod
metadata:
  name: sample-annoations
  annotations:
    annotation1: val
    annotation2: "200"
spec:
  containers:
  - name: nginx-container
    image: nginx:1.16
    • 리소스 생성 후 부여: kubectl annotate pods sample-annotations annotations3=val3
    • 기존 값을 변경하고자 할 때는 --overwrite 옵션을 추가하면 된다.
    • 어노테이션 확인: kubectl describe pod sample-annotations
    • 어노테이션 삭제: kubectl annotate pod sample-annotations annotation3-
  • 레이블
    • 리소스 생성: kubectl apply -f dir/sample-label.yaml
    apiVersion: v1
kind: Pod
metadata:
  name: sample-labels
  labels:
    label1: val1
    label2: val2
spec:
  containers:
  - name: nginx-container
    image: nginx:1.16
    • 리소스 확인
    kubectl describe pod sample-labels
    • 리소스 생성 후 부여
    kubectl label pods sample-labels label3=val3
    • 레이블 덮어쓰기
    kubectl label pods sample-labels label3=val3_new --overwrite
    • 레이블 삭제
    kubectl label pods sample-labels label3-
  • 개발자 입장에서의 레이블
    • 리소스에 부여된 레이블을 사용해서 대상 리소스를 필터링 할 수 있다.
      • label1=val1 인 파드를 조회
      kubectl get pods -l label1=val1
  • 모든 레이블을 표시하고 파드 목록을 조회
kubectl get pods --show-labels

prune을 이용한 리소스 삭제

  • 쿠버네티스를 운용할 때 수동으로 kubectl 명령어를 실행하는 일은 거의 없는데 수동으로 운영하는 것은 휴먼 에러가 발생하기 쉽고 사람이 파악하고 관리할 수 있는 리소스 수에 한계가 있기 때문에 권장하지 않는다.
  • 하나의 매니페스트를 Git 저장소에서 관리하고 변경이 있을 때만 kubectl apply 명령어를 사용해 자동으로 매니페스트를 적용시키는 방법 등을 사용한다.
  • 매니페스트에서 리소스를 삭제하기 위한 kubectl delete 명령을 자동으로 실행하려면 매니페스트에서 삭제된 리소스를 감지할 수 있는 구조를 만들어야 한다.
  • 실습
    • kubectl apply 명령어에서 --prune 옵션을 이용해서 자동으로 삭제하는 기능을 구현
      • prune 디렉토리 만들고 그 안에 pod를 생성하기 위한 매니페스트 파일을 추가 (sample-pod1.yaml, sample-pod2.yaml)
      apiVersion: v1
kind: Pod
metadata:
  name: sample-pod1
  labels:
    system: a
spec:
  containers:
    - name: nginx-container
      image: nginx:1.16

      # prune옵션이 없는 경우 
# 2개의 매니페스트 파일을 실행
kubectl apply -f ./prune # prune 디렉토리에 들어간 것
# sample-pod2.yaml 파일 삭제
rm prune/sample-pod2.yaml
# 매니페스트 파일을 실행
kubectl apply -f ./prune
# 파드 확인
kubectl get pods 
# sample-pod2.yaml 파일이 삭제되었음에도 sample-pod2가 남아있다.

# 원래대로 복원하기 (비교하려구)
# 모든 파드를 삭제
kubectl delete pods --all
# sample-pod2.yaml 파일 생성
# pod2.yaml 들어가서 name에 숫자만 2로 바꾸기 

# prune옵션이 있는 경우 
# 리소스 생성
kubectl apply -f ./prune --prune -l system=a
# sample-pod1.yaml 파일 삭제
kubectl apply -f ./prune --prune -l system=a
# 확인
kubectl get pods # 삭제된 sample-pod2 를 정리해서 조회되지 않음

편집기 사용

  • kubectl edit 리소스종류 리소스이름

리소스 일부 정보 업데이트

  • kubectl set 변경할정보 리소스종류 리소스이름 실제값
  • 변경 가능한 정보
    • env
    • image
    • resources
    • selector
    • serviceaccount
    • subject
  • 이미지 변경
  • # sample-pod.yaml을 이용해서 리소스 생성 kubectl apply -f sample-pod.yaml # 이미지 변경 kubectl set image pod sample-pod nginx-container=1.17
  • yaml 파일과 쿠버네티스 등록 정보 비교
  • kubectl diff -f yaml파일경로 kubectl diff -f sample-pod.yaml

사용 가능한 리소스 종류의 목록 조회

  • 모든 리소스 종류 조회
kubectl api-resources
  • 네임스페이스 수준의 리소스
kubectl api-resources --namespaced=true
  • 클러스터 수준의 리소스
kubectl api-resources --namespaced=false

리소스 정보 가져오기

  • 기본 정보 확인
    • 리소스 전체 가져오기
    kubectl get all
    • 리소스를 지정해서 목록에 해당하는 리소스를 가져오기 (여러 개인 경우는 나열)
    kubectl get 리소스종류
    • 리소스 중 특정한 이름을 가진 리소스 정보 가져오기
    kubectl get 리소스종류 소스이름
    • 특정 레이블을 가진 리소스 가져오기
    kubectl get 리소스종류 label이름=값
    • 노드 목록 조회
    kubectl get nodes
  • -o 옵션을 사용하면 다양한 형식으로 출력할 수 있다.
# 조금 자세히 출력
kubectl get pods -o wide
# 야믈로 출력
kubectl get pods -o yaml sample-pod
# 컬럼 이름 수정
kubectl get pods -o custom- columns="NAME:{.metadata.name},NodeIP:{.status.hostIP}"
# jsonpath를 이용하면 특정 항목 값만 조회가 가능하다.
kubectl get pods sample-pod -o jsonpath="{.metadata.name}"
  • 상세 정보 보기
kubectl describe 리소스종류 리소스이름
  • 노드 확인
kubectl get nodes
  • 노드의 리소스 사용량 확인
kubectl top node # 미니큐브에서는 안됨
  • 파드의 리소스 사용량 확인
kubectl -n kube-system top pod
  • 컨테이너의 리소스 사용량 확인
kubectl -n kube-system top pod --containers

컨테이너에서 명령 수행

kubectl exec -it 파드이름 --명령
# sample-pod에 ls 명령을 수행
kubectl exec -it sample-pod -- /bin/ls

kubectl exec -it 파드이름 -c 컨테이너이름 --명령
# sample-pod의 nginx-container에 ls 명령을 수행
kubectl exec -it sample-pod -c nginx-container -- /bin/ls

# sample-pod의 bash셸에 접속
kubectl exec -it sample-pod -- /bin/bash

# 인수를 전달해서 실행
kubectl exec -it sample-pod -- /bin/bash -c "ls -all --classify | grep lib"

포트포워딩

  • kubectl port-forward 리소스 외부포트:내부포트
    • 리소스가 파드이면 파드에 포워딩
    • 리소스에 replicas나 deployment 설정하면 파드 중 하나로 포워딩
    • 서비스를 포트포워딩하면 서비스에 연결된 파드 중 하나로 포트 포워딩

로그 확인

kubectl logs 파드이름

# 컨테이너의 로그 확인
kubectl logs 파드이름 -c 컨테이너이름
kubectl logs sample-pod -c nginx-container

# 실시간 로그 추력
kubectl logs -f

# 시간과 개수 설정
kubectl logs --since=시간 --tail=개수 --timestamps=true 파드이름

컨테이너와 파일 복사

kubectl cp 소스 타깃

# 컨테이너의 파일 가져오기
kubectl cp sample-pod:etc/hostname ./hostname

# 파일
kubectl cp hostname sample-pod:/tmp/newfile
# 확인해보기
kubectl exec -it sample-pod -- ls /tmp # newfile

클러스터에 컨테이너를 기동시키기 위한 리소스

  • 종류
    • Pod
    • ReplicaController
    • ReplicaSet
    • Deployment
    • DaemonSet
    • StatefulSet
    • Job
    • CronJob
  • 리소스 간의 관계
    • Pod ←—— ReplicaController
                         ReplicaSet ←———Deployment
                         DaemonSet
                         StatefulSet
                          Job ←————CronJob

Pod

  • kubernetes의 최소 배포 단위로 다수의 컨테이너가 모인 집합체
  • 하나의 pod는 한 개 이상의 컨테이너로 구성되고 하나의 파드에 여러 개의 컨테이너를 포함시킬 수 있다.
  • 동일한 파드에 포함된 컨테이너끼리는 네트워크 적으로 격리되어 있지 않고 IP 주소를 공유한다.
  • 컨테이너가 두 개 들어있는 파드를 생성한 경우 이 두 컨테이너는 같은 IP 주소를 가지고 이로 인해 파드 내부의 컨테이너는 서로 localhost로 통신할 수 있다.

Pod의 디자인 패턴

  • Sidecar Pattern
    • 메인 컨테이너의 보조적인 기능을 추가하는 sub container를 포함하는 패턴
    • 예를 들면 특정 변경 사항을 감지하여 동적으로 설정을 변경하는 컨테이너 그리고 깃 저장소와 로컬 스토리지를 동기화하는 컨테이너와 애플리케이션의 로그 파일을 오브젝트 스토리지로 전송하는 컨테이너들이 보조적인 기능으로 많이 사용된다.
    • 파드는 데이터 영역을 공유하고 가지고 있을 수 있기 때문에 대부분 데이터와 설정에 관련된 패턴이라고 할 수 있다.
  • Ambassador Pattern
    • 메인 컨테이너가 외부 시스템과 접속할 때 대리로 중계해주는 서브 컨테이너를 포함한 패턴
    • 파드에 두 개의 컨테이너가 있어서 메인 컨테이너에서 목적지에 localhost를 지정해서 앰버서더 컨테이너로 접속할 수 있다.
    • 앰버서더 컨테이너를 사용하지 않고 메인 컨테이너에서 동작 중인 애플리케이션이 sharding 된 데이터베이스 하나를 선택해서 접속하게 되면 메인 컨테이너는 DB와의 결합도가 강해진다.
    • 앰버서더 컨테이너를 사용함으로써 메인 컨테이너는 항상 localhost를 지정해서 앰버서더 컨테이너로만 접속하고 앰버서더 컨테이너가 여러 목적지에 중계해서 연결하도록 구성하게 되면 느슨한 결합을 유지할 수 있게 된다. → 앰버서더 컨테이너를 경유하면 단일 데이터베이스를 사용하는 개발환경이나 분산된 데이터베이스를 사용하는 서비스 환경 모두에서 특별한 변경사항 없이 애플리케이션을 사용할 수 있다.
      • 프론트엔드와 백엔드 서버가 서로 다이렉트로 소통하지 못하게 하고 그 사이에 gateway를 넣으라고 하는 이유도 바로 강한 결합을 피하기 위해서
      • 그래서 도메인도 별명이 있는 것! CNAME (URL에 대한 별명)
  • Adaptor Pattern
    • 서로 다른 데이터 형식을 변환해주는 컨테이너를 포함하는 패턴
    • 프로메테우스 등의 모니터링 소프트웨어는 정의된 형식으로 메트릭을 수집해야 하는데 대부분의 미들웨어가 제공하는 메트릭 출력 형식은 프로메테우스 메트릭을 지원하지 않기 때문에 어댑터 컨테이너를 사용해서 외부 요청에 맞게 데이터 형식으로 변환하고 데이터를 반환해서 사용한다.
728x90
반응형

'현대 오토에버 클라우드 스쿨' 카테고리의 다른 글

Kubernetes- DaemonSet, StatefulSet, Job  (3) 2025.07.03
Kubernetes- Deployment  (1) 2025.07.02
Kubernetes- Pod  (2) 2025.06.30
Kubernetes 개념  (3) 2025.06.27
Docker Swarm  (2) 2025.06.26
'현대 오토에버 클라우드 스쿨' Related Articles more