표쥰 클러스터 아키텍처

제어 영역

K8s API 서버, 스케줄러,코어 리소스 컨트롤러를 포함하여 제어 영역 프로세스를 실행.

제어 영역 및 k8s API

 제어 영역은 클러스터의 통합 엔드포인트.

K8s API 호출을 통해 클러스터와 상호작용하고 제어 영역은 k8s API 서버 프로세스를 실행하여 이러한 요청을 처리합니다.

통신하는 방법 HTTP/gRPC,kubectl,cloud console

API 서버 프로세스는 클러스터의 모든 통신을 위한 허브

• 노드,파드,스케쥴러,컨트롤러???

모든 내부 클러ㄹㄹ스터 프로세스( 클러스터 노드, 시스템 및 구성요소, 애플리케이션 컨트롤ㄹ) 는 aPI 서버 클라이언트로 작동. API 서버는 전체 클러스터의 단일 신뢰 소스??

제어 영역 및 노드 상호작용

제어 영역은 모든 클러스터 노드엣 ㅓ실행되는 항목을 결정.
제어 영역은 컨테이너화된 애플리케이션과 같은 워크로드를 예약하고 워크로드으 ㅣ수명 주기, 확장 업그레이드를 관리.
제어 영역은 또한 이러한 워크로드의 네트워크 및 스토리지 리소스를 관리.

Artifact Registry 및 Container Registery

클러스터를 만들거나 업데이트하면 제어 영역에서 실행되는 k8s 소프트웨어의 컨테이너 이미지를 pkg.dev Artifact Registry 또는 gcr.io Container Registry의 리전 중단이 발생하면 google은 중단의 영향을 받지 않는

노드

클러스터는 일반적으로 하나 이상의 노드를 포함 이러한 노드는 컨테이너식 애플리케이션 및 다른 워크로드를 실행하는 작업자 머신. 개발머신은 클러스터를 생성할 때 사용자를 대싱해서 핟가 생성하는 VM 인스턴스입니다.

각 노드는 노드의 자체 보고 상태에 대한 업데이트를 수싱하는 제어영역에서 관리

노드는 클러스터의 워크로드를 구성하는 컨테이너를 지원하는데 필요한 서비스를 실행.

런타임 및 Kubernetes 노드 에이전트(kubelet)이 포함.

노드 할당 가능 리소스

클러스터의 일부로 작동하도록 만들기 위해 필요한 노드 리소스 중 일부가 필요.
노드의 총 리소스 != 노드에 할당 가능한 리소스
윈도우 os 일경우 리소스가 더 많이 필요

Pod에 대한 리소스를 요청 및 pod 의 리로스 사용을 제한할 수 있다.

클러스터 유형

클러스터를 만든 후에는 선택사항을 변경할 수 없음.

• 가용성
• 버전 안정성
• 네트워크

클러스터 관리 수준

클러스터의 유연성,책임,제어의 수준

작업 모드

표준 : 클러스터의 기본 인프라에 대한 고급 구성 유연성을 제공. 프로덕션 워크로드에 필요한 구성이 결정.

클러스터 가용성 유형

영역(단일 영역 또는 멀티 영역) 유형과 리전 유형이 포함.

영역 클러스터

단일 영역에 단일 제어 영역이 존재. 가용성 요구사항에따라 영역 클러스터의 노드를 단일 영역 또는 여러영역에 배포하도록 선택

다중 영역 클러스터

단일 영역에서 실행되는 단일 제어 영역 복제본과여러 영역에서 실행되는 노드가 있습니다. 클러스터, 노드, 워크로드는 제어 영역을 사용할 수 있기 전까지는 구성할 수 없음.

클러스터 버전

출시 채널

안정성 수준을 알면 – 출시 채널에 등록
기본적으로 새 클러스터는 일반 출시 채널에 등록.
구글에서는 해당 출시 채널에서 업데이트가 제공되면 클러스터와 클러스터 노드를 자동으로 업그레이드.

특정 버전

특정 워크로드를 지원하는 특정 k8s 버전을 사용해야 하는경우 클러스터를 만들 때 버전을 지정할 수 있습니다.

기본 버전

출시 채널에 클러스터를 등록하는 대신(채널없음) 정적 버전을 사용, 특정 버전을 설정하지 않은 경우 기본 버전이 적용,

클러스터 네트워킹

네트워크 라우팅 모드를 지정하고 클러스터 네트워크를 격리하는 방법을 지정할 수 있음.

VPC 기반 및 경로 기반 클러스터

gke에는 pod에서 pod로 트래픽을 라우팅하는 방법에 따라 클러스터를 구분

VPC 기반 클러스터 - 별칭 ip를 사용하는 클러스터

경로 기반 클러스터 - Google cloud Route를 사용하는 클러스터

VPC 기반

• 새 클러스터에 권장되는 네트워크 모드 ( Autopilot 모드의 기본 값)
• 표준 모드에서 만든 클러스터의 경우 기본 네트워크 모드는 GKE 버전과 클러스터를 만드는 데 사용하는 방법에 따라 다름

네트워크 격리 선택사항

공개 네트워크에서 클러스터의 워크로드 액세스를 구성 ( weave?) 경로는 자동으로 생성 안됨.
비공개 클러스터에서는 내부 주소를 Pod 및 노드에 할당 -> 워크로드는 공개 네트워크와 격리!

비공개 클러스터

내부IP 주소에만 의존하는 VPC기반 클러스터 유형. 비공개 클러스터의 노드,Pod,서비스에는 고유한 서브넷 IP 주소 범위가 필요.

특정 비공개 노드에 아웃바운드 인터넷 액세스 권한을 부여하려면 Cloud NAT를 사용하거나 NAT 게이트웨이를 관리

아키텍처

비공개 클러스터 = 외부 ip 주소가 null~~
비공개 클러스터에 호스틍된 nodeport 유형의 서비스는 노드에 인터넷 라우팅이 가능한 공개 ip 주소가 없으므로 외부 xxxx
제어 영역 비공개 엔드포이늩와 제어 영역 공개 엔드포인트가 존재.
제어 영역의 비공개 엔포에 고유한 /28 IP 주소 범위를 지정해야 하며
제어 영역의 공개 엔드포인트를 사용 중지 가능

내부 IP 주소를 사용하더라도 외부 클라이언트가 클러스터의 서비스에 연결할 수 있음.

• 인터넷의 소스 IP 주소가 있는 외부 클라이언트는 서비스 매니페스트에서 spec.loadBalancerSourceRanges를 생략 하면 LoadBalancer 유형의 외부 서비스에 연결할 수 있다.
• NodePort 또는 ClusterIP 유형의 서비스를 만들어 외부 인그레스를 사용하면 외부 클라이언트에 서비스를 노출할 수 있음.

비공개 클러스터에서 비공개 Google 액세스 사용

클러스터와 동일한 프로젝트에서 VPC 네트워크를 사용하는 비공개 클러스터으 ㅣ경우 GKE 는 클러스터를 만들 때 비공개 클러스터에서 사용하는 서브넷에 비공개 구글 액세스를 사용 설정.

비공개 클러스터의 제어 영역

모든 GKE 클러스터에는 제어 영역에서 관리되는 Kubernetes API 서버가 있다.
제어 영역은 구글 소유 프로젝트의 VPC 네트워크에 있는 가상머신에서 실행. 리전 클러스터에는 여러 제어 영역이 있으며 각 제어 영역은 자체 vm에서 실행.

비공개 클러스터에서 제어 영역의 VPC 네트워크는 VPC 네크워트 피어링을 통해 클러스터의 VPC 네트워크에 연결

VPC 네트워크 피어링을 사용하여 클러스터의 VPC 네트워크를 세 번째 네트워크에 연결하면 세 번째 네트워크는 제어 영역의 VPC 네트워크에 있는 리소스에 도달할 수 없습니다. 이는 VPC 네트워크 피어링이 직접 피어링된 네트워크 간의 통신만 지원하고 세 번째 네트워크는 제어 영역 네트워크와 피어링될 수 없기 때문