[Kubernetes & Docker] 4-3. kubectl 기초 (2/2)

도커 로고

오늘은 kubectl 기초 사용법에 대한 마무리를 짓도록 하겠다. 이전 글 참고

 

1.6 파드 재기동

디플로이먼트 등의 리소스와 연결되어 있는 모든 파드를 재기동할 수 있다. (rollout restart)
파드 기동 시 처리를 재실행하고 싶을 때나, 시크릿 리소스에서 참조되는 환경 변수를 변경하고 싶을 때 사용하면 좋다고 함.

kubectl rollout restart

# 리소스 생성
$ kubectl apply -f sample-deployment.yaml
$ kubectl apply -f sample-pod.yaml

# 이후 기동된 pod 를 확인
$ kubectl get pod

NAME READY STATUS RESTARTS AGE
sample-deployment-77c7b569f6-7llhl 1/1 Running 0 44s
sample-deployment-77c7b569f6-gh74t 1/1 Running 0 44s
sample-deployment-77c7b569f6-vgvzh 1/1 Running 0 44s
sample-pod 1/1 Running 0 33s

# Deployment 리소스의 모든 파드 재기동
$ kubectl rollout restart deployment

sample-deployment deployment.apps/sample-deployment restarted

# 단독 파드에는 사용 불가능
$ kubectl rollout restart pod

sample-pod error: pods "sample-pod" restarting is not supported

이후 kubectl get pod 에서 AGE 를 보면 재기동 여부를 확인할 수 있다.

$ kubectl get pod

NAME READY STATUS RESTARTS AGE
sample-deployment-7cb5854d44-2fpwj 1/1 Running 0 51s
sample-deployment-7cb5854d44-dw6xw 1/1 Running 0 50s
sample-deployment-7cb5854d44-qw2bd 1/1 Running 0 52s
sample-pod 1/1 Running 0 3m6s

롤링 배포로 이루어지는 것 같은데, 단독 파드의 경우(kind가 Pod 인 경우)에는 재시작을 할 수 없다.
그럼 단독 pod 는 재시작할 수 없는 걸까? 찾아보니 삭제 후 다시 만들어야 한다고 한다.

 

1.7 generateName으로 임의의 이름을 가진 리소스 생성

앞에서 설명했듯이 기본적으로 kubectl apply 명령어를 사용하는 것이 바람직하지만, kubectl create 를 사용하여 난수가 있는 이름의 리소스를 생성할 수 있다.

metadate.name 대신 metadata.generateName 을 지정하고 리소스를 생성하면, 그 이름에 접두사(prefix)를 붙여 이름이 자동으로 생성된다.

sample-generatename.yaml

apiVersion: v1
kind: Pod
metadata:
# name: sample-pod
  generateName: sample-generatename-
spec:
  containers:
  - name: nginx-container
    image: nginx:1.16

아까 sample-deployment.yaml 는 워크로드 리소스 중 deployment 리소스를 통해 3개의 pod를 한꺼번에 생성했었는데, 그때 처럼 자동 생성된 이름을 사용할 수 있게 된다.

주의할 것은 metadata.generateName 은 kubectl apply 에서는 사용할 수 없다고 한다.

 

1.8 리소스 상태 체크와 대기(wait)

kubectl 명령어를 연속적으로 실행할 때, 명령어가 완료되고 난 후 완료되길 기다렸다가 다음 명령어를 실행해야 되는 경우가 있는데,
그때 사용하는 것이 kubectl wait 명령어 이다.

실행하면 --for 옵션에 지정한 상태가 되기까지 kubectl 명령어가 최대 --timeout 옵션에 지정하는 시간 (기본값은 30초) 까지 종료하지 않고 대기한다.

# 파드를 세 개 생성한다.
$ kubectl create -f sample-pod.yaml

# 아까 배운 generateName 을 활용한다.
$ kubectl create -f sample-generatename.yaml
$ kubectl create -f sample-generatename.yaml

# 여기서 sample-pod 가 정상적으로 기동할 때(ready 상태가 될 때)까지 대기
$ kubectl wait --for=condition=Ready pod/sample-pod

# 모든 파드가 스케줄링될 때(PodScheduled 상태가 될 때)까지 대기
$ kubectl wait --for=condition=PodScheduled pod --all

# 모든 파드가 삭제될 때 까지 파드마다 최대 5초씩 대기한다.
# 아직 파드를 삭제하지 않으므로 타임아웃 한다.
$ kubectl wait --for=delete pod --all --timeout=5s

# 모든 파드를 삭제한 후 곧바로 kubectl wait를 실행
$ kubectl delete pod --all --wait=false

# 모든 파드가 삭제될 때까지 대기
$ kubectl wait --for=delete pod --all

매니페스트 파일을 대상으로도 사용할 수 있다.

# 파드 생성
$ kubectl apply -f sample-pod.yaml

# 매니페스트 파일이 정상적으로 기동할 때 까지 대기
$ kubectl wait --for=condition=Ready -f sample-pod.yaml

 

 

1.9 매니페스트(yaml) 파일 설계

매니페스트 파일에 여러 리소스를 정의하거나 여러 매니페스트 파일을 동시에 적용할 수도 있다.

 

하나의 매니페스트 파일에 여러 리소스를 정의

관리가 쉬워지지만, 공통으로 사용하는 설정 파일이나 패스워드 등은 별도의 매니페스트로 분리하는 것이 좋다.
--- 로 구분한다.

sample-multi-resource-manifest.yaml

---
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.12
          ports:
            - containerPort: 80
---
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

적용 순서는 위에서 부터 아래로 적용된다.

 

여러 매니페스트 파일을 동시에 적용

디렉토리 안에 있는 모든 yaml 파일을 재귀적으로사용할 수 있다. (대박..)

 

dir 구성

이렇게 구성되어 있는 매니페스트 파일을 한번에 생성할 수 있다.

 

# 디렉토리(아래에 있는 모든 yaml 파일)를 지정하여 리소스 생성
$ kubectl apply -f ./dir

이때는 sample-pod1, 2만 실행된다.

 

# 디렉토리 안의 서브 디렉토리도 모두 가져와 리소스 생성
$ kubectl apply -f ./dir -R

이때는 sample-pod1, 2, 3 모두 실행된다.

따라서 이런 규칙을 잘 활용하면 마이크로서비스 단위로도 나눌 수 있고,
위의 예시처럼 워크로드 리소스를 Deployment + Service 로 통합할 수 있다.
또 디렉토리 별로 나눌 수도 있겠다.

 

1.10 어노테이션과 레이블

쿠버네티스Manifest 파일에 Annotation과 Label 을 부여할 수 있다.

명칭	개요
어노테이션	시스템 구성 요소가 사용하는 메타데이터
레이블	리소스 관리에 사용하는 메타데이터

 

어노테이션

어노테이션 관련한 내용은 공식 문서를 참조하는게 더 나은 것 같다.
간단하게 메타데이터라고 보면 되고, 접두사는 DNS 형식으로 253자 까지 가능하고, 키 이름과 값은 63문자 씩이다.

접두사는 키 앞에 쓰이며, rgbplace.kubernetes.io/annotation1 이런 식으로 쓸 수 있다. (참고)

apiVersion: v1
kind: Pod
metadata:
  name: sample-annotation
  annotations:
    annotation1: "200"
    annotation2: val2
spec:
  containers:
    - name: nginx-container
      image: nginx:1.12

어노테이션을 확인하기 위해 전에 배웠던 kubectl get pod 파드이름 -o yaml 을 사용하여 볼 수 있다.

어노테이션은 다음과 같이 3가지의 이유로 인해 사용한다.

• 시스템 구성 요소를 위한 데이터 저장
  • 사용자가 아닌 시스템이 생성하며 자동으로 부여한다.
• 모든 환경에서 사용할 수 없는 설정
  • 모든 쿠버네티스 환경(GKE/AKS/EKS)에서 사용할 수 없는 설정은 어노테이션으로 제어할 수 있도록 구현되어있다.
• 정식으로 통합되기 전의 기능을 설정
  • 실험적인 기능과 평가 중인 새로운 기능 설정을 어노테이션으로 사용하는 경우도 있다.

 

레이블

리소스를 구분하기 위한 정보 같은 거라고 볼 수 있다.
역시 공식문서를 보고 최신 내용을 지속적으로 보는 것이 좋겠다.

apiVersion: v1
kind: Pod
metadata:
  name: sample-label
  labels:
    label1: val1
    label2: val2
spec:
  containers:
    - name: nginx-container
      image: nginx:1.12

매니페스트 파일로 작성할 수도 있고, kubectl 에서 직접 부여할 수도 있다.

# 레이블 부여
$ kubectl label pods sample-label label3=val3

# 레이블 덮어쓰기
$ kubectl label pods sample-label label3=val3-new --overwrite

# 레이블 확인
$ kubectl get pod sample-label -o json | jq .metadata.labels

# 레이블 삭제
$ kubectl label pods sample-label label3-

그리고 레이블을 활용한 다양한 방법이 있다.

# label1=val1 과 label2 레이블을 가진 파드를 표시
$ kubectl get pods -l label1=val1,label2

# 파드와 label1 레이블 표시 ([중요]이때, label1 에 무슨 값이 들어있는지 확인 가능하다.)
$ kubectl get pods -L label1

# -l -L 동시에 사용하기
$ kubectl get pods -l label1=val1 -L label2

레이블은 크게 두 가지 용도로 사용된다.

• 개발자가 사용하는 레이블
  • 많은 리소스를 효율적으로 관리할 때 사용
• 시스템이 사용하는 레이블
  • 파드 수를 유지하는 워크로드 리소스(ReplicaSet) 에서는 레이블에 부여된 파드 수를 계산하여 관리하는데, 그때 사용
  • 서비스 리소스(LoadBalancer) 에서 레이블을 기준으로 목적지 파드를 결정할 때 사용

 

처음부터 레이블을 지정할 정책을 정하고, 다음과 같이 몇 가지 레이블을 지정해 두는 것이 좋다.

• 프로젝트
• 애플리케이션 종류
• 애플리케이션 버전
• 환경

사용할 수 없는 레이블 단어가 있으니 공식문서를 보고 예약어를 확인할 수 있도록 하자

 

후기

• 이후엔 본격적으로 CKAD 자격증 공부에 대한 내용을 기술하려고 한다.
• kubectl 에 대한 나머지 내용은 필요하면 추가적으로 정리해보도록 하겠다.