$ kubectl get pods -o wide -w -n exapi
NAME                         READY   STATUS    RESTARTS   AGE   IP            NODE                                                     NOMINATED NODE                                READINESS GATES
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          1s      <none>        <none>                                                   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     ContainerCreating   0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          100s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          101s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          102s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          2m11s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          1s      <none>        <none>                                                   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-6889b9d9d8-8n2mf       0/1     ContainerCreating   0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          85s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          86s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          87s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          116s    10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1

자알 돌아간다~ 정상적인 것처럼 보이나...

Default 값을 믿고 열심히 삽질해 준 나에게 감사한다.

Rolling Update 시 가장 먼저 선행해야 할 것은 strategy 명시이다. 기본값으로 테스트하겠다고 이 부분을 생략한게 큰 타격이 됐다.

$ my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: exapi
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0         # 0 fast
      maxUnavailable: 1   # 0 slow

maxSurge 와 maxUnavailable 값은 배포시 최대 생성 pod 수와 종료 수를 명시할 수 있다. 각각 0/1, 1/0 으로 설정할 경우 running 상태 이후에 terminating 을 시키느냐, pending 과 동시에 terminating 을 시키느냐의 차이이며 약 30초 정도의 차이를 확인했다.

겉보기에는 잘 작동하는 것처럼 보이나 배포시 약 5~10초간 502 Gateway Error 뒤에 504 Gateway Time-out 이 발생한다. 우선 502 에러가 발생하는 시점을 찾아봤다.

쿠버네티스에서 kubectl rollout restart 명령으로 배포할 경우, 새 pod 가 추가되고 Running 상태가 되면 기존 포드가 삭제되는 식이다. 확인 결과 pod 가 Terminating 되는 순간에 502 에러가 발생했다. ALB 의 Target 이 동시에 draining 되는 시점이기도 하다. 인터넷을 후벼파서 결과, 502 에러를 최소화 할 수 있는 방법을 찾아 결국 해냈다.

502 Gateway Error / 504 Gateway Time-out Error 최소화

1. ingress : connection-draining 설정

ALB 에 connection-draining 관련 옵션을 주어 기존 연결에 대한 처리를 유지한다. (이미 기본값으로 동작중. 효과없음.)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  ...
  annotations:
    ...
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "30"

2. pod : readiness-gate 설정

readiness-gate 옵션을 활성화 하여 새로운 target 이 healthy 상태로 연결되기 전까지 기존 target 을 종료하지 않음. (마찬가지로 502 에러는 발생하나, ALB 내의 target 이 healthy 상태가 한개도 유지되지 않는 어이없는 상황은 막을 수 있음). 반드시 필요!

$ kubectl label namespace {mynamespace} elbv2.k8s.aws/pod-readiness-gate-inject=enabled

apiVersion: apps/v1
kind: Deployment
metadata:
spec:
  template:
    spec:
      containers:
      - name: api
      readinessGates:
      - conditionType: target-health.alb.ingress.k8s.aws/api-ingress_api-nodeport_80

readiness-gate 옵션을 활성화할 namespace 에 레이블을 설정하고, target-health.alb.ingress.k8s.aws/{ingress-name}_{service-name}_{port} 를 위처럼 삽입한다. 설정이 올바르지 않으면 ALB 에서 target 그룹을 인식하지 못할 수도 있으니 주의!

3. pod : preStop 설정

life-cycle hooks 에서 pod 가 중지되기 전에(preStop) 딜레이를 가지며 기존 연결을 마저 처리한다. 새로운 연결이 이루어지지 않는다. (인터넷에서 좋아요도 가장 많고, 실제로 preStop 설정만으로 502 에러를 해결하였음.)

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
        lifecycle:
          preStop:
            exec:
              command: ["sleep", "60"]

4. pod : terminationGracePeriodSeconds 설정

preStop 가 실패했을 때 대신 컨테이너를 종료시킨다. (preStop sleep 값보다 +10초 정도로 설정: default 값은 45초)

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: web-api
      ...
      terminationGracePeriodSeconds: 70

5. pod livenessProbe / readinessProbe 설정

pod 의 활성화 상태를 나타내는 livenessProbe 가 실패하면 재시작 정책의 대상이 된다. pod 준비 상태를 나타내는 readinessProbe 가 실패하면 해당 pod 는 모든 엔드포인트에서 제거된다. (두 방법 모두 비정상 pod 에 연결을 못받게 하여 502 에러를 줄인다고는 하는데 효과는 잘 모르겠음.)

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
      ...
        livenessProbe:
          httpGet:
            path: /
            port: 80
          periodSeconds: 4
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 10

정리

이 5가지 설정 중 3가지를 사용하여 무중단 배포를 완벽하게 해결했다.

preStop
readinessGates
terminationGracePeriodSeconds

readinessGates 설정을 가장 먼저 한 바람에 필수요소인지는 확실치 않다. (조만간 테스트 예정)
preStop 설정으로 무중단 배포를 해결했다. (본인의 서비스와 사양에 맞는 설정이 필요할 수 있다.)
terminationGracePeriodSeconds 설정을 하지 않아도 문제는 없었다. 내 경우 기본값이 45초 만으로 충분한 듯.

한가지 더... kubectl rollout 으로 테스트 할 때 기존의 pod 가 원치 않는 동작을 할 수도 있다. 항상 기존 pod 는 delete 로 삭제한 후에 새로 생성하여 테스트 하는 것이 원하는 결과를 얻는데 도움이 될 것 같다.

무중단 배포도 안된다고 며칠을 eks 욕하고 있었는데... 정말 다행이다. ^_______________^

쿠버네티스에서는 배포 방법으로 블루/그린 배포, 카나리 배포, 롤링 업데이트 등을 사용할 수 있다. 롤링 업데이트 방식은 운영중인 어플리케이션의 파드 수를 하나씩 줄이고, 새로운 어플리케이션의 파드 수를 하나씩 늘려가며 변경하는 방법이다. 쿠버네티스는 어플리케이션 이미지를 업데이트 하면 롤링 업데이트 방식으로 배포를 진행할 것이다. 쿠버네티스에서 배포 업데이트는 버전으로 관리되고, 이전의 안정적인 버전으로도 복구가 가능하다.

다음 테스트는 kubernetes-bootcamp:v1 이미지를 사용 중인 서비스 환경에서 v2 이미지로 교체하였을 때 어플리케이션의 배포 진행을 파악하고, 다시 v1 이미지로 복원하는 시나리오 이다.

4개의 파드에 kubernetes-bootcamp:v1 이미지를 구동하여, 이미 서비스로 운영중임을 확인.

해당 deployment 에 어플리케이션 이미지를 교체할 때,  kubectl edit deployment  명령을 사용하거나  kubectl set image  명령을 사용할 수 있다.

위 명령은 deployment 에 다른 이미지를 사용하도록 변경하고, 롤링 업데이트를 시작하도록 한다. 업데이트 확인.

잠시 후에 서비스 ip 로 접근해 보면, 다음과 같이 새로운 v2 버전의 파드에 로드 밸런싱 되는 것을 확인할 수 있다.

그렇다면 업데이트 과정을 살펴보자.

새로 생성된 ReplicaSet(5bf4d5689b) 의 파드 수가 하나씩 늘어나고, 동시에 ReplicaSet(6bf84cb898) 의 파드 수가 줄어들며 롤링 업데이트가 진행되는 것을 확인할 수 있다. 

만약에 경우에 이전 버전의 업데이트로 돌아가려면  rollout undo  명령으로 가능하다.

여기서 또 다시 rollout undo 명령을 실행하면 v1 버전보다 더 예전의 업데이트가 아닌 바로 전인 v2 버전으로 다시 돌아가는 것에 주의하자.

Google Cloud Platform 에서 쿠버네티스를 운영하기 위한 방법으로 Kubernetes Engine 과 Kubernetes API 를 사용하여 어플리케이션을 배포 및 관리 할 수 있다. 간단하게 쿠버네티스를 이용하여 어플리케이션을 테스트 해보자.

GKE(Google Kubernetes Engine) 를 사용하여 쿠버네티스 클러스터 생성

kubectl 를 사용하여 Docker 컨테이너를 배포 및 관리

쿠버네티스의 Deployment 와 Service 를 사용하여 마이크로 서비스로 어플리케이션 분리

1. 구성 연결

GCP 콘솔의 APIs & services 에서 Kubernetes Engine API 와 Container Registry API 이 활성화 되어 있는지 체크하고, Cloud Shell 이나 Cloud SDK 를 사용하여 GCP 계정, 프로젝트, zone 설정 등을 확인한다.

2. 클러스터-노드 생성

위의 명령으로 클러스터(bootcamp) 와 node 가 5개 생성된다. --scopes 인수는 나중에 사용할 프로젝트 호스팅과 Google Cloud Storage API 에 대한 액세스를 제공한다.

GCP 콘솔에서 확인하고 싶다면 클러스터는 [Kubernetes Engine > Cluster], 노드는 [Compute Engine > VM Instances] 에서 확인할 수 있다. 아래 예제처럼 GCP 콘솔에서 직접 클러스터를 생성할 수도 있다.

3. 어플리케이션 배포

위 명령으로 nginx 컨테이너를 담은 파드가 생성되고 노드에 배치됐다.

4. 서비스 생성 (외부IP 노출)

위 명령으로 LoadBalancer 타입의 서비스를 생성하여 nginx 컨테이너를 외부에서 접근할 수 있게 한다. 생성된 External-IP 와 port 는 서비스가 유지되는 동안만 유효하다. (External-IP 생성에 일정 시간이 소요될 수 있음)

5. pod 수 확장

위 명령은 생성해 놓은 nginx 배포(deployment) 의 pod 수를 3 개로 늘린다. 마스터는 요청에 따라 적절한 노드를 찾아 2개의 파드를 각각 추가로 배치한다. 트래픽이 많거나 적을 경우 위와 같이 파드 수를 늘리거나 줄일 수 있다.

6. 어플리케이션 테스트

7. 삭제

파드나 서비스를 더 이상 사용하지 않을 경우 아래와 같이 삭제한다.

hello minikube 글에서 어플리케이션 배포부터 노출까지 알아봤었는데 그 때의 배포 명령이 기억 나는가?

위와 같이 kubectl create deployment 명령 다음에 배포에 관련된 정보나 상태 등의 spec 을 inline 으로 나열하였었다. 명령의 이러한 파라미터들은 JSON 형식으로 변환되어 쿠버네티스 API 로 전달된 후 처리된다. 이렇게 kubectl 명령에 inline 으로 파라미터나 플러그 등을 나열하는 것을 명령형(Imperative) 커맨드라고 하며, 주로 일회성 작업을 할 때 사용한다. 나열될 파라미터 수가 적을 때 사용하면 유용하다.

또 한가지 배포에 관련된 정보나 상태 등의 spec 을 상세하게 나열하는 대신 파일(.yaml) 안에 정의하는 방법을 사용할 수도 있는데, 이것을 명령형 오브젝트 구성(Imperative object configuration) 이라고 한다. 다음과 같이 로컬 파일이나 url 상의 파일을 지정하여 사용할 수 있다.

위 yaml 예제 파일에는 다음과 같이 3개의 nginx 파드를 생성하는 내용이 담겨 있다.

.yaml(야믈) 파일은 위처럼 공백 문자를 이용한 들여쓰기로 구조체를 구분하며, 리스트, 해시, 스칼라 데이터의 조합을 모두 표현할 수 있다. 각 항목들을 살펴보면 통신할 api 버전, 생성할 오브젝트 종류, 이름, 식별자, 파드 수, 어플리케이션 이름, 컨테이너 이미지 정보, 연결포트 등이 정의되어 있으며, 쿠버네티스 API 는 이 정의대로 Deployment 를 생성하게 된다. 운영시에는 inline 방식의 명령형 커맨드 보다는 .yaml 파일에 오브젝트를 정의하는 명령형 오브젝트 구성을 주로 사용하게 되며, 위처럼 아주 깔끔하고, 명확하게 오브젝트의 의도를 한눈에 파악할 수 있다. 물론 .yaml 파일을 작성하는 방법이나 오브젝트 정의 방법을 숙지해야 하는 것은 함정!

오브젝트 정의 방법을 간단하게 살펴보자.

쿠버네티스에서 가장 중요한 것은 무엇일까. 아마도 위에 정의한 것 처럼 사용자가 원하는 리소스 및 스펙이 계속해서 유지되는 것이 가장 중요할 것이다. 즉, 사용자가 바라는 상태(desired state) 를 계속해서 유지해야 한다. 배포될 어플리케이션(pod)의 워크로드 정보를 나타내는 클러스터 정보(namespace), 네트워크(service), 디스크 리소스(volume) 를 쿠버네티스의 기본 오브젝트라고 한다. 또한 기본 오브젝트들을 편리하게 관리하기 위한 컨트롤러들이 있다. 파드 복제 수(ReplicaSet), 배포(Deployment), 상태관리API(StatefulSet), 파드를 모든 노드에 복제(DaemonSet), 단일실행(Job) 들이 그것이다. 이러한 오브젝트들은 위와 같이 .yaml 파일에 정의하여 생성/업데이트/삭제 등의 관리를 할 수 있다.

아래는 오브젝트 정의에 필요한 필수 요소이다.

• apiVersion - 이 오브젝트를 생성하는데 사용할 API 버전
• kind - 생성할 오브젝트 종류
• metadata - 오브젝트를 식별할 수 있는 고유 이름
• spec - 오브젝트 특유의 중첩된 필드를 포함하며, 오브젝트마다 정확한 포맷이 다르므로 관리할 오브젝트의 spec 포맷을 확인한다.

위의 deployment 오브젝트 정보를 담은 .yaml 파일을 실행하면 아래와 같이 nginx 를 구동하는 3개의 파드가 생성된 것을 확인할 수 있다.

여차저차해서 Minikube start 명령으로 VM 노드에 클러스터를 생성했다. 이 모든건 삽질이었다. katacoda 란 사이트에서는 minikube 가 설치된 서버에서 브라우저 환경을 제공하여 무료로 minikube 테스트를 할 수 있다.ㅠ 그래도 클러스터 생성하기까지 많은 것들을 얻을 수 있었다! 제일 처음 사용해 본 minikube 명령은 클러스터 생성/중지/삭제 등의 기본적인 구동관련 위주로 쓰이므로 앞으로 자주 사용하게 될 kubectl 명령에 익숙해져야 한다. 이제 쿠버네티스를 맛볼 수 있는 최고의 프로그램 Hello world 어플리케이션 테스트할 수 있다. 단순히 어플리케이션의 구동 테스트이므로 심플하게 과정만 보자. (no VM 환경이라면 클러스터에 명령을 내릴 kubectl 도구를 수동으로 설치해야 한다.)

특정 어플리케이션 컨테이너화(이미지로 빌드) 및 저장소에 푸시하기.

어플리케이션 배포하기.

어플리케이션 구동 확인하기.

1. Deployment 생성

kubectl 은 클러스터(엄밀히 말하면 클러스터의 Master, 더 엄밀히 말하면 Master 의 apiserver) 에 명령할 때 필요한 클라이언트 도구이며, 위와 같이 kubectl create 명령으로 클러스터에 무엇인가를 생성하도록 명령할 수 있다. ( kubectl create deployment  는  kubectl run  명령과 같다.) 빠른 진행을 위해 배포할 어플리케이션(hello-minikube) 의 컨테이너화, 저장소 푸시 과정이 생략되었으며, 그러한 컨테이너 이미지만 있으면 클러스터에서 배포가 가능하다는 것을 보여준다. 쿠버네티스에서 배포(deployment) 란 특정 노드에 어플리케이션 컨테이너를 담은 pod 를 생성하는 것을 말한다. pod 는 그 안의 어플리케이션 컨테이너와 그 각종 정보(name, port, ...)들을 담고 있다.

2. Deployment 확인

kubectl get 명령은 클러스터(Master) 에 정보를 요청하는 것이다. 위 명령으로 현재 deployment 와 pod 의 정보 및 상태를 확인할 수 있다. deployment 와 pod 가 뭐가 다른건지 궁금할 수도 있다. pod 는 기본 오브젝트이고 deployment 는 컨트롤러로서(나중 설명), deployment 가 pod 를 컨트롤한다. deployment 가 배포를 위한 전략 정보를 담고 있다면, pod 는 그 전략대로 실행된 결과물로 볼 수 있다. 이렇게 생성된 pod 는 기본적으로 클러스터 내부에서만 접근할 수 있다. 외부에서 접근이 가능하려면 로드밸런스 같은 역할을 하는 Service 를 생성해야 한다.

3. Service 생성

외부 네트워크에서 특정 리소스에 접근하려면, kubectl expose 명령을 사용하여 LoadBalancer 타입의 Service 가 생성되며 이를 통해 외부에서 Service 로 접근이 가능하게 할 수 있다.

4. Service 확인

외부 네트워크에서 접근할 수 있는 Service 리스트이다. 이제 hello world 어플리케이션을 구경할 수 있는 엔드포인트는 어떻게 될까. minikube 에서는 LoadBalancer 타입의 service 라도 외부ip 로 접근이 불가능하나(pending상태), minikube ip 명령으로 cluster 생성시 발급된 VM IP 와 위 service 의 우측 포트 30369 를 통해 접속하거나, minikube service hello-node 명령을 사용하여 즉시 브라우저를 띄워 어플리케이션을 확인할 수 있다. no VM 환경에서는 로컬에서 Service 로 접근이 가능하다. (ex. 10.108.144.78:8080)

5. 어플리케이션 확인

6. 리소스 삭제

더이상 클러스터와 생성한 작성들을 사용하지 않는다면 아래와 같이 삭제할 수 있다.

7. 클러스터 중지/삭제

중지(stop) 는 클러스터 내부의 리소스들이 삭제되지 않지만, 삭제(delete) 는 클러스터 및 내부 리소스들이 모두 삭제된다.