[GKE] 난 이 글을 쓰고나면 클러스터 구성중 모르는 키워드는 없을거야!

이제 나름 k8s의 기술적 구성 용어나

기본 명령어는 이해하고 있었는데

실적용을 해 볼 기회를 노리고 있었다

다행히 이번에 사용 가능 명령이 떨어졌고

조금 더 깊어보고자 오늘도 발버둥 쳐본다

당연히 분석하고 뜯는 입장에선

Standard로 설정해서 부딪히고 깨지기로 했다

라고 하기엔 이전에 해보았고 AWS보단 쉽기에 찬찬히해보자

클러스터 기본 사항 설정

나는 명령어 날릴 때 이게 클러스터 이름인지

아니면 노드 이름인지 헷갈리기 때문에 직관적으로 지었다

---------

🛫 영역, 지역의 차이 🛫

: 이 둘의 차이는 컨트롤 플레인의 HA에 결정 요소를 주는 것이다

영역 선택 시,

컨트롤 플레인이 특정 하나의 영역(us-central1 -a )에 귀속되게 된다

그렇기에 해당 영역이나 컨트롤 플레인의 장애 발생 시

모든 서비스의 마비가 발생할 수 있다.

지역 선택 시,

컨트롤 플레인이 지역 (us-central1)의 여러 군데 배치된다.

이로 하나의 컨트롤 플레인이 장애가 발생하여도

타 지역의 복제된 컨트롤 플레인이 인계하여 무중단 클러스터 관리가 된다!

결정은 쉬웠다

영역 (us-central1-a)	지역 (us-central1)

나는 지금 테스트 용이라 지역 클러스터가 필요하지 않다...

---------

🛸 출시 채널 🛸

이건 클러스터가 사용할 Kubernetes 버전에 대해서

안정성/업데이트 속도를 지표로 어떻게 조정할 것인지를 묻는 것이다.

나처럼 standard를 쓴다면 아래와 같은 경고가 뜰 것이다.

블로그에 이미지는 설정 깔끔하게 보여주려고 설명과 경고는 편집해서 없앴기에 안 보였다

standard에서 특정 출시 채널을 선택하게 되면

이를 자동관리하는 Autopilot 모드에서는 충돌될 가능성이 있기에

이후 Autopilot 모드로 전환이 불가하거나

컴퓨팅 클래스같은 것과 충돌 가능함을 알리는 것이다

Fleet

클러스터 관리 시스템

역할

2개 이상의 클러스터를 논리적으로 그룹화 해준다!

논리적 그룹화 (Normaliztion)	여러 클러스터(GKE, 타 클라우드 등)를 하나의 Fleet 멤버로 묶어 관리의 복잡성을 줄이고 통합 가능
일관된 구성 적용 (Config Sync)	중앙 Git 저장소에 정의된 Kubernetes 구성 및 정책을 Fleet 내 모든 클러스터에 자동으로 동기화
중앙 집중식 정책 관리 (Policy Controller)	Fleet 내 클러스터 전체에 걸쳐 보안 및 거버넌스 정책을 강제하고 감사하여, 설정 오류나 보안 취약점을 미리 방지
멀티 클러스터 네트워킹 (Multi-Cluster Ingress)	여러 클러스터에 분산된 서비스들을 하나의 글로벌 로드 밸런싱 IP로 통합해 고가용성 확보 및 지능적 트래픽 분산
통합 관찰성 (Observability)	등록된 모든 클러스터의 로그, 측정항목, 보안 상태를 중앙화된 Google Cloud Monitoring / Logging에서 모니터링 가능

아주 좋고 훌륭한데, 나는 영역 클러스터에

클러스터도 전 서비스에서 하나만 쓰기에 사용할 이유가 없었다

노드 설정 구성

아주 간단히 보면 아래 의미를 가진다.

1) 커스텀 OS 쓸래요 (권장 - 빠르고 가벼움)

2) 익숙한 Ubuntu 쓸래요

3) Windows 쓸래요

잠시 의문 키워드 해결하기

Container-Optimized OS	컨테이너 워크로드에 최적화된 OS COS는 일반적인 범용 OS와 달리,오직 컨테이너를 실행하는 것에만 맞춰져 있음
일부 사용자에게 영향을 주는 제한사항이란?	1) 읽기 전용 루트 파일 시스템 2) 패키지 관리자(apt, yun, dnf 등)의 부재로 필요 도구는 모두 컨테이너화 하여 사용해야함 3) 특정 드라이버/커널 모듈 요구는 COS 간소화 커널 구성으로 충족 불가할 수 있음
어째서 보안과 성능이 더 우수?	- 보안 1) OS에 필수적인 요소만 포함하였음 2) 루트가 읽기 전용임 3) k8s 관련 구성 요소를 Google이 최적화함 - 성능 1) 경량화로 VM 부팅 시간 단축으로 클러스터 오토스케일링 시 노드 빠르게 준비 2) OS 커널과 설정이 컨테이너 런타임에 맞춰 튜닝되어 있음
NFS, GlusterFS, XFS가 뭐죠	- NFS(Network File System) > 역할: 네트워크 기반 파일 공유, 분산 파일 시스템 프로토콜 > 특징: GKE 노드들이 해당 서버 접속해서, 디렉토리를 로컬 디스크처럼 쓸 수 있음 - GlusterFS > 역할: 여러 서버 디스크를 묶어 단일 대용량 저장소처럼 해주는 오픈소스 분산 파일 시스템 > 특징: 스케일 아웃에 용이, 저렴한 하드웨어로 고가용성 스토리지를 구축할 때 씀 - XFS > 역할: 단일 서버나 VM에서 사용되는 로컬 파일 시스템 > 특징: 대용량 파일 및 파일 시스템을 효율적으로 관리하도록 설계, 쓰기 성능이 우수

----------------------------------

압축배치

하드웨어적으로 동일하거나 매우 가까운 위치에 노드를 몰아두는 설정이다

여러 복잡한 사정으로 한 번 지정하면 변경할 수 없나보다

------------------------------

프로비저닝 모델 구분

표준 VM:
일반적인 선택

스팟 VM:
표준 VM에 비해 60%가량 저렴하나,

표준 VM 자원이 모자라게 되면 GCP가 이 인스턴스를 회수함

flex-start VM:
표준과 스팟 사이의 가격으로 회수 상황시,

정한 정책이나 선택을 통해 표준 VM 가격으로 사용 가능

(단, 최대 7일 이용가능 + 자원이 남아야 할당의 제약 존재)

나는 표준 VM 했다

----------------------------

노드 풀 업그레이드 전

직관 적인 둘 사이에 생소한 친구가 하나 있다

flex-start 전략을 활용해 저렴하게 기존 노드도 두는 전략이다

신규 노드 프로비저닝: 노드 풀에 필요한 신규 노드가 최신 GKE 버전으로 프로비저닝됩니다.
기존 노드 사용 중단: 기존 노드(이전 버전)는 최대 실행 기간이 만료 혹은 리소스가 필요 없어질 때까지 사용되다가 중단
전략 고정: 이 옵션은 클러스터 생성 후에는 변경 불가

-------------------------------------------

이름을 재밌게 지었다 노드 오염을 관용과 함께 사용해서 파드가 부적절한 노드에 예약되지 않도록 한다는 것

1. 🟥 Taint (오염) - "들어오지 마!" (규칙/제한)

적용 위치: 노드
역할: 노드에 부정적인 표시를 하는 것! "이 노드에 파드들을 배치하는 것을 기본적으로 거부한다"

2. 🟩 Toleration (허용) - "괜찮아, 난 들어갈게!" (열쇠/면제)

적용 위치: 파드
역할: Taint가 적용된 노드에 예외적으로 배치될 수 있도록 파드에 '면제권'을 부여하는 것!
예시: 특정 파드에 "나는 GPU를 쓸 자격이 있다!!!"라는 면제권(Toleration)을 부여! 이 면제권이 있는 파드만 경고문(Taint)이 붙은 노드에 들어갈 수 있음!

설정	새 파드 예약	기존 파드 처리	사용 목적
NO_EXECUTE	금지	즉시 축출 (Evict)	노드 교체, 심각한 문제로 즉시 비울 때
NO_SCHEDULE	금지	유지	유지 보수 시작, 새로운 파드 진입만 막을 때 (가장 일반적)
PREFER_NO_SCHEDULE	지양 (선호)	유지	선호하지 않는 노드로 표시 (Soft Rule)

-------------------------------------

GCE 인스턴스 메타데이터

인스턴스를 실행했을때,

GCP에서 예약해둔 키워드 같은걸 활용해 시작 스크립트를 넣거나

이런 시작 스크립트에 넣은 환경 변수 값 같은걸 정의해서 넣을 수 있다.

유형	예시 키 (Key)	예시 값 (Value)	역할
시작 스크립트	startup-script	쉘 스크립트 내용	VM 부팅 후 딱 한 번 실행될 명령어 지정 (소프트웨어 설치, 환경 구성 등)
네트워크 구성	disable-legacy-endpoints	true 또는 false	기존의 Compute Engine 메타데이터 엔드포인트 사용 여부를 제어 (이미지에서 보셨던 예시)
운영체제 접속	ssh-keys	사용자 공개 SSH 키	VM에 로그인할 수 있는 사용자 권한 설정
GKE 구성	kube-env	YAML 또는 Base64 데이터	노드가 쿠버네티스 클러스터에 조인하는 데 필요한 상세 설정 정보

'기술 단어장 > Cloud' 카테고리의 다른 글

[AWS] AWS SAA(Solutions Architect - Associate) 6일 공부 후 합격 (0)	2026.02.13
[S3] 네컷 사진관의 개인정보 유출 문제 제안 및 개선 (1)	2025.11.10
[GCP] Azure VM 기반 Docker 환경에서 GCP 관리형 서비스로의 이관 (0)	2025.10.21
[Azure] 정적 웹 호스팅 비용 절감을 위한 전략 및 자동 배포 과정 오류 처리 (0)	2025.05.21
[Cloud] SKT의 유심교체 사태로 보는 AWS S3 보안 (0)	2025.04.28

메프도의 요약노트