[Kubernetes] Owner - Dependent (Garbage collector)

해당 글은 Kubernetes 공식문서 Garbage Collection를 토대로 작성한 글입니다.

조금 쉽게 표현하고자 추상적으로 표현한 부분들이 있는데, 자세한 내용은 공식문서를 참조해주세요.

---

쿠버네티스에서 일부 리소스들은 다른 특정 리소스로 하여금 만들어져 운영되는 경우가 있습니다.

• 다시 말해서, 특정 리소스가 일부 리소스의 owner 일 수 있고, 이러한 owner 리소스에 대해 일부 리소스가 dependents 리소스 일 수 있습니다. 즉, 리소스 간에 종속적인 관계가 존재할 수 있는 것입니다.
• 예를 들면, ReplicaSet 은 여러 Pod 들의 owner 라고 말할 수 있을 겁니다. 또한, 이 Pod 들은 ReplicaSet 에 대해 dependents 리소스라고 할 수 있겠죠.

---

Owner references

이러한 종속관계는 dependent 리소스의 metadata.ownerReferences 필드를 통해 나타낼 수 있습니다.

Kubernetes API Reference Docs

• metadata.ownerReferences 는 apiVersion, kind, name, uid 필드를 통해 owner 리소스를 명시할 수 있습니다.
• 추가적으로 controller, blockOwnerDeletion 필드를 통해 쿠버네티스 특정 동작을 설정할 수 있습니다.

기존 종속적인 관계가 있는 리소스(ReplicaSets, DaemonSets, Deployments, Jobs and CronJobs, and ReplicationControllers 등)에서는 자동으로 이러한 ownerReferences 가 지정되어 동작합니다.

 

한번 테스트 해보죠.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-repset
spec:
  replicas: 3
  selector:
    matchLabels:
      pod-info: sample
  template:
    metadata:
      labels:
        pod-info: sample
    spec:
      containers:
      - name: nginx
        image: nginx

위 ReplicaSet을 배포해봅시다.

$ kga
NAME                  READY   STATUS    RESTARTS   AGE
pod/my-repset-29t76   1/1     Running   0          45s
pod/my-repset-nbbhh   1/1     Running   0          45s
pod/my-repset-s86vj   1/1     Running   0          45s

NAME                        DESIRED   CURRENT   READY   AGE
replicaset.apps/my-repset   3         3         3       45s

3개의 Pod 가 만들어진 것을 확인할 수 있습니다.

이 중 한 개의 Pod metadata를 살펴봅시다.

$ k edit pod/my-repset-29t76

...

apiVersion: v1
kind: Pod
metadata:

	...

  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: my-repset
    uid: 766396cd-d067-481a-8003-81aafcf80670

...

ownerReferences 필드가 설정되어져 있는 것을 볼 수 있습니다.

딱 봐도 Pod 을 생성한 ReplicaSet 을 가르키는 것 같네요.

ReplicaSet uid 를 확인해보면 확실해지겠죠?

$ kubectl get rs my-repset -o yaml | grep uid | cut -d ":" -f 2
766396cd-d067-481a-8003-81aafcf80670

uid도 같은 것을 보아 owner - dependent 관계가 자동으로 설정되어져있음을 볼 수 있습니다.

 

당연히 수동으로 직접 이러한 owner - dependent 관계를 만들기 위해 ownerReferences 를 설정할 수 있습니다.

한번 해볼까요?

apiVersion: v1
kind: Pod
metadata:
  name: pod-owner
spec:
  containers:
  - name: container
    image: kubetm/init

위 Pod를 생성해 uid를 확인해봅시다.

$ k edit pod pod-owner

apiVersion: v1
kind: Pod
metadata:

  ...

  name: pod-owner
  namespace: default
  uid: 2ab40d57-1eed-488e-8271-0721ead830c1

	...

이를 이용해 ownerReferences 필드에 사용해봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: pod-child
  ownerReferences:
    - apiVersion: v1
      kind: Pod
      name: pod-owner
      uid: 2ab40d57-1eed-488e-8271-0721ead830c1
spec:
  containers:
  - name: container
    image: kubetm/init

위 Pod을 생성해봅시다. 정상적으로 만들어지는 것을 볼 수 있습니다.

• uid 가 제대로 설정되지 않는다면 해당 Pod는 만들어지지 않습니다. 바로 Terminating 상태가 됩니다. 종속관계의 대상이 없어진 것으로 인식하고 Garbage로 판단됩니다.

 

그래서, ownerReferences 를 통해 연결해주면 어떤 동작이 달라질까요?

• delete 동작에 종속관계가 사용되어 제거됩니다. 좀 추상적으로 이야기했지만, owner-dependents 관계에 따라 kubernetes garbage selector에 의해 함께 제거될 수 있습니다.

---

Deletion

controller, blockOwnerDeletion 필드 설정 없이 연결만 해주었다고 합시다.

• dependent 리소스를 제거하는 경우
  • owner 리소스에 영향 없이 dependent 리소스만 제거됩니다.
• owner 리소스를 제거하는 경우
  • owner 리소스 제거 후, dependent 리소스가 제거됩니다.
  • 병렬적으로 제거되지 않고, 순차적으로 동작합니다. 별다른 설정이 없다면 owner 리소스가 먼저 제거됩니다.

위 방식이 default인 경우 동작하는 형태입니다. ReplicaSet을 제거했을 때, 연결된 Pod들이 자동으로 제거되는 것을 생각하면 되겠죠?

 

Cascading deletion

위에서 언급했듯 owner 리소스를 제거하면 dependent 리소스가 제거됩니다. 이렇게 종속관계 리소스들이 흐르듯 제거가 되는 것을 Cascading deletion 이라고 합니다. (Database FK에서 cascade 옵션 같은 것을 생각하면 이해하기 쉽겠네요!)

 

쿠버네티스에서는 3가지의 Cascading deletion을 제공하고 있습니다.

• background cascading deletion
  • dependent 리소스가 삭제되기 전에 owner 리소스가 삭제됩니다.
• foreground cascading deletion
  • owner 리소스가 삭제되기 전에 dependent 리소스가 먼저 삭제됩니다.
  • owner 리소스가 Terminating 상태가 된 후, dependent 리소스가 삭제됩니다. dependent 리소스가 다 완전히 삭제되면, onwer 리소스도 삭제됩니다.
• orphan
  • ownerReferences 를 무시합니다. 즉, 특정 리소스를 제거했을 때 owner 관계를 따지지 않고 그 특정 리소스만을 제거합니다.

 

쿠버네티스는 background cascading deletion을 default로 사용하고 있습니다.

• 이는 공식문서와 kubectl reference docs에서 확인할 수 있습니다.

 

그럼 default(background)가 아닌 다른 cascading deletion을 사용하고 싶은 경우엔 어떻게 할까요?

쿠버네티스 API를 사용하면 되지만, 이를 쉽게 활용하게 만든 kubectl 사용법만 설명하겠습니다.

• kubectl delete 에서 --cascade 옵션을 사용하면 됩니다.
  • background [default], foreground, orphan
• ex) kubectl delete pod pod-owner --cascade foreground