4.2 kubernetes, AWS, EKS

유다시티 fullstack 코스 study note입니다.

 

 

하나의 컨테이너로는 부족 - > container orchestration

There are several options for container orchestration (kubernetes is one of them)

Automatically building and testing your code when changes are made is called continuous integration.

Continuous integration combined with automated deployment is referred to as cintinuous delivery.

 

AWS’ Kubernetes service -> EKS

continuous delivery pipeline -> AWS Code pipeline

continuous integration -> AWS Codebuild

 

Scaling

-vertical scaling - increase or decrease of the resources of the machine

(not easy to change resources quickly depending on demand)

 

-horiziontal scaling - run same application across multiple machine

Orchestration platforms automate the deployment and scaling of multiple containers. (kubernetes is the popular one)

 

Kubernetes

• Cluster: A group of machines running Kubernetes

• Master: The system which controls a Kubernetes cluster. You will typically interact with the master when you communicate with a cluster. The master includes an api, scheduler, and management daemon.

• Nodes: The machines in a cluster. These can be virtual, physical, or a combination of both. each node in a cluster must have a container "runtime" such as a docker. 컨테이너를 돌릴 수 있는 다커같은 런타임.

• Pods: It is considered as the smallest unit in a cluster. It is a logical group of containers on a node that runs a deployed module/application. A pod consists of one or more containers, shared storage resources, and a unique IP address. Note that all the containers within a Pod share the namespaces and filesystem volumes. Pods are not persistent, and may be brought up and down by the master during scaling. 컨테이너의 개념으로 봐도 괜찮으며, 여러 노드에 복사될수 있다.

**로컬 컨테이너의 한계점은

1.  인커밍 트래픽의 맞추어 리소스(컨테이너 수)를 직접 조절하기 힘들다.

2. 여러 호스트에 horizontally 여러 컨테이너를 만들었다 하더라도, 앱을 추가 개발하려하면 모든 컨테이너에 코드를 복붙해야 한다.

3. 로컬컴퓨터가 여러 컨테이너를 다룰만큼 하드웨어가 좋기 힘들다.

 

Reliability of Kubernetes at Scale

In the diagram shown above, each POD runs a specific module (App A, App B, App C...) of an application. Moreover, the PODs (hence, the containers) are not attached to a specific node (host). Instead, multiple nodes are hosting similar PODs. This architecture mitigates the chances of a single point of failure, and thus provides high availability. The master system brings a layer of abstraction for the external client/application.

 

Remember, all the containers within a Pod share the namespaces and filesystem volumes. In addition, all PODs that are running the same application module share storage resources. Hence, in order to have a persistent way to store data, volumes can be attached to pods.

Whereas, in order to have a persistent way to communicate with ephemeral pods, a higher-level service abstraction is provided.

Service: An abstraction for communicating with a set of pods

In order to have a persistent way to communicate with ephemeral pods, a higher-level service abstraction is provided. Additionally, in order to have a persistent way to store data, volumes can be attached to pods.

• Service: An abstraction for communicating with a set of pods

**볼륨은 디렉토리 같은 개념으로 보면 될듯.

 

**어플리케이션에 필요한 각종 모듈 컨테이너들이 pod이라고 한다면 복붙되서 여기저기 흩어져서 지워졌다 생겼다 함으로 통합적인 커뮤니케이션을 위해서 service라는 개념이 있는 것 같다.

 

Amazon EKS

kubernetes service로서, 클러스터 생성부터 모든 것을 수행해준다.

이용자는 Nodes, Pods, and Services 를 set up 하기만 하면 된다.

 

AWS CLI

awscli는 커맨라인툴에서 aws서비스와 interact할수 있게 해준다.

python module로 이용하는 방법이 있는데, 

 

'''

pip install awscli --upgrad

'''

 

로 install 해주면 된다.

 

AWS IAM 콘솔에 들어가 유저를 생성하고, 

 

'''

aws configure --profile default 

'''

를 이용해서 cli에서 사용할 유저를 연동시킬수 있다. (콘솔에서 해당 유저 access key를 알아놔야한다.)

 

추가적으로, 해당 유저가 어떤 role을 수행할수 있는지 롤세팅을 해주어야 하는데,

롤 만들기는 두가지 절차가 필요하다.

 

1)TRUST POLICY 

해당 롤을 어떤 유저가 이용할수 있는지 등록해줘야 한다.

 

'''

{ "Version": "2012-10-17", "Statement":[{ "Effect": "Allow", "Principal": {"AWS":"arn:aws:iam::013452265158:root"}, "Action": "sts:AssumeRole" }] }

'''

 

principal 에 어떤 유저인지를 설정해줘야하고, action이나 effect가 뜻하는 바는 해당 롤을 assume하도록 allow해준다는 것.

 

자세한 내용은 강의에 있는데,

'''

aws iam create-role --role-name UdacityFlaskDeployCBKubectlRole --assume-role-policy-document file://trust.json --output text --query 'Role.Arn'

'''

 

명령어 입력시, --assume-role-policy-document 은 create-role 명령어 이용시 trust policy를 지정해주는 보조 쿼리이고, --output text --query 'Role.Arn' 경우는 명령어 입력 후에 나타나는 반응화면이 text 형식이고 해당 role의 arn을 보여주라는 의미이다. arn(amazon resource name)

 

이제 해당 롤일 수행할 수 있는 policy를 붙여줘야 하는데,

 

'''

{ "Version": "2012-10-17", "Statement":[{ "Effect": "Allow", "Action": ["eks:Describe*", "ssm:GetParameters"], "Resource":"*" }] }

'''

이런식으로 eks서비스에서 describe 관련 권한과 ssm서비스에서 parameter를 가져올수 있는 권한들을 부여할 수 있다.

 

aws cli에서는 아래와 같이 입력해줄  수 있다.

 

'''

aws iam put-role-policy --role-name UdacityFlaskDeployCBKubectlRole --policy-name eks-describe --policy-document file://iam-role-policy.json

'''

 

EKS CTL, KUBE CTL

eks ctl은 클러스터를 만들때 필요한 command line tool인데, 클러스터 creation만들기를 쉽게 해준다.

os 마다 install 하는 방식은 다르며,

eks ctl을 이용해서 클러스터를 만들때 cloudformation은 자동으로 생성된다.

 

kube ctl 은

클러스터를 만든 이후에 해당 kubernetes cluster와 interact하기 위한 command line tool이다.

이 역시 os 마다 install하는 방식이 다르다.

 

'''

eksctl create cluster --name eksctl-demo

'''

 

와 같은 명령어를 통해서 커맨드라인에서 클러스터를 생성할 수 있고,

cloud foramtion 콘솔에 가보면 해당 클러스터가 생성중인걸 확인할수있다.

 

'''

kubectl get nodes

'''

그 이후에는 kubectl을 이용해서 interact가능하다.

 

 

CODE PIPELINE, CODE BUILD

code pipeline 과 code build는 continuous integration과 continuous delivery를 위한 aws의 툴로 볼수 있다.

code pipeline은 전반적인 pipeline의 flow를 정의하고

code build는 그 pipeline에 포함되어 코드를 빌드하는 과정을 담당한다.

 

eks는 ctl에서 cluster를 위한 cloudforamtion template을 자동으로 만들지만,

code pipeline은 그렇지 않다.

 

cloudforamtion 템플릿은 해당 pipeline이 돌아가기 위해 필요한 모든 로직 및 aws 서비스들의 stack이 정의되어 있는 템플릿이라고 할 수 있다.

 

codebuild도 역시 어떤식으로 build하는지에 대한 instruction이 들어가 있는 buildspec.yml파일이 필요한데,

내용을 보면 실제로 docker image등을 생성하는 command가 들어가 있는 것을 확인해볼수 있다.

 

 

여기부터는 EKS Proejct관련 메모

Containerizing, Running locally

JWT 를 이용해서, 간단히 이메일을 코드 decode할수 있는 flask app.

(plus로 logging 기능이 있다)

 

로컬에서 돌려볼때는

export JWT_SECRET='myjwtsecret'

export LOG_LEVEL=DEBUG

로 environment variable 설정 해주고

python main.py 로 해당 파일 실행해주면 된다.

 

curl을 이용해서 app을 이용해볼것

 

docker image를 이용하는 경우에는

gunicorn 명령어를 이용해서 entry point를 만들어서 이용해 볼것.

별도 env 파일에 env variable을 넣고

컨테이너 run할 시에 관련 flag를 넣어주면 local에서도 env파일을 이용할 수 있다.

 

배포시에는 aws parameter store에 넣을것

 

Create an EKS Cluster and IAM Role

유저만들고, 롤만들고, 롤에 트러스트폴리시로 유저 붙이고, 롤에 권한 부여하고

eks 클러스터 만드는 것은 ,4.2 수업에서와 동일하다.

 

추가적으로 codebuild도 클러스터를 활용할수 있도록 권한을 부여해줘야 한다.

권한 부여 방식이 좀 다른데,

aws auth config map을 내용을 바꿔서 update 해주어야 한다.

 

Deployment to Kubernetes using CodePipeline and CodeBuild

GITHUB ACCESS TOKEN 을 generate 해야 한다.

 

CLOUD FORMATION 서비스에서 

템플릿 파일을 올려서 code pipeline을 만들수 있다.

이때에 템플릿 파일 paramter에 관련 github repo와 user아이디를 설정해주어야 하고,

콘솔에서 stack detail에 access token도 입력해주어야 한다.

 

이 때에 codebuild 콘솔에 build project 가 자동생성된다.

콘솔안에서 start build를 눌러주면 building이 시작된다.

(git repo에 buildspec파일이 꼭 있어야 한다.)

 

env 설정은 aws paramter store에 해당 variable을 저장하고

buildspec에 아래의 라인을 추가해줘야한다.

'''

env: parameter-store: JWT_SECRET: JWT_SECRET

'''

 

Adding test to build

buildspec파일에 preinstall 부분에 test file을 run하도록 할수있다.

assert False 가 발생하면 빌드가 중간에서 실패한다.