CI/CD 파이프라인 구축하기 - 5.1 (파이프라인 구축 전 kubectl, eksctl 설정 및 yaml 파일 작성하기)

아래 포스팅에서 이어집니다!

https://wooinge.tistory.com/144

CI/CD 파이프라인 구축하기 - 4.2 (Ansible Playbook을 이용한 Docker 컨테이너 배포)

 

---

---

현재 구축한 CI/CD 파이프라인의 모습은 아래와 같다.

만약에 도커에 장애가 생겨 컨테이너가 고장나버리면 어떻게 될까?

도커는 아쉽게도 컨테이너가 죽었을 때 다시 살려내는 방법이 존재하지 않는다.

그렇게 되면 결국 사용자들이 서비스를 이용하지 못하는 상황이 발생하게 된다.

 

 

도커 장애 시 복구 방법 존재하지 않음

 

 

이렇게 도커만을 이용해서 애플리케이션을 배포하는 것은 장애 관련해서 상당한 위험이 존재하기 때문에 우리는 도커가 아닌 Kubernetes를 이용해 컨테이너를 배포할 것이다.

CI/CD 파이프라인 구성

 

쿠버네티스는 컨테이너 오케스트레이션 기술로, 여러 개의 컨테이너를 효과적으로 관리하고 자동화하는 기술을 제공하는 서비스이다. 

오케스트레이션에 대해서 조금 더 자세히 알고 싶다면 아래의 글을 참고해주세요!

https://wooinge.tistory.com/63

쿠버네티스 개요 - 컨테이너와 오케스트레이션

 

쿠버네티스를 이용한 배포를 위해 EKS를 사용할 것이다.

파이프라인을 구축하기 전에 사전에 해줘야 할 설정을 이 포스팅에서 해보려고 한다.

 

1. EKS 서버 구축하기

 

[EKS 사용을 위해 해줘야 할 사전 작업]

• AWS-CLI 최신 버전 업데이트
• kubectl 설치
• eksctl 설치
• IAM 역할 생성 및 부여

가장 먼저 eks 사용을 위한 EC2 인스턴스를 생성하고 AWS-CLI와 kubectl/eksctl 설치 따로 해줘야 한다.

아래의 문서를 참고하여 진행하면 된다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/install-awscli.html

AWS CLI 설정 - Amazon EKS

 

 

[EC2 Instance 생성]

• 이름: eks-bootstrap-server
• AMI: Amazon Linux 2
• 인스턴스 유형: t2.micro
• 기존 키페어 연결: devops-project-key
• 기존 보안 그룹 설정: devops-sg

인스턴스 생성 완료

 

MobaXTerm을 이용하여 터미널에 접속한다.

터미널 접속 완료

 

아마존의 버전을 확인해보면 현재 버전이 1로 되어있다.

이를 최신 버전으로 업데이트해줘야 한다.

aws-cli version 1

 

 

참고 문서

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Installing or updating to the latest version of the AWS CLI - AWS Command Line Interface

 

아래의 명령어를 복사한 뒤 터미널에 입력해준다.

 

다운로드 모두 진행 후에도 1로 떠있는데, 당황하지말고 exit 명령어를 사용하여 다시 루트 계정으로 로그인 해본다.

다시 로그인하면 버전이 2로 바뀌어있는 것을 확인할 수 있다.

변경되지 않은 버전,,.,

 

재로그인 후 버전 변경 확인

 

다음은  kubectl 설치이다.

 

1.29 버전을 사용하려고 한다.

 

다운로드를 받으면 현재 파일의 권한이 644로 설정되어 있는데, 실행 권한을 줘야지 사용할 수 있게된다.

 

하지만 바로 사용할 수는 없다.

로컬에서 설치한 실행 파일은 /usr/local/bin 디렉토리에 담겨져 있어야 하기 때문이다.

파일을 옮겨준 뒤 kubectl 명령어를 사용해보면 정상적으로 작동하는 것을 확인할 수 있다.

 

eksctl도 아래의 코드를 이용해서 똑같이 진행해주면 된다.

curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo mv /tmp/eksctl /usr/local/bin

 

 

마지막으로 eks-bootstrap-server에게 부여해줄 역할을 생성한다.

 

 

우선은,,, 원활한 실습을 위해 모두 full access 권한을 준다,,, 

 

EC2 인스턴스에게 방금 만든 eks-role을 부여한다.

 

 

이제  eks를 사용할 수 있는 모든 준비가 끝났다.

 

 

2. EKS 클러스터 생성

아래의 명령어를 이용해서 eks 클러스터를 생성할 수 있다.

클러스터의 이름, 리전, 노드 사양을 작성한다.

eksctl create cluster --name hyun \
--region ap-northeast-2 \
--node-type t2.small

 

이 작업은 거의 20분 정도 걸린다고 한다... ,,,,

 

생성 터미널을 보니 CloudFormation에서 무슨 일이 일어나고 있는 것 같았다.

 

열심히 만들어지는 동안 aws 콘솔에 들어와 Cloudformation을 확인해보면 열심히 클러스터가 만들어지는 것을 확인할 수 있다.

생성중...

생성 완료

클러스터와 노드 그룹이 생성되었다.

생성 완료

 

ec2 인스턴스 대시보드에서도 추가된 노드를 확인할 수 있다.

터미널에서 kubectl get nodes 명령을 이용하여 확인할 수도 있다.

최소/최대 노드 수를 설정하지 않았기 때문에 기본 개수인 2개가 생성된 것이다.

생성된 노드 확인 명령

 

ec2 인스턴스 목록

 

 

cat /root/.kube/config을 살펴보면 클러스터 정보를 확인할 수 있다.

certificate-authority-data: 클러스터 인증을 위해 사용됨

server: 마스터 노드로 사용

클러스터 정보 조회

 

 

클러스터 삭제 명령은 다음과 같다.

eksctl delete cluster hyun --regin ap-northeast-2

 

테스트를 위해 httpd 이미지 기반 pod를 생성할 것이다.

kubectl run webapp --image=httpd

생성 완료

 

--image 옵션에는 도커 허브 이미지 이름이나 레포지토리 경로를 입력할 수 있다.

이제 쿠버네티스를 어떤 식으로 사용해야 되는지 알아보겠다.

 

 

3. 매니패스트 파일 생성하기

쿠버네티스는 Ansible과 동일하게 yaml 파일을 작성하여 여러 요소를 생성할 수 있다.

파일을 작성하기 전에 어떤 식으로 pod를 배포하는지 순서대로 진행해보겠다.

 

 

nginx 배포 및 복제본 생성

kubectl create deployment demo-nginx --image=nginx --port=80 --replicas=2

→ demo-nginx라는 이름의 배포를 생성한다. 이미지는 도커 허브에 있는 nginx를 이용할 것이고, 포트 번호는 80번을 이용할 것이다. 그리고 복제본은 2개를 생성할 것이다.

nginx 배포 명령 실행

 

kubectl get deployment 명령어로 확인

배포 목록 조회

 

복제본의 수를 확인하고 싶다면 kubectl get replicaset을 입력하면 된다.

복제본 목록 조회

생성된 pod 조회

 

nginx 서버를 두 개 만들었으므로 두 개 모두 서버의 부하 분산을 할 수 있도록 중간 매개체가 필요해졌다.

부하 분산을 돕는 Load Balancer를 생성한다.

쿠버네티스에서는 Load Balnacer를 service의 한 종류라고 말할 수 있는데, 기존에 있는 배포에 서비스를 배치하기 위해서는 expose 명령어를 사용하면 된다.

kubectl expose deployment demo-nginx --port=80 --type=LoadBalancer

 

로드밸런서 연결

 

kubectl get all 명령을 이용하면 현재 생성된 모든 요소들을 조회할 수 있다.

현재 상황 조회

 

그리고 aws 콘솔에서도 로드 밸런서가 생성된 것을 확인할 수 있다.

 

expose 명령을 이용했기 때문에 기존에 존재하던 클러스터 인스턴스가 등록되어 있는 것을 확인할 수 있었다.

로드밸런서에 연결된 인스턴스 목록

 

port 번호도 터미널 상과 aws 콘솔 상에서 동일한 것을 확인할 수 있다.

 

 

 

이제 이 과정을 매니페스트 파일을 생성해서 다시 해볼 것이다.

삭제는 delete로 할 수 있다.

 

 

이제 본격적으로 파일 작성을 해볼 것이다.

pod와 Load balancer를 생성해보겠다.

 

pod 생성 파일 작성

# pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  labels:
    app: demo-app

spec:
  containers:
    - name: demo-nginx
      image: nginx
      ports:
        - name: demo-nginx
          containerPort: 80

 

로드 밸런서 생성 파일 작성

# service.yml

apiVersion: v1
kind: Service
metadata:
  name: demo-service

spec:
  ports:
    - name: nginx-port
      port: 80
      targetPort: 80
  type: LoadBalancer

 

-f 옵션은 파일을 이용하여 생성할 수 있도록 돕는다.

pod 생성

load balancer 생성

생성 완료

 

 

현재 각각 생성했기 때문에 pod와 load balancer가 따로 놀고 있는 것을 확인할 수 있다.

그래서 이걸 service 생성 파일에 selector라는 구분자를 이용하여 pod를 구분할 수 있도록 만들 수 있다.

로드 밸런서가 부하 분산을 해야하는 pod가 어떤 건지 알려주면 로드 밸런서는 자신에게 연결된 pod에게만 부하 분산을 하는 형식이다.

selector에는 연결할 pod의 labels를 작성해주면 된다.

pod의 labels를 selector에 추가

 

kubectl apply -f service.yml 명령을 다시 입력하여 업데이트한 파일 내용으로 변경하면 로드 밸런서의 엔드포인트가 pod의 IP로 변경된 것을 확인할 수 있다.

아주 성공적이다.

 

이제 로드밸런서의 EXTERNAL IP로 접속해보면 nginx 서버에 무사히 접속할 수 있다.

 

 

다음 포스팅은,,, 이제 이 쿠버네티스를 이용하여 CI/CD 파이프라인을 구축하는 데 활용해보겠다.