소개
- GKE는 컨테이너화된 애플리케이션 즉 하드웨어에 독립적이고 격리된 사용자 공간 인스턴스에 패키지화된 애플리케이션에서 작동
- GKE 및 Kubernetes에서 이러한 컨테이너가 애플리케이션이든 일괄 작업이든 총체적으로 워크로드라고 부른다.
- 워크로드의 두 가지 주요 유형인 배포와 작업에 대해 다룰 것이다.
- GKE 클러스터를 확장하는 데 사용되는 메커니즘도 다룰 것이다.
- => 배포를 생성하고 사용하고 확장하는 방법과 더불어 작업 및 크론 작업을 생성 및 실행하는 방법 수동 및 자동으로 GKE 클러스터를 확장하는 방법. 어떤 노드에 포드를 실행하거나 실행하지 않을지 제어하는 방법 소프트웨어를 클러스터에 포함시키는 방법.
배포
- 원하는 pod의 상태. 배포는 pod 상태를 선언함.
- 포드 사양을 업데이트할 때마다 예를 들어 포드를 최신 컨테이너 이미지로 업데이트할 때 변경된 배포 버전과 일치하는 새 ReplicaSet이 생성됨
- 배포는 업데이트된 포드를 통제된 방식으로 출시함
- 이전 포드는 이전 ReplicaSet에서 제거되고 새 ReplicaSet의 새로운 포드로 교체
- 업데이트된 포드가 안정적이지 않은 경우 관리자는 이전 배포 버전으로 포드를 롤백할 수 있음
- 배포 구성을 수정하면 포드를 수동으로 확장할 수 있습니다 워크로드를 자동으로 관리하도록 배포를 구성할 수도 있음
- 배포는 스테이트리스(Stateless) 애플리케이션을 위해 설계되었습니다 스테이트리스(Stateless) 애플리케이션은 데이터 또는 애플리케이션 상태를 클러스터나 영구 스토리지에 저장하지 않는다
- 스테이트리스(Stateless) 애플리케이션의 대표적인 예는 웹 프런트엔드
- 일부 백엔드에는 데이터를 영구적으로 저장해야 하는 경우가 있어 이러한 백엔드를 관리하려면 배포 이외의 Kubernetes 객체를 사용
- 원하는 상태는 배포 YAML 파일에 기술합니다 여기에는 포드의 특성 포드를 운영 방식으로 실행하는 법, 수명 주기 이벤트를 포함
- 이 파일을 Kubernetes 제어 영역에 제출하면 배포 컨트롤러가 생성되는데 원하는 상태를 실현하고 시간이 지나도 이 상태를 유지
- 컨트롤러는 Kubernetes가 생성한 루프 프로세스로 클러스터에서 실행 중인 객체 또는 객체 집합의 원하는 상태가 관찰된 상태와 일치하도록 일상 작업을 처리. 이 과정에서 ReplicaSet이 생성.
- ReplicaSet은 어느 시점에서든 특정 수의 포드 복제본이 실행되도록 하는 컨트롤러
- Deployment has three different lifecycle states
- Progressing State
- 작업이 수행되었음
- 새 ReplicaSet을 생성하거나 ReplicaSet을 확장 또는 축소하는 작업
- Complete State
- 모든 새 복제본이 최신 버전으로 업데이트되어 사용 가능하고 실행 중인 기존 복제본이 없다
- Failed State
- 새로운 ReplicaSet 생성을 완료할 수 없을 떄 발생
- Kubernetes에서 새 포드의 이미지를 가져오지 못했거나 작업을 완료하는 데 일부 리소스 할당량이 충분하지 않았을 수 있다
- 작업을 시작한 사용자에게 권한이 없을 수 있다
- Progressing State
- 버전이 많아지고 관리가 복잡해진다.
- YAML 파일과 소스 코드 저장소를 유지하는 것이 필요하다.
배포 생성 방법
- There are three ways to create a Deployment
- 1. YAML 파일과 같은 manifest 파일과 kubectl apply 명령어를 사용하여 선언적으로 배포를 생성
- 2. 명령줄에서 매개변수를 지정하는 kubectl run 명령어를 사용하여 배포를 명령적으로 생성
- 태그의 이미지는 컨테이너에서 실행할 이미지와 이미지 버전을 지정
- 이 배포는 3개의 복제본을 시작하고 포트 8080을 노출
- 라벨은 키와 값을 사용하여 정의되며 --generator는 사용할 API 버전을 지정하고 --save-config는 나중에 사용할 구성을 저장
- 3. GCP Console에서 GKE 워크로드 메뉴를 사용
- 컨테이너 이미지와 버전을 지정하거나 Container Registry에서 바로 선택할 수도 있다
- 환경 변수 및 초기화 명령어를 지정할 수 있고 라벨과 함께 애플리케이션 이름과 네임스페이스를 추가할 수도 있습니다
- Use kubectl to inspect your Deployment
- 배포를 통해 생성된 ReplicaSet는 원하는 수의 포드가 실행되고 항상 사용 가능한 상태로 유지되도록 한다.
- 포드에 오류가 발생하거나 제거되면 ReplicaSet는 자동으로 새 포드를 실행한다.
- 사용자는 kubectl get 및 describe 명령어를 사용하여 배포의 상태와 세부정보를 검사할 수 있다.
- 사용자는 kubectl get deployment 명령어를 사용하여 배포 내 모든 복제본의 원하는 상태 현재 상태, 최신 상태 사용 가능한 상태를 복제본이 실행된 시간과 함께 가져올 수 있다.
- DESIRED는 배포 사양에 지정된 원하는 복제본 수를 나타냄
- CURRENT는 현재 실행 중인 복제본의 수
- UP-TO-DATE는 현재 배포 사양에 따라 완전히 최신 상태인 복제본의 수
- AVAILABLE에는 사용자가 사용할 수 있는 복제본의 수
- Use the 'describe' command to detailed info
Scaling a Deployment manually
- kubectl 명령어를 사용하거나 GCP Console에서 총 복제본 수를 정의하여 배포를 수동으로 확장할 수 있음
- 또한 manifest를 수동으로 변경하여 확장할 수도 있음
- CPU 사용률 기준점과 함께 원하는 포드의 최소 및 최대 개수를 지정하여 배포를 자동 확장할 수 있음
- 자동 확장 역시 kubectl autoscale 명령어를 사용하거나 GCP Console에서 직접 수행할 수 있음
- 이렇게 하면 수평형 포드 자동 확장 처리라는 Kubernetes 객체가 만들어진다
- 이 객체는 대상 CPU 사용률에 맞게 실제 확장을 수행한다
- 기억해야 할 점은 클러스터를 전체적으로 확장하는 것이 아니라 해당 클러스터 내의 특정 배포만 확장한다는 것
- 스래싱은 확장을 제어하는 데 사용한 측정항목이 자주 변동되면서 배포된 복제본의 수에도 자주 변동이 생기는 현상
- 수평형 포드 자동 확장 처리는 휴지 또는 지연 기능을 지원한다
- 이를 통해 다른 축소 작업을 수행하기 전에 대기 기간을 지정할 수 있다. (기본값은 5분)
Q. 배포
1. 배포와 ReplicaSet는 서로 어떤 관계인가요?
=> 배포는 배포가 지정하는 특정 버전의 포드를 생성하고 유지하도록 ReplicaSet 컨트롤러를 구성합니다.
2. 배포와 함께 사용하기에 적합한 애플리케이션 유형은 무엇인가요?
=> 스테이트리스(Stateless)
배포 업데이트
- 이미지 버전의 변경과 같이 배포의 포드 사양을 변경하는 경우 자동 업데이트 롤아웃이 발생
- 이러한 자동 업데이트는 포드 사양의 변경사항에만 적용할 수 있다
- 방법
- 1. 배포 사양 YAML 파일과 함께 kubectl apply 명령어를 사용
- 포드 템플릿 외부에 있는 복제본의 수와 같은 배포의 다른 사양을 업데이트할 수 있다.
- 2. kubectl set 명령어를 사용
- 이 방법을 사용하면 이미지, 리소스, 선택기 값 등 배포에 대한 포드 템플릿 사양을 변경할 수 있다.
- 3. kubectl edit 명령어를 사용
- 이 명령어를 사용하면 직접 내용을 변경할 수 있는 vim 편집기를 통해 사양 파일이 열리죠 파일을 저장하고 편집기를 종료하면 kubectl이 업데이트된 파일을 자동으로 적용
- 4. Cloud 콘솔 사용
- GCP 콘솔에서 배포 매니페스트를 수정할 수 있으며 추가 옵션을 통해 순차적 업데이트를 수행할 수 있습니다.
- 1. 배포 사양 YAML 파일과 함께 kubectl apply 명령어를 사용
- 배포가 업데이트될 때 배포는 새 ReplicaSet를 실행하고 통제된 방식으로 새로운 포드 세트를 만든다.
- 먼저 새 ReplicaSet에서 새 포드가 실행된다. 그런 다음 이전 포드가 이전 ReplicaSet에서 삭제된다.
- 이것은 순차적 업데이트 전략의 예시로 램프 전략이라고도 한다.
- 업데이트가 천천히 출시되므로 애플리케이션의 가용성을 보장한다는 것이다.
- 그러나 이 프로세스에는 시간이 걸릴 수 있으며 트래픽이 이전 포드 및 새 포드로 전달되는 방식을 제어할 수가 없다.
'⛅ Cloud Study > ☁️ Public Cloud' 카테고리의 다른 글
[AWS VPC] 12장 연결 서비스2: 공간과 공간 연결(단방향) (0) | 2023.08.17 |
---|---|
[AWS VPC] 11장 연결 서비스1: 공간과 공간 연결(양방향) (0) | 2023.08.10 |
[GCP GKA 스터디] Workloads - Kubernetes 작업 (0) | 2023.08.06 |
[GCP] Foundations - Kubernetes 아키텍처 (0) | 2023.08.06 |
[GCP] Foundations - 컨테이너 및 Kubernetes 소개 (0) | 2023.08.06 |