GCP Cloud Engineer - 64
2024-04-19
- Cloud
- GCP
- Kubernetes
번역이 좀 이상하긴함.. 두 번 나눠서 정리함.
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 데이터를 참조하여 클러스터의 상태를 결정하고, 필요한 작업을 수행합니다.
GCP Cloud ...
GCP Cloud ...