반응형

Google Associate Cloud Engineer Exam Dumps 2019

Udemy 에 있는 Dump 풀면서 적은 오답노트들..

 

## failover replica

Failover replica helps provides High Availability for Cloud SQL. The failover replica must be in the same region as the primary instance.

 

 ## Cloud Datastore

 A scalable, fully managed NoSQL document database for your web and mobile applications. Semistructured application dataHierarchical dataDurable key-value dataUser profilesProduct catalogsGame state.

Bigtable is not an ideal storage option for state management.

 

## BigQuery

BigQuery is a good storage option with analysis capability. Also, the access to the data can be controlled using ACLs and Views. BigQuery uses access control lists (ACLs) to manage permissions on projects and datasets

Cloud Storage is a good storage option but does not provide direct analytics capabilities.

 

 ## HTTP load Balancer

HTTP load balancer support global access. HTTP(S) load balancing can balance HTTP and HTTPS traffic across multiple backend instances, across multiple regions. Your entire app is available via a single global IP address, resulting in a simplified DNS setup. HTTP(S) load balancing is scalable, fault-tolerant, requires no pre-warming, and enables content-based load balancing. For HTTPS traffic, it provides SSL termination and load balancing.

 

 ## Big Table

Cloud Bigtable is the most performant storage option to work with IoT and time-series data. Google Cloud Bigtable is a fast, fully managed, highly-scalable NoSQL database service. It is designed for the collection and retention of data from 1TB to hundreds of PB.

 

## Testing application

Google Compute Engine managed instance group can help the testing application to scale to reduce the amount of time to run tests.

 

## Cloud SQL
Failover replica must be in the same region.

## App Engine Standard, Flexible
The App Engine Standard Environment provides rapid scaling as compared to App Engine Flexible Environment and is ideal for applications requiring quick start times and handle sudden and extreme spikes.

 

Feature - SSH-debugging

Standard environment - No

Flexible environment - Yes


## App Engine Deployer
App Engine Deployer gives write access only to create a new version.

## roles/storage.objectCreator
allows users to create objects. Does not give permission to view, delete, or overwrite objects.

 

## Instance Group auto-healing

performs a health check and if the application is not responding the instance is automatically recreated

 

## Kubernetes Cluster auto-repairing

as the resiliency and high availability can be increased using the node auto-repair feature, which would allow Kubernetes engine to replace unhealthy nodes.

 

## gsutil options

Multi-threaded/processed: Useful when transferring large number of files.

Parallel composite uploads: Splits large files, transfers chunks in parallel, and composes at destination.

Retry: Applies to transient network failures and HTTP/429 and 5xx error codes.

Resumability: Resumes the transfer after an error.

 

## command

gcloud compute instances create "preempt" --preemptible --no-boot-disk-auto-delete 

gcloud container clusters resize --num-nodes= --size=

gcloud container clusters update --min-nodes=

gcloud deployment-manager deployments update

kubectl set image deployment nginx nginx=nginx:1.9.1]

gcloud app deploy --project 

 

728x90
반응형
반응형

Kubernetes를 사용하면서 자주 사용하는게 kubectl 명령어 이다. 그리고 그중에서 컨테이너를 생성할때 항상 kubectl create 명령어를 사용했다. 그런데 사용하다보니 어떤 글에는 create 를 사용하고 어디에서는 apply 를 사용하는 것을 보게 되었다. 그래서 이 차이점이 궁금해서 이렇게 정리하게 되었다. 


아래 내용들은 kubernetes document 에서 요약한 내용들이다. 

https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview/



Kubernetes 에서 Object Management 에는 3가지가 있다. 


Management technique

Operates on

Recommended environment 

Supported writers 

 Imperative commands

 Live objects 

 Development 

 1+ 

 Imperative object configuration

 Individual files  

 Production 

 1 

 Declarative object configuration

 Directories of files 

 Production 

 1+ 



Imperative Commands


장점

- 클러스터에 특정 오브젝트를 한번에 실행하거나 시작할수 있는 가장 쉬운 방법이다. (실제 이미지 바로 실행 시킨다. )


단점

- 기존 설정에 대한 히스토리를 제공하지 않는다. (그래서 위에 권장 환경이 Development 인것 같다.)

- 변경사항이나 audit 내역, 템플릿등을 제공하지 않는다. 


ex)

kubectl run nginx --image nginx



Imperative object configuration


- 최소한 1개 이상의 YAML 이나 JSON 포맷의 파일을 이용해서 Object 를 생성한다. 


ex)

kubectl create -f nginx.yaml

Imperative object configuration vs Imperative Commands

장점

- 설정파일 내용을 Git 같은 곳에 저장이 가능하기 때문에 설정에 대한 변경 히스토리가 확인 가능하다. 

- 새로운 Object를 생성하기 위한 템플릿을 제공한다. 

단점

- YAML 파일 작성이 필요하며 템플릿 사용을 위해 Object schema 에 대해서 이해가 필요하다.


Imperative object configuration vs Declarative object configuration 

장점
- 더 간단하고 이해하기 쉽다.

단점

- 파일로 적용할때에만 동작한다. 디렉토리는 불가능.

- 실행중인 object 를 update 하기 위해서는 설정파일에 반영을 해야 한다. 



Declarative object configuration

- 모든 설정 파일들은 디렉토리 안에 들어있고 오브젝트를 생성하거나 패치 한다.


ex)

kubectl apply -f configs/


Declarative object configuration vs Imperative object configuration

장점

- 실행중인 오브젝트 직접 적용한 변경사항을 설정파일에 merge 하지 않더라도 유지된다.(???)


단점

- 디버깅 하기 어렵고 예상한 결과가 아닐 경우 이해하기 어렵다.

- diffs 를 사용한 부분 업데이트는 복잡한 병합과 패치를 만들게 된다.


Imperative commands 나  Imperative object configuration 는 이해가 되는데  Declarative object configuration 은 약간 이해가 안된다. 


https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/


여기 있는 샘플을 가지고 확인해보자.


sample_deployment.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
cs



Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
kind: Deployment
metadata:
  annotations:
    # ...
    # This is the json representation of simple_deployment.yaml
    # It was written by kubectl apply when the object was created
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  # ...
  minReadySeconds: 5
cs


kubectl.kubernetes.io/last-applied-configuration 어노테이션에 보면 sample_deployment.yaml  에 적용한 내용들이 나와있다. 


다시 아래와 같이 명령어를 실행해보고 확인해보자.


kubectl scale deployment/nginx-deployment --replicas=2

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # note that the annotation does not contain replicas
    # because it was not updated through apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  replicas: 2 # written by scale
  # ...
  minReadySeconds: 5
cs


이 경우에는 apply를 하지 않았기 때문에 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함되지 않았다.


sample_deployment.yaml 파일을 수정해보자. 


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11.9 # update the image
        ports:
        - containerPort: 80
cs


nginx image 버전이 1.7.9 에서 1.11.9 로 변경 되었다.


Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # The annotation contains the updated image to nginx 1.11.9,
    # but does not contain the updated replicas to 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
    # ...
spec:
  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
  # minReadySeconds cleared by `kubectl apply`
  # ...
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.9 # Set by `kubectl apply`
cs


확인을 해보면 apply 로 적용한 nginx 버전은 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함 되어있다. 하지만 replicas 는 포함되지 않았다.


Warning: Mixing kubectl apply with the imperative object configuration commands create and replace is not supported. This is because create and replace do not retain the kubectl.kubernetes.io/last-applied-configuration that kubectl apply uses to compute updates


그리고 위와 같은 주의 사항도 있다. apply 는 create 나 replace 를 지원하지 않는다는 거다. 이유는 create 나 replace 는 kubectl.kubernetes.io/last-applied-configuration 어노테이션을 유지 하지 않기 때문이라고 한다. 



apply 와 create 의 차이점을 찾아보다가 여기까지 오게 되었다. 결과적으로 가장 큰 차이점은 apply 를 할 경우에는 기존 설정에 대한 정보를 가지고 있다는 점인것 같다. 


apply 이외에도 다른 명령어들이 있지만 우선은 이것만 이해하는걸로 하자.





728x90
반응형
반응형

현재 AWS  EC2 에 올라가 있는 ubuntu 에 kubernetes를 설치해 보았다. 

그런데 설치를 하다보니 프리티어로 받은 t2.micro 가지고는 너무 성능이 느렸다. 거의 접속도 못할 지경에 이르렀다. 그래서 어차피 설치하고 지울거니깐 t2.large로 올렸다.


설치 전에 Docker 가 먼저 설치 되어 있어야 한다.

(Docker 가 설치 안되어 있다면 https://docs.docker.com/install/linux/docker-ce/ubuntu/#set-up-the-repository 여기 참고하거나 아래 링크 에도 내용은 나와있다.)


https://kubernetes.io/docs/setup/independent/install-kubeadm/


여기에 들어가보면 친절하게 설치 하는 방법을 찾을 수 있다.

내용을 살펴보면 Docker 설치도 포함하고 있어서 Docker 가 설치되어 있지 않다면 그대로 따라 하면 된다.


그리고 나는 Ubuntu 에 설치를 하니 아래와 같이 명령어를 실행 했다. 혹시 명령어 실행중 permission 에러가 나면 sudo 붙이고 실행 하면 된다.

apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

이렇게 하면 kubelet, kubeadm, kubectl 이 설치가 된다.


https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/


그 다음 스텝으로 위 링크로 들어가서 클러스터를 생성 하면 된다.


여기 나와 있는 내용중에 보면 사양이 나와있다. 

  • One or more machines running a deb/rpm-compatible OS, for example Ubuntu or CentOS
  • 2 GB or more of RAM per machine. Any less leaves little room for your apps.
  • 2 CPUs or more on the master
  • Full network connectivity among all machines in the cluster. A public or private network is fine.

최소 사양이다. 이러니 t2.micro 로는 역부족이었다.

kubeadm init <args> 

이렇게 명령어를 날리면 뭔가 내용이 올라오면서 설치가 된다. args는 다양하게 있으나 나는 우선 필요가 없어서 안 넣었다. 설치가 완료되면 아래와 같은 내용들이 나온다. (ip랑 port, 토큰 부분은 ㅌㅌㅌ로 처리했다.)


Your Kubernetes master has initialized successfully!


To start using your cluster, you need to run the following as a regular user:


  mkdir -p $HOME/.kube

  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

  sudo chown $(id -u):$(id -g) $HOME/.kube/config


You should now deploy a pod network to the cluster.

Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:

  https://kubernetes.io/docs/concepts/cluster-administration/addons/


You can now join any number of machines by running the following on each node

as root:


  kubeadm join <ip>:<port> --token ㅌㅌㅌㅌㅌㅌㅌㅌ --discovery-token-ca-cert-hash sha256:ㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌㅌ


잘 읽어보면 cluster 시작하려면 .kube에 config 파일을 만들라는 내용이 있다. 아주 편리하게 저 내용을 그대로 복사해서 붙여넣으면 된다. 그리고 아래 join에 나오는 내용은 잘 복사해서 저장해두자.


이렇게 하고 "kubectl get pods --all-namespaces" 라고 치면 아래와 비슷하게 나온다. 


NAMESPACE     NAME                                       READY     STATUS    RESTARTS   AGE

kube-system   coredns-78fcdf6894-86s7n                   0/1       Pending   0          7m

kube-system   coredns-78fcdf6894-ngk7x                   0/1       Pending   0          7m

kube-system   etcd-ip-172-31-22-134                      1/1       Running   0          7m

kube-system   kube-apiserver-ip-172-31-22-134            1/1       Running   0          7m

kube-system   kube-controller-manager-ip-172-31-22-134   1/1       Running   0          6m

kube-system   kube-proxy-46x54                           1/1       Running   0          7m

kube-system   kube-scheduler-ip-172-31-22-134            1/1       Running   0          6m


그리고 위에도 써있듯이 cluster에 network를 배포해야 한다. 

위 링크(https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network 또는 https://kubernetes.io/docs/concepts/cluster-administration/addons/) 따라가보면 종류별로 방법이 있다. 설치하고 나서 다음과 같이 확인 해보면 된다.


 kubectl get nodes

NAME               STATUS    ROLES     AGE       VERSION

ip-111-11-11-111   Ready     master    32m       v1.11.2


아직 node 를 추가 못해봤는데 다음에는 node 도 따로 추가해봐야겠다.


728x90
반응형

+ Recent posts