# GKE

euijoo3233

1. Introduce Storage & Volume 먼저, 스토리지와 볼륨의 개념을 살펴보자. Kubernetes는 개체를 사용하여 관리하는 리소스를 나타낸다. 이 규칙은 포드뿐만 아니라 스토리지에도 적용되며, 이러한 모든 개체는 추상화로 작동힌다. 즉, 구현 세부 사항에 힘들게 주의를 기울이지 않고도 개체가 나타내는 리소스를 관리할 수 있다는 장점이 있는 것이다. Kubernetes는 스토리지 추상화를 볼륨 및 PersistentVolume으로 제공한다. 볼륨은 Pod의 모든 `컨테이너에 액세스할 수

euijoo3233

1. kubectl 관리자가 K8S 클러스터를 제어하는 데 사용하는 유틸리티이며 컨트롤 플레인에서 kube-apiserver와 통신하는 데 사용된다. kubectl로 작업을 수행하려면 다음과 같이 구성해야한다. k8s 클러스터의 위치 및 자격 증명을 예로 들어 클러스터에서 포드 목록을 보려는 관리자를 예로 들어보면, 적절한 자격 증명으로 kubectl을 클러스터에 연결한 후, 관리자는 kubectl get pods명령을 실행할 수 있다. 그러면 , kubectl 은 이를 API 호출로 변환하여 클러스터의 컨트롤 플레인 서버에서 HTTPS를 통해 kube-apiserver로 보낸다. 다음으로 kube-apiserver는 etcd를 쿼리하여 요청을 처리하고 kube-apis

euijoo3233

1. Container 대규모로 쿠버처럼 컨테이너를 오케스트레이션하는 방법은 제공하지 않음. Google Cloud Build 를 사용하여 Docker 형식의 컨테이너 이미지를 만들 수 있음. 하지만, 컨테이너는 Linux의 본질적이고 원시적인 기능이 아닌 대신에 워크로드를 격리하는 기능은 여러 기술의 구성에서 파생된다. Linux Process 각 리눅스 프로세스에는 다른 모든 프로세스와 별개인 고유한 가상 메모리 주소 공간이 있다. 빠르게 생성되고 파괴됨 컨테이너는 Linux namespace를 사용하여 애플리케이션이 볼 수 있는 프로세스 ID 번호, Directory Tree ,IP Addr 등을 제어한다. 하지만, Linux 네임스페이스는 쿠버 네

shmoon2

앞에서 GKE 에 대한 접근을 개별 계정 기반으로 컨트롤 하는 방법을 알아봤습니다.(RBAC) 여기에서는 GCP IAM Group 기반으로 접근제어 하는 방법을 알아봅니다. GKE 를 생성하다 보면 아래와 같은 옵션이 있습니다. https://cloud.google.com/kubernetes-engine/docs/how-to/google-groups-rbac#setup-group google groups 혹은 cloud id 권한을 가지고 iam group을 생성한다.(반드시 아래와 같은 그룹명으로 생성합니다.) 그룹을 생성합니다. 그리고 관리 대상 IAM group 을 위에서 생성한 group에 중첩해서 member 로 설정합니다. 모든 리소스를 조회해봅니다. ![](https://vel

shmoon2

k8s에서 RBAC 가시성을 관리를 하는 여러가지 방법을 알아봅니다. 1.쿠버네티스 대시보드 https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/ 클러스터 > 클러스터 롤 바인딩, 클러스터 롤, 롤 바인딩, 롤 에서 RBAC 관련 정보를 볼 수 있습니다. 대시보드 형식으로 개별 리소스에 대한 정보를 일일이 조회해야합니다. 2.RBAC-lookup https://rbac-lookup.docs.fairwinds.com/#installation

shmoon2

GKE Cluster에 대한 RBAC 기반 관리를 하기 위해 GCP의 IAM 과 K8s builtin RBAC을 적절히 조합해 더욱 세부적인 접근 제어를 할 수 있습니다. 위 그림을 보면 GCP IAM의 predefined roles 와 kubernetes의 cluster roles는 100%는 아니지만 어느정도 비슷합니다. 중요한 점은 GCP의 roles는 기본적으로 gcp 프로젝트 레벨이기 때문에 IAM 을 통해 갖는 GKE에 대한 권한은 클러스터 레벨(namespace가 아닌)라는 점입니다. 그렇기 때문에 IAM role을 부여하면 GKE cluster(project 포함) 내의 admin, edit, view 각각에 대한 cluster 레벨 권한이 부여됩니다. GKE의 resource에 대한

son_doobu96

쿠버네티스에 익숙해지기 위해 간단한 개인 미션을 진행하였다. 목표 : 쿠버네티스를 이용해 nginx pod를 띄우고 포트 포워딩을 통해 local에서 접속이 가능하도록 구성 이번 실습은 GKE를 통해 진행했다. AWS의 경우 조금 사용해 봤다 보니 큰 어색함이나 불편함이 없었지만 GKE의 경우 처음 사용해보다 보니 명령어나 리전설정등 모든 부분에서 조금 어색함이 있어 초반에 많은 에러를 겪은 것 같다. 먼저 아래의 명령어를 통해 GKE 클러스터를 생성했다. 이후 아래의 명령어를 통해 사용자에게 클러스터 내 모든 리소스에 접근할 수 있는 권한을 줬다. 이후 nginx 이미지를 이용해 Pod를 생성해줬다. 아래 명령어를 통해 pod가 생성됨을 확인할 수 있다. ![](https://velog.velcdn.com/images/son_doobu96/post/019a6f30-c898-4aab-b433-07b4b144d803/image.pn

son_doobu96

■ 오케스트레이션이란 무엇인가? orchestrate의 사전적 의미 ‘to plan and organize something carefully and sometimes secretly in order to achieve a desired result’ Cambridge Dictionary 즉 컨테이너 오케스트레이션 도구는, 수십~수백개의 컨테이너를 관리하고자 할 때 보다 더 잘 관리하기 위한 툴이다. ■ 컨테이너 오케스트레이션 툴이 필요한 이유? 마이크로서비스로 아키텍처 트렌드가 변화함에 따라 컨테이너의 갯수가 증가했고 여기에 확장성, 장애대응등을 위한 스케일링, 레플리카까지 추가되며 그 갯수가 이제는 수백 수천개에 이르게 되었다. 그러다보니 일일히 컨테이너를 관리할 수 있는 시기가 지나게 되었고 효율적으로 컨테이너를 관리할 수 있는 툴이 필요하게 되었다. 컨테이너 오케스트레이션의 대표적인 툴로 쿠버네티스가 현재 가장 많이 사용된다. ■

minbrok

GitHub Actions GitHub Actions는 코드 저장소(repository)로 유명한 GitHub에서 제공하는 CI/CD 기능이다. GitHub Actions를 사용하면 자동으로 코드 저장소에서 어떤 이벤트가 발생했을 때 특정 작업이 일어나게 하거나 주기적으로 어떤 작업들을 반복해서 실행시킬 수도 있다. GKE 웹 어플리케이션 배포 실습에 있는 어플리케이션을 받아와서 GitHub Actions를 사용해 배포해볼 것이다. 우선 GKE 클러스터를 생성해주는데 이전 GitLab CI/CD 포스트에서와 마찬가지로 비공개 클러스터로 생성해줄 것이다. ([GitLab CI/

minbrok

GitLab CI/CD GitLab은 GitLab Runner라는 것을 작동하여 CI/CD 파이프라인을 구현할 수 있다. Runner에도 여러 버전이 있지만 default로 모든 프로젝트를 지원하는 Shared Runner를 사용해 GKE에 application 배포해볼 것이다. 아키텍처 클러스터 생성 비공개 GKE 클러스터를 생성해줄 것이다. 우선 VPC를 커스텀모드로 따로 생성해주자 ![](https://velog.velcdn.com/images/minbrok/post/fcd45402-e8a4-4d76-9f

minbrok

GCP에서 GKE를 구성하여 앱을 배포해볼 것이다. (개인적으로 클러스터 구축하기가 너무 편하다..) 아키텍처 >간단하게 웹페이지 방문 횟수가 Count되어 뜨는 app을 배포할 것이고 DB는 redis를 사용할 것이다. Flask 애플리케이션은 Redis를 사용하여 데이터를 저장한다. Redis Master에 데이터를 쓰고 여러 Redis Slave에서 데이터를 읽는 구조. Backend redis-master.yaml redis가 배포될 backend namespace가 따로 생성되고 Service를 통해 Internal LB가 생성될 것이다. redis svc의 external-ip가 나오면 이 external-ip를 밑에 redis-slave.yaml 안에 입력해서 redi

minbrok

나는 GCP에서 GKE를 구성하여 GKE 클러스터에 카프카를 세팅해볼 것이다. (여기서 쓰이는 yaml파일들은 특정 클라우드 환경에 종속되지 않기 때문에 편한 환경에서 진행해보면 된다.) GKE 구성 현재 진행하려 하는 것은 굳이 자동확장까지 할 필요는 없으므로 Standard를 선택한다. 여기서 이름, 리전, 그리고 노드에 관한 설정을 해주고 싶으면

hoonki

사내 Celery 도입을 위해서 GKE(Google Kubernetes Engine)에 RabbitMQ를 설치해야 했다. GKE에 RabbitMQ RabbitMQ를 설치하는 도중 Pod이 계속 Pending State에 머물러있길래 왜 그런지 살펴보던 중 Persistent Volume 및 Persistent Volume Claim과 관련된 이슈라는 것을 깨달았다. 오늘은 k8s에서 데이터를 영구적으로 저장하는 메커니즘인 Persistent Storage에 관한 내용을 다룰 것이다. 스토리지 관리는 K8s 클러스터 내에 있는 컴퓨트 노드(인스턴스) 관리와는 별개의 문제이다. 외부 별도의 스토리지 시스템을 이용해 데이터를 저장할 수도 있고 클러스터 내 노드의 자원을 사용할 수도 있다. k8s에서는 Persistent Storage를 통해서 클러스터 개

hoonki

개요 신규 프로젝트에서 Celery를 활용하기 위해 브로커에 쓰일 RabbitMQ를 구축해야 했다. 이미 우린 GKE를 활용해서 백엔드 애플리케이션 및 Celery Worker를 올리려고 하였기 때문에 RabbitMQ도 GKE에 구축해야 했다. (물론 클라우드 기반해서 제공하는 서비스도 있으나 그래봐야 Celery 메시지 전달 정도라서, 사용량이 많지 않을 것 같아 간단하게 내가 구축하는게 나을 것 같았다.) 설치 방법 RabbitMQ 공식 문서 - RabbitMQ Cluster Operator https://www.rabbitmq.com/kubernetes/operator/operator-overview.html RabbitMQ 공식 문서에는 Kubernetes 환경에서 Ra

calmlake79

앞글 에서 Container Registry를 정리하는 글을 썼었습니다. 연결되는 내용입니다만, 다음으로는 실제로 사용되지 않는 Container Registry를 정리하는 내용입니다. GKE를 사용하다보면, 당연히 과거에는 사용했으나, 현재는 사용하지 않는 Workload들이 늘어나게 됩니다. 물론 매번 바로 바로 삭제하면 좋지만 사람일이라는게 그렇게 될리가 있나요... 따라서 한참 시간이 지나면 삭제된 Workload들에 연결되어 있던 Docker Image들이 차곡차곡 Container Registry에 쌓이게 됩니다. 그렇다면 각각 목록을 불러와서 사용되지 않는 이미지를 diff해서 삭제하면 됩니다. 위와 같은 스크립트를 호출하면 namespace 목록을 불러올 수 있습니다. ( kube는 기본적으

leesjpr

Rancher 에서 GKE 를 사용한 Kubernetes cluster 구축에 대한 내용을 정리 https://rancher.com/docs/rancher/v2.6/en/quick-start-guide/deployment/google-gcp-qs/ Rancher version: 2.6v Cloud Platform: Google Cloud Platform Prerequisites: Rancher server, GCP service account, gcp account, gcp project, Google Kubernetes Engine 사용 설정 Cluster 생성 메인 메뉴의 클러스터 관리 메뉴로 진입 ![](https://images.velog.io/images/leesjpr/post/433c4ed0-8051-4a9a-bba8-74be777f1762/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%

ifthenelse

1. GCP GKE란 구글 클라우드 플랫폼(gcp)에서 제공하는 managed kubernetes 서비스이다. Google Kubernetes Engine의 약자이다. 다른 클라우드 플랫폼(aws, azure)보다 간단하게 설정 가능하다고 해서 해당 내용을 정리해 본다. 2. GKE 클러스터 생성 gcp 접속후 메뉴에서 GKE로 이동한다. 만들기 버튼을 클릭하면 아래와 같은 화면으로 변경된다. 표준 모드와 autopilot 모드가 있는데, "표준"모드를 선택한다. 자세한 내용은 살펴 보아야 겠지만, autopilot은 반자동 모드 같은 느낌이다. 표준보다 간단하게 사용할수 있도록 상당수 설정을 구글이 자동으로 진행해 주는것 같다. ![](https://images.velog.io/images/if

1yangsh

kOps (Kubernetes Operations) > 구글의 GKE, Amazon EKS 등 클라우드 환경에서의 Kubernetes 설치 프로그램 > 구글에서 개발 1. 작업 환경 구축 가상머신 Ubuntu 18.04 준비 (t2.micro) -> US 리전 (상대적으로 저렴) ssh 접속 (로컬 shell로 접속하는 방법) key pair 다운로드한 디렉터리로 이동 ssh -i @ 연결이 안되는 경우 홈 경로로 이동 cd ~ .ssh 로 이동 cd .ssh known_host 의 내용을 전부 지운 후 다

200ok

목표 GKE를 사용하여 다중 계층 웹 어플리케이션 빌드하기 해당 애플리케이션은 방문자가 로그에 텍스트를 입력하고 최근에 기록된 몇 개 항목을 볼 수 있는 방명록이다. 학습 내용 부하 분산기를 사용하여 외부 IP에서 방명록 웹 서비스 설정하기 단일 마스터 및 여러 복제본으로 구성된 Redis 클러스터 실행하기 GKE 중요 개념 학습(선언적 구성, 디플로이먼트, 서비스) 사전 설정 Kubernetes Engine API 사용 설정 테스트를 위한 프로젝트 선택 gcloud, kubectl 설치 (Cloud Shell, gcloud SDK의 경우 설치 불필요) gcloud 명령줄 도구 설정 프로젝트 ID와 Compute Engine 영역 옵션의 입력 시간을 절약하기 위해 기본값 세팅 ![](https://images.velog.io/images/200ok/post/4f98b111-bcc7-4e61-9d25-1019e36

200ok

학습 내용 서비스 계정 생성 방법 Pub/Sub에서 서비스 계정에 필요한 역할을 할당하는 방법 Pub/Sub 외에도 모든 Google Cloud 서비스에 적용 가능 계정의 키를 Kubernetes Secrets에 저장하는 방법 서비스 계정을 사용하여 애플리케이션 구성 및 배포 방법 예시 애플리케이션은 Pub/Sub Topic을 구독하고 표준 출력으로 게시된 메시지를 보여준다. 서비스 계정으로 인증 GCP에서는 다음과 같은 방법으로 Google Cloud 서비스에 인증할 수 있다. Workload Identity 기본 Compute Engine 서비스 계정 Kubernetes Secrets Workload Identity Workload Identity란, GKE에서 Google Cloud 서비스에 인증하는 데 권장되는 방식이다. 이 인증 방법이 사용 사례에 적합한 경우 가장 먼저 이 옵션을 선