T-워크로드 템플릿에 없는 파드를 포착한다면

#kubernetes/workload/deployment #kubernetes/pod #kubernetes/controller #container #cloud #topic/temp

개요

디플로이먼트의 기본 사용법은 라벨 셀렉터와 템플릿의 라벨을 일치시켜 작성하는 것이다.
그런데 만약.. 셀렉터가 너무 범용적으로 작성되었다면 어떤 일이 발생할까?
그래서 한 컨트롤러가 관리하고 있는 파드들에 다른 컨트롤러가 개입되는 상황이 생긴다면..?
가령 이미 존재하고 있는 셀렉터와 같은 셀렉터를 사용했거나 하는 상황 말이다.

설정

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: default
  name: default
spec:
  replicas: 3
  selector:
     matchLabels:
       app: default
  template:
    metadata:
      labels:
        app: default
    spec:
      containers:
      - image: nginx:latest
        name: nginx

이 상태에서 같은 라벨에 대해 셀렉터를 부여할 것이다.

같은 라벨을 가진 파드가 이미 존재할 때

apiVersion: v1
kind: Pod
metadata:
  name: "orphan"
  namespace: default
  labels:
    app: default
spec:
  containers:
  - name: myapp
    image: "nginx:latest"
    ports:
    - containerPort: 80
      name: http

라벨에 app:default가 있는 일반 파드를 만든다.
Pasted image 20240922000914.png
디플은 정상적으로 파드들을 만들어냈다.
Pasted image 20240922000722.png
edit으로 하나를 줄이는 식으로 수정해도 잘 작동한다.
이건 rollout에 추적이 되지 않으니 다른 방법을 사용해보자.
Pasted image 20240922001431.png
이번에는 이미지를 변경했다. 잘만 추적한다.
음.. 뒤돌려도 잘만 된다.
버전 추적도 잘 되는데..?
아무런 영향도 없이..

단순 파드로는 그다지 영향이 없는 것일지도 모르겠다.

다른 워크로드가 같은 라벨로 포착하고 있다면?

그럼 같은 워크로드면 어쩔래..?

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: another
  name: another
spec:
  replicas: 3
  selector:
    matchLabels:
      app: default
  template:
    metadata:
      labels:
        app: default
    spec:
      containers:
      - image: nginx:latest
        name: nginx

이름만 다르고 똑같이 생긴 디플로이먼트이다.
Pasted image 20240922002558.png
안 헷갈리게 디플 라벨도 바꿨어야 했는데, 아무튼 app:default를 셀렉터로 하는 다른 디플이 있다!
Pasted image 20240922002646.png
일단 시작은 너무 잘 돼버리고~
Pasted image 20240922002820.png
일단, 개수랑 이미지를 바꿨는데도 추적이 잘 된다.
Pasted image 20240922002955.png
undo를 해봤는데, 원래대로 돌아가지 않는다.
undo할 때 개수 조절이 잘 안 되는 건 원래 그런 거라 사실 큰 상관이 없어보인다.
실험해본 사항은 다음과 같다.

이렇게 다 문제가 없어버리면 언제 문제가 생긴다고 봐야 하는 거냐?

레플리카셋으로 테스트하기

레플리카셋 문서를 읽다가 알게 된 것이다.
디플로이먼트로 실험할 때는 분명 셀렉터 이슈가 없는 것을 포착했다.
Pasted image 20241223225645.png
그러나 레플리카셋을 만들어서 올리면 그때는 문제가 발생한다.
orphan 파드에 자동으로 ownerReference 필드가 생기면서 레플이 추적하는 파드가 되어버렸다.

원인 분석

Pasted image 20241223230243.png
새로운 사실을 알 수 있었다.
디플로이먼트로 만들어지는 레플리카셋과 파드는 라벨로 pod-template-hash라는 값까지 가지게 된다.
아무래도 디플로이먼트는 여러 개의 레플리카셋을 가질 수 있다보니, 각 레플을 관리하기 위해 자체적으로 새로운 라벨을 추가하는 모양이다.
그래서 여태 디플로이먼트를 사용할 때는 같은 라벨을 가진 파드가 있다고 해도, 셀렉터로 추적이 되지 않았던 것이다.
Pasted image 20241223230520.png
보다시피 저 라벨을 붙여버리니 바로 기존에 존재하던 레플이 관리하던 파드가 하나 사라져버렸다.

결론

디플로이먼트와 같이, 흔히 사용하는 워크로드들은 레플리카셋을 둘 때 pod-template-hash라는 추가 라벨을 붙여준다.
그래서 템플릿만 봤을 때는 같은 라벨을 가진 다른 리소스가 있더라도 실상 문제가 발생하진 않는다.
그럴 일은 거의 없겠으나, 직접 레플리카셋을 만들어 사용하는 사람이 있다면 이 문제를 매우 유념해야 할 것이다.

참고