GCP Cloud Engineer - 64

번역이 좀 이상하긴함.. 두 번 나눠서 정리함.

Google Kubernetes Engine (GKE) 개념

• 제어 플레인(Control Plane) 관리:

  • ㅁ GKE는 제어 플레인의 모든 구성 요소를 관리함.

  • ㅁ 제어 플레인은 Google Cloud가 관리하며, 사용자에게는 IP 주소만 노출.

  • ㅁ 사용자는 제어 플레인에 대해 별도로 비용을 지불하지 않음.

• 노드 관리:

  • ㅁ GKE는 Compute Engine 가상 머신 인스턴스로 노드를 생성하고 이를 클러스터에 등록함.

  • ㅁ 노드의 종류, CPU, 메모리, 플랫폼을 선택할 수 있으며, 노드 풀(Node Pool)로 여러 노드 유형을 만들 수 있음.

  • ㅁ 노드 수명에 따라 비용을 지불하며, 제어 플레인 비용은 포함(XX)되지 않음.

• 노드 풀(Node Pools):

  • ㅁ 노드 풀은 클러스터 내의 노드의 하위 집합으로, 공유 구성(예: CPU, 메모리, 플랫폼)을 가짐.

  • ㅁ 노드 풀을 통해 워크로드를 특정 하드웨어에 실행할 수 있음.

  • ㅁ 노드 풀은 GKE 고유 기능으로, 자동 노드 업그레이드 및 수리, 클러스터 자동 확장을 지원함.

• 노드 리소스 관리:

  • ㅁ 각 노드의 일부 CPU와 메모리는 Kubernetes 및 GKE 구성 요소에 사용됨.

  • ㅁ 노드의 모든 리소스가 포드(Pod -> Kubernetes의 가장 작은 배포 단위)에 사용될 수는 없음.

• 리전 및 존 클러스터:

  • ㅁ 클러스터는 단일 Compute Zone에서 실행되며, 3개의 동일한 노드와 1개의 노드 풀을 기본적으로 가짐.

  • ㅁ 리전 클러스터는 여러 Compute Zone에 제어 플레인과 노드를 분산시켜, 단일 Zone의 장애에도 애플리케이션이 계속 동작할 수 있도록 함.

  • ㅁ 리전 클러스터는 기본적으로 3개 Zone에 걸쳐 있으며, 각 Zone마다 동일한 노드 수를 가짐.

  • ㅁ 생성된 클러스터는 존과 리전 클러스터 간에 변경할 수 없음.

• 프라이빗 클러스터:

  • ㅁ 프라이빗 클러스터는 제어 플레인과 노드를 공개 인터넷에서 숨김.

  • ㅁ 클러스터 제어 플레인은 Google Cloud 서비스(예: Cloud Logging, Cloud Monitoring)를 통해 내부 IP 주소로 액세스 가능.

  • ㅁ 외부 IP 주소로 제어 플레인에 액세스할 수 있는 권한을 부여할 수 있음.

  • ㅁ 노드는 프라이빗 Google 액세스를 통해 제한된 아웃바운드 통신 가능.

---

Kubernetes 객체 모델

• ㅁ Kubernetes가 관리하는 모든 것은 객체로 표현됩니다.

• ㅁ 이러한 객체, 속성 및 상태를 볼 수 있고 변경할 수 있습니다.

선언적 관리 원칙

• ㅁ Kubernetes는 사용자가 관리 대상 객체의 상태를 어떤 상태로 원하는지 알려주기를 기대합니다.

• ㅁ Kubernetes는 그 상태를 만들어내고 유지하기 위해 노력합니다.

• ㅁ 이를 위해 이른바 '감시 루프(watch loop)'를 사용합니다.

Kubernetes 객체

• ㅁ 지속적인 엔터티로 정의되며, 클러스터에서 실행 중인 상태, 원하는 상태, 현재 상태를 나타냅니다.

• ㅁ 다양한 종류의 객체가 있으며, 컨테이너 애플리케이션, 사용 가능한 리소스, 동작에 영향을 주는 정책을 나타냅니다.

• ㅁ 객체에는 두 가지 중요한 요소가 있습니다:

  • 객체 스펙: 생성하려는 각 객체에 대해 Kubernetes에 제공하며, 원하는 특성을 정의합니다.

  • 객체 상태: Kubernetes 컨트롤 플레인에서 제공하는 객체의 현재 상태입니다.

Kubernetes 컨트롤 플레인

• ㅁ Kubernetes 클러스터를 작동시키기 위해 협력하는 다양한 시스템 프로세스를 가리킵니다.

Pod

• ㅁ 표준 Kubernetes 모듈의 기본 구성 요소이며, 배포 가능한 최소 Kubernetes 객체입니다.

• ㅁ Kubernetes 시스템에서 실행 중인 모든 컨테이너는 Pod입니다.

• ㅁ Pod는 컨테이너가 살아가는 환경을 체현하며, 하나 이상의 컨테이너를 수용할 수 있습니다.

• ㅁ Pod 내의 컨테이너는 긴밀하게 연결되어 있으며, 네트워킹 및 스토리지 리소스를 공유합니다.

• ㅁ Kubernetes는 각 Pod에 고유한 IP 주소를 할당합니다.

• ㅁ Pod 내의 모든 컨테이너는 IP 주소와 네트워크 포트를 포함한 네트워크 네임스페이스를 공유합니다.

• ㅁ 동일한 Pod 내의 컨테이너는 localhost 127.0.0.1을 통해 통신할 수 있습니다.

• ㅁ Pod는 컨테이너 간에 공유될 스토리지 볼륨 세트를 지정할 수 있습니다.

예시

• ㅁ nginx 웹 서버의 인스턴스 세 개를 각각 자체 컨테이너에서 실행하고 싶다고 가정해 봅시다.

• ㅁ Kubernetes에서는 선언적 관리 원칙에 따라 이러한 nginx 컨테이너를 나타내는 객체를 선언합니다.

• ㅁ 아마도 Pod 객체일 것입니다.

• ㅁ Kubernetes의 역할은 그 Pod를 시작하고 존재하도록 유지하는 것입니다.

• ㅁ 하지만 Pod는 자가 치유 기능이 없습니다.

• ㅁ nginx 웹 서버를 팀으로 협력하도록 하려면, 더 발전된 종류의 객체를 사용해야 할 수 있습니다.

작동 방식

• ㅁ 우리가 Kubernetes에게 세 개의 nginx Pod로 구성된 원하는 상태를 제공했다고 가정해 봅시다.

• ㅁ Kubernetes는 원하는 상태와 현재 상태를 비교합니다.

• ㅁ 현재 상태가 원하는 상태와 일치하지 않으면, Kubernetes의 컨트롤 플레인이 상황을 개선합니다.

• ㅁ 원하는 Pod 실행 개수는 세 개이지만 현재 실행 중인 것이 없으므로, 세 개의 Pod가 시작될 것입니다.

• ㅁ Kubernetes 컨트롤 플레인은 클러스터 상태를 지속적으로 모니터링하여 선언된 내용과 비교하고 필요에 따라 상태를 개선합니다.

모르는 단어

인바운드 통신 & 아웃바운드 통신

인바운드(Inbound)와 아웃바운드(Outbound)는 네트워크 통신에서 사용되는 용어입니다.

인바운드(Inbound):

인바운드 통신은 외부 네트워크에서 내부 네트워크로 들어오는 트래픽을 의미합니다.

예를 들어, 웹 서버에 접속하는 사용자의 요청은 인바운드 통신에 해당합니다.

보안 설정에서는 인바운드 규칙을 통해 이러한 트래픽을 제어합니다.

아웃바운드(Outbound):

아웃바운드 통신은 내부 네트워크에서 외부 네트워크로 나가는 트래픽을 의미합니다.

예를 들어, 웹 서버가 데이터베이스 서버에 쿼리를 보내는 것은 아웃바운드 통신에 해당합니다.

보안 설정에서는 아웃바운드 규칙을 통해 이러한 트래픽을 제어합니다.

이 두 용어는 보안 그룹, 방화벽 규칙 등에서 네트워크 트래픽을 제어하는 데 사용됩니다.

ETCD

ETCD는 분산 키-값 저장소로, 데이터의 일관성과 신뢰성을 보장하기 위해 사용됩니다.

ETCD는 분산 시스템에서 중요한 설정 정보, 상태 정보 등을 저장하고, 이 정보를 클러스터 내의 다른 노드와 공유하는 데 사용됩니다.

ETCD는 Raft 합의 알고리즘을 사용하여 클러스터 내의 모든 노드가 동일한 상태를 유지하도록 합니다.

특히, 쿠버네티스에서는 ETCD를 사용하여 모든 클러스터 데이터를 저장합니다.

이에는 각 노드와 포드의 상태, 서비스, 볼륨, 네임스페이스, 사용자 권한 등의 정보가 포함됩니다.

쿠버네티스의 모든 컴포넌트는 이 ETCD 데이터를 참조하여 클러스터의 상태를 결정하고, 필요한 작업을 수행합니다.