목차
- 레플리케이션 컨트롤러의 특징
- 레플리케이션 작동 방식
- 레이플리케이션 컨트롤러의 파드 생성 방식
- 컨트롤러 조정 루프
- 레플리케이션 컨트롤러의 세가지 요소
- 레플리케이션 컨트롤러가 레이블 셀렉터 혹은 파드 템플릿에 미치는 영향
- 레플리케이션 컨트롤러 생성 및 관리
- 레플리케이션컨트롤러 생성
- 레플리케이션컨트롤러 작동 확인
- 노드 장애 대응
- 레이블 혹은 레이블 셀렉터를 변경된다면?
- 파드 템플릿 변경
- 파드 스케일링
- 스케일링에 대한 선언적 접근의 원리
레플리케이션 컨트롤러의 특징
레플리케이션 작동 방식
레플리케이션 컨트롤러는 쿠버네티스 리소스로서 파드가 항상 실행되도록 보장해야 합니다. 어떤 이유에서든 파드가 사라지면, 쉽게 말해 클러스터에서 노드가 사라지거나 노드에서 파드가 제거된 경우, 레플리케이션 컨트롤러는 사라진 파드를 감지해 교체 파드를 생성합니다. 다음 그림은 파드가 두 개 있는 노드가 다운될 때 어떤 일이 일어나는지 보여줍니다.
파드 A는 직접 생성해 관리되지 않는 파드인 반면, 파드 B는 레플리케이션 컨트롤러에 의해 관리됩니다. 노드에 장애가 발생한 후 레플리케이션 컨트롤러는 사라진 파드 B를 교체하기 위해 새로운 파드를 생성하지만 기존의 파드 A는 완전히 유실됩니다.
이 그림에서 레플리케이션 컨트롤러는 하나의 파드만 관리하지만 일반적으로 레플리케이션 컨트롤러는 파드의 여러 레플리카를 작성하고 관리하기 위한 것입니다. 이것이 '레플리케이션 컨트롤러'라고 불리는 이유입니다.
레이플리케이션 컨트롤러의 파드 생성 방식
레플리케이션 컨트롤러는 실행 중인 파드 목록을 지속적으로 모니터링하고, 특정 레이블 셀렉터의 실제 파드 수가 의도하는 수와 일치하는지 항상 확인합니다. 이런 파드가 너무 적게 실행 중인 경우 파드 템플릿에서 새 복제본을 만들고, 너무 많은 파드가 실행 중이면 초과 복제본이 제거됩니다.
지정한 복제본 숫자보다 적거나 많을 수 있는지 궁금할 수 있을 것 같아 몇 가지 내용을 정리해 보았습니다.
- 누군가 같은 유형의 파드를 수동으로 만든다.
- 누군가 기존 파드의 유형을 변경한다.
- 누군가 의도하는 파드 수를 줄인다.
컨트롤러 조정 루프
레플리케이션 컨트롤러의 역할은 정확한 수의 파드가 항상 레이블 셀렉터와 일치하는지 확인하는 것입니다. 그렇지 않은 경우 레플리케이션 컨트롤러는 의도하는 파드 수와 실제 파드 수를 일치시키기 위한 적절한 조취를 취합니다. 레플리케이션 컨트롤러의 작동 방식은 바로 위에서 설명한 바 있습니다.
레플리케이션 컨트롤러의 세가지 요소
- 레이블 셀렉터: 레플리케이션 컨트롤러의 범위에 있는 파드를 결정합니다.
- 레플리카 수: 실행할 파드의 의도하는 수를 지정합니다.
- 파드 템플릿: 새로운 레플리카를 만들 때 사용합니다.
레플리케이션 컨트롤러의 레플리카 수, 레이블 셀렉터, 심지어 파드 템플릿은 언제든지 수정할 수 있지만 레플리카 수의 변경만 기존 파드에 영향을 끼칩니다.
레플리케이션 컨트롤러가 레이블 셀렉터 혹은 파드 템플릿에 미치는 영향
레이블 셀렉터와 파드 템플릿을 변경해도 기존 파드에는 영향을 미치지 않습니다. 레이블 셀렉터를 변경하면 기존 파드가 레플리케이션 컨트롤러의 범위를 벗어나므로 컨트롤러가 해당 파드에 대한 관리를 중지합니다 . 또한 레플리케이션 컨트롤러는 파드를 생서한 후에는 파드의 실제 "콘텐츠"에 신경을 쓰지 않습니다. 따라서 템플릿은 이 레플리케이션컨트롤러로 새 파드를 생성할 때만 영향을 미칩니다. 템플릿을 새 파드를 만들기 위한 쿠키 커터라고 생각할 수 있습니다.
레플리케이션 컨트롤러 사용 시 이점은 다음과 같이 정리할 수 있습니다.
- 기존 파드가 사라지면 새 파드를 시작해 파드가 항상 실행되도록 합니다.
- 클러스터 노드에 장애가 발생하면 장애가 발생한 노드에서 실행 중인 모든 파드에 관한 교체 복제본이 생성됩니다.
- 수동 또는 자동으로 파드를 쉽게 수평으로 확장할 수 있게 합니다.
레플리케이션 컨트롤러 생성 및 관리
레플리케이션 컨트롤러 생성
레플리케이션 컨트롤러를 생성하는 방법과 이 컨트롤러가 파드를 유지하는 방법을 살펴봅시다. 파드를 비롯해 기타 다른 쿠버네티스 리소스와 마찬가지로 쿠버네티스 API 서버에 JSON 또는 YAML 디스크립터를 게시해 레플리케이션 컨트롤러를 만듭니다.
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia < 레플리케이션 컨트롤러 이름
spec:
relicas: 3 < 복제 및 유지할 컨테이너 수
selector: < 파드 셀렉터로 레플리케이션 컨트롤러가 관리하는 파드 선택
app: kubia
template: < 새 파드에 사용할 파드 템플릿
metadata:
labels:
app: kubia
spec:
containerL
- name: kubia
image: luksa/kubia
ports:
- containerPort: 8080
파일을 API 서버에 게시하면, 쿠버네티스는 레이블 셀렉터 app=kubia와 일치하는 파드 인스턴스가 세 개를 유지하도록 하는 kubia라는 이름의 새로운 레플리케이션 컨트롤러를 생성합니다. 파드가 충분하지 않으면 제공된 파드 템플릿에서 새 파드가 만들어질 것입니다. 템플릿의 내용은 이전에 다루었던 파드의 정의와 거의 동일합니다.
템플릿의 파드레이블은 레플리케이션컨트롤러의 레이블 셀렉터와 완전히 일치해야 합니다. 그렇지 않으면 컨트롤러에서 새 파드를 무한정 생성할 수 있습니다. 이는 새로운 파드를 가동시키더라도 실제 복제본 수가 의도하는 복제본 수와 일치하지 않기 때문입니다. 이런 경우를 방지하기 위해 API 서버는 레플리케이션 컨트롤러의 정의를 검증하고 잘못 구성된 경우 이를 받아 들이지 않습니다.
셀렉터를 지정하지 않는 것도 선택 가능한 옵션입니다. 셀렉터를 지정하지 않으면 템플릿의 레이블로 자동 설정됩니다. 레플리케이션 컨트롤러릉 정의할 때 파드 셀렉터를 지정하면 안됩니다. 쿠버네티스가 파드 템플릿에서 이를 추출하도록 하는 것이 YAML을 좀 더 간결하고 단순하게 유지할 수 있습니다.
레플리케이션컨트롤러 작동 확인
app=kubia인 레이블을 가진 파드가 없으므로 레플리케이션컨트롤러는 파드 템플릿에서 세 개의 새로운 파드를 가동 시켜야 합니다. 파드를 조회해 레플리케이션컨트롤러가 해야 할 작업을 수행했는지 확인해봅시다. kubectl get pods 명령어를 사용하면 실제로 파드가 생성된 것을 확인할 수 있을 것입니다. 여러분은 세개의 파드를 원한다고 YAML에 작성하였고, 레플리케이션 컨트롤러가 이에 따라 세 개의 파들을 생성합니다. 레플리케이션 컨트롤러는 이제 이 세개의 파드를 관리하게 됩니다. 다음은 레플리케이션 컨트롤러가 어떻게 반응하지 보기 위해 파드를 약간 망가뜨려볼 수 있습니다.
- 파드가 살제될 경우
먼저 파드 중 하나를 수동으로 삭제해서, 레플리케이션 컨트롤러가 어떻게 새로운 파드를 즉시 기동해 파드의 수를 세 개로 되돌리는지 확인합니다. 파드를 삭제하고 다시 조회하면 하나는 제거가 되고 있고, 이미 새로운 파드가 생성되어 총 4개가 가동중일 것 입니다. 이렇게 작동한다면 레플리케이션 컨트롤러가 제 역할을 잘 수행하준 것 입니다.
명령어: kubectl delete pod <pod이름> - 컨트롤러가 새로운 파드를 생성한 원리
컨트롤러가 새 교체 파드를 만들어 파드 삭제에 대응합니다. 엄밀히 말하면 그 것은 삭제 그 자체에 대한 대응이 아니라 결과적인 상태(부족한 파드 수)에 대응하는 것입니다. - 레플리케이션컨트롤러는 삭제되는 파드에 대해 즉시 통지를 받지만(API 서버는 클라이언트가 리소스 및 리소스 목록의 변경을 감지하는 것을 허용해 줍니다.), 이 통지 자체가 대체 파드를 생성하게 하는 것은 아닙니다. 이 통지는 컨트롤러가 실제 파드 수를 확인하고, 적절한 조치를 취하도록 하는 트리거 역할을 합니다.
노드 장애 대응
쿠버네티스 클러스터에 노드가 세 개가 있다고 가정해 봅시다. 노드 장애를 시뮬레이션하기 위해 노드 중 하나의 네트워크 연결을 끊는 것입니다. 해당 노드에서는 더 이상 파드가 잘동할 수 없게 됩니다.
쿠버네티스를 사용하지 않는 환경에서 노드에 장애가 발생하면 운영 팀은 해당 노드에서 실행 중인 애플리케이션을 수동으로 다른 시스템에 마이그레이션해야 할 것입니다. 반면 쿠버네티스는 이를 자동으로 수행합니다. 레플리케이션 컨트롤러는 노드의 파드가 다운됐음을 감지하자마자 파드를 대체하기 위해 새 파드를 가동합니다.
레이블 혹은 레이블 셀렉터를 변경된다면?
레플리케이션컨트롤러가 생성한 파드는 어떤 식으로든 이 레플리케이션컨트롤러와 묶이지 않습니다. 레플리케이션컨트롤러는 레이블 셀렉터와 일치하는 파드만을 관리합니다. 파드의 레이블을 변경하면 레플리케이션컨트롤러의 범위에서 제거되거나 추가될 수 있습니다. 이러한 방식으로 레플리케이션 컨트롤러에서 다른 레플리케이션 컨트롤러로 이동할 수도 있습니다.
파드의 레이블을 변경해 더 이상 레플리케이션컨트롤러의 레이블 셀렉터와 일치하지 않게 만들면 해당 파드는 수동으로 만든 다른 파드처럼 됩니다. 더 이상 아무도 이 파드를 관리하지 않습니다. 파드를 실행하는 노드에 장애가 발생하면, 파드는 당연히 다시 스케줄링되지 않습니다. 그러나 파드의 레이블을 변경하면 파드가 하나 사라진 것을 레플리케이션컨트롤러가 감지하고 사라진 파드를 대체하기 위해 새로운 파드를 기동함을 명심해야 합니다.
반대로 파드의 레이블을 변경하는 대신 레플리케이션컨트롤러의 레이블 셀렉터를 수정하면 어떻게 될까요? 모든 파드가 레플리케이션컨트롤러의 범위를 벗어나게 되기 때문에 세 개의 새로운 파드를 생성하게 될 것이 정답입니다.
쿠버네티스는 레플리케이션컨트롤러의 레이블 셀렉터를 변경하도록 허용하지만 다른 리소스들의 경우는 그렇지 않습니다. 여러분이 이런 컨트롤러의 레이블 셀렉터를 변경할 수는 없겠지만, 일반적으로 해당 파드 템플릿은 변경되게 될 것입니다.
파드 템플릿 변경
레플리케이션컨트롤러의 파드 템플릿은 언제든지 수정할 수 있습니다. 파드 템플릿을 변경하는 것은 쿠키 커터를 다른 것으로 교체하는 것과 같습니다. 나중에 잘라낼 쿠키에만 영향을 줄 뿐 이미 잘라낸 쿠키에는 아무런 영향을 미치지 않습니다. 기존 파드를 수정하려면 해당 파드를 삭제하고 레플리케이션컨트롤러가 새 템플릿을 기반으로 새 파드로 교체하도록 해야 합니다.
파드 스케일링
지금까지 레플리케이션컨트롤러가 특정 수의 파드 인스턴스를 항상 실행하도록 보장하는 방법을 살펴보았습니다. 원하는 복제본 수를 변경하는 것은 매우 간단한 일이며, 이는 파드를 수평으로 스케일링(확장)하는 것이 무척 쉬운 일임을 의미합니다.
파드 수를 늘리거나 줄이는 것은 레플리케이션 컨트롤러 리소스의 replicas 필드 값을 변경하기만 하면 됩니다. 변경하면 레플리케이션 컨트롤러가 파드가 많을 때, 일부를 삭제하거나, 너무 적으면 파드를 추가로 생성합니다.
즉, vi 등 편집기를 이용해 레플리케이션 컨트롤러 생성에서 보여주었던 예시에서 replicas 숫자를 변경해주거나 kubectl scale 명령어를 이용해 줍니다.
스케일링에 대한 선언적 접근의 원리
쿠버네티스에서 파드를 수평으로 확장한다는 것은 "x개의 인스턴스가 실행되게 하고 싶다."와 같이 의도하는 바를 언급하는 것입니다. 쿠버네티스에게 무엇을 어떻게 하라고 말하는게 아니라 의도하는 상태를 지정할 뿐입니다.
이 선언적 접근 방식을 통해 쿠버네티스 클러스터와 쉽게 상호작용할 수 있습니다. 현재 실행 중인 인스턴스 수를 수동으로 판단해서 추가로 실행해야 할 인스턴스 수를 쿠버네티스에게 명시적으로 알려줘야 한다고 상상해봅시다. 이는 더 많은 작업이 필요하며 오류 발생 가능성이 훨씬 높습니다. 간단히 숫자를 변경하는 것이 훨씬 쉽습니다. 이것을 자동으로 스케일링 해줄 수 있는 쿠버네티스 명령어가 있는데 차후 다뤄보도록 하겠습니다.
'Container > Kubernetes' 카테고리의 다른 글
| [Kubernetes] 파드 효율적으로 관리하기 (3) 데몬셋이란? (0) | 2023.04.09 |
|---|---|
| [Kubernetes] 파드 효율적으로 관리하기 (2) 레플리카셋이란? (0) | 2023.04.08 |
| [Kubernetes] 파드를 안정적으로 유지하기 (0) | 2023.04.07 |
| [Kubernetes] 쿠버네티스 레이블(Label)과 유사한 정보 분리 방법(Annotation, Namespace) (0) | 2023.04.05 |
| [Kubernetes] 쿠버네티스에서 레이블(Label)이란? (0) | 2023.04.05 |