클라우드 68일차

GCP가 AWS와 다른점은

GCP의 모든 작업들은 project 내부에서 이루어진다. 그래서 project를 삭제해주기만 하면 그 안의 모든 것들이 삭제 된다.

프로젝트 이름 : 6 ~ 30 C 내에서 생성

일반적인 서비스들은 project id 기반으로 동작

프로젝트의 이름과 ID는 다를 수 있다. 편의상 둘을 동일하게 만들어주는 것이 좋다.

 

k8s 처럼 각각의 서비스를 api 로 접근하여 사용한다.

필요한 서비스의 api를 활성화하여 서비스를 이용할 수 있다.

 

필요한 서비스 몇가지

1. cloud source repositories api

GCP에서 제공하는 소스코드 관리 저장소. github 등의 외부 호스팅서비스를 연계하여 사용할 수도 있다. 커밋을 이용한 버전관리도 가능.(Dockerfile등 관리)

먼저 이 친구를 사용해보자

먼저 CI/CD, Source Repositories를 선택해서 사용해보자

 

2. GKE(Goolge Kubernetes Engine)

gcp에서 제공하는 kubernetes 클러스터 서비스

 

로컬에서 k8s를 사용하고자 한다면

서버 > k8s 관련 패키지 설치 > network를 위한 Add on 설치 > 클러스터 구성

 

GCP[GKE]/AWS[EKS] > 일종의 완전관리형 서비스로 노드의 flavor와 숫자, k8s의 버전을 선택하면 OS 설치, 클러스터 구현까지 모두 이루어진 다음 해당 서비스를 사용할 수 있게 된다.

 

3. 도커 이미지 저장소

Container Registry API

 

4. Cloud Build API

일반적으로 이미지를 작성하여 관리하고자 할 때에는 로컬에서이미지를 작성한 뒤(build) 이를 push 하여 저장소에 올려야 한다.

Cloud Build API는 코드를 이용하여 이미지작성에서 부터 저장소에 Push 하는 것 까지 한번에 해결할 수 있다.

저기에 보이는 Kubernetes Engine API를 눌러 사용해보자

 

도커 이미지 저장소

1. 로컬 저장소 -> 자신의 컴퓨터 또는 서버에 직접적으로 설치되는 저장소. 해당 컴퓨터(서버)에서만 사용할 수 있다.

 

2. 사설 저장소 -> 인증을 통해 허가된 사용자만 접근할 수 있는 저장소. 도커허브에서 사설로 지정한 저장소, gcp/aws/azure와 같은 퍼블릭 클라우드 환경에서 제공하는 사설 저장소.

제한된 공간에서 제한된 사람(노드)들만 접근할 수 있도록 구성하는 private-registry (insecure 모드로 동작시키면 보안인증등의 과정없이 실행 가능), harbor 와 같은 3rd party를 이용할 수도 있다.

 

3. 공용 저장소

docker hub에서 public으로 생성한 저장소. 누구나 push, search, pull 할 수 있다.

 

(build -> test -> deploy를 끊김없이 진행할 수 있다.)

 

---

 

```

git clone https://github.com/beomtaek78/btstore

cd btstore

cd kube

```

kube에 위와같이 3가지 폴더가 보인다. 그중에서 blue만 확인해보면

 

위와같이 보인다. python을 이용한 간단한 이미지를 만들어보자.

 

그래서 blue와 green을 이용해서 간단한 이미지를 만들어보자.

```

vi config/cloudbuild.yaml

```

반드시 kube 위치에서 이걸 봐야한다.

보면 steps에서 이미지를 만들고

iamges에서 image를 push한다.

 

```

gcloud builds submit --config config/cloudbuild.yaml

```

 

 

이게 되었다면 CI/CD의 Container Registry > 이미지로 가보면 된다.

가보면 imageview라는 폴더 안에 docker image 두개가 있는것을 볼 수 있다.

 

그래서 이런식으로 imageview:blue, imageview:green 이라는 두개의 이미지가 만들어져서 push 된 것을 확인할 수 있다.

 

2. 클러스터 구축하기

master는 지금 사용하고 있는 PC 자체라고 생각하자!

 

bastion host

 

????

망할 이부분 다 날라갔다.

 

만들어진 deployment를 외부로 배포하기 위해 만들어야 하는 것들 : lb가 대표적

인그레스도 여기에서 구성가능하다.

 

여기에서 배포도 가능하다. 물론 우리는 CLI 환경에서 배포해볼 것이다.

 

PV를 만들수도 있다.

 

configmap을 변수에 담아서 배포할 수도 있다.

여기안에 secret도 담을 수 있다.

 

secret을 이용하게 되면 password, login 정보 등을 담아서 쓸 수 있다. file을 이용해서 배포할 수 있다. key로도 가능하다.

 

지금은 구글 클라우드 환경이지 우리가 지금까지 만들고 사용하던 환경이 아니다.

 

보면 네임스페이스 중에 overlay 네트워크가 빠진것을 확인할 수 있다. 기존에는 calico, weave net, plunnel 등을 썼는데 GCP를 쓰면서 자동으로 overlay 네트워크를 만들어주고 이들이 하나의 테넌트 이기 때문에 터널링이 이미 구성이 되어 있는 상태인 것이다.

 

이제 어제자에 github에서 받았던 폴더를 가지고 와서 kube 폴더 안에서 실행해주자

```

ls config/

```

이중에 configmap.yaml 파일을 확인해보면 위와같이 작성되어 있는 것을 볼 수 있다.

 

배포해보자

projectid라는 cm이 배포되었다.

 

내용을 확인해보니 위와같이 작성되어 있다.

 

실재로 GCP CM에 projectid가 있는것을 볼 수 있다.

 

그런데 yaml 파일로 보니 내용물이 약간 다르다는 느낌이 있다.

 

이걸 ssh에서 보기 위해서는

```

k get cm projectid -o yaml

```

해주면 내용물들을 볼 수 있다.

 

그다음 secret을 봐보자

type : Opaque == noraml로 되어 있는 것을 볼 수 있다.

일반적인 key: value형태로 데이터를 저장할때 사용하게 된다.

그래서 나온 값들을 base64로 해석하면 "asa", "aBcD123" 으로 넣어놨다. 이것도 배포해보자

 

그러면 위와같이 secret key가 나오는 것을 확인할 수 있다.

 

secret은 로컬에 저장될 떄에는 암호화된 형태로 저장되나 이를 Pod에 배포할 때에는 복호화된 상태에서 보관된다.

 

이 상태에서 config/deployment-blue.yaml 파일을 확인해보면 위와같이 정보가 나오는 것을 확인할 수 있다.

 

보면 파일의 apiVersion이 잘못되어 있다.

이미지도 <PROJECT_ID> 라는 부분이 존재하는데 이거 인식을 못한다. 이거 직접 넣어주어야 한다.

apiVersion과 image 부분을 수정해주고 다시 배포해보자

이번에는 selector가 빠지었다고 뜬다.

 

보니까 확실히 matchLabels까지 포함된 부분이 없다. 이걸 수정하고 배포해보자

그리고 green도 배포해주자

 

배포가 완료되었다.

 

그리고 gcp의 kubernetes engine에서 작업 부하 란에서도 이미지들이 배포된 것을 확인해볼 수 있다.

config/service.yaml 도 함께 배포해버리자

 

그리고 서비스 및 수신쪽에서도 네트워크가 배포된것을 확인해볼 수 있다.

 

 

실재로 ip를 타고 가보니 위와같은 사이트가 열리는 것을 볼 수 있다.

참고로 이미 프로젝트 지워서 ip를 입력해도 들어가지지 않는다.

 

정보를 봐보자

포트 부분에 대상 포트는 이 포드들이 어떤 포트에서 서비스를 하는지,

노드 포트는 각각의 노드에서 어떤 포트로 클러스터로 넘기는지

포트는 서비스의 포트이다.

 

으로 바꾸고 저장해보자

그러면 리소스가 업데이트되었다고 뜰것이다. 실재로 확인해보자

 

```

k describe svc webserver

```

이라고 하면 실재로 Selector가 변경된 것을 확인할 수 있다.

 

도메인 : cloudpia.site

sub domain : 

gildong = 30.1.5.4

로 되어 있다면 사이트를 연계해줄 수 있다.

 

그래서 가비아에 가서 도메인을 하나 사고 거기에 우리의 ip를 연계해주면 된다.

 

quiz.

현재 test.cloudpia.site 로 접속하면 미리 지정해 두었던 페이지로 접속된다. -> blue 또는 green

nginx를 deploy로 배포하고 외부에서 test.cloudpia.site/nginx로 접속했을 때 해당 deploy의 포드로 접속되도록 ingress를 구축하라!

 

서비스의 품질을 향상 시키기 위한 다양한 방법들...

1. QoS(Quality of Service) : 서버로의 접속에 대하여 혼잡이 발생한 경우 이를 각각의 중요도에 따라 분류하고 중요데이터를 먼저 처리하도록 할 수 있는 방법.

QoS가 필요한이유는 접속자는 많은데 실재로 처리할 수 있는 대역폭(bandwidth), 처리량(throughput)이 낮은 경우. 처리량은 1초에 처리하는 양이기 때문에 디바이스 자체의 성능이라고 생각. 대역폭은 케이블이다. 케이블에서 제공하는 동시에 얼마만큼이 지나갈 수 있는가를 이야기 한다. 

IP의 특징은 Best Effort이기에 안전하게 도착하는 것에대해서 보장해주지 않는다. 그래서 대역폭이 너무 작으면 패킷 drop이 발생할 수 있다.

또 패킷을 상대에게 보내는 과정에서 패킷간 보내는 속도 차이로 인하여 jitter가 발생할 수도 있다. 이럴때는 중요 데이터와 아닌 것을 구분해서 중요한 데이터가 먼저 라우터에서 처리될 수 있도록 하는 것이다. 그러면 queue안에 패킷이 담기게 된다. 이때의 알고리즘에 따라서 queueing 방식이 달라지게 된다.

일반적인 LAN 구간에서는 FIFO(First In First Out) 방식을 사용한다. 먼저들어온 얘가 먼저 나가는 방식이다. 그런데 이렇게 하면 데이터 양이 많아졌을때 중요데이터가 처리되지 않는 문제가 생길 수 있다. 그래서 큐에 따라 중요도를 나누고 패킷을 분산처리하는 것이다.

1) 큐에 넣을때에도 ACL(Access Control List)로 지나가도 되는 패킷과 아닌 패킷을 구분해준다.

2) 허용이 된 친구들에 대해서 주소를 바꿀지 허용을 할지를 결정하게 된다. NAT를 거치게 된다.

3) 라우팅 테이블에 의해서 어떤 포트로 보낼지를 결정하게 된다. 그리고 output queue에 담게 된다.

 

큐잉기법을 사용하게 되면 중요데이터를 먼저 처리하게 된다.

 

2. Ingress

회사의 서버에서 제공되는 컨텐츠를 종류에 따라 구분하고 동영상, 사진 등의 서비스는 많은 리소스가 필요하므로 이를 별도로 처리할 수 있는 포드를 배포하여 다른 서비스에 영향을 미치지 않으면서도 컨텐츠를 빠르게 처리할 수 있는 방법

 

3. scaling

서버의 성능 문제로 인하여 빠른 응답이 어려운 경우 해당 서버를 scale out 또는 scale up을 통해 리소스 문제를 해결하고 빠른 처리가 가능하도록 할 수 있다. 클라우드 환경에서는 이를 자동화하여 auto scaling을 적용할 수 있다.

 

4. CDN(콘텐츠 전송 네트워크 - aws : cloudfront)

CDN은 웹 페이지, 이미지, 비디오 등의 콘텐츠를 사용자의 물리적 위치와 가까운 프록시 서버에 캐싱합니다. 이렇게 하면 콘텐츠가 로딩될 때까지 기다릴 필요 없이 영화 감상, 소프트웨어 다운로드등의 작업을 할 수 있다.

 

최근에는 스마트폰을 이용한 다양한 컨텐츠 서비스가 제공되고 있다. 이동중에 해당 서비스를 안정적으로 제공받기 위해서는 CDN 서비스를 구축해 두어야 한다.

 

위와같이 보다 가까운 쪽에서 서비스를 받을 수 있다.

이중화를 통해서 안전성을 도모할 수도 있다.

 

cronjob은 k8s에서 제공하는 오브젝트로 linux의 cron과 유사하다. 주 목적은 반복적인 작업을 내부적으로 동작하도록 하고 싶을 때 동작시키지만 cron은 시스템에 적용하여 영구적으로 사용할 수 있으나 cronjob은 포드와 같은 형태로 동작 시키는 휘발성 특징을 가지고 있다.

 

주로 백업, 모니터링과 같은 작업에 사용된다.

이와 비슷하게 이를 yaml 파일로 구현할 수 있다.

 

```

k apply -f config/cronjob.yaml

k get cj -w #cronjob을 watch 모니터링 하겠다.

```

위와 같이 crontab이 뜨고 있는 것을 확인할 수 있다.

 

 

 

---

 

aws eks

 

먼저 컴퓨터를 재시작해서 swap 메모리를 사용할 수 있도록 만들어주자

```

vi /etc/fstab

```

이렇게 한다음 컴퓨터를 재시작해야한다.

 

aws에서는 로컬 PC를 aws와 연결하기 위해서 aws의 IAM 서비스를 통해 관리자 계정정보를 불러와야 한다.

aws 전체를 관리할 수 있는 bastion host가 존재하는데 여기에 IAM 계정이 존재하는 것이다. 이걸 이용해서 aws의 모든 서비스를 사용할 수 있게 된다.

 

aws에 접속해서 security credentials로 들어와보자

 

여기에서 Access keys를 만들어보자

여기에서 show access key를 누르거나 Download key file을 받아서 나의 key와 secret key를 받을 수 있다.

 

이 상태에서 aws를 컨트롤하기 위해 aws cli를 설치하자

```

apt-get install -y awscli

aws 탭탭

```

하고 aws 명령을 쓸 수 있다면 성공이다.

```

aws configure

```

우리의 계정정보를 입력해주자

 

```

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

sudo mv /tmp/eksctl /usr/local/bin

eksctl version

```

위와같이 뜨면 eksctl 설치 성공이다.

 

이제 우리 VPC로 가보자

이중에 우리의 서브넷으로 들어가보자

 

 

서브넷 중에서 기본 서브넷 예로 되어 있는 것을 모두 복사해오자 이 서브넷들에 eskctl를 실행시킬것이다.

 

eksctl	create	cluster	\
--vpc-public-subnets	subnet-0aa043265c1d3416e,subnet-06fa0716c7a32ba53,subnet-02cdeb9013b0373ea	\
--name	eks-work-cluster	\
--region	ap-northeast-1	\
--version	1.19	\  #	EKS	클러스터	버전
--nodegroup-name	eks-work-nodegroup	\  #	노드	그룹이름
--node-type	t2.small	\  #	워커	노드	인스턴스	타입
--nodes	2	\  #	워커	노드	수
--nodes-min	2	\  #	워커	노드	최소	수
--nodes-max	5  #	워커	노드	최대	수

eksctl create cluster \
--vpc-public-subnets subnet-0aa043265c1d3416e,subnet-06fa0716c7a32ba53,subnet-02cdeb9013b0373ea \
--name eks-tonyhan-cluster \
--region ap-northeast-1 \
--version 1.19 \
--nodegroup-name eks-work-nodegroup \
--node-type t2.small \
--nodes 2 \
--nodes-min 2 \
--nodes-max 5

이렇게하면 

이런식으로 deploying stack 이 뜨면서 yaml 파일이 자동으로 만들어진다.