목차
- 레플리케이션 컨트롤러 대신 레플리카셋
- 레플리카셋과 레플리케이션 컨트롤러 비교
- 레플리카셋 정의하기
- 더욱 섬세하게 레플리카셋 사용하기
레플리케이션 컨트롤러 대신 레플리카셋
초기에는 레플리케이션 컨트롤러가 파드를 복제하고 노드 장애가 발생했을 때 재스케줄링하는 유일한 쿠버네티스 구성 요소 였습니다. 후에 레플리카셋 이라는 유사한 리소스가 도입됐습니다. 이는 비교적 차세대 레플리케이션 컨트롤러이며, 레플리케이션 컨트롤러를 완전히 대체할 수 있게 되었습니다.
이전에 다루었던 레플리케이션 컨트롤러 대신 레플리카셋을 다루는 것으로 진행해도 좋았겠지만, 발전한 순서를 알면 더 좋지 않을까 했습니다. 또한 현장에서는 여전히 레플리케이션 컨트롤러가 계속 사용되기도 함으로 이를 잘 이해하는 것이 좋습니다.
레플리케이션 컨트롤러와 레플리카셋은 거의 동일하기 때문에 대신해서 사용하는 데 아무 문제가 없을 것입니다. 일반적으로 레플리카셋을 직접 생성하지 않고, 다음에 배울 상위 수준의 디플로이먼트 리소스를 생성할 때 자동으로 생성되게 합니다. 어쨌든 레플리카셋을 이해해야 하므로 레플리케이션 컨트롤러와 어떻게 다른지 확인해봅시다.
레플리카셋과 레플리케이션 컨트롤러 비교
레플리카셋은 레플리케이션 컨트롤러와 똑같이 동작하지만 좀 더 풍부한 표현식을 사용하는 파드 셀렉터를 갖고 있습니다. 레플리케이션 컨트롤러의 레이블 셀렉터는 특정 레이블이 있는 파드만을 매칭시킬 수 있는 반면, 레플리카셋의 셀렉터는 특정 레이블이 없는 파드나 레이블의 값과 상관없이 특정 레이블의 키를 갖는 파드를 매칭시킬 수 있습니다.
또한 예를 들어 하나의 레플리케이션 컨트롤러는 레이블이 env=production인 파드와 레이블이 env-deve1인 파드를 동시에 매칭시킬 수 없습니다. 레이블이 env=production인 파드 또는 레이블이 env=deve1인 파드만 매칭시킬 수 있습니다. 그러나 레플리카셋은 하나의 레플리카셋으로 두 파드 세트를 모두 매칭시켜 하나의 그룹으로 취급할 수 있습니다.
마찬가지로 레플리케이션 컨트롤러는 값에 상관없이 레이블 키의 존재만으로 파드를 매칭ㅎ시킬 수 없지만, 레플리카셋은 가능합니다. 예를 들어 레플리카셋은 실제 값이 무엇이든 env 키가 있는 레이블을 갖는 모든 파드를 매칭시킬 수 있습니다.
레플리카셋 정의하기
이제 레플리카셋을 생성해 이전에 레플리케이션컨트롤러에서 생성했다가 버려져서 혼자 남겨진 파드를 레플리카셋이 어떻게 취하는지 살펴보겠습니다. 먼저 다음 예제처럼 새로운 YAML 파일을 만들어 레플리케이션컨트롤러를 레플리카셋으로 다시 작성합니다.
apiVersion: apps/v1beta2 > 레플리카셋은 레플리케이션 컨트롤러와 다르게 이 버전 그룹에 속합니다.
kind: ReplicaSet
metadata:
name: kubia
spec:
relicas: 3
selector:
matchLabels: > 레플리케이션컨트롤러와 유사하지만 matchLabels가 추가됩니다.
app: kubia
template:
metadata:
labels:
apps: kubia
spec:
container:
- name: kubia
image: luksa/kubia
가장 먼저 주목할 점은 레플리카셋이 v1 API의 일부가 아니기 떄문에 리소스를 생성할 때 적절한 apiVersion을 지정해야 한다는 것입니다. 앞에서 만든 레플리케이션 컨트롤러와 내용이 동일한 레플리카셋 유형의 리소스를 생성합니다.
유일한 차이점은 셀렉터에 있습니다. 파드가 가져야 하는 레이블은 selector 속성 바로 아래 나열하는 대신 selector.matchLables 아래에 저장합니다. 이는 레플리카셋에서 레이블 셀렉터를 정의하는 가장 단순한 방법입니다.
app=kubia 셀렉터와 매칭되는 이전에 실해 세 개의 파드가 여전히 실행 중이기 때문에 이 레플리카셋을 생성해도 새 파드가 생성되지는 않습니다. 레플리카셋은 기존 세 개의 파드를 자신의 관리하에 둡니다.
더욱 섬세하게 레플리카셋 사용하기
레플리케이션 컨트롤러에 비해 레플리카셋의 주요 개선 사항은 좀 더 섬세한 레이블 셀렉터입니다. 첫 번째 레플리카셋 예제에서는 의도적으로 단순한 matchLabels 셀렉터를 사용해 레플리카셋이 레플리카컨트롤러와 다르지 않다는 것을 확인했습니다. 이제 더 강력한 matchExpressions를 사용해 셀렉터를 작성합니다.
selector:
matchExpressions:
- key: app > 라벨 키
operator: IN > 비교 연산자
values:
- kubia > 비교할 값
셀렉터에 표현식을 추가할 수 있습니다. 예제와 같이 각 표현식은 키, 연산자, 가능한 값이 포함돼야 합니다. 이 중 유효한 연산자의 예시를 가져왔습니다.
- In: 라벨 값이 values 목록에 있는 경우 일치합니다.
- NotIn: 라벨 값이 values 목록에 없는 경우 일치합니다.
- Exists: 라벨 값이 존재하는 경우 일치합니다.
- DoesNotExist: 라벨 값이 존재하지 않는 경우 일치합니다.
- Gt: 라벨 값이 주어진 값보다 큰 경우 일치합니다. (문자열은 ASCII 값으로 비교됩니다.)
- Lt: 라벨 값이 주어진 값보다 작은 경우 일치합니다. (문자열은 ASCII 값으로 비교됩니다.)
- Gte: 라벨 값이 주어진 값보다 크거나 같은 경우 일치합니다. (문자열은 ASCII 값으로 비교됩니다.)
- Lte: 라벨 값이 주어진 값보다 작거나 같은 경우 일치합니다. (문자열은 ASCII 값으로 비교됩니다.)
여러 표현식을 지정한 경우 셀렉터가 파드와 매칭되기 위해서는, 모든 표현식이 true여야 합니다. matchLabels와 matchExpressions를 모두 지정하면, 셀렉터가 파드를 매칭하기 위해서는, 모든 레이블이 일치하고, 모든 표현식이 true로 평가 돼야합니다.
'Container > Kubernetes' 카테고리의 다른 글
[Kubernetes] 일회성 작업 효율적으로 관리하기 (1) Job 리소스 (0) | 2023.04.09 |
---|---|
[Kubernetes] 파드 효율적으로 관리하기 (3) 데몬셋이란? (0) | 2023.04.09 |
[Kubernetes] 파드 효율적으로 관리하기 (1) 레플리케이션 컨트롤러란? (0) | 2023.04.08 |
[Kubernetes] 파드를 안정적으로 유지하기 (0) | 2023.04.07 |
[Kubernetes] 쿠버네티스 레이블(Label)과 유사한 정보 분리 방법(Annotation, Namespace) (0) | 2023.04.05 |