[Cloud Study Jam] Architecting with Google Kubernetes Engine: Foundations

Cloud Computing and Google Cloud

GKE

 

Resource Management

프로젝트가 GCP의 기본 단위

고유한 프로젝트 ID, 번호는 고정됨

폴더안에 프로젝트가 존재함.

 

IAM으로 관리되는 부분을 다르게 관리가능

 

구글은 다양한 부분의 보안을 제공한다.

 

 

Billing

3 가지 도구로 비용 청구 실 수를 막을 수 있다.

 

스크립트

웹 후크

BigQuery로 데이터를 받을 수 있다.

 

rate quotas : 특정 시간 후에 속도 할당량이 재설정

GKE에 1000의 할당량을 주면 100초마다 구글 클라우드 프로젝트로 각각의 API로 호출된다. 100초 후 할당량 재할당

 

allocation quotas

내가 가질 수 있는 자원을 관리한다. 특정 간격으로 재설정되지는 않는다. 대신 기존에 있던 것을 해제해야한다. 각각의 프로젝트는 5 개 이상의 개인 cloud network 를 허용하지 않는다.

 

 

Interacting with Google Cloud

참고로 이건 비용이 청구되지 않는다

 

웹 기반 인터페이스, 바닦에는 웹 쉘이 존재한다.

Computing Options

Getting Started with Google Cloud Platform and Qwiklabs

 

 

Introduction to Containers

 

Containers and Container Images

FROM : public repo에서 이미지 가져옴

copy : 파일 일부 복사

run : 결과를 게시

CMD : 내부에서 실행될 명령어

 

 

Introduction to Kubernetes

 

Introduction to Google Kubernetes Engine

 

Compute Options Detail

 

---

 

Kubernetes Concepts

kubernetes object

principle of declarative management

 

 

The Kubernetes Control Plane

Google Kubernetes Engine Concepts

 

 

Kubernetes Object Management

 

 

A note about Services

Services provide load-balanced access to specified Pods. There are three primary types of Services:

• ClusterIP: Exposes the service on an IP address that is only accessible from within this cluster. This is the default type.
• NodePort: Exposes the service on the IP address of each node in the cluster, at a specific port number.
• LoadBalancer: Exposes the service externally, using a load balancing service provided by a cloud provider.

In Google Kubernetes Engine, LoadBalancers give you access to a regional Network Load Balancing configuration by default. To get access to a global HTTP(S) Load Balancing configuration, you can use an Ingress object.

You will learn more about Services and Ingress objects in a later module in this learning path.

 

Controller objects to know about

This reading explains the relationship among several Kubernetes controller objects:

• ReplicaSets
• Deployments
• Replication Controllers
• StatefulSets
• DaemonSets
• Jobs

A ReplicaSet controller ensures that a population of Pods, all identical to one another, are running at the same time. Deployments let you do declarative updates to ReplicaSets and Pods. In fact, Deployments manage their own ReplicaSets to achieve the declarative goals you prescribe, so you will most commonly work with Deployment objects.

Deployments let you create, update, roll back, and scale Pods, using ReplicaSets as needed to do so. For example, when you perform a rolling upgrade of a Deployment, the Deployment object creates a second ReplicaSet, and then increases the number of Pods in the new ReplicaSet as it decreases the number of Pods in its original ReplicaSet.

Replication Controllers perform a similar role to the combination of ReplicaSets and Deployments, but their use is no longer recommended. Because Deployments provide a helpful "front end" to ReplicaSets, this training course chiefly focuses on Deployments.

If you need to deploy applications that maintain local state, StatefulSet is a better option. A StatefulSet is similar to a Deployment in that the Pods use the same container spec. The Pods created through Deployment are not given persistent identities, however; by contrast, Pods created using StatefulSet have unique persistent identities with stable network identity and persistent disk storage.

If you need to run certain Pods on all the nodes within the cluster or on a selection of nodes, use DaemonSet. DaemonSet ensures that a specific Pod is always running on all or some subset of the nodes. If new nodes are added, DaemonSet will automatically set up Pods in those nodes with the required specification. The word "daemon" is a computer science term meaning a non-interactive process that provides useful services to other processes. A Kubernetes cluster might use a DaemonSet to ensure that a logging agent like fluentd is running on all nodes in the cluster.

The Job controller creates one or more Pods required to run a task. When the task is completed, Job will then terminate all those Pods. A related controller is CronJob, which runs Pods on a time-based schedule.

Later modules in this learning path will cover these controllers in more depth.

 

 

Migrate for Anthos Introduction

 

 

Migrate for Anthos Architecture

 

Migration Path

 

Migrate for Anthos Installation