이번에는 Kubernetes Service에 대해 실습해보자 ✔️ Service 한번 생성된 Pod는 영속적으로 존재하지 않을 수 있다. 동작 실패나 준비 상태 점검 등 여러 가지 이유로 인해 중단되거나 시작될 수 있으며 이로 인해 다음과 같은 문제가 발생한다. Pod를 재가동하면 이전과는 다른 IP 주소를 가질텐데 그렇다면 Pods의 set와 통신하려면 어떻게 해야할까? 이것이 서비스가 필요한 이유이다. 서비스는 Pods에 안정적인 Endpoint를 제공한다. Service는 labels을 사용해 어떤 Pods가 동작 중인지를 확인한다. Pods에 올바른 라벨이 붙어있는 경우는 service에 의해 자동적으로 인식되어 공개된다. 서비스가 일련의 Pod에 제공하는 액세스 레벨은 서비스의 타입에 달려있다...

✔️ 실습에 앞서 실습 목표 Kubernetes Engine 을 사용하여 완전한 Kubernetes 클러스터를 프로비저닝하기 kubectl을 사용하여 Docker 컨테이너를 배포하고 관리하기 Kubernetes의 배포 및 서비스를 사용하여 애플리케이션을 마이크로서비스로 나누기 ✔️ GKE 환경 설정 Cloud Shell 환경에서 다음 명령을 입력하여 영역을 설정한다. gcloud config set compute/zone us-central1-b 영역을 설정한 후 이 실습에서 사용할 클러스터를 시작한다. gcloud container clusters create io ✔️ 샘플 코드 받기 Cloud Shell 명령줄에서 GitHub 저장소를 복제한다. gsutil cp -r gs://spls/gsp021..

✔️ 실습에 앞서 실습 목표 네트워크 로드 밸런서와 HTTP 로드 밸런서의 차이점 알기 Engine Virtual Machine에서 실행 중인 애플리케이션에 대해 네트워크 로드 밸런서를 설정하는 방법 습득 Google Cloud에는 로드밸런싱을 수행하는 몇가지 방법이 있다. 그 중 Network 로드 밸런서와 HTTP(s) 로드 밸런서에 대해 배워본다. 실습 내용 네트워크 로드 밸런서를 설정한다. HTTP 로드 밸런서를 설정한다. 네트워크 로드 밸런서와 HTTP 로드 밸런서의 차이점 배우기 ✔️ Task 1 : 모든 리소스에 대한 기본 지역 및 영역 설정하기 1. Cloud Shell에서 기본 영역을 설정한다. gcloud config set compute/zone us-central1-a 2. 기본 영..

✔️ GKE 다루기 Google Kubernetes Engine (GKE)은 Google 인프라를 사용해 컨테이너화된 어플리케이션을 배포, 관리 및 확장하기 위한 관리형 환경을 제공한다. Kubernetes Engine 환경은 컨테이너 클러스터를 형성하도록 그룹화된 여러 머신(특히 Compute Engine 인스턴스)로 구성된다. GKE를 사용해 컨테이너를 생성하고 어플리케이션 배포를 실습해본다 ! ✔️ Default Compute Zone 설정하기 Compute Zone이란 클러스터와 해당 리소스가 있는 대략적인 지역의 위치이다. ex) us-central1-a는 us-central1의 영역의 zone인 것이다. Default Compute Zone을 us-central1-a로 설정하기 위해 Cloud..

✔️ Prometheus란 ? Prometheus는 SoundCloud 사에서 만들었다가 독립된 오픈소스 시스템 모니터링 및 경고 툴킷이다. 2016년에 쿠버네티스를 잇는 두번째 호스팅 프로젝트로 Cloud Native Computing Foundation(CCNF)에 합류했다. ✔️ Prometheus 기능 프로메테우스의 주요 기능들은 다음과 같다. 메트릭 이름 및 키/값 쌍으로 식별되는 다차원 데이터 모델을 시계열로 저장 다차원 모델을 다각도로 활용하는 유연한 쿼리 언어인 PromQL. 이를 통해 성능 분석이 가능. 다양한 그래프 및 대시보드 지원(with Grafana) alertmanager를 통한 알림 생성 발생 애플리케이션 코드 계측을 위한 클라이언트 라이브러리 분산 스토리지나 다른 원격 서비..

✔️ Serverless란 무엇인가 ? 서버리스란 서버가 없는 백엔드가 아니라, 내가 직접 서버를 관리하지 않는 백엔드를 말한다. Serverless는 왜 탄생했는가 ?! 서버리스의 탄생 배경을 알기 위해선 과거의 어플리케이션 배포 방식에 대해 이해할 필요가 있다. 과거 어플리케이션을 배포하기 위해서는 서버의 하드웨어, 소프트웨어를 직접 관리해야 했었다. 만약 정전이 되거나 누군가가 전원을 뽑았다면 서버가 다운되고 운영되던 서비스는 중단된다. 또는 갑작스런 사용자 유입 증가로 인해 트래픽이 증가한다면 서버의 메모리가 충분하지 않아 메모리를 추가해야 했다. 이때 ! Amazon의 EC2가 등장하게 된다. EC2란 아마존에게 비용을 지불하고 고성능의 서버를 대여해서 사용하는 것이다. 우리가 잘 알고 있는 A..