고민의 흔적

Kubernetes의 작동 방식을 파악하기 위한 선행 개념

1. Kubernetes 객체 모델
   1. Kubernetes가 관리하는 각 항목은 객체로 표시되며 이러한 객체의 속성과 상태를 확인하고 변경할 수 있습니다.
   2. Kubernetes 객체는 클러스터에서 실행 중인 항목의 상태 (원하는 상태 및 현재 상태)를 나타내는 영구 항목으로 정의됩니다.
   3. 다양한 종류의 객체는 컨테이너화 된 애플리케이션 사용 가능한 리소스, 해당 동작에 영향을 미치는 정책을 나타냅니다.
2. 선언적 관리 원칙
   1. Kubernetes를 사용한다면 관리되고 있는 객체에 대해 원하는 상태를 지정해야 합니다.
   2. Kubernetes가 객체를 해당 상태로 전환하여 유지하게 됩니다.(감시 루프 사용)

Kubernetes 객체의 두 가지 중요한 요소

1. 만들려는 각 객체에 대해 '객체 사양'을 Kubernetes에 제공합니다 이 사양에 원하는 특성을 제공하여 객체의 원하는 상태를 정의합니다.
   1. '객체 상태'는 Kubernetes 제어 영역에서 제공하는 객체의 현재 상태입니다.
   2. 각 객체는 Kubernetes가 호출하는 특정 유형 또는 종류입니다.
2. 'Kubernetes 제어 영역'이란 여러 시스템 프로세스를 가리키며 이 프로세스들의 상호작용을 통해 Kubernetes 클러스터가 작동합니다.

포드란?

1. 포드는 표준 Kubernetes 모듈의 기본 구성 요소이며 배포 가능한 가장 작은 Kubernetes 객체입니다. Kubernetes 시스템에서 실행 중인 모든 컨테이너가 포드입니다.
2. 포드는 컨테이너가 위치한 환경을 구현하며 해당 환경은 하나 이상의 컨테이너를 수용할 수 있습니다.
3. 포드에 컨테이너가 두 개 이상 있는 경우 긴밀하게 결합되어 네트워킹 및 스토리지를 포함한 리소스를 공유합니다.
4. Kubernetes는 각 포드에 고유한 IP 주소를 할당합니다. 포드 내의 모든 컨테이너는 네트워크 네임스페이스를 공유하며 여기에는 IP 주소 및 네트워크 포트가 포함됩니다.
5. 동일한 포드 내의 컨테이너는 로컬 호스트 127.0.0.1을 통해 통신할 수 있습니다.
6. 포드는 컨테이너 간에 공유할 스토리지 볼륨 모음을 지정할 수 있습니다.

https://kubernetes.io/ko/docs/concepts/workloads/pods/

포드의 간단한 예

1. nginx 웹 서버 인스턴스 3개가 각각 컨테이너에서 항상 실행 중인 상태로 필요하다고 가정한다.
2. Kubernetes는 선언적 관리 원칙을 구현합니다. 객체를 선언하여 nginx 컨테이너에 이러한 객체를 나타냅니다. 어떤 종류의 객체일까요? 바로 포드입니다. 이제 Kubernetes가 이러한 포드를 실행하고 유지하는 작업을 맡습니다. 하지만 포드는 자가 복구되지 않는다는 점에 주의하세요 모든 nginx 웹 서버를 유지하는 동시에 하나의 팀으로 함께 작동하기를 원한다면 더 정교한 종류의 객체를 사용하도록 요청할 수 있습니다.
3. Kubernetes에 원하는 상태, 즉 항상 실행 중인 3개의 nginx로 구성된 상태를 지정했다고 가정합시다.
4. 해당 상태를 나타내는 하나 이상의 객체를 만들고 유지하도록 Kubernetes에 지시하여 이 작업을 실행했습니다 그러면 Kubernetes는 원하는 상태를 현재 상태와 비교합니다 3개의 nginx 컨테이너에 대한 선언이 완전히 새로운 선언이라고 가정하면 현재 상태가 원하는 상태와 일치하지 않으므로 Kubernetes, 정확히 말하면 Kubernetes의 제어 영역이 상황을 해결할 것입니다 선언한 객체에서는 실행 중이어야 하는 포드의 수가 3개인데 현재 0개가 실행 중이므로 3개가 되도록 시작합니다 또한 Kubernetes 제어 영역은 클러스터의 상태를 지속적으로 모니터링하여 선언된 상태와 현재를 끊임없이 비교하고 필요에 따라 상태를 수정합니다.

Kubernetes 클러스터

• 클러스터에는 컴퓨터가 필요합니다. 요즘 클러스터를 구성하는 컴퓨터는 일반적으로 가상 머신입니다.
• 한 컴퓨터를 '제어 영역'이라고 하고 다른 컴퓨터를 간단히 '노드'라고 합니다. 노드의 역할은 포드를 실행하는 것이며 제어 영역의 역할은 전체 클러스터를 조정하는 것입니다.
• 몇 가지 중요한 Kubernetes 구성요소가 제어 영역에서 실행됩니다.
• 사용자가 직접 상호작용하는 단일 구성요소는 kube-APIserver이며 이 구성요소의 역할은 클러스터의 상태를 보거나 변경하는 명령어를 수락하는 것으로 여기에는 포드 실행이 포함됩니다.

kube-APIserver

kubectl 명령어

이 명령어의 역할은 kube-APIserver에 연결하고 Kubernetes API를 사용하여 통신하는 것입니다 kube-APIserver는 또한 수신된 요청을 인증하고 요청의 승인 여부와 유효성을 확인하며 허용 제어를 관리합니다.

etcd

실제로 클러스터 상태에 대한 모든 쿼리 또는 변경은 kube-APIserver로 보내져야 합니다.

etcd는 클러스터의 데이터베이스입니다 이는 클러스터의 상태를 안정적으로 저장하는 역할을 합니다 여기에는 모든 클러스터 구성 데이터와 많은 동적 정보(클러스터의 일부인 노드, 실행해야 하는 포드, 실행 위치)가 포함됩니다 사용자는 etcd와 직접 상호작용하지 않습니다. kube-APIserver가 시스템의 나머지 부분을 대신하여 데이터베이스와 상호작용합니다.

kube-scheduler

포드를 노드에 예약하는 역할을 합니다 이를 위해 각 개별 포드의 요구사항을 평가하고 가장 적합한 노드를 선택합니다.

노드에서 포드를 시작하는 작업

하지만 실제로 노드에서 포드를 시작하는 작업은 수행하지 않습니다. 대신 노드에 아직 할당되지 않은 포드 객체를 발견할 때마다 노드를 선택하고 해당 노드의 이름을 포드 객체에 작성합니다. 그러면 시스템의 또 다른 구성요소가 포드를 시작하는 역할을 합니다.

kube-scheduler는 포드 실행 위치를 어떻게 결정할까요?

• kube-scheduler는 모든 노드의 상태를 파악하고 하드웨어, 소프트웨어, 정책을 기반으로 포드가 실행될 수 있는 위치에 대해 여러분이 정의한 제약조건도 준수합니다.
• 예를 들어 특정 포드에 대해 메모리 용량이 일정 수준인 노드에서만 실행되도록 지정할 수 있습니다 또한 어피니티 사양을 정의하여 포드 그룹이 동일한 노드에서 실행되도록 할 수도 있고 안티 어피니티 사양으로 포드가 동일한 노드에서 실행되지 않게 할 수도 있습니다.

kube-controller-manager

• kube-APIserver를 통해 클러스터 상태를 지속적으로 모니터링합니다 클러스터의 현재 상태가 원하는 상태와 일치하지 않을 때마다 kube-controller-manager는 원하는 상태를 달성하기 위해 변경을 시도합니다 이를 '컨트롤러 관리자'라고도 하는데 많은 Kubernetes 객체가 컨트롤러라는 코드 루프에 의해 관리되기 때문입니다 이러한 코드 루프는 해결 프로세스를 처리합니다.
• 다른 종류의 컨트롤러에는 시스템 수준의 책임이 있습니다 예를 들어 노드 컨트롤러의 역할은 노드가 오프라인 상태일 때 모니터링하고 응답하는 것입니다.

kube-cloud-manager

• 기본 클라우드 제공업체와 상호작용하는 컨트롤러를 관리합니다.
• 예를 들어 Kubernetes 클러스터를 Google Compute Engine에서 수동으로 시작하면 kube-cloud-manager는 필요할 때 부하 분산기 및 스토리지 볼륨과 같은 Google Cloud 기능을 가져오는 역할을 합니다.
• 각 노드는 제어 영역 구성요소의 작은 그룹도 실행합니다.
• 예를 들어 각 노드는 Kubelet을 실행합니다. Kubelet은 각 노드에 있는 Kubernetes의 에이전트와 같습니다. kube-APIserver가 노드에서 포드를 시작하려고 하면 해당 노드의 Kubelet에 연결됩니다. Kubelet은 컨테이너 런타임을 사용하여 포드를 시작하고 준비 프로브 및 활성 프로브를 포함한 수명 주기를 모니터링하고 Kube-APIserver에 다시 보고합니다.
• 컨테이너 런타임은 컨테이너 이미지에서 컨테이너를 시작하는 방법을 아는 소프트웨어입니다.

Google Kubernetes Engine 관련 개념

• Kubernetes 클러스터를 직접 설정하는 작업은 아주 복잡합니다. 다행히 오픈소스 명령어 kubeadm으로 클러스터 초기 설정의 대부분을 자동화할 수 있습니다. 그러나 노드가 실패하거나 노드 유지보수가 필요한 경우 관리자가 수동으로 응답해야 합니다.
• 사용자의 관점에서 보면 훨씬 더 간단합니다. GKE는 사용자를 대신하여 모든 제어 영역 구성요소를 관리합니다. GKE는 IP 주소를 노출하고 그 주소로 모든 Kubernetes API 요청을 사용자가 보내지만 GKE가 사용자를 대신하여 모든 제어 영역 인프라를 프로비저닝하고 관리합니다. 또한 별도의 제어 영역을 추상화합니다.

노드

• 모든 Kubernetes 환경에서 노드는 Kubernetes 자체가 아닌 클러스터 관리자가 외부에서 만듭니다.
• GKE는 이 프로세스도 자동화합니다 Compute Engine 가상 머신 인스턴스를 시작하고 노드로 등록합니다. Cloud Console에서 바로 노드 설정을 관리할 수 있습니다.
• 노드에 설정된 시간당 요금이 부과됩니다.(제어 영역 제외) 노드는 Compute Engine에서 실행되므로 클러스터를 만들 때 노드 머신 유형을 선택할 수 있습니다.

https://kubernetes.io/ko/docs/concepts/architecture/nodes/

노드 머신

• 기본적으로 노드 머신 유형은 n1-standard-1이며 가상 CPU 1개와 3.75GB의 메모리를 제공합니다.
• 일반적으로 최대 96개의 가상 CPU 코어를 사용할 수 있으며 이는 가상 머신으로서는 다소 큰 편에 속합니다 노드의 코어 수와 메모리 용량은 맞춤 설정할 수 있으며 CPU 플랫폼을 선택할 수 있습니다 노드 또는 노드 풀에 대한 기본 최소 CPU 플랫폼을 선택할 수 있으므로 노드 성능을 개선할 수 있습니다 GKE는 절대로 사용자가 지정한 것보다 오래된 CPU 플랫폼을 사용하지 않고 더 최신 플랫폼을 선택하는 경우 비용은 지정된 플랫폼과 동일합니다.

노드 풀

• 여러 노드 머신 유형을 선택하려면 여러 노드 풀을 만들면 됩니다. 노드 풀은 클러스터 내 노드의 하위집합으로 메모리 용량 또는 CPU 세대와 같은 구성을 공유합니다. 또한 노드 풀을 통해 손쉽게 워크로드가 클러스터 내의 올바른 하드웨어에서 실행되도록 할 수 있습니다. 원하는 노드 풀로 워크로드의 레이블을 지정하기만 하면 됩니다. 노드 풀은 Kubernetes 기능이 아니라 GKE 기능입니다.
• 오픈소스 Kubernetes 내에서 유사한 메커니즘을 구축할 수 있지만 이 경우 직접 유지 관리해야 합니다 이 노드 풀 수준에서 자동 노드 생성, 자동 노드 복구 클러스터 자동 확장을 사용 설정할 수 있습니다.
• 여기에는 주의할 점이 있습니다 각 노드의 CPU 및 메모리 일부는 노드가 클러스터의 일부로 작동하게 하는 GKE와 Kubernetes 구성요소를 실행하는 데 필요합니다 예를 들어 15GB의 메모리가 있는 노드를 할당하면 15GB 모두를 포드에서 사용할 수는 없습니다.

클러스터

• 클러스터는 단일 Google Cloud 컴퓨팅 영역에서 시작되며 하나의 노드 풀에 3개의 동일한 노드가 있습니다 노드 수는 클러스터 생성 중 또는 생성 후에 변경할 수 있습니다.
• 더 많은 노드를 추가하고 애플리케이션의 여러 복제본을 배포하면 애플리케이션의 가용성이 일정 수준까지는 향상됩니다.

GKE 리전 클러스터

• 전체 컴퓨팅 영역이 다운됬을 때 GKE 리전 클러스터를 사용하면 이 문제를 해결할 수 있습니다.
• 리전 클러스터에는 클러스터에 대한 단일 API 엔드포인트가 있습니다. 그러나 제어 영역과 노드는 한 리전 내의 여러 Compute Engine 영역에 분산되어 있습니다. 리전 클러스터는 애플리케이션의 가용성이 단일 리전 내의 여러 영역에서 유지되도록 합니다.
• 또한 제어 영역의 가용성도 유지되므로 애플리케이션과 관리 기능 모두가 몇몇 영역이 손실되어도 유지됩니다. (전체 영역 손실 시 유지되지 않습니다)
• 기본적으로 리전 클러스터는 3개의 영역에 분산되어 있고 각 영역에는 제어 영역 1개와 노드 3개가 있습니다. 이 수는 늘리거나 줄일 수 있습니다.
• 영역 클러스터를 빌드한 후에는 리전 클러스터로 변환할 수 없으며 그 반대의 경우도 마찬가지입니다.
• 리전 별 또는 영역별 GKE 클러스터를 비공개 클러스터로도 설정할 수 있습니다. 전체 클러스터, 즉 제어 영역 및 해당 노드는 공개 인터넷에서 숨김 처리됩니다.

Kubernetes 객체 관리

• 모든 Kubernetes 객체는 고유한 이름과 고유 식별자로 구분됩니다.
• Kubernetes가 만들고 유지할 객체를 매니페스트 파일을 사용하여 정의했습니다.

매니페스트 파일

이는 일반 텍스트 파일입니다. YAML 또는 JSON 형식으로 작성할 수도 있습니다. YAML은 사람이 읽기 쉽고 수정이 덜 번거롭다. 이 YAML 파일은 포드에 대한 원하는 상태 즉 이름과 실행할 특정 컨테이너 이미지를 정의합니다.

매니페스트 파일의 특정 필수 필드

• apiVersion은 객체를 만드는 데 사용되는 Kubernetes API 버전을 나타냅니다 Kubernetes 프로토콜은 이전 버전과의 호환성을 유지할 수 있도록 버전이 지정됩니다.
• kind는 원하는 객체를 정의합니다.
• metadata는 객체를 식별할 수 있도록 이름, 고유 ID, 네임스페이스(선택사항)를 사용합니다. 동일한 YAML 파일에 여러 관련 객체를 정의할 수 있으며 권장사항이기도 합니다. 하나의 파일이 여러 파일보다 관리하기가 쉽다.
• YAML 파일은 버전 관리 저장소에 저장해야 합니다. 이 방법을 사용하면 변경사항을 쉽게 추적 및 관리하고 필요할 때 해당 변경사항을 취소할 수 있습니다. 이는 클러스터를 다시 만들거나 복원해야 하는 경우에도 큰 도움이 됩니다.
• Kubernetes 객체를 만들 때 이름을 문자열로 지정합니다. 이름은 고유해야 합니다. 특정 종류의 객체 하나만 한 Kubernetes 네임스페이스에서 특정 이름을 가질 수 있습니다. 그러나 객체가 삭제되면 이름을 다시 사용할 수 있습니다. 이름에는 영숫자 문자, 하이픈, 마침표를 사용할 수 있으며 최대 문자 길이는 253자입니다.
• 클러스터의 수명 주기 중에 만든 모든 객체에는 Kubernetes에서 생성된 고유 ID(UID)가 할당됩니다 즉, 클러스터의 수명 주기 중에는 두 객체에 한 UID가 할당되지 않습니다.
• 라벨은 키-값 쌍이며, 이를 사용하여 생성 중이나 생성 후에 객체를 태그 합니다 라벨은 객체와 객체의 하위 집합을 식별하고 구성하는 데 도움이 됩니다. 예를 들어 'app'이라는 라벨을 만들고 이 객체가 속한 애플리케이션을 값으로 지정할 수 있습니다.
• 라벨에 특정 값이 있는 모든 리소스 또는 특정 값이 없는 모든 리소스 또는 사용자가 제공하는 집합에 값이 있는 모든 리소스를 요청할 수 있습니다.
• 200개 이상의 YAML 섹션을 관리하는 것은 매우 어렵겠죠 또 다른 문제가 있습니다. 포드는 스스로 복구되지 않고 영원히 실행되도록 설계된 것도 아닙니다. 포드는 일회성, 임시적 용도로 설계되었습니다. 이러한 이유로 Kubernetes에서 실행하는 항목을 관리하는 데에는 개별 포드를 지정하는 것보다 더 효과적인 방법이 있습니다. 이와 같은 설정을 통해 애플리케이션의 고가용성을 수평적 확장과 함께 유지할 수 있습니다. 그보다는 컨트롤러 객체를 선언하여 포드의 상태를 관리하게 할 수 있습니다.

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/

배포

• 배포는 웹 서버와 같이 수명이 긴 소프트웨어 구성요소에 적합하며 특히 구성요소를 그룹으로 관리하려는 경우에 더욱 적합합니다.
• 이 예시에서 kube-scheduler가 배포용 포드를 예약할 때 kube-APIserver에 알립니다.
• 이러한 변경사항은 컨트롤러 특히 배포 컨트롤러가 지속적으로 모니터링합니다. 배포 컨트롤러가 nginx 포드 3개를 모니터링하고 유지합니다. 이 포드 중 하나가 실패하면 배포 컨트롤러는 현재 상태와 원하는 상태의 차이를 인식하고 새 포드를 시작하여 문제를 해결하려고 합니다. 각 포드에 여러 YAML 매니페스트 또는 파일을 사용하는 대신 단일 배포 YAML을 사용하여 동일한 컨테이너의 복제본 3개를 시작했습니다. 배포는 정의된 포드 집합이 지정된 시간에 실행되도록 합니다. 객체 사양 내에서 원하는 복제본 포드의 개수 포드 실행 방법 이러한 포드 내에서 실행할 컨테이너, 마운트 할 볼륨을 지정하게 됩니다. 이러한 템플릿을 기반으로 컨트롤러는 클러스터 내에서 원하는 포드 상태를 유지합니다.

프로젝트

• 작업을 하다 보면 아마 여러 프로젝트에 단일 클러스터를 사용하게 될 것입니다 동시에 프로젝트 또는 팀을 기반으로 리소스 할당량을 유지하는 것이 중요합니다.
• 각 Kubernetes 클러스터는 하나의 GCP 프로젝트에 연결되어 있는데 이 프로젝트는 공식적 의미의 프로젝트입니다 이를 통해 IAM 정책이 적용되고 비용이 청구되는 것입니다.

네임스페이스

• 어떻게 클러스터의 모든 작업을 체계적으로 정리할 수 있을까요? Kubernetes를 사용하면 단일 물리적 클러스터를 '네임스페이스'라고 하는 여러 가상 클러스터로 추상화할 수 있습니다.
• 네임스페이스는 포드, 배포, 컨트롤러 등 리소스 이름 지정 범위를 제공합니다.
• 동일한 네임스페이스에는 중복된 객체 이름을 사용할 수 없습니다 동일한 이름(nginx)으로 포드 3개를 만들 수 있지만 동일한 네임스페이스를 공유하지 않는 경우에만 가능합니다.
• 네임스페이스 'Test'에서 동일한 이름('nginx Pod')으로 포드를 하나 더 만드는 것은 허용되지 않습니다.
• 객체 이름은 모든 네임스페이스가 아닌 한 네임스페이스 내에서만 고유하면 됩니다. 네임스페이스를 사용하면 클러스터 전체에 리소스 할당량을 적용할 수도 있습니다. 이러한 할당량은 네임스페이스 내의 리소스 사용량 한도를 정의합니다.
• 배포 사본을 빠르게 테스트해 보기 위해 사용한다고 가정해 봅시다 새 네임스페이스에서 이름 충돌 없이 테스트를 간단하게 수행할 수 있습니다 .
• 워크로드 리소스는 기본적으로 이 네임스페이스를 사용합니다.
• 네임스페이스를 만들 때 네임스페이스에 리소스를 적용하려면 명령줄 네임스페이스 플래그를 사용하거나 리소스에 대한 YAML 파일에 네임스페이스를 지정할 수 있습니다.

Kube-system 네임스페이스

• Kubernetes 시스템 자체에서 만든 객체를 포함합니다.
• kubectl 명령어를 사용하면 기본적으로 Kube-system 네임스페이스의 항목이 제외되지만 콘텐츠를 확인하도록 명시적으로 선택할 수 있습니다.
• Kube-public 네임스페이스는 모든 사용자가 읽을 수 있도록 공개된 객체를 포함합니다. Kube-public은 클러스터에서 실행되는 모든 객체에 정보를 배포하기 위한 도구입니다. 반드시 사용할 필요는 없지만 클러스터에서 실행되는 모든 객체가 동일한 목표와 관련이 있고 공통 정보가 필요한 경우 특히 유용할 수 있습니다.

서비스

서비스는 지정된 포드에 대한 로드 밸런싱 액세스를 제공합니다. 다음의 세 가지 주요 유형이 있다.

1. 클러스터IP: 이 내에서만 액세스 할 수 있는 IP 주소에 서비스를 노출합니다.
2. NodePort: 클러스터에 있는 각 노드의 IP 주소에 서비스를 표시합니다.
3. 로드 밸런서: 다음에서 제공하는 로드 밸런싱 서비스를 사용하여 서비스를 외부에 노출합니다.

Google Kubernetes Engine에서 로드 밸런서는 지역 네트워크 로드에 대한 액세스를 제공합니다.

기본적으로 구성 균형을 조정합니다. 전역 HTTP(S) 부하 분산에 접근하려면 구성, 수신 개체를 사용할 수 있습니다.

컨트롤러 개체 간의 관계

1. ReplicaSets
2. Deployments
3. Replication Controllers
4. StatefulSets
5. DaemonSets
6. Jobs

ReplicaSet 컨트롤러는 모든 Pods의 모집단이 서로 동일하도록 보장한다. 배포를 통해 ReplicaSet 및 Pods에 대한 선언적 업데이트를 수행할 수 있습니다. 실제로 Deployments는 선언적 목표를 달성하기 위해 자체 ReplicaSet을 관리합니다. 가장 일반적으로 Deployments 개체로 작업할 수 있도록 을 지정합니다. Deployments 기능을 사용하면 필요에 따라 ReplicaSet을 사용하여 Pod를 생성, 업데이트, 롤백 및 확장할 수 있습니다. 예를 들어 Deployments의 롤링 업그레이드를 수행할 때 두 번째 ReplicaSet을 만든 다음 새 ReplicaSet의 포드 수를 늘립니다. 원본 ReplicaSet의 포드 수를 줄입니다. 복제 컨트롤러는 ReplicaSets 및 Deployments는 하지만 더 이상 사용하지 않는 것이 좋습니다. Deployments는 유용한 기능을 제공하기 때문입니다. 로컬 상태를 유지하는 애플리케이션을 배포해야 하는 경우 StatefulSet이 더 나은 옵션입니다. StatefulSet은 포드가 동일한 컨테이너 사양을 사용한다는 점에서 배포와 유사합니다. 배포를 통해 생성된 ID에는 영구 ID가 부여되지 않습니다. 대조적으로 Pods는 StatefulSet을 사용하여 생성된 것은 안정적인 네트워크 ID와 함께 고유한 영구 ID를 가지고 있다. 클러스터 내의 모든 노드 또는 선택한 노드에서 특정 팟을 실행해야 하는 경우는 DaemonSets. DaemonSet은 특정 Pod가 항상 모든 부분 집합 또는 일부 부분 집합에서 실행되도록 보장합니다. 새 노드가 추가되면 DaemonSet이 자동으로 해당 노드에 Pods를 설정합니다. 다른 프로세스에 유용한 서비스를 제공하는 무중단 프로세스입니다. Kubernetes cluster는 DaemonSet을 사용하여 fluentd와 같은 로깅 에이전트가 의 모든 노드에서 실행되도록 할 수 있습니다. 작업 컨트롤러는 태스크를 실행하는 데 필요한 하나 이상의 포드를 생성합니다. 작업이 완료되면, 그러면 Job이 모든 팟을 종료합니다. 관련 컨트롤러는 CronJob으로, 팟을 실행한다.

Migrate for Anthos

• Google Cloud의 컨테이너화 된 배포로 가져오기 위한 도구입니다.
• 프로세스가 자동화되어 있다 워크로드는 온프레미스이거나 다른 클라우드 제공업체에 있을 수 있습니다. 앞서 말씀드렸듯이 Migrate for Anthos는 자동화되어 있으며 속도도 매우 빠릅니다. 대부분의 마이그레이션은 10분 이내에 완료되며 한 번에 애플리케이션 데이터를 마이그레이션 하거나 또는 애플리케이션이 활성화될 때까지 클라우드로 스트리밍 하는 방식 중에서 선택할 수 있습니다.