Coursera Week6 (Managing)

Compute Engine Resources

public Images : 유지 & 제공 by Google, openSource communities, third-party vendors. 일반적으로 No additional cost, 프리미엄 image 는 요금 붙음.
Custom images : only my project. image를 import하는데는 돈이 들지 않지만, keep or image storage 에는 돈 듬.
✨ Creating Custom Images
1) A persistent disk
2) A snapshot of a persistent dist
3) Another image in your project
4) An image that is shared from another project
5) A compressed RAW image in Google Cloud Storage

*GCP에서는 머신이미지, 이미지, 스냅샷을 통해 백업을 할 수 있음.
-Snapshot(기억장치) : incremental(증분) 가능

Kubernetes Engine Resources

$ kubectl get pods
$ kubectl expose de
Our next section deals at managing Kubernetes Engine resources. In particular, we'll look a bit more closely at how to deploy and work with Kubernetes pods. A deployment represents a group of replicas of the same pod and keeps your pods running, even when nodes they run on fail. You could represent a component of an application or an entire App. In this case, the engine acts web server by default pods and deployment are only accessible inside your GKE cluster. To make them publicly available, you can connect a load balancer to your deployment by running the Cube CTL exposed command. Kubernetes then creates a service with a fixed type key for your pods, and the controller says, I need to attach an external load balancer with a public IP address chat service, so others outside the cluster can access it. In GKE, the load balancer is created as a network load balancer. Instead of issuing commands, you can provide a configuration file that tells Kubernetes what do you want your desired state to look like, and Kubernetes figures out how to do it. To get the file, you can run a Cube CTL get pods command as shown here to get a YAML file. In this case, the YAML file declares that you want three replicas of your engine next pod. It also defines a selector field, so the deployment knows how to group specific pods' replicas, and you could add a label to the pod templates, so they get selected. To run five replicas instead of three, all you do is update the deployment conflict file, and then run the Cube CTL apply command to use the updated config file.

용어

A. CLUSTER

GKE의 기초이며, 제어영억, 노드로 구성되어있음.
1) 노드 : 클러스트는 일반적으로 하나 이상의 노드 가짐. 실행하는 작업자 머신. GKE가 생성하는 VM머신
2) 제어영역 : Kubernetes API 서버, 스케줄러, 코어 리소스 컨트롤러 등등 관리

B. Pod

kubernetes에서 가장 작고 기본적인 배포 가능 객체
하나 이상의 컨테이너 포함 ( 여러 컨테이너도 가능)
네트워크 : 포드에 고유 IP 할당
storage : 컨테이너 간 공유될 수 있는 공유 저장공간 볼륨 집합

GKE가 제공하는 것
1) Compute Engine instances에 대한 Load Balacing
2) Node Pools로 cluster안에 하위 subsets of nodes 제공 for additional flexibility.
3) Automatic scaling of your cluster's node instance 개수.
4) Automatic upgrades for your cluster's node software.
수동 업그레이드하면 자동 업그레이드보다 더 최신을 가질 수도 있다. 일반적으로 베타 or 공개버전인 것을 GKE 포함. 알파 버전은 GKE알파클러스터에서 사용한다.
5) Node auto-repair to maintain node health and availability.
6) Cloud Logging and Monitoring for visibility into your cluster.

작업 모드

Autopilot : 전체 클러스터 및 노드 인프라 자동관리 => 사용자들이 워크로드(도커가 올라가는 컨테이너식 APP)에 집중할 수 있도록(비용지불은 됨).
표준 : 전체 제어 권한 제어

# GCLOUD 계정 정보
gcloud auth list

# GCLOUD 프로젝트 정보
gcloud config list project

# 지역정보 셋팅
gcloud config set compute/zone us-central1-a

# Cluster 생성
gcloud container clusters create my-cluster

# 생성한 Cluster 권한 얻기
gcloud container clusters get-credentials my-cluster

# hello container 생성
kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

# port 열기
kubectl expose deployment hello-server --type="LoadBalancer" --port 8080
>> Load Balacer를 설정하고 외부 IP 설정해줌

# YAML에 어떤 pod를 배포하고 싶은지 설정해서 실행. ( template - 갯수를 다르게 함으로써 쉽게 크기 조절 가능)
kubectl get pods -l "app=nginx"
kubectl apply -f nginx-deployment.yaml

# kubernetes로 실행
kubectl get service hello-server

# delete cluster
gcloud container clusters delete [CLUSTER-NAME]

App Engine

App Engine은 확장 가능한 웹 애플리케이션을 개발하고 호스팅하기 위한 완전 관리형 서버리스 플랫폼
Scaling :
1) manual : use resident instances, 계속 런 하는 특정 갯수의 instances. low-level과 무관하다. 복잡한 초기설정, 메모리에 의존적
2) basic : dynamic instances. 가장 기본적. idle상태일 때 멈춤.
3) automatic : dynamic instances, 최소 instaces를 정해둘 수 있다.

Data Solutions

1) Object lifecycle management
Our next section deals with choosing the best options for managing your solution's data. In particular, we'll look at storage type options for managing cloud storage buckets.
You can assign a life cycle management configuration to a bucket. The configuration contains a set of rules which apply to current and future objects in the bucket.
When an object meets the criteria of one of the rules, cloud storage automatically performs its specified action on the object. Here are some example use cases. Downgrade the storage class of objects older than 365 days to cold line storage. Delete objects created before January 1, 2013. Keep only the three most recent versions of each object in a bucket with versioning enabled.

The following actions are supported for lifecycle, delete, delete live and/or archived objects. This action can be applied to both versioned and non-versioned objects. In a bucket with versioning enabled, deleting a live object archives the object, or deleting an archived object believes object permanently.

SetStorageClass, change the storage class of live and/or archived objects. This action can be applied to both versioned and non-versioned objects. The following conditions are supported for a lifecycle rule. Age, this condition is satisfied when an object reaches a specified age in days. CreatedBefore, this condition is satisfied when an object is created before midnight, the specified date and UTC is live. If the value is true, this life cycle conditions matches only live objects. If the value is false it matches only archive objects. MatchesStorageClass, this condition is satisfied when an object in the bucket is stored as a specified storage class. NumberOfNewerVersions, relevant only for versioned objects. If the value of this condition is set to n, an object satisfies the condition when there are at least n versions, including the live versions newer than n. For live objects, the number of newer versions is considered to be zero.