JWS

[Lv2. 전화번호 목록] 풀이 기록

JAEJUNG — Wed, 4 Feb 2026 00:50:12 +0900

처음 제출한 답

def solution(phone_book):
    
    phone_book = sorted(phone_book, key=lambda x:x)
    p_book = phone_book.copy()

    for p in phone_book:
        del p_book[0]
        for p2 in p_book:
            if p in p2:
                return False
    return True

리스트가 주어지고 특정 인덱스가 다른 인덱스의 접두사가 되는 경우를 찾는 건데

최대 길이가 1,000,000 이다보니 for문을 두번 돌리면서 풀면 시간초과가 난다

그리고 점수도 83.3점이라 제대로 맞히지도 못했다..

그래서 하루동안 머리를 싸매다가 제미나이 힘을 좀 빌림

우선 포인트는,

1. Dictionary를 써야 한다.

2. 관점을 좀 다르게 봐야 한다.

1. Dictionary

for문 2번은 O(n^2), Dictionary는 O(n)
모든 phone_book 요소를 Dictionary에 등록

2. 관점을 다르게 보자

처음 풀 땐 크기가 작은 놈을 기준으로 이게 어떤 큰 놈의 접두사가 될까 ? 로 접근했는데 이 방식은 결국 배열의 모든 요소를 봐야 함
그래서 큰 놈을 기준으로 하나씩 쪼개면서 쪼갠 값이 리스트에 있나 ? 를 보면 됨

블로그를 정리하면서 생각해보니 이런 식으로 2중 for문을 돌려도 정답이 되긴 한다.

def solution(phone_book):    
    phone_book = sorted(phone_book, key=lambda x:int(x), reverse=True)
    
    for p in phone_book:
        tp = ''
        for i in range(len(p) - 1):
            tp += p[i]
            if tp in phone_book:
                return False
    return True

다만 효율성에서 시간 초과가 떨어진다.

결국 2중 for문으로는 아무리 잘 짜도 100점을 못 받는 것 같다.

해시로 풀어보면 다음과 같다.

phone_book에서 하나씩 꺼내고 꺼낸 요소를 한글자씩 쪼개서 dictionary에 있는지 확인한다.
len(p) - 1 은 자기 자신과 비교하지 않기 위해서다.

def solution(phone_book):    
    
    phone_dict = {p:True for p in phone_book}

    for p in phone_book:
        tp = ''
        for i in range(len(p) - 1):
            tp += p[i]
            if tp in phone_dict:
                return False
    return True

[Lv1. 신고 결과 받기] 풀이 기록

JAEJUNG — Tue, 20 Jan 2026 01:43:11 +0900

처음 제출한 답

뭔가 딕셔너리로 풀어야 될 거 같은데 잘 안떠올라서 for문 덕지덕지로 일단 해결

def solution(id_list, report, k):
    answer = []

    matrix = [[0] * len(id_list) for _ in range(len(id_list))]
    report_count = dict()
    id_list_len = len(id_list)

    for i in range(id_list_len):
        report_count[id_list[i]] = 0

    for r in report:
        reporter, bad_man = r.split(" ")
        r_index = id_list.index(reporter)
        b_index = id_list.index(bad_man)
        
        if matrix[r_index][b_index] == 0:
            matrix[r_index][b_index] += 1
        
    for y in range(id_list_len):
        count = 0
        for x in range(id_list_len):
            if matrix[x][y] == 1:
                count += 1
        if count >= k:
            for z in range(id_list_len):
                if matrix[z][y] == 1:
                    report_count[id_list[z]] += 1
    
    for i in id_list:
        answer.append(report_count[i])

    return answer

성능 보니까 딱 봐도 느려보인다.

다른 사람의 풀이 보고서 set + 딕셔너리로 푸는 것 확인

두번째 풀이

set 쓴 거 보고 허탈했다.
answer를 저렇게 0으로 세팅하고 reporter의 인덱스를 찾아서 1씩 더해주는 방법

def solution(id_list, report, k):
    answer = [0] * len(id_list)
    reports = {x : 0 for x in id_list}

    for r in set(report):
        bad_man = r.split(" ")[1]
        reports[bad_man] += 1
    
    for r in set(report):
        bad_man = r.split(" ")[1]
        if reports[bad_man] >= k:
            reporter = r.split(" ")[0]
            reporter_index = id_list.index(reporter)
            answer[reporter_index] += 1

    return answer

성능을 보면 작게는 2배에서 크게는 10배까지 줄어들었다.

근데 index() 가 전체를 순회해서 이것도 느린 거라고 한다.

그럼 index()를 쓰지 말고 풀어보자

마지막 풀이

user_index라는 딕셔너리를 통해 각 user별 value를 바로 +1 시켜주고 answer에는 value 들만 더해주는 방식

def solution(id_list, report, k):
    answer = []
    reports = {x : 0 for x in id_list}
    user_index = {x : 0 for x in id_list}

    for r in set(report):
        bad_man = r.split(" ")[1]
        reports[bad_man] += 1
    
    for r in set(report):
        bad_man = r.split(" ")[1]
        if reports[bad_man] >= k:
            reporter = r.split(" ")[0]
            user_index[reporter] += 1

    for i in id_list:
        answer.append(user_index[i])

    return answer

성능이 1, 2번 대비 눈에 띄게 좋아진 것 확인

[EKS] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials" 해결하기

JAEJUNG — Fri, 4 Oct 2024 17:43:02 +0900

테스트용 EC2에서 EKS 쪽 작업할 게 생겨 IAM Role 할당 -> ~/.kube/config 설정 후

API 요청을 보냈더니 에러가 났다.

평소 쿠버네티스 세팅은

EC2에 IAM Role 할당 (Administrator 혹은 최소한의 Node Role)
aws eks update-kubeconfig
aws-auth configmap에 IAM Role 추가 (혹은 IAM Access Entries에 Role 추가)

이 세 가지만 하면 문제 없었는데,, 다 돼있는데도 안돼서 당황했다.

그래서 이번 글에서는 겉핡기식으로 알고 있던 쿠버네티스 인증에 대해 조금 자세히 다뤄보고 왜 저런 이슈가 발생했는지 기록해놔야겠다 라는 생각이 들었다.

쿠버네티스 인증

Kubernetes uses client certificates, bearer tokens, or an authenticating proxy to authenticate API requests through authentication plugins. (Link)

쿠버네티스 공식문서를 보면 인증 방식으로 크게 세 가지를 지원한다.

Client Certificates (X.509)
Bearer Tokens
Authenticating Proxy

이 중에서 EKS 인증에서 활용되는 Token 방식에 대해 알아보자.

EKS는 Webhook Token, Service Account Token과 더불어 2021년 2월부터 OIDC 인증도 지원한다.

Webhook Token Authentication

우리는 쿠버네티스 API 서버와 통신하기 위해 최초 로컬 혹은 특정 서버에 클러스터를 등록해주는 과정을 거친다.

이때 aws eks update-kubeconfig 명령어를 사용하게 되는데 이건 단순히 kubectl과 EKS Cluster를 connect 시켜주기 위한 사전절차일 뿐이다.

[ec2-user@ip-172-20-10-116 ~]$ aws eks update-kubeconfig --region ap-northeast-2 --name jaejung-eks-cluster
Updated context arn:aws:eks:ap-northeast-2:123456789012:cluster/jaejung-eks-cluster in /home/ec2-user/.kube/config

자동으로 home 디렉토리 하위 .kube/config 파일을 업데이트 해주기 때문에 사용하기 간편하지만 eks api를 호출하기 때문에

폐쇄망의 경우 eks용 interface endpoint를 생성하거나 직접 config 파일을 업데이트 해줘야 한다.

물론 IAM 주체에 eks:DescribeCluster 권한이 할당되어 있어야 하며 aws sts get-caller-identity 입력 시 표시되는 자격 증명을 사용한다고 보면 된다.

이때 호출되는 자격증명이 IAM Role이 맞는지, Access key가 입력돼있는 건 아닌지 꼭 확인해야 한다. (이 글을 쓰는 이유이기도 함)

이제 Webhook Authentication이 어떻게 동작하는지 살펴보자.

1. Client가 kubectl을 입력하면 bearer token이 생성된다.

kubectl을 입력하면 어떻게 token이 생성될까?

답은 ~/.kube/config에 있다.

kubectl은 기본적으로 $Home/.kube/config 파일에서 클러스터, 인증, 컨텍스트 정보를 읽어들인다.

그리고 config 파일 하단을 보면 이런 값이 들어가있다.

- name: arn:aws:eks:ap-northeast-2:123456789012:cluster/jaejung-eks-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - --region
      - ap-northeast-2
      - eks
      - get-token
      - --cluster-name
      - jaejung-eks-cluster
      - --output
      - json
      command: aws

결론적으로 kubectl을 입력하면 이 명령어가 자동으로 실행된다고 보면 된다.

aws --region ap-northeast-2 eks get-token --cluster-name jaejung-eks-cluster --output json

직접 실행해보면 굉장히 긴 토큰값이 반환되는 것을 볼 수 있다.

명령어를 실행할 때마다 새로운 토큰값이 생성되고 이 토큰의 만료 기간은 15분이다.

관련 re:Post를 보면 만료 시간은 수정할 수 없다고 한다.

이 토큰값은 base64로 인코딩된 문자열이라서 디코딩해보면 이런 값이 된다.

https://sts.ap-northeast-2.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIA2B6Y4IBCUSBQBF7W%2F20240926%2Fap-northeast-2%2Fsts%2Faws4_request&X-Amz-Date=20240926T073528Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMj%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaDmFwLW5vcn.............

https://sts.ap-northeast-2.amazonaws.com/
Action=GetCallerIdentity
Version=2011-06-15
X-Amz-Algorithm=AWS4-HMAC-SHA256
X-Amz-Credential=ASIA2B6Y4IBCUSBQBF7W
...

정리해보면

1. eks get-token을 통해 response로 token을 전달받고

2. 이 token은 base 64로 Encoding 되어있고

3. Decoding 해보면 AWS STS(Secure Token Service)의 GetCallerIdentity API를 호출하는 Pre-Signed URL 값이 된다.

2. 이제 사용자 인증을 받아보자.

그럼 인증은 어떤 방식으로 진행될까?

우선 위에서 생성된 토큰이 EKS API 서버로 전송된다.

(kubectl <-> Kubernetes API 서버간 통신은 client-go 라이브러리를 통해 이루어진다.)

API 서버는 전달받은 Token을 aws-iam-authenticator server에 전달한다.

aws-iam-authenticator server는 Token Authentication Webhook 호출 -> sts get-caller-identity 호출 과정을 통해

IAM으로부터 UserID, 사용자에 대한 ARN을 반환받는다.

그 다음으로 aws-auth configmap이 쿠버네티스 보안 주체를 리턴한다.

youtube 영상에서 이 부분이 뭔 뜻인지 이해가 안갔는데

그냥 IAM 사용자와 Kubernetes 사용자를 매핑시켜둔 게 aws-auth configmap 이니까 IAM으로부터 반환 받은 사용자 정보가 aws-auth에 존재하는지 확인하는 절차 정도로 이해했다.

이후 aws-iam-authenticator server는 Kubernetes API 서버에게 TokenReview 라는 데이터 타입으로 username, group을 반환한다.

tokenreview 데이터는 대충 이렇게 생겼다.

{
  "kind": "TokenReview",
  "apiVersion": "authentication.k8s.io/v1beta1",
  "metadata": {
    "creationTimestamp": null
  },
  "spec": {
    "token": "$BEARER_TOKEN"
  }
}

이 데이터를 가지고서 Kubernetes RBAC 체계에서 요청에 대해 Allow / Deny를 결정짓게 된다.

쉽게 말하면 결국 인증을 요청한 사용자에 대한 정보가 여러 api 호출을 거쳐 configmap에 매핑돼있는 게 확인이 됐을 때 '인증 완료' 가 찍히는 것이다.

이제 돌고돌아 couldn't get current server API group list 오류는 왜 났을까?

aws sts get-caller-identity를 호출했더니 내가 EC2에 할당해놓은 IAM Role이 아니라 예전에 등록해둔 Access key, Secret key로 인해 IAM User가 반환되었다.

결국 EKS에는 IAM Role을 등록해두고 인증을 요청한 주체는 엉뚱한 사용자라서 오류가 났었다.

끝.

참고자료

https://coffeewhale.com/kubernetes/authentication/x509/2020/05/02/auth01/

https://seungjjun.tistory.com/m/313

https://www.youtube.com/watch?v=d16UXBthfYQ&t=656s&ab_channel=AmazonWebServicesKorea

쿠버네티스 Auto Scaling #2 (CA, Karpenter)

JAEJUNG — Mon, 11 Mar 2024 16:11:32 +0900

서론

앞서 쿠버네티스 Auto Scaling #1 (HPA, VPA)에서 Pod에 대한 Auto Scaling을 다뤘다.

당연한 얘기지만 충분한 Pod를 배치하기 위해선 그에 맞는 Node의 리소스가 받쳐줘야 한다.

그렇다고 확장될 경우를 대비하여 미리 용량이 큰 노드를 준비해놓는다면 리소스 낭비로 이어지기 때문에 적절한 시기에 필요한 만큼 확장/축소시켜 트래픽을 처리하는 것이 바람직하다.

이때 활용할 수 있는 것이 바로 클러스터 오토스케일링 기능이다.

(참고로 EC2 타입별 띄울 수 있는 최대 Pod 개수는 정해져있다. 링크)

클러스터의 오토스케일링을 위한 솔루션에는 크게 Cluster Autoscaler, Karpenter 이외에도 nOps의 Compute Copilot, CAST AI, NeApp Spot Ocean과 같은 제품이 있다.

Amazon EKS는 쿠버네티스의 CA(Cluster Autoscaler)와 Karpenter를 지원한다.

(AWS가 2021년에 Karpenter를 오픈소스로 공개하기 전까지는 CA가 유일한 옵션이었음.)

Cluster AutoScaler(CA)

CA를 설명하기에 앞서 먼저 Pod가 배포되는 과정부터 알아보자.

클러스터에 'Pod 만들어주세요' 라고 요청하면 최초 상태는 Pending이 된다.
그럼 k8s 스케줄러가 사용 가능한 노드에 대해 일련의 계산을 수행하여 이 노드가 Pod를 가져갈 수 있는지 확인한다.
만약 현재 상태로는 Pod를 배치할 수 없다고 판단하면 Pod가 Unschedulable 상태가 된다.

Cluster Autoscaler는 AWS의 Autoscaling Group을 사용한다.

기본적으로 10초마다 Unschedulable pod가 있는지 체크하면서 만약 스케줄링되지 않은 pod가 발견되면 오토 스케일링 그룹을 통해 노드를 추가해서 용량을 증설시키는 방식이다. (참고링크)

kubectl -n kube-system logs -f deployment/cluster-autoscaler

전반적인 흐름은 아래 그림과 같다.

https://aws.amazon.com/ko/blogs/tech/amazon-eks-cluster-auto-scaling-karpenter-bp/

CA 설치(단순 설치는 생략)

Cluster Autoscaler 설치는 AWS Workshop 자료를 참고한다.

동작 테스트

테스트를 위해 deployment의 개수를 10개로 늘려준다.

kubectl scale --replicas=10 deployment/nginx-to-scaleout

CA의 로그를 확인해보면 unschedulable pod를 발견하고 자동으로 auto scaling group의 사이즈를 키우는 것을 확인할 수 있다.

-> 노드가 생성되고 있는 모습

이제 pod의 개수를 원래대로 줄여본다.

kubectl scale --replicas=1 deployment/nginx-to-scaleout

배치할 pod가 없으므로 Scale-in이 진행되고 있다.

다만 Scale-in은 Scale-out과는 다르게 실행 중인 프로세스를 모두 중지시킨 후 서버가 종료되기 때문에 시간이 조금 더 걸린다.

한 마디로 Graceful Shutdown을 위한 시간이라고 볼 수 있음.

추가 옵션

아래는 CA를 설정하면서 몇 가지 고려해볼만한 추가 옵션이다.

CA의 반응 시간을 제어하려면?

어떤 서비스를 올리느냐에 따라 서비스마다 최초 구동 시간이 상이하다.

CA가 Unschedulable pod가 있는지 스캔하는 간격보다 pod가 뜨는 시간이 더 오래 걸린다면 불필요한 스케일링이 발생할 수 있다.

그런 경우를 대비해 pod-scale-up-delay 플래그를 활용할 수 있다.

"cluster-autoscaler.kubernetes.io/pod-scale-up-delay": "600s"

Scale-in의 시간을 조절하려면?

노드의 개수를 축소시키는 시간을 조절할 수 있다.

노드를 더 오래 유지하고 싶을 때(예를 들어 pod가 다시 배치되는 경우)에는 scale-down-unneeded-time 값으로 조절한다.

extraArgs:
  scale-down-unneeded-time: 3m

Scale-in을 막으려면?

노드의 annotate로 아래 값을 지정해주면 된다.

"cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"

이렇게

kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

그 외 추가적인 플래그는 아래 공식문서를 참고.

https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/#additional-parameters

Cluster-Autoscaler - EKS Best Practices Guides

Kubernetes Cluster Autoscaler Overview The Kubernetes Cluster Autoscaler is a popular Cluster Autoscaling solution maintained by SIG Autoscaling. It is responsible for ensuring that your cluster has enough nodes to schedule your pods without wasting resour

aws.github.io

Karpenter

Karpenter는 AWS가 개발한 쿠버네티스 노드의 자동 확장 기능을 수행하는 오픈소스 프로젝트이다.

Karpenter의 목표는 클러스터의 용량(capacity) 관리를 단순화하고 현재 워크로드의 요구 사항을 정확하게 충족하는 JIT(Just-In-Time)으로 리소스를 프로비저닝하는 데 있다.

노드의 용량은 크게, 개수는 적게 프로비저닝함으로써 Daemonset 배포 시 혹은 쿠버네티스 시스템 구성 요소들의 오버헤드를 줄이는 이점을 가져갈 수 있다. (통신 오버헤드, etcd 오버헤드, 스케줄링 오버헤드 등등)

https://catalog.us-east-1.prod.workshops.aws/eks-autoscaling/ko-KR/05-karpenter

서론에서 얘기했듯 Karpenter는 21년 12월 새로운 쿠버네티스 클러스터 오토스케일러로 발표됐다.

Cluster Autoscaler가 있는데 왜 굳이 또 다른 오토스케일러가 나왔을까?

Cluster Autoscaler를 쓰면서 불편한 점

CA도 오토스케일러로써 충분히 제 역할을 다하고 있다. 오히려 karpenter가 발표되기 전까진 유일한 옵션이었기 때문에 레퍼런스도 그만큼 많다.

다만 사용자가 느끼기에 Karpenter 대비 다소 번거로운 점들이 있다.

1. Auto Scaling Group의 관리

CA는 AWS의 ASG를 활용하고 있다.

예를 들어 클러스터 내 여러 서비스가 있고 각각 다른 타입의 EC2를 사용한다고 가정해보자.

테스트 : Spot
웹서비스 : M type
데이터 분석 : R type

이런 경우 관리자는 각각의 템플릿을 만들고 ASG를 생성해주어야 한다.

뿐만 아니라 변경사항이 생기면 템플릿을 수정하고 버전도 변경해주어야 하기 때문에 대규모 클러스터에서는 이를 관리하기가 굉장히 번거로울 수 있다.

2. 프로비저닝 지연 시간

CA는 ASG를 활용하여 AWS Cloud Provider를 구현한 형태이다.

즉 부하가 발생하면 중간에 AWS 리소스 요청을 한번 거치기 때문에 스케일링 되는데 약간의 지연시간이 발생한다.

아래는 Kubernetes CA FAQ에서 제공하고 있는 Cluster Autoscaler에 대한 SLO 수치이다.

소규모의 경우 30초 이내, 대규모 클러스터의 경우 60초 이내라고 설명한다.

반면 Karpenter는 Kubernetes 스케줄러를 우회하여 EC2 플릿과 직접 상호작용한다.

동작 테스트 부분에서 다시 다루겠지만 Karpenter 컨트롤러는 주기적으로 인스턴스의 가격을 이벤트로 받아오고 필요한 리소스에 맞추어 노드를 직접 프로비저닝 하게 된다.

아마 여기서 속도 차이가 발생하지 않을까 싶다.

Provisioner란?

Karpenter는 provisioner라는 리소스를 활용한다.

CA가 Launch Template에 정의된 값을 참조하여 오토 스케일링을 수행한다면 Karpenter는 이 provisioner에 정의된 값에 따라 노드 오토 스케일링을 수행한다.

말 그대로 서버 스펙, os, 타입, 제약조건과 같은 값을 이 곳에 모두 정의하면 된다.

특징으로는,

operator 연산자를 통해 여러 다양한 인스턴스 타입을 정의할 수 있다.
Launch Template은 타입을 하나만 설정할 수 있기 때문에 Pod의 요청값에 딱 맞는 노드가 아닐 수 있다.
Karpenter를 사용하면 이러한 bin packing 문제를 개선할 수 있다.
*여기서 bin packing problem이란 n개의 아이템을 m개의 빈에 채워넣는 문제이다.
pod 별로 리소스 요청량이 다르기 때문에 작은 타입의 노드를 여러대 준비해놓는 경우 노드별 유휴 자원이 많이 발생할 수 있다.
그래서 EKS 모범 사례 가이드에서도 볼 수 있듯이 CA를 제대로 쓰려면 노드 그룹 수를 최소화하고 인스턴스 유형을 키우라고 기재돼있다.
노드 만료에 대한 기본값을 설정할 수 있다.
EKS 클러스터를 운영하다 보면 특정 Node가 오래 사용되어 제때 보안 패치가 안되는 경우가 있다.
이런 경우를 대비하여 노드의 만료기간을 정한다면 주기적인 보안 패치에 대비할 수 있다.

아래는 Provisioner 오브젝트에 대한 예시 yaml 파일이다.

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  labels:
    intent: apps
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot"]
    - key: karpenter.k8s.aws/instance-size
      operator: In
      values: ["m6i.2xlarge","m6i.4xlarge","c6i.4xlarge"]
  limits:
    resources:
      cpu: 1000
      memory: 1000Gi
  ttlSecondsAfterEmpty: 30
  ttlSecondsUntilExpired: 2592000
  providerRef:
    name: default
---
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  subnetSelector:
    alpha.eksctl.io/cluster-name: ${CLUSTER_NAME}
  securityGroupSelector:
    alpha.eksctl.io/cluster-name: ${CLUSTER_NAME}
  tags:
    KarpenterProvisionerName: "default"
    NodeType: "karpenter-workshop"
    IntentLabel: "apps"

Provisioner에서 제공하는 필드에 대해 살펴보자.

Instance Type

리스트 형태로 여러 타입을 설정 가능, 대상을 넓게 정의하는 것이 좋다

key: node.kubernetes.io/instance-type
key: karpenter.k8s.aws/instance-family
key: karpenter.k8s.aws/instance-category
key: karpenter.k8s.aws/instance-generation

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: "karpenter.k8s.aws/instance-family" # 인스턴스 유형
      operator: In
      values: ["c5", "m5", "r5"]
    - key: "karpenter.k8s.aws/instance-cpu"   # cpu 크기
      operator: In
      values: ["4", "8", "16", "32"]
    - key: "topology.kubernetes.io/zone"      # 가용 영역
      operator: In
      values: ["ap-northeast-2a", "ap-northeast-2b"]
    - key: "kubernetes.io/arch"               # cpu 아키텍처
      operator: In
      values: ["arm64", "amd64"]
    - key: "karpenter.sh/capacity-type"       # 용량 타입 
      operator: In
      values: ["spot", "on-demand"]

spec.limits.resources

프로비저너가 리소스를 관리할 때 최대 리소스 양을 정해놓는다.

지정된 리밋을 초과하면 기존 노드가 종료될 때까지 새 노드 프로비저닝이 금지된다.

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000 
      memory: 1000Gi
      nvidia.com/gpu: 2

Weighted Provisioners

.spec.weight 필드를 통해 프로비저너간의 우선순위를 설정할 수 있다.

우선순위가 필요한 경우는 뭐가 있을까?

예를 들어 Savings Plan, 예약 인스턴스를 구입한 경우 얘네들을 먼저 사용해줘야 비용효율적인 운영이 가능하다.

Karpenter에게 default 프로비저너보다 우선하여 reserved-instance 프로비저너를 생성하여 노드 프로비저닝이 가능하다.

이때 사용하는 옵션이 weight 값이다.

Reserved Instance Provisioner

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: reserved-instance
spec:
  weight: 50
  requirements:
  - key: "node.kubernetes.io/instance-type"
    operator: In
    values: ["c4.large"]
  limits:
    cpu: 100

Default Provisioner

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
  - key: karpenter.sh/capacity-type
    operator: In
    values: ["spot", "on-demand"]
  - key: kubernetes.io/arch
    operator: In
    values: ["amd64"]

Default Node 설정

pod를 특정 노드에 스케줄링 시키고 싶을 때 Node Selector, Affinity 같은 설정을 한다.

그러나 pod 생성할 때 매번 affinity 설정을 해주면 아래와 같은 제약사항이 발생한다.

1. 일일이 설정하기 번거로움

2. affinity 설정이 변경될 때마다 모든 pod가 재스케줄링 되기 때문에 클러스터 전체에 영향

3. 클러스터 리소스를 상당히 많이 소모함, -> affinity 기능 자체가 상당한 양의 프로세싱을 요구하므로 대규모 클러스터에서는 사용하지 않는 것을 권장한다.(https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/)

리소스를 많이 쓴다는 건? -> 대규모 클러스터에선 스케줄링에 레이턴시가 걸릴 수 있음.

Note:
Inter-pod affinity and anti-affinity require substantial amount of processing which can slow down scheduling in large clusters significantly. We do not recommend using them in clusters larger than several hundred nodes.

Karpenter는 클러스터 전체에 Default 구성을 적용할 수 있다.

Provisioner를 생성할 때 특정 Capacity type, 아키텍처 등을 지정하고 .spec.weight 값을 높게 할당하면 된다.

그 외 별도 요구사항이 있는 경우 나머지 Provisioner를 따라간다.

Default Provisioner

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  weight: 50
  requirements:
  - key: karpenter.sh/capacity-type
    operator: In
    values: ["spot", "on-demand"]
  - key: kubernetes.io/arch
    operator: In
    values: ["amd64"]

ARM64 Provisioner

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: arm64-specific
spec:
  requirements:
  - key: karpenter.sh/capacity-type
    operator: In
    values: ["spot", "on-demand"]
  - key: kubernetes.io/arch
    operator: In
    values: ["arm64"]
  - key: node.kubernetes.io/instance-type
    operator: In
    values: ["a1.large", "a1.xlarge"]

On-demand / Spot 비율

운영을 하다보면 용도별로 온디맨드/스팟을 구분하여 사용할 때가 있다.

Karpenter에서 일정한 비율로 온디맨드와 스팟 인스턴스를 분할하는 방법을 살펴보자.

먼저 스팟과 온디맨드 각각의 프로비저너를 생성한다.

capacity-spread 라는 새 레이블을 만들고 서로 겹치지 않는 값을 할당한다.

아래 예시는 스팟에 4개, 온디맨드에 1개

-> 스팟:온디맨드 노드 비율이 4:1이 됨

Spot Provisioner

  requirements:
  - key: "karpenter.sh/capacity-type"
    operator: In
    values: [ "spot"]
  - key: capacity-spread
    operator: In
    values:
    - "2"
    - "3"
    - "4"
    - "5"

On-Demand Provisioner

  requirements:
  - key: "karpenter.sh/capacity-type"
    operator: In
    values: [ "on-demand"]
  - key: capacity-spread
    operator: In
    values:
    - "1"

여기에 위에서 설정한 capacity-spread 레이블을 토폴로지 키로 topologySpreadConstraints를 활용해 분산되게 배포한다.

Topology Spread Constraint

      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: capacity-spread
        whenUnsatisfiable: DoNotSchedule

여기서 잠시 토폴로지 분배 제약조건(Topology Spread Constraint)에 대해 알아보자.

Topology Spread Constraint

Pod를 분배하는 방법은 크게 Node 기준에서의 NodeAffinity와 Pod 기준에서의 PodAffinity가 있다.

Topology Spread Constraint는 Pod가 클러스터 내에서 물리적 혹은 논리적 위치에 균등하게 배포되도록 하는 기능이다.

개념만으론 와닿지 않으니 아래 예시를 살펴보자.

AWS의 서울 리전(ap-northeast-2) 기준으로 ap-northeast-2a, ap-northeast-2c 라는 가용영역에 각 노드가 한 대씩 있다고 가정해보자.

여기서 이 가용영역이 토폴로지 도메인(Topology Domains)이 된다.

토폴로지 도메인은 pod가 분포될 수 있는 물리적 혹은 논리적 영역을 뜻한다 (노드, 데이터센터 등등)

노드에 라벨을 붙여서 pod가 균등하게 배포되는지 확인해보자

topology.kubernetes.io/region=ap-northeast-2 (공통)
topology.kubernetes.io/zone=ap-northeast-2a (a 가용영역의 노드에)
topology.kubernetes.io/zone=ap-northeast-2c (c 가용영역의 노드에)
노드 명은 kubectl get nodes를 입력했을 때 나오는 NAME 필드의 값이다.

kubectl lable node <A az 노드 명> topology.kubernetes.io/region=ap-northeast-2 topology.kubernetes.io/zone=ap-northeast-2a
kubectl lable node <C az 노드 명> topology.kubernetes.io/region=ap-northeast-2 topology.kubernetes.io/zone=ap-northeast-2c

라벨을 지정한 후에는 아래 명령어를 통해 노드에 설정된 라벨을 확인할 수 있다.

kubectl get nodes -o jsonpath="{.items[*].metadata.labels}" | jq

아래 yaml 파일을 통해 10개의 pod를 생성해보자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-spread
  namespace: karpenter
spec:
  replicas: 10
  selector:
    matchLabels:
      app: deploy-spread
  template:
    metadata:
      labels:
        app: deploy-spread
    spec:
      containers:
      - image: nginx
        name: nginx
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: deploy-spread

여기서 topologySpreadConstraints 부분에 어떤 설정값들이 있는지 살펴보자

maxSkew (Required)
파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다.
만약 1로 설정했다면 최대 1개의 pod까지 뷸균형을 허용한다는 뜻이다.
(e.g. 5개의 pod를 띄운다면 a존에 2개, c존에 3개까지는 허용, a존 4개 c존 1개는 불가)
topologyKey
노드 라벨의 Key 값
whenUnsatisfiable
분산 제약 조건을 만족하지 않을 경우 Pod를 어떻게 처리할지에 대한 방법이다.
- DoNotSchedule : 기본값이며 쿠버네티스 스케줄러에 스케줄링을 하지 말라고 알려줌
- ScheduleAnyway : 쿠버네티스 스케줄러에 skew를 최소화하는 노드에 높은 우선순위를 부여하면서 스케줄링을 계속 하도록 지시
labelSelector
일치하는 pod를 찾기 위해 사용(토폴로지 도메인에 속할 파드를 결정짓기 위함)

Pod가 배포된 노드를 확인해보면 a존과 c존에 각각 5개의 pod가 배포된 것을 확인할 수 있다

운이 좋게 5개씩 배포가 됐을 수 있지만 운영을 하다보면 모든 노드의 부하 비율이 동일한 것을 보장할 수 없다.

제약조건을 없앤 후 배포해보면 5:5로 배포되지 않는 것을 알 수 있다.

간단하게 Cluster AutoScaler와 Karpenter에 대해 살펴보았다.

처음부터 CA를 사용하여 대규모 클러스터를 운영했다면 Karpenter로 넘어가는 게 쉽지 않을 것 같은데

이제 막 EKS 도입을 고려하는 중이라면 Karpenter를 안쓸 이유가 없어보인다.

AWS Lambda@Edge를 활용한 실시간 이미지 리사이징

JAEJUNG — Fri, 1 Dec 2023 18:38:06 +0900

개요

본 포스팅을 들어가기에 앞서 먼저 이미지 리사이징이 왜 필요한지 생각해볼 필요가 있습니다.

B2C 서비스, 특히 온라인 쇼핑몰을 접속해보면 굉장히 많은 상품 사진들을 볼 수 있습니다.

저는 국내 브랜드를 좋아하니 탑텐몰에서 아우터 항목을 한번 살펴보겠습니다.

상품들을 한 눈에 보여주니 마음에 드는 옷을 바로바로 고를 수 있겠네요.

https://www.goodwearmall.com/display/category/list?dspCtgryNo=SSMA02A05A04

대부분의 쇼핑몰들은 브라우저 메인 화면부터 세부 카테고리에 접속하기까지 소비자들의 이목을 끌기 위해 공통적으로 제공하는 것이 있습니다.

바로 썸네일(Thumbnail)인데요.

위 사진처럼 굳이 상품을 하나하나 클릭하지 않더라도 어떤 상품들이 있는지, 상품의 색상은 무엇인지 등의 정보를 소비자에게 노출시키기 위해 썸네일을 활용하고 있습니다.

여러 사진들 중에서 한 가지를 골라 썸네일의 크기를 한번 확인해보겠습니다.

아래 사진의 크기는 284 x 374.88입니다.

상품을 클릭한 후 상세 페이지에 들어가니 사진의 크기가 384 x 512로 커진 것을 볼 수 있습니다.

https://www.goodwearmall.com/product/RAE3TC3001BK/detail?trackNo=gwearcate&trackDtl=gwearcate_SSMA02A05A04

그럼 컨텐츠 관리자는 상품 이미지를 어떻게 관리해야 할까요?

접속 엔드포인트가 PC가 아닌 모바일, 패드 등의 장비라면 이보다 사이즈가 더 작을 것이고 상품의 이미지 저장을 위해 아마 S3 서비스를 사용할 테니

각 카테고리별로 상품을 하나씩 업로드 한다면 아마 이런 식으로 파일이 저장되겠네요.

만약 1000개의 상품을 가지고 있는 쇼핑몰이라고 가정해보겠습니다.

각각 100x100, 300x300, 500x500 사이즈의 사진이 필요한 경우 원본 이외에 1000장 x 3 = 3000장의 이미지에 대해 리사이징 처리하고

이를 S3에 모두 저장해야 하며, 새로운 사이즈가 필요하다면 그때마다 다시 리사이징 작업을 수행해줘야 합니다.

이렇게 사이즈별로 이미지를 모두 관리한다면 스토리지 비용 뿐 아니라 이미지를 관리하기가 너무 복잡할 것 같네요.

이러한 이슈를 해결하고 싶다면 필요시 실시간으로 이미지를 리사이징하여 클라이언트에게 제공하면 됩니다.

AWS CloudFront 서비스는 AWS의 대표적인 CDN 서비스로 원본 컨텐츠를 캐싱하여 사용자에게 더욱 빠른 응답을 제공할 수 있습니다.

CloudFront의 여러 기능 중에서 Lambda@Edge 기능을 활용하면 실시간 이미지 리사이징이 가능합니다.

Lambda@Edge란?

엣지 로케이션에서 Lambda 함수를 실행시키기 위해 CloudFront에서 제공하는 기능

이 Lambda@Edge 기능을 이해하기 위해 먼저 CloudFront에서 발생하는 4가지 이벤트에 대해 살펴보겠습니다.

• Viewer Request

Client에게 요청을 받는 시점에 함수가 실행됩니다.

AWS에서 제공하는 Viewer Request의 예제 일부분을 보면 Client의 IP, Host(CloudFront)의 정보, http method 등의 정보를 확인할 수 있습니다.

{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "viewer-request",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "host": [
              {
                "key": "Host",
                "value": "d111111abcdef8.cloudfront.net"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "curl/7.66.0"
              }
            ],
            "accept": [
              {
                "key": "accept",
                "value": "*/*"
              }
            ]
          },
          "method": "GET",
          "querystring": "",
          "uri": "/"
        }
      }
    }
  ]
}

• Origin Request

Origin(S3)에 요청을 전달할 때 함수가 실행됩니다.

CloudFront와 Client에 대한 정보 이외에도 Origin에 대한 정보가 포함되어 있습니다.

각 헤더들에 대한 자세한 정보는 Lambda@Edge 이벤트 구조 를 확인하시면 됩니다.

{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "origin-request",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "x-forwarded-for": [
              {
                "key": "X-Forwarded-For",
                "value": "203.0.113.178"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "Amazon CloudFront"
              }
            ],
            "via": [
              {
                "key": "Via",
                "value": "2.0 2afae0d44e2540f472c0635ab62c232b.cloudfront.net (CloudFront)"
              }
            ],
            "host": [
              {
                "key": "Host",
                "value": "example.org"
              }
            ],
            "cache-control": [
              {
                "key": "Cache-Control",
                "value": "no-cache, cf-no-cache"
              }
            ]
          },
          "method": "GET",
          "origin": {
            "custom": {
              "customHeaders": {},
              "domainName": "example.org",
              "keepaliveTimeout": 5,
              "path": "",
              "port": 443,
              "protocol": "https",
              "readTimeout": 30,
              "sslProtocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
              ]
            }
          },
          "querystring": "",
          "uri": "/"
        }
      }
    }
  ]
}

• Origin Response

Origin으로부터 응답을 수신한 후 실행되는 함수입니다.

{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "origin-response",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "x-forwarded-for": [
              {
                "key": "X-Forwarded-For",
                "value": "203.0.113.178"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "Amazon CloudFront"
              }
            ],
            "via": [
              {
                "key": "Via",
                "value": "2.0 8f22423015641505b8c857a37450d6c0.cloudfront.net (CloudFront)"
              }
            ],
            "host": [
              {
                "key": "Host",
                "value": "example.org"
              }
            ],
            "cache-control": [
              {
                "key": "Cache-Control",
                "value": "no-cache, cf-no-cache"
              }
            ]
          },
          "method": "GET",
          "origin": {
            "custom": {
              "customHeaders": {},
              "domainName": "example.org",
              "keepaliveTimeout": 5,
              "path": "",
              "port": 443,
              "protocol": "https",
              "readTimeout": 30,
              "sslProtocols": [
                "TLSv1",
                "TLSv1.1",
                "TLSv1.2"
              ]
            }
          },
          "querystring": "",
          "uri": "/"
        },
        "response": {
          "headers": {
            "access-control-allow-credentials": [
              {
                "key": "Access-Control-Allow-Credentials",
                "value": "true"
              }
            ],
            "access-control-allow-origin": [
              {
                "key": "Access-Control-Allow-Origin",
                "value": "*"
              }
            ],
            "date": [
              {
                "key": "Date",
                "value": "Mon, 13 Jan 2020 20:12:38 GMT"
              }
            ],
            "referrer-policy": [
              {
                "key": "Referrer-Policy",
                "value": "no-referrer-when-downgrade"
              }
            ],
            "server": [
              {
                "key": "Server",
                "value": "ExampleCustomOriginServer"
              }
            ],
            "x-content-type-options": [
              {
                "key": "X-Content-Type-Options",
                "value": "nosniff"
              }
            ],
            "x-frame-options": [
              {
                "key": "X-Frame-Options",
                "value": "DENY"
              }
            ],
            "x-xss-protection": [
              {
                "key": "X-XSS-Protection",
                "value": "1; mode=block"
              }
            ],
            "content-type": [
              {
                "key": "Content-Type",
                "value": "text/html; charset=utf-8"
              }
            ],
            "content-length": [
              {
                "key": "Content-Length",
                "value": "9593"
              }
            ]
          },
          "status": "200",
          "statusDescription": "OK"
        }
      }
    }
  ]
}

• Viewer Response

CloudFront가 Client에게 반환하기 전 실행되는 함수입니다.

{
  "Records": [
    {
      "cf": {
        "config": {
          "distributionDomainName": "d111111abcdef8.cloudfront.net",
          "distributionId": "EDFDVBD6EXAMPLE",
          "eventType": "viewer-response",
          "requestId": "4TyzHTaYWb1GX1qTfsHhEqV6HUDd_BzoBZnwfnvQc_1oF26ClkoUSEQ=="
        },
        "request": {
          "clientIp": "203.0.113.178",
          "headers": {
            "host": [
              {
                "key": "Host",
                "value": "d111111abcdef8.cloudfront.net"
              }
            ],
            "user-agent": [
              {
                "key": "User-Agent",
                "value": "curl/7.66.0"
              }
            ],
            "accept": [
              {
                "key": "accept",
                "value": "*/*"
              }
            ]
          },
          "method": "GET",
          "querystring": "",
          "uri": "/"
        },
        "response": {
          "headers": {
            "access-control-allow-credentials": [
              {
                "key": "Access-Control-Allow-Credentials",
                "value": "true"
              }
            ],
            "access-control-allow-origin": [
              {
                "key": "Access-Control-Allow-Origin",
                "value": "*"
              }
            ],
            "date": [
              {
                "key": "Date",
                "value": "Mon, 13 Jan 2020 20:14:56 GMT"
              }
            ],
            "referrer-policy": [
              {
                "key": "Referrer-Policy",
                "value": "no-referrer-when-downgrade"
              }
            ],
            "server": [
              {
                "key": "Server",
                "value": "ExampleCustomOriginServer"
              }
            ],
            "x-content-type-options": [
              {
                "key": "X-Content-Type-Options",
                "value": "nosniff"
              }
            ],
            "x-frame-options": [
              {
                "key": "X-Frame-Options",
                "value": "DENY"
              }
            ],
            "x-xss-protection": [
              {
                "key": "X-XSS-Protection",
                "value": "1; mode=block"
              }
            ],
            "age": [
              {
                "key": "Age",
                "value": "2402"
              }
            ],
            "content-type": [
              {
                "key": "Content-Type",
                "value": "text/html; charset=utf-8"
              }
            ],
            "content-length": [
              {
                "key": "Content-Length",
                "value": "9593"
              }
            ]
          },
          "status": "200",
          "statusDescription": "OK"
        }
      }
    }
  ]
}

여기서 주의깊게 봐야 할 이벤트는 Origin Response 이벤트입니다.

S3로부터 응답을 수신한 후 함수가 실행되는데 아직 CloudFront에서 캐싱하기 전의 상태로, 이 과정에서 Lambda 함수를 사용하여 이미지를 리사이징 처리하여 CloudFront에 캐싱하게 됩니다.

이러한 기능이 바로 Lambda@Edge입니다.

구현

본 실습은 CloudFront와 Lambda@Edge를 활용하여 실시간으로 리사이징이 이루어지는지 확인하기 위함으로.

각 서비스별 구체적인 제약사항이나 Cost Reduction에 대한 부분은 다루지 않았다는 점 참고 바랍니다.

정책 생성

먼저 Lambda 함수를 CloudFront에서 실행하기 위한 IAM 권한을 설정합니다.

[IAM]-[정책]-[정책 생성]을 클릭합니다.

서비스를 하나하나 클릭하여 액세스 레벨을 체크하는 것보다 코드를 통해 한 번에 지정하는 것이 더 수월하기 때문에

[JSON]을 클릭한 후 아래 코드를 추가합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole",
                "lambda:GetFunction",
                "lambda:EnableReplication",
                "cloudfront:UpdateDistribution",
                "s3:GetObject",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams"
            ],
            "Resource": "*"
        }
    ]
}

태그의 경우 선택 사항으로써 정책에 대한 간단한 설명을 추가합니다.

[요약] 부분을 확인하면 조금 전 입력한 JSON 코드를 통해 서비스에 대한 액세스 레벨이 추가된 것을 확인할 수 있습니다.

정책에 대한 이름을 지정하고 [정책 생성]을 클릭합니다.

역할 생성

조금 전 생성한 정책을 할당할 서비스를 설정하는 과정입니다.

[IAM]-[역할]-[역할 만들기]에서 Lambda를 클릭합니다.

[권한 정책 연결]에서 조금 전 생성했던 ImageResizing 권한을 선택합니다.

태그 또한 역할에 대한 간단한 설명으로 작성해줍니다.

역할 이름을 지정한 후 [역할 만들기]를 통해 역할을 생성합니다.

신뢰관계 수정

위 두 과정을 통해 정책과 역할을 생성했습니다.

정책은 '어떤 서비스에 대해 어느 정도의 Access Level을 부여할지' 를 설정하는 것과 같고,

역할은 '해당 정책을 부여할 사용자(서비스)를 누구로 할지' 와 같다고 생각하시면 됩니다.

흔히 IAM 정책을 '모자를 씌운다' 라고 표현하는데, 이 헬맷을 착용했을 때만 해당 권한을 사용할 수 있기 때문입니다.

역할을 사용하기 위해서는 이 역할을 위임할 사용자를 정해야 하는데 이때 '신뢰 관계' 를 지정하게 됩니다.

신뢰 관계를 맺은 사용자는 임시 토큰을 발급받게 되고, 역할에 연결된 권한들을 사용할 수 있습니다.

앞서 생성한 ImageResizing_Role 역할을 확인해보면 [신뢰 관계] 부분에 lambda가 설정된 것을 확인할 수 있습니다.

실습을 진행하기 위해선 lambda 이외에 lambda@edge를 사용하기 때문에 해당 신뢰 관계에 lambda@edge에 대한 부분을 추가해주어야 합니다.

[신뢰 관계 편집]을 클릭하여 .Statement.Principal.Service 부분에 edgelambda.amazonaws.com를 추가합니다.
(에러가 발생한다면 쉼표와 대괄호 등의 기입에 주의합니다.)

CloudFront 배포 생성

CloudFront 배포를 생성하기 전 먼저 S3 버킷에 이미지 파일이 업로드 돼있어야 합니다.

자세한 방법은 S3 버킷 생성, 파일 업로드 포스팅을 참고 바랍니다.

[CloudFront]-[배포 생성]을 클릭합니다.

(여기서부터 집중)

S3 Origin의 원본 이미지를 가져와 캐싱하기 때문에 먼저 [원본 도메인]에서 이미지가 업로드 돼있는 S3 버킷을 선택해줍니다.

다음은 OAI에 대한 설정입니다.

OAI(Origin Access ID)란?

OAI란, 이름 그대로 Origin에 Access가 가능한 ID 값을 의미한다.

S3에 객체를 업로드하면 각각의 객체에 액세스할 수 있는 URL이 할당됩니다.

(e.g. https://[버킷 명].s3.[리전].amazonaws.com/[객체 명])

이 URL을 그대로 사용할 수도 있지만 버킷 명이 노출되면 원본 컨텐츠에 직접 액세스할 수 있기 때문에 보안적으로 이슈가 발생할 수 있습니다.

그렇기 때문에 OAI란 식별자 값을 할당하여 이 OAI 값이 적용돼있지 않은 대상은 S3로 접근이 불가능하게 설정해주어야 안전합니다.

다시 CloudFront 서비스로 돌아가서 [CloudFront]-[보안]-[원본 액세스 ID]를 클릭합니다.

임의의 이름을 설정한 후에 [생성] 버튼을 눌러 식별자를 생성해줍니다.

OAI를 생성한 후 [CloudFront]-[배포 생성]을 클릭하여 [S3 버킷 액세스]-[예, OAI 사용]을 클릭합니다.

생성했던 OAI 값으로 설정하고 [버킷 정책]에서 [예, 버킷 정책 업데이트]를 수행하면 자동으로 S3 버킷 정책에 해당 OAI 값이 설정되게 됩니다.

다음으로 리사이징 처리를 어떻게 수행할 것인지 생각해봐야 합니다.

Client가 원본 이미지가 아닌 300x300 이미지를 조회한다고 가정하면 도메인 뒤에 파라미터 값으로 width=300와 height=300과 같은 쿼리 스트링이 필요합니다.

대충 example.com/1.jpg?width=300&height=300 이런 형식이 될 것입니다.

우리는 파일명 뒤에 ?s=100x100 과 같은 식으로 파라미터 값을 전달하여 이미지를 리사이징 시켜보도록 하겠습니다.

물론 width와 height를 모두 [지정된 쿼리 문자열 포함]에 추가시켜도 됩니다.

[캐시 키 및 원본 요청]-[Legacy cache settings]에서 [쿼리 문자열] 부분에 s 를 추가합니다.

[배포 생성]을 클릭하면 아래와 같이 CloudFront 도메인을 확인할 수 있습니다.

현재 S3에 Galaxy.jpg라는 파일을 업로드했으므로, CloudFront URL 뒤에 1.jpg 파일을 조회하여 원본 이미지를 먼저 확인합니다.

이제 리사이징 할 코드를 올리기 위한 Lambda 함수를 생성해보도록 하겠습니다.

앞서 말했듯, Lambda@Edge란 기능은 현재 버지니아 북부 리전(us-east-1)만 지원하고 있습니다.

리전을 버지니아 북부로 이동한 후 [Lambda]-[함수 생성]을 클릭합니다.

참고할 만한 자료가 대부분 Node.js로 작성되었으며, 본 실습 또한 Node.js로 진행하겠습니다.

[런타임]에서 Node.js 14.x 버전을 선택합니다.

아래 [권한] 부분에서 [기존 역할 사용] 부분에 앞서 생성했던 역할을 부여해줍니다.

함수가 생성되면 아래와 같이 코드를 업로드할 수 있는 화면이 표시된 것을 확인할 수 있습니다.

이제 해야할 것은 크게 아래 4가지입니다.

1. Cloud9 개발 환경 구성

2. Resizing을 위한 Sharp 라이브러리 설치

3. 코드 작성 후 zip 형태로 Lambda에 업로드

4. Lambda@Edge 배포

Sharp 라이브러리는 간단하게 npm install sharp 명령어로 가능합니다.

다만, Sharp 빌드 환경을 Lambda에서 진행해야 합니다. (Sharp는 외부 라이브러리이기 때문에 Cloud9이 필요)

먼저 버지니아 북부 리전으로 이동 후 [Cloud9]-[Create Environment]를 클릭합니다.

크게 변경할 사항은 없으며, Default VPC 이외의 VPC를 사용 중이라면 Network 설정 부분에서 VPC를 변경해줍니다.

생성이 완료되면 아래와 같이 코드 입력과 함께 터미널을 이용할 수 있는 화면이 표시됩니다.

좌측의 [aws]를 클릭합니다.

[aws]-[US East]-[Lambda] 아래 생성한 Lambda 함수를 클릭하여 [Download]를 클릭합니다.

[Download] 후 'Select a workspace~' 입력칸이 나타나면 demo를 입력해줍니다.

입력 후 index.js 파일이 정상적으로 import 되는지 확인합니다.

작성돼있던 코드를 모두 지우고 아래 코드를 입력해줍니다.

<your region name>과 <your bucket name>의 경우 각자의 리전과 버킷명을 입력합니다.

const querystring = require("querystring");

const AWS = require("aws-sdk");
const S3 = new AWS.S3({
  region: "<your region name>"
});
const Sharp = require("sharp");

const BUCKET = "<your bucket name>";

exports.handler = async (event, context, callback) => {
  const response = event.Records[0].cf.response;

  const request = event.Records[0].cf.request;
  const params = querystring.parse(request.querystring);
  if (!params.s) { // example.com?s=100x100 의 형태가 아닐 경우 원본 이미지를 반환
    callback(null, response);
    return;
  }
  const uri = request.uri;

  const imageSize = params.s.split("x");
  const width = parseInt(imageSize[0]);
  const height = parseInt(imageSize[1]);

  const [, imageName, extension] = uri.match(/\/(.*)\.(.*)/);

  const requiredFormat = extension == "jpg" ? "jpeg" : extension;// sharp에서는 jpg 대신 jpeg 확장자를 사용
  const originalKey = imageName + "." + extension;
  try {
    const s3Object = await S3.getObject({ 
      Bucket: BUCKET,
      Key: originalKey
    }).promise();

    const resizedImage = await Sharp(s3Object.Body)
      .resize(width, height)  
      .toFormat(requiredFormat)
      .toBuffer();

    response.status = 200; 
      //cache 에서 이미지를 찾지 못한 경우이기 때문에 404가 발생하지만 우리가 예상했던 동작이기 때문에 200 으로 반환
    response.body = resizedImage.toString("base64");
    response.bodyEncoding = "base64";
    response.headers["content-type"] = [
      { key: "Content-Type", value: "image/" + requiredFormat }
    ];
    return callback(null, response);
  } catch (error) {
    console.error(error);
    return callback(error);
  }
};

코드를 수정 후 터미널에서 아래 작업을 순서대로 진행합니다.

ec2-user:~/environment $ cd ImageResizing_Function/

ec2-user:~/environment/ImageResizing_Function $ npm init -yes

ec2-user:~/environment/ImageResizing_Function $ npm install sharp

패키지 설치가 완료되면 현재 Lambda 환경에 패키지 관련 디렉토리가 추가된 것을 확인할 수 있습니다.

이제 설치한 패키지들을 Lambda 환경에 업로드 할 순서입니다.

[Uploda Lambda]-[Directory]에서 아래 디렉토리를 선택하고 [Open]을 클릭합니다.

Directory 빌드 여부 항목에선 No를 클릭합니다.

##업로드 시 'Security Token ~ expired' 에러가 표시된다면

-> Terminal에서 aws configure 명령어 입력 후 계정정보를 입력 -> Cloud9 새로고침 후 재시도

업로드가 완료되면 [코드 소스] 부분이 아래와 같이 표시됩니다.

함수 실행에는 문제가 없으므로 다음 과정으로 넘어가면 됩니다.

우측의 [작업]-[Lambda@Edge 배포]를 클릭합니다.

만약 Lambda 함수를 버지니아 북부 리전에 생성하지 않았다면 해당 버튼은 비활성화 돼있으므로 리전을 반드시 확인합니다.

수정해줘야 할 부분은 [CloudFront 이벤트] 부분입니다.

Lambda 함수는 S3 Origin에서 원본 이미지가 반환될 때 실행되기 때문에 오리진 응답(Origin Response) 이벤트를 클릭해줍니다.

[배포]를 클릭하면 현재 Lambda 함수가 배포되고 있는 것을 확인할 수 있습니다.

이제 CloudFront 뒤에 파라미터 값을 붙여서 실시간으로 이미지가 리사이징되어 표시되는지 확인해보겠습니다.

URL/파일명.jpg?s=widthxheight와 같은 형식으로 확인이 가능합니다.

지정한 사이즈대로 이미지가 리사이징되어 표시되는 것을 확인할 수 있습니다.

마무리

이상으로 본 실습을 마치도록 하겠습니다.

S3 저장소 용량, CloudFront 트래픽 비용 등이 많이 발생하고 있다면 Lambda@Edge를 활용하여 실시간 리사이징을 구현하는 것도 좋은 방법 중의 하나가 될 것 같습니다.

P.S 부족하거나 틀린 부분은 언제든지 댓글로 남겨주시면 감사하겠습니다!

[참고]

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html

Lambda@Edge 이벤트 구조 - Amazon CloudFront

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

https://engineering.huiseoul.com/lambda-%ED%95%9C%EA%B0%9C%EB%A1%9C-%EB%A7%8C%EB%93%9C%EB%8A%94-on-demand-image-resizing-d48167cc1c31

Lambda 한개로 만드는 On-demand Image Resizing

Lambda 단! 한개로 만드는 On-demand Image Resizing

engineering.huiseoul.com

쿠버네티스 Auto Scaling #1 (HPA, VPA)

JAEJUNG — Mon, 20 Nov 2023 15:04:58 +0900

쿠버네티스는 한정된 리소스를 유연하게 사용하기 위해 Auto Scaling 기능을 지원하고 있습니다.

Auto Scaling은 각 리소스에 대한 Metric 정보을 기반으로 동작하며 데이터를 수집하기 위해선 먼저 클러스터에 Metric Server가 구성되어 있어야 합니다.

Metric Server 배포하기

메트릭 서버는 클러스터 내 존재하는 Pod의 메트릭 정보를 실시간으로 수집해서 Kubernetes API 서버에 전달하는 역할을 수행합니다.

만약 메트릭 서버가 설치되지 않았다면 아래와 같이 'Metrics API not available'과 같은 에러가 표시됩니다.

설치 방법은 간단합니다.

아래 명령어를 통해 메트릭 서버 구성요소를 배포해줍니다.

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

메트릭 서버의 동작 과정은 아래와 같습니다.

https://malwareanalysis.tistory.com/659

설치가 완료되고 나면 정상적으로 메트릭 조회가 가능합니다.

추가로 아래 명령어를 통해 메트릭 서버가 수집한 데이터를 확인할 수 있습니다.

정상적으로 메트릭이 수집되는 것을 확인했으니 이제 본격적으로 Auto Scaling에 대해 알아보겠습니다.

Auto Scaling에는 크게 Pod Auto Scaling과 Node Auto Scaling이 있습니다.

Pod Auto Scaling

Pod는 쿠버네티스에서 생성 가능한 가장 작은 컴퓨팅 단위로 주로 컨테이너의 그룹을 의미합니다.

실제 애플리케이션이 Pod 위에서 구동되기 때문에 수요에 맞추어 Pod를 스케일링 하는 것이 굉장히 중요합니다.

스케일링은 크게 Scale In-Out(개수), Scale Up-Down(용량)이 있으며 쿠버네티스에선 각각 HPA(Horizontal Pod AutoScaling)과 VPA(Vertical Pod AutoScaling)으로 구현됩니다.

HPA(Horizontal Pod AutoScaling)

Horizontal은 '수평의' 라는 뜻으로 트래픽이 증가함에 따라 아래 그림과 같이 Pod의 개수를 늘려나가는 방식입니다.

HPA의 동작방식에 대해 살펴보겠습니다.

먼저 쿠버네티스에선 Pod의 개수를 관리할 수 있도록 ReplicaSet, Deployment, StatefulSet과 같은 오브젝트를 제공합니다.

HPA를 설정하면 Horizontal Pod AutoScaler가 레플리카셋의 크기를 조정할 수 있도록 AutoScaling 프로세스를 간헐적으로 실행하게 게 됩니다.

https://kimjingo.tistory.com/166

실행 주기는 kube-controller-manager의 --horizontal-pod-autoscaler-sync-period 파라미터 값에 따르며 default 15초입니다.

각 주기마다 컨트롤러 매니저는 정의된 메트릭에 대해 리소스 사용률을 질의합니다.

메트릭은 크게 CPU와 Memory값이 있으며 custom 메트릭을 사용할 수도 있습니다.

(참고링크: Scaling on custom metrics)

kubectl autoscale deployment php-apache `#평균 cpu 사용율` \
    --cpu-percent=50 \
    --min=1 `#최소값` \
    --max=10 `#최댓값`

Pod의 개수는 아래 알고리즘에 의해 결정됩니다.

원하는 레플리카 수 = ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]

예를 들어 현재 CPU 메트릭 값이 200m이고 원하는 값이 100m 인 경우 200 / 100 = 2 이므로 replica 수는 2배가 됩니다.

현재 메트릭 값이 50m이라면 50 / 100 = 0.5 이므로 replica 수는 반으로 줄게 됩니다.

만약 값이 1.0에 가깝다면 스케일링이 동작하지 않으며 이 오차 범위는 --horizontal-pod-autoscaler-tolerance 플래그를 지정하여 관리할 수 있습니다.(default 0.1)

테스트를 통해 부하 발생 시 실제로 pod의 개수가 증가하는지 살펴보도록 하겠습니다.

먼저 pod를 배포해줍니다.

> deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: php-apache
spec:
selector:
matchLabels:
run: php-apache
replicas: 1
template:
metadata:
labels:
run: php-apache
spec:
containers:
- name: php-apache
image: registry.k8s.io/hpa-example
ports:
- containerPort: 80
resources:
limits:
cpu: 500m
requests:
cpu: 200m

$ kubectl apply -f deployment.yaml                                                                           
deployment.apps/php-apache created

service를 배포해줍니다.

> service.yaml

apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

$ kubectl apply -f service.yaml                     
service/php-apache created

hpa를 배포해줍니다.

> hpa.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 50
        type: Utilization
    type: Resource
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache

$ k apply -f hpa.yaml
horizontalpodautoscaler.autoscaling/php-apache created

배포된 hpa 리소스를 보시면 타겟에 대한 메트릭 기준 값, 최소/최대 Pod 개수 등을 확인할 수 있습니다.

k get hpa -A
NAMESPACE   NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
default     php-apache   Deployment/php-apache   0%/50%    1         10        1          10s

이제 service에 부하를 주어 hpa가 정상적으로 동작하는지 확인해보겠습니다.

아래는 loop를 돌면셔 php-apache 서비스를 호출하는 pod를 생성하는 명령어입니다.

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

hpa를 모니터링하면서 실제 부하가 50%를 넘어가는 것을 확인합니다.

부하가 발생하면 pod 개수가 자동으로 scale out 되는 것을 확인할 수 있습니다.

VPA(Vertical Pod AutoScaling)

HPA를 통해 Pod의 개수가 수평적으로 확장되는 것을 확인했습니다.

이제 VPA를 통해 Pod의 크기가 수직 확장되는 것을 확인해볼 차례입니다.

Vertical은 '수직의' 라는 뜻으로 트래픽이 증가함에 따라 아래 그림과 같이 Pod의 크기를 늘리는 방식입니다.

VPA의 동작방식을 알아보겠습니다.

HPA에 Horizontal Pod AutoScaler가 pod의 메트릭을 추적하고 있다면 VPA에서는 Vertical Pod AutoScaler가 pod의 메트릭을 추적합니다.

만약 pod의 리소스가 부족하다면 pod를 Restart하여 리소스를 증가시킵니다.

https://kimjingo.tistory.com/166

테스트를 통해 pod의 리소스가 VPA에 의해 실제로 변화하는지 살펴보겠습니다.

먼저 VPA는 현재 베타 기능이기 때문에 Kubernetes 클러스터에서 기본 제공되지 않습니다.

따라서 VPA의 git 저장소에서 소스코드를 직접 다운로드 받아 설치해주셔야 합니다.

$ git clone https://github.com/kubernetes/autoscaler.git

다운로드 후에는 아래 경로의 스크립트를 실행하면 필요한 오브젝트가 구성됩니다.

./autoscaler/vertical-pod-autoscaler/hack/vpa-up.sh

vpa pod를 확인하면 admission-controller, recommender, updater 총 세 개의 pod가 생성된 것을 확인할 수 있습니다.

Pod가 VPA에 의해 Recreate 되는 과정은 아래와 같으며 각 Component가 어떤 역할을 하는지 보겠습니다.

https://www.kubecost.com/kubernetes-autoscaling/kubernetes-vpa/

Recommender

-> Metric Server로부터 pod의 메트릭 값을 읽어들여 적합한 리소스 값을 VPA에게 recommend하는 역할

Admission Controller

-> pod의 resource.request를 수정

Updater가 기존 pod를 종료시키면 kubernetes controller가 pod를 다시 생성하며 이때 Admission Controller가 mutant webhook으로 pod request를 최적값으로 수정합니다.

Updater

Recommender가 계산한 최적값에 따라서 다시 시작해야 할 pod를 결정하는 역할

예제 애플리케이션을 통해 테스트를 진행해보겠습니다.

먼저 아래 경로에서 예제 yaml 파일을 배포합니다.

kubectl apply -f autoscaler/vertical-pod-autoscaler/examples/hamster.yaml

yaml 파일 내용을 확인해보면

1. name이 hamster인 Deployment를 target으로 참조하는 VPA와

2. name이 hamster이고 replicas가 2인 deployment를 각각 정의해두었습니다.

vpa pod를 확인해보면 target pod의 최적값을 확인할 수 있습니다.

실제 deployment에 기재된 request 값과 VPA의 최적값이 다르기 때문에 pod가 restart 되는 것을 확인합니다.

이벤트를 좀 더 자세하게 확인하고 싶다면 kubectl get events를 사용할 수 있습니다.

적용만 해놓으면 리소스를 자동으로 할당해주기 때문에 간편해보이지만 VPA는 몇가지 알려진 제약사항이 있습니다. (Github 링크)

Whenever VPA updates the pod resources, the pod is recreated, which causes all running containers to be recreated. The pod may be recreated on a different node.
VPA cannot guarantee that pods it evicts or deletes to apply recommendations (when configured in Auto and Recreate modes) will be successfully recreated. This can be partly addressed by using VPA together with Cluster Autoscaler.
VPA does not update resources of pods which are not run under a controller.
Vertical Pod Autoscaler should not be used with the Horizontal Pod Autoscaler (HPA) on CPU or memory at this moment. However, you can use VPA with HPA on custom and external metrics.
The VPA admission controller is an admission webhook. If you add other admission webhooks to your cluster, it is important to analyze how they interact and whether they may conflict with each other. The order of admission controllers is defined by a flag on API server.
VPA reacts to most out-of-memory events, but not in all situations.
VPA performance has not been tested in large clusters.
VPA recommendation might exceed available resources (e.g. Node size, available size, available quota) and cause pods to go pending. This can be partly addressed by using VPA together with Cluster Autoscaler.
Multiple VPA resources matching the same pod have undefined behavior.

주된 내용은 pod가 restart되며 다른 노드에 pod가 생성될 수 있다는 점, HPA와 함께 사용하면 안되다는 점, 그리고 대규모 클러스터에서 완벽히 테스트되지 않았다는 점 등이 있습니다.

이 중에서 VPA, HPA를 왜 함께 사용하면 안되는지 궁금했습니다.

결국은 리소스의 평균 사용률을 기반으로 auto scaling 할 때 임계값에 도달하면 VPA와 HPA가 동시에 이벤트를 발생시켜서 충돌이 발생할 수 있다는 게 핵심인 것 같습니다.

이와 관련하여 discussion한 내용이 있는데.. 이해가 안가서 이건 차차 정리해놓아야겠네요

Pod Auto Scaling만으로는 쿠버네티스의 스케일링을 완벽히 수행하기에 한계가 있기 때문에 이제는 Node Auto Scaling을 알아야 합니다.

Node Auto Scaling은 쿠버네티스 Auto Scaling 2편에서 이어 작성하도록 하겠습니다.

Session Manager를 통해 EC2 인스턴스 접속하기(feat. CentOS)

JAEJUNG — Wed, 14 Sep 2022 12:23:09 +0900

Private Subnet에 위치한 EC2 서버에 접속하는 방법은 크게 두 가지가 있습니다.

1. Public Subnet에 Bastion을 두고 SSH 터널링으로 접속하는 법

2. AWS Session Manager를 활용하는 법

Bastion host를 두면 아래와 같은 장점이 있습니다.

1. AWS 웹 콘솔 접속 없이 cli로 프라이빗 서버 액세스 가능

2. 방화벽 설계를 단순화할 수 있음

그러나, Bastion 서버를 직접 구성해야 하고, 서버 비용과 key 파일을 관리해야 한다는 수고로움이 발생합니다.

Session Manager를 사용하면 위와 같은 작업이 불필요하게 됩니다.

Session Manager(이하 SSM)는 AWS 웹 콘솔 내 브라우저 기반의 Shell, CLI를 제공하여 Private Subnet에 위치한 서버에 액세스할 수 있는 완전관리형 서비스입니다.

SSM Agent가 이미 설치돼있는 서버는 아래와 같습니다.(자세한 링크는 여기)

Amazon Linux Base AMIs dated 2017.09 and later
Amazon Linux 2
Amazon Linux 2 ECS-Optimized Base AMIs
macOS 10.14.x (Mojave), 10.15.x (Catalina), and 11.x (Big Sur)
SUSE Linux Enterprise Server (SLES) 12 and 15
Ubuntu Server 16.04, 18.04, and 20.04
Windows Server 2008-2012 R2 AMIs published in November 2016 or later
Windows Server 2016, 2019, and 2022

타 AMI를 이용해 서버를 구성하면 수동으로 SSM Agent를 설치해주어야 합니다.

(공식 문서는 여기)

본 포스팅에선 CentOS 8을 기준으로 작성되었으며, 기본적인 인프라 구성이 완료되었다는 가정 하에 진행됩니다.

VPC 내 DNS 설정 변경

사용 중인 VPC를 클릭한 후 [Edit DNS hostnames]를 클릭해줍니다.

아래와 같이 [Enable]을 클릭한 후 변경사항을 저장해줍니다.

해당 옵션은 인스턴스의 public 혹은 private IP에 해당하는 DNS 주소를 제공해줍니다.

IAM Role 부여

Session Manger를 통해 접속할 인스턴스에는 SSM 서비스에 대한 액세스 권한이 존재해야 합니다.

먼저 "AmazonEC2RoleforSSM" 권한이 부여된 Role을 하나 생성해줍니다.

인스턴스에 IAM Role을 부여해줍니다.

[Connect]를 클릭하면 아래와 같이 4가지 방법을 통해 EC2 인스턴스에 접속이 가능합니다.

그 중 Session Manager를 클릭하면 아래와 같이 Connect 버튼이 비활성화되어 있는 것을 볼 수 있습니다.

SSM을 통한 접속이 불가능할 때 체크해야할 것은 크게 세 가지가 있습니다.

1. VPC의 DNS hostnames가 활성화되어 있는지

2. 적절한 권한이 할당된 IAM Role이 부여돼있는지

3. SSM Agent가 설치돼있는지

SSM Agent 동작 확인

1, 2번 항목은 조금 전에 설정을 완료했으므로 직접 서버에 접속해서 ssm agent가 동작 중인지 확인해보겠습니다.

(인스턴스에 eip 할당, rt에서 igw 추가)

확인 명령어는 아래와 같으며, ssm agent가 preinstalled 되지 않은 AMI이기 때문에 현재 동작 중인 서비스가 없다고 표시됨을 알 수 있습니다.

[centos@ip-10-0-10-155 ~]$ sudo systemctl status amazon-ssm-agent
Unit amazon-ssm-agent.service could not be found.

SSM Agent 설치

해당 인스턴스는 CentOS 8 버전이므로 AWS docs에서 제공하는 방법을 통해 agent 설치를 진행해줍니다.

[centos@ip-10-0-10-155 ~]$ sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
CentOS-8 - AppStream                            105  B/s |  38  B     00:00
Error: Failed to download metadata for repo 'AppStream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

*CentOS 7은 아래 명령어로 설치 진행

sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

명령어를 입력하면 위와 같이 Failed to download 에러가 발생합니다.

에러 로그를 확인해보면 No URLs in mirrorlist ~라고 표시되는 것을 확인할 수 있으며, 본 포스팅을 작성하게 된 이유이기도 합니다.

CentOS 8이 2021.12.31부로 EOS됨에 따라 CentOS Mirror site가 vault로 전환되었습니다.

mirror site는 네트워크 트래픽을 줄이기 위해 다른 서버로 파일을 복사해놓은 웹사이트 즉 파일 서버이며, mirror list는 이러한 mirror site를 모아놓은 list라고 보면 됩니다.

패키지를 다운로드 받을 서버를 찾지 못해서 발생하는 오류로, 아래 명령어를 통해 mirror site를 valut로 전환하면 이를 해결할 수 있습니다.

sudo sed -i -e "s|mirrorlist=|#mirrorlist=|g" /etc/yum.repos.d/CentOS-*
sudo sed -i -e "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-*

다시 명령어를 입력하여 설치를 완료해줍니다.

[centos@ip-10-0-10-155 ~]$ sudo dnf install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
CentOS-8 - AppStream                                            16 MB/s | 8.4 MB     00:00
...
...
Installed:
  amazon-ssm-agent-3.1.1767.0-1.x86_64

Complete!

ssm agent 서비스를 확인해보면 정상적으로 active 상태인 것을 확인할 수 있습니다.

[centos@ip-10-0-10-155 ~]$ sudo systemctl status amazon-ssm-agent
● amazon-ssm-agent.service - amazon-ssm-agent
   Loaded: loaded (/etc/systemd/system/amazon-ssm-agent.service; enabled; vendor preset: disab>
   Active: active (running) since Wed 2022-09-14 02:19:45 UTC; 20s ago

모든 설정을 마쳤으며, Session Manager 접속이 활성화된 것을 확인할 수 있습니다.

이상으로 설명을 마치며, 틀린 부분이 있다면 언제든지 피드백 부탁드립니다.

감사합니다.

Openswan을 활용한 AWS Site-to-Site VPN 구성하기

JAEJUNG — Tue, 2 Aug 2022 09:43:25 +0900

2.4 Customer Gateway 주소 확인 ( IDC )

2.5 Customer Gateway 생성 ( AWS )

2.6 VGW(Virtual Private gateways) 생성

2.7 VPN Connection 설정

2.8 VPN 구성 다운로드

2.9 Openswan 설치 ( IDC )

개요

두 사설망 간의 연결을 위해선 크게 두 가지 방법이 존재합니다.

1. 물리적인 전용선을 설치하여 연결하는 방식

2. 가상의 네트워크 망을 구성하여 연결하는 방식

전용선을 직접 연결하면 다른 이용자에 영향을 받지 않고 빠르고 보다 안정적인 통신이 가능하지만

그만큼 물리적인 연결이 필요하기 때문에 거리가 멀어질수록 회선 비용이 증가하게 됩니다.

대신 VPN(Virtual Private Network)이라는 가상의 통신만을 통해 네트워크를 연결하는 방식을 주로 활용합니다.

이번 포스팅에선 AWS의 Site-to-Site VPN 설정을 위한 과정을 설명합니다.

AWS와 IDC를 구분하기 위해 두 리전(서울-AWS, 오레곤-IDC) 간 환경을 구성하고, IDC에 Openswan을 설치하여 vpn을 위한 설정을 진행합니다.

Openswan이란 리눅스 상에서 구현된 IPSec VPN 오픈소스이며, IPSec VPN에 대한 자세한 내용은 여기를 참고해주세요.

최종 아키텍처는 아래와 같습니다.

환경 구성

아래 github 링크를 통해 HOL에 필요한 환경 구성을 위한 Terraform 코드를 준비합니다.

user@MZC01-WOWJD:~/Terraform_HOL$ git clone https://github.com/aboova/HOL_S2S-VPN.git

Key pair 생성

테라폼 코드 배포 전 미리 key-demo 이름을 가진 Key Pairs를 구성해놓습니다. (두 리전 모두)

Private key file format은 .pem 으로 설정합니다.

서울 리전은 AWS 환경, 오레곤 리전은 IDC 환경이라고 생각하면 됩니다.

user@MZC01-WOWJD:~/Terraform_HOL/HOL_S2S-VPN/terraform_AWS_seoul$ terraform apply

user@MZC01-WOWJD:~/Terraform_HOL/HOL_S2S-VPN/terraform_IDC_oregon$ terraform apply

인프라 아키텍처

위 코드로 인프라 구성 시 아래 아키텍처와 같은 환경 구성이 완료됩니다.

Ping 테스트

아직 VPN 설정이 되지 않았으므로, 동일 리전 간 통신은 가능, 서로 다른 리전 간 통신은 불가능한 상태임을 알 수 있습니다.

이제 HOL을 위한 기본 인프라가 준비됐으니, 아래 과정을 통해 VPN 구성을 진행합니다.

Customer Gateway 주소 확인 ( IDC )

먼저 IDC 측의 서버 IP를 확인합니다.

CGW는 Site-to-Site(이하 s2s) VPN 연결에 필요한 온프레미스 측의 Gateway 디바이스를 나타내는 AWS 리소스입니다.

Oregon 리전의 'Public-IDC-Server'의 퍼블릭 IP를 확인하시면 됩니다.

Customer Gateway 생성 ( AWS )

서울 리전에서 [VPC]-[VPN]-[Customer gateways] 항목에서 새로운 CGW를 생성해줍니다.

[Name tag] 값과 [IP address] 값을 입력해줍니다.

여기서 BGP ASN이란, 각기 다른 오퍼레이터가 관리하는 IP 서브넷을 식별하기 위해 고유하게 부여된 번호인데

이번 실습에선 default로 진행합니다.

VGW(Virtual Private gateways) 생성

[VPC]-[VPN]-[Virtual private gateways] 항목에서 새로운 VGW를 생성해줍니다.

CGW가 IDC를 위한 Gateway라면, VGW는 AWS를 위한 Gateway라고 생각하시면 됩니다.

[Name tag]를 입력하고 ASN은 default로 선택 후 생성을 진행해줍니다.

생성된 VGW를 VPC에 attach 시켜줍니다.

*VGW는 하나의 VPC에만 연결이 가능합니다.

VPN Connection 설정

[VPC]-[VPN]-[Site-to-Site VPN Connections] 항목에서 새 vpn 연결을 생성합니다.

Name tag와 함께 조금 전 생성했던 VGW, CGW를 선택합니다.Static IP prefixes는 IDC의 VPC IP 대역을 입력해줍니다.

- Local IPv4 network CIDR은 VPN을 통해 통신이 가능한 IDC 측의 추가 IP 대역

- Remote IPv4 network CIDR은 AWS 측의 추가 IP 대역을 의미하는데 여기선 default로 설정을 진행합니다.

설정을 완료하고 일정 시간이 지나면 State가 Available 상태로 변경됩니다.

아래 Tunnel details를 확인하면 VPN 터널의 Status가 Down으로 표시돼있는데, 이는 IDC 측의 VPN 장비 설정이 아직 이루어지지 않았기 때문입니다.

VPN 구성 다운로드

[Download configuration]을 클릭하여 vpn 구성에 필요한 정보를 다운받습니다.

[Vendor]를 Openswan으로 변경 후 Download를 클릭합니다.(.txt 파일이 다운로드 됩니다)

AWS 측에서 설정해야 할 작업은 끝났습니다.

이제 VPN 설정을 위해 IDC 측의 서버로 이동하여 필요한 작업을 진행하겠습니다.

Openswan 설치 ( IDC )

IDC(오레곤)의 퍼블릭 서브넷에 위치한 서버에 접속합니다. (Public-IDC-Server)

이미 userdata 스크립트를 통해 서버 구동 시 설치가 완료됐으므로, 해당 과정은 넘어가셔도 됩니다.

(깡통 서버에서 openswan 설치 시 yum -y install openswan 명령어를 사용하시면 됩니다.)

Network 설정

/etc/ipsec.conf 파일에서 include /etc/ipsec.d/*.conf 부분이 주석처리 되어 있지 않은지 확인해줍니다.

만약 주석처리가 되어 있다면 주석을 해제해주시면 됩니다.

[root@ip-10-50-0-41 ~]# cat /etc/ipsec.conf | grep "include /etc/ipsec.d"
include /etc/ipsec.d/*.conf

/etc/sysctl.conf 파일을 확인하여 아래 내용이 기입돼있는지 확인합니다.

(서버 구동 시 userdata를 통해 입력된 상태입니다.)

- net.ipv4.ip_forward를 활성화시킴으로써, 해당 시스템 안에서 커널이 처리하는 패킷에 대하여 외부로 forwarding 가능

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0

IPSec 설정

Tunnel 설정

/etc/ipsec.d/ 경로에 aws.conf 파일을 생성하고, vpn connection 생성 후 다운로드 받았던 txt 파일을 클릭합니다.

클릭하면 conn Tunnel1과 conn Tunner2 부분이 있습니다.

아래 표를 참고하여 해당 부분에 필요한 값을 기입해줍니다.

- leftid, right 항목은 각 사용자별 상이하므로 위 캡쳐본의 값과 다를 수 있습니다.

- 암호화 알고리즘의 변경으로 인해 phase2alg, ike 항목을 우측 표와 같이 변경합니다.

- leftsubnet은 IDC의 IP 대역, rightsubnet은 AWS의 IP 대역으로 수정합니다.

- 두 개의 터널에서 동일한 IP 대역을 설정하기 위해선 overlapip=yes 옵션이 필요합니다.

Before	After
phase2alg=aes128-sha1;modp1024	phase2alg=aes_gcm
ike=aes128-sha1;modp1024	ike=aes256-sha1;modp1024
auth=esp	#auth=esp
leftsubnet=<LOCAL NETWORK>	leftsubnet=10.50.0.0/16
rightsubnet=<REMOTE NETWORK>	rightsubnet=10.60.0.0/16
	맨 아랫줄에 overlapip=yes 추가

필요한 값을 수정하면 tunnel에 대한 설정은 아래와 같습니다.

    ...생략
    #auth=esp
        keyingtries=%forever
        keyexchange=ike
        leftsubnet=10.50.0.0/16
        rightsubnet=10.60.0.0/16
        dpddelay=10
        dpdtimeout=30
        dpdaction=restart_by_peer
        overlapip=yes

Secret 값 저장

/etc/ipsec.d/ 경로에 aws.secrets 파일을 생성한 후 .txt 파일을 참고하여 VPN 통신에 필요한 비밀 키를 저장합니다.

(vpn 구성 파일의 5) 항목을 확인하면 됩니다.)

[root@ip-10-50-0-41 ~]# cat /etc/ipsec.d/aws.secrets
44.228.63.198 3.36.136.43: PSK "PqJxLZwOjqpJW9gf6Npxu3qotylhokkS"
44.228.63.198 15.164.186.113: PSK "O1wH8pzOxYCwQVb6FWouOPyzzskfk0n5"

설정을 모두 완료했다면 IPSec 서비스를 재시작시켜줍니다.

[root@ip-10-50-0-41 ~]# systemctl restart ipsec.service

아래와 같이 loaded 2, active 2가 표시되면 터널 구성이 정상적으로 완료된 겁니다.

웹 콘솔에서 터널의 Status가 UP으로 변경된 것을 확인할 수 있습니다.

라우팅 테이블 수정

먼저 IDC 환경의 라우팅 테이블을 수정하겠습니다.현재 라우팅 세팅은 아래와 같습니다.

	Destination	Target
Public	0.0.0.0/0	igw-0ecf20c7ae6db7d5a
	10.50.0.0/16	local
Private	0.0.0.0/0	nat-0d4b912a1d3d4ca89
	10.50.0.0/16	local

VPN 구성을 완료했으므로, IDC 서버에서 AWS 측으로 전달되는 트래픽은 CGW, 즉 Openswan이 설치된 Public-IDC-Server로 향해야 합니다.

Public과 Private 라우팅 테이블에 Destination: 10.60.0.0/16, Target: [Instance]-[Public-IDC-Server] 항목을 추가해줍니다.

인스턴스 설정에서 [Public-IDC-Server]-[Networking]-[Change source/destination check]를 클릭합니다.

[Source / destination checking] 항목에서 Stop을 체크 후 Save 해줍니다.

해당 옵션은 해당 인스턴스 자체가 송수신되는 트래픽의 source/destination인지를 묻는 옵션인데,

NAT, VPN 등의 용도로 EC2 인스턴스를 사용하는 경우에는 해당 옵션을 Stop으로 변경해주어야 합니다.

AWS 환경의 라우팅 테이블 수정은 간단합니다.

Public과 Private 모두 트래픽이 VGW로 향하게 설정하면 됩니다.

Destination: 10.50.0.0/16, Target: [Virtual Private Gateway]-[vpntest-vgw]

결과

이제 각각의 서버에 접속해서 타 리전에 위치한 서버로 ping을 날려봅시다.

IDC Public -> AWS Public&Private

IDC Private -> AWS Public&Private

AWS Public -> IDC Public&Private

AWS Private -> IDC Public&Private

지정된 Gateway로 트래픽이 잘 향하는지 확인하려면 아래와 같이 라우팅 테이블에서 해당 항목을 추가/제거하는 방식으로 확인할 수 있습니다.

이것으로 Openswan을 활용한 AWS Site-to-Site VPN 설정 과정을 마무리하겠습니다.

오류/수정사항이 있다면 피드백 부탁드립니다. 긴 글 읽어주셔서 감사합니다.

CI/CD with Jenkins&ArgoCD

JAEJUNG — Tue, 3 May 2022 17:41:24 +0900

이번 포스팅에선 Jenkins와 Bitbucket, Harbor를 통해 CI/CD Pipeline을 구축하는 과정에 대해 설명한다.

전체 Architecture는 아래와 같다.

개발자가 Bitbucket으로 소스코드를 Push한다.
Push event를 트리거 삼아 Webhook이 Jenkins로 전달된다.
Jenkins에선 Bitbucket의 Jenkinsfile을 기반으로 docker image를 build하고 이를 Harbor에 push한다.
ArgoCD는 Bitbucket의 변경사항을 감지하여 이를 EKS Cluster에 배포한다.

사전 작업

Jenkins 서버에 Docker 설치

해당 포스팅에서 Jenkins는 Dockerfile을 빌드하는 역할을 한다.

따라서 Jenkins 서버에서도 Docker가 설치되어 있어야 하며, Docker를 사용할 권한도 있어야 한다.

이전 글인 EC2에 Jenkins 구축하기를 참고하여 jenkins가 구축된 서버에 Docker를 설치한다.

[root@jenkins docker]# sudo amazon-linux-extras install -y docker

[root@jenkins docker]# service docker start

[root@jenkins docker]# usermod -aG docker ec2-user

Harbor와 Jenkins 연동하기

harbor는 https 통신을 기본으로 하기 때문에 접속하기 위해선 인증서를 필요로 한다.

그러나 간단한 테스트를 진행하기 위한 http 통신도 지원하기 때문에 아래 링크를 참고하여 http로 harbor에 접속한다.

(링크: Connecting to Harbor via HTTP)

Jenkins docker daemon 설정

여기서 harbor로 접속하는 User는 jenkins이기 때문에 jenkins에서 먼저 설정을 진행한다.

http 통신을 위해선 Jenkins의 Docker daemon에 --insecure-registry 값을 추가해주어야 한다.

/etc/docker 하위 경로에 daemon.json 파일을 생성해주고,

key:value 형태로 key값에 insecure-registries, value에 harbor의 IP를 입력한다.

[root@jenkins docker]# vi /etc/docker/daemon.json

{
  "insecure-registries" : ["{harbor's domain}"]
}

jenkins에서 docker service를 restart 시켜준다.

[root@jenkins docker]# systemctl restart docker

docker info 명령으로 harbor의 IP가 추가되었는지 확인한다.

[root@jenkins docker]# docker info | grep -A 5 "Insecure Registries"
 Insecure Registries:
  0.0.0.0
  3.39.236.59 #harbor의 ip가 표시된다면 정상 적용 완료
  127.0.0.0/8

EKS Node 또한 pod를 배포하는 과정에서 harbor로부터 이미지를 pull하기 필요하기 때문에,

위에서 진행했던 동일한 과정을 EKS Node에서도 진행한다.

다만, EKS Node에는 이미 /etc/docker 경로에 daemon.json 파일이 존재하기 때문에 값을 추가만 해준다.

[root@ip-192-168-1-94 docker]# cat daemon.json
{
  "insecure-registries" : ["{Harbor의 IP}"],
  "bridge": "none",
  ...
}

값을 추가해준 후에 동일하게 docker service를 restart 시켜준다.

[root@ip-192-168-1-94 docker]# systemctl restart docker

Jenkins - > Harbor로 push, pull test

harbor에 액세스가 이루어졌으니, 이제 테스트 이미지를 통해 push/pull이 잘 되는지 확인해보자.

테스트 Image 준비

테스트 이미지로는 용량이 작은 alpine 이미지로 테스트를 진행한다.

[root@jenkins docker]# docker pull alpine

[root@jenkins docker]# docker images -a
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
alpine       latest    0ac33e5f5afa   4 weeks ago   5.57MB

harbor Repository 생성

먼저 harbor 웹 콘솔에 접속해서 새 repository를 생성해준다.

(Project Access Level을 Public으로 생성하면 docker login 안해도 됨)

[PUSH COMMAND]를 통해 harbor로 이미지를 push하기 위한 명령어를 확인할 수 있다.

harbor로 image push

harbor로 이미지를 push하기 위해선 기존 이미지의 태그명을 수정해주어야 한다.

[root@jenkins docker]# docker tag alpine 3.39.236.59/demo/image

[root@jenkins docker]# docker images -a
REPOSITORY               TAG       IMAGE ID       CREATED       SIZE
3.39.236.59/demo/image   latest    0ac33e5f5afa   4 weeks ago   5.57MB
alpine                   latest    0ac33e5f5afa   4 weeks ago   5.57MB

docker push 명령어를 통해 harbor로 이미지를 push해준다.

[root@jenkins docker]# docker push 3.39.236.59/demo/image

harbor에서 image가 업로드 된 것을 확인한다.

harbor에서 pull test

테스트를 위해 저장돼있는 docker image를 모두 삭제해준다.

docker rmi -f $(docker images -q)

이제 docker pull 명령어를 통해 harbor에 등록돼있는 이미지를 가져와보자.

[root@jenkins docker]# docker pull 3.39.236.59/demo/image
Using default tag: latest
latest: Pulling from demo/image
df9b9388f04a: Pull complete
Digest: sha256:a777c9c66ba177ccfea23f2a216ff6721e78a662cd17019488c417135299cd89
Status: Downloaded newer image for 3.39.236.59/demo/image:latest
3.39.236.59/demo/image:latest

등록된 docker image를 확인하여 harbor에서 image가 정상적으로 pull 됐는지 확인한다.

[root@jenkins docker]# docker images -a
REPOSITORY               TAG       IMAGE ID       CREATED       SIZE
3.39.236.59/demo/image   latest    0ac33e5f5afa   4 weeks ago   5.57MB

Jenkins에 harbor credential 등록

Jenkins가 파이프라인을 수행하는 과정에서 harbor에 접근할 수 있어야 하기 때문에(빌드된 image를 harbor에 push하는 과정) 사전에 Credential을 생성해준다.

harbor에서 Robot Account 생성

먼저 Harbor에 접속에서 [Robot Accounts]-[NEW ROBOT ACCOUNT]를 클릭한다.

Robot Account는 docker CLI와 helm CLI에서만 사용할 수 있는 특수 계정이며, Harbor interface에 로그인이 불가능하다는 특징이 있다.

일반 User와 다르게 Expiration time을 설정할 수 있고, Project 별 액세스 권한을 줄 수 있기 때문에 간단한 테스트 용도로 생성하기에도 적합하다.

Name은 test로 입력하고, [Cover all projects] 옵션은 활성화 시켜준다.

생성하게 되면 Secret 값이 부여되며, [EXPORT TO FILE]을 클릭하여 Credential 값을 보관한다.

Jenkins Credential 생성

Jenkins 웹 콘솔에 접속하여 [Jenkins 관리]-[Manage Credentials]-[Jenkins]를 클릭한다.

[Global credentials]를 클릭

좌측 탭에서 [Add Credentials] 클릭

Username, Password는 조금 전 생성했던 harbor robot account의 id와 password 값을 입력한다.

ID는 추후 pipeline 내에서 인식할 수 있는 credential의 ID로 harbor_credential로 기입하고,

Description은 harbor credential이라는 것을 알 수 있게끔 간단한 설명을 입력한다.

생성된 credential 확인

Jenkins 플러그인 설치

Jenkins를 사용하면서 추가적인 기능, 다른 서비스들과의 연동 등을 위해 다양한 플러그인을 제공한다.

이번 실습을 위한 plug-in 목록은 다음과 같다.

Generic Webhook Trigger Plugin
Bitbucket Plugin
Pipeline (Jenkins 최신 버전 설치 시 이미 플러그인이 설치되어 있을 수 있음)
Blue Ocean
Docker
Docker Pipeline

플러그인 설치를 위해 Jenkins 웹 콘솔에 접속하여 [Jenkins 관리]-[플러그인 관리]를 클릭한다.

[설치 가능] 탭에서 필요한 플러그인을 체크한 후 [Install without restart]를 클릭하여 설치해준다.

해당 옵션을 통해 여러 플러그인을 동시에 설치할 수 있다.

아래 [Jenkins 재시작] 버튼을 체크하여 플러그인 설치가 완료된 후 Jenkins 서버를 재시작시켜준다.

Bitbucket 설정

Bitbucket은 Gitlab, Github와 같은 Git 코드 관리 솔루션이다.

(세 가지 솔루션의 차이점에 대해 알고 싶다면 여기에서 확인)

계정 생성

계정 생성은 Bitbucket 에서 진행하며, 본 글에서는 생략하도록 한다.

Bitbucket Repository 생성

Bitbucket은 Repository의 상위 개념으로 Project가 존재하며, 관련된 Repository들을 한 Project로 묶을 수 있다.

두 개의 Repository하고, 동일한 Project 아래에서 관리할 것이다.

Bitbucket 콘솔에서 [Create]-[Project]를 클릭한다.

Name과 Description을 입력한다.

아래와 같이 두 개의 Repository를 생성한다.

Default branch의 경우 main으로 지정한다.

Jenkins Repository에 파일 업로드

Jenkins-test에 아래 파일들을 업로드해주자.

Dockerfile

FROM nginx:latest
COPY ./index.html /usr/share/nginx/html/index.html
CMD ["nginx", "-g", "daemon off;"]
EXPOSE 80

Jenkinsfile

script 아래 변수명은 각자 지정한 이름으로 설정한다.

USER: bitbucket username
BITBUCKET_SERVER: bitbucket server url
GITOPS_REPO: bitbucket k8s repo name
HARBOR_REPO: harbor의 image pull 경로
HARBOR_URL: harbor url
HARBOR_USERNAME: harbor username
GIT_SUFFIX: image registry name

↓↓↓코드↓↓↓

pipeline {
    agent any
    stages{
        stage('========== Clone repository ==========') {
            steps{
                script{
                    GIT_BRANCH = 'main'
                    USER = 'mz-ljj'
                    BITBUCKET_SERVER = 'bitbucket.org/mz-ljj'
                    GITOPS_REPO = 'k8s-test'

                    BUILD_ID = "${env.BUILD_NUMBER}"

                    HARBOR_REPO = '3.39.236.59/demo/testbuild'
                    HARBOR_URL= 'http://3.39.236.59/'
                    HARBOR_USERNAME = 'admin'
                    GIT_SUFFIX = 'testbuild'

                    checkout scm
                }
            }
        }
        stage('========== Build image ==========') {
            steps{
                script{
                    app = docker.build("${HARBOR_REPO}")
                }
            }
        }

        stage('========== Push image ==========') {
            steps{
                script{
                    docker.withRegistry("${HARBOR_URL}", "${HARBOR_USERNAME}") {
                    app.push("${env.BUILD_NUMBER}")
                    app.push("latest")
                    }
                }
            }
        }
        stage('========== clone yaml ========') {
            steps{
                script{
                        withCredentials([gitUsernamePassword(credentialsId: 'jenkins', gitToolName: 'Default')]) {
                            sh 'rm -rf k8s-test'
                            sh "git clone https://${USER}@${BITBUCKET_SERVER}/${GITOPS_REPO}.git -b ${GIT_BRANCH}"
                        }
                }
            }

        }
        stage('========== Deploy image ===========') {
            steps{
                script{
                    dir("${GITOPS_REPO}") {
                        withCredentials([gitUsernamePassword(credentialsId: 'jenkins', gitToolName: 'Default')]) {
                            sh 'git config --global init.defaultBranch main'
                            sh 'git branch -m \"main\"'
                            sh "git config --global user.email \"admin@jenkins.com\""
                            sh 'git config --global pull.rebase false'
                            sh "ls -al"
                            sh "sed -i \"s,${HARBOR_REPO}:.*,${HARBOR_REPO}:${env.BUILD_ID},g\" deployment.yaml"
                            sh "cat deployment.yaml"
                            sh "git add ."
                            sh "git commit --allow-empty -m \"[Jenkins] updateing image: to ${env.BUILD_ID}\" "
                            sh "git push origin ${GIT_BRANCH}"
                        }
                    }
                }
            }
        }
    }
}

index.html

deploy test 1:59 pm

k8s repository에 파일 업로드

k8s-test에 아래 파일들을 업로드해준다.

deployment.yaml

(미리 harbor에 nginx 이미지를 업로드해둔다.)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: 3.39.236.59/demo/testbuild:1
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: harbor

LoadBalancer.yaml

apiVersion: v1
kind: Service
metadata:
 name: nginx-service
 namespace: default
 annotations:
   service.beta.kubernetes.io/aws-load-balancer-type: external
   service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
   service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"
   service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "2"
   service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
   service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
   service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: "deregistration_delay.timeout_seconds=10, deregistration_delay.connection_termination.enabled=true" # supported values ["deregistration_delay.timeout_seconds=10, stickiness.enabled=true,stickiness.type=source_ip, proxy_protocol_v2.enabled=true, deregistration_delay.connection_termination.enabled=true, preserve_client_ip.enabled=true", stickiness.enabled=true,stickiness.type=source_ip]
spec:
 ports:
   - port: 80
     name: tcp-80
     targetPort: 80
     protocol: TCP
 type: LoadBalancer
 selector:
   app: nginx

Jenkins 파이프라인 설정

bitbucket webhook 설정

우리는 git repository에서 push가 발생했을 때 Jenkins에서 자동으로 빌드가 돼야 한다.

그러기 위해선 먼저 git repo에서 이벤트 발생 시 Jenkins가 이를 감지할 수 있는 수단이 필요하다.

그 역할을 이 webhook이 수행해줄 것이다.

Title은 자유롭게 입력하고,

URL의 경우 http://{Jenkins 서버의 IP}:8080/bitbucket-hook/으로 기입한다.

bitbucket token 생성

app password를 생성하면 최초 1회만 확인이 가능하기 때문에, 화면에 표시된 값을 기록해두어야 한다.

이제 Jenkins 웹 콘솔에서 새로운 Pipeline을 생성해보자.

먼저 General 탭에서 [Build when a change is pushed to BitBucket], [Generic on branch created] 옵션을 클릭해준다.

옵션을 아래와 같이 설정하고 Repository URL에 Bitbucket Repository의 URL을 입력한다.

# 아래와 같은 오류가 발생하면 Jenkins 서버에 git이 설치되지 않아서 표시되는 것으로 jenkins에 git을 설치해준다.

sudo yum install -y git

Repository URL을 입력하면 아래와 같은 오류가 발생한다.

이는 BitBucket의 Credential이 없어서 발생하는 오류이다.

아래 Credentials에서 [Add]-[Jenkins]를 클릭한다.

Username은 Bitbucket의 ID, Password 부분은 조금 전 생성했던 app password를 입력한다.

(id는 bitbucket_credential로 설정)

Branch는 main, Script Path는 Jenkinsfile로 입력한다.

이제 저장을 한 후 [Build Now]를 눌러 수동으로 빌드를 해보자.

[블루 오션 열기]를 클릭하면 빌드되는 과정을 대시보드 형태로 한 눈에 확인할 수 있다.

Harbor에 들어가서 빌드된 이미지를 확인해보자.

Webhook으로 자동 빌드 확인

수동 빌드가 아닌 git repo에 코드가 변경됐을 때 Jenkins에서 자동으로 빌드가 되는지도 확인해보자.

Bitbucket Repo에서 index.html 파일에 임의로 내용을 변경 후 commit을 클릭한다.

[Repository settings]-[Webhook] 탭에서 View requests를 확인한다.

로그를 확인해보면 push 이벤트에 대해 정상적으로 webhook이 보내진 것을 확인할 수 있다.

Jenkins로 돌아가보면 push 이벤트를 트리거 삼아 빌드가 실행되는 것을 확인할 수 있다.

ArgoCD로 앱 배포

bitbucket push 후 jenkins에서 자동으로 빌드가 실행되는 것까지 확인하였다.

이 과정까지가 CI(Continuous Integration)이며, 이제 CD(Continuous Deployment)를 완성시켜보자.

EKS에 harbor 인증정보 추가

먼저 harbor의 계정정보가 담긴 secret을 생성해주어야 한다.

deployment.yaml 파일을 보면 deployment가 배포될 때 spec.template.spec.imagePullSecret 값을 참조하여 컨테이너 이미지를 받아온다.

...
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: 3.39.236.59/demo/testbuild:1
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: harbor

아래 명령어로 secret 오브젝트를 생성해준다.

kubectl create secret docker-registry harbor --docker-server=http://<harbor 주소> --docker-username=admin --docker-password=Harbor12345

이제 ArgoCD에 Repository를 추가하고, app을 배포해보자

ArgoCD 설치 및 접속을 참고하여 ArgoCD 웹 콘솔에 접속한다.

[Settings]-[Repositories] 클릭

Repository URL: bitbucket의 k8s-test repository url

Username: Bitbucket 계정 ID

Password: Bitbucket 계정 app password

[CONNECTION STATUS]가 "Successful"로 표시되면 정상적으로 Repository와 연결된 것이며, "Create application"을 클릭한다.

Application Name: demo

Project: default

[SKIP SCHEMA VALADTAION] 옵션 활성화

Repository URL: bitbucket k8s-test repository url

Path: . 입력

Cluster URL: EKS Cluster

Namespace: default

현재 sync 옵션이 manual여서 OutOfSync인 상태로, SYNC를 눌러 Repository와 동기화시켜준다.

service와 deployment가 정상적으로 배포됐으며, service에 접속해보자.

service 도메인은 HOSTNAMES에서 확인할 수 있다.

현재 웹 서버에 아래와 같은 문구가 띄어져있는 상태이다.

이제 index.html 파일을 수정한 후 자동으로 빌드를 거쳐 pod에 배포되는지 확인해보자.

1. bitbucket에서 code 수정 후 commit

2. Jenkins 빌드

3. Harbor에 image push

4. ArgoCD sync

현재 bitbucket과 sync를 맞추고 있기 때문에 변경사항이 생기면 아래와 같이 OutOfSync 상태가 된다.

다시 한번 sync를 맞춘 후 service에 접속해보자.

-> 최종 배포된 Pod 상태 확인

결론

Jenkins와 ArgoCD를 활용한 CI/CD 파이프라인 구성을 통해 Source Repository에 소스코드를 push해주기만 하면

빌드 과정을 통해 인프라 자동화를 구현할 수 있었다.

EC2에 Jenkins 구축하기

JAEJUNG — Tue, 3 May 2022 13:13:17 +0900

Jenkins란

Jenkins는 소프트웨어 구축, 테스트, 전달 및 배포와 관련된 모든 종류의 작업을 자동화하는 데 사용할 수 있는 오픈 소스 자동화 서버이다.

서비스를 개발하는 과정에서 개발자들이 코드 작성 외에 Test, Build, Deploy 등의 번거로운 과정을 직접 하지 않고,

Pipeline 구축을 통해 자동화하여 처리할 수 있는 CI/CD 도구라고 할 수 있다.

Jenkins는 여러 장점이 있지만 대표적으로 아래와 같다.

무료
다양한 플러그인 지원
많은 사용자를 보유(레퍼런스 많음)

Jenkins 이외에도 Travis, GitLabCI 등의 다양한 CI 도구가 있으니 본인의 환경에 맞춰 적절하게 사용하면 될 것 같다.

설치 방법

JAVA 설치
Jenkins 설치

(원활한 실습 진행을 위해 root 사용자로 모든 작업을 진행했음.)

JAVA 설치

jenkins docs를 보면 Java 8 or Java 11 are required for running modern versions of Jenkins. 라고 되어 있다.

OpenJDK/JRE 8, 11도 지원하며, 이외 다른 모든 Java 버전은 지원되지 않는다고 한다.

(Jenkins 최신 버전은 Java 17도 지원한다고 함)

Java 버전을 선택하여 사용할 수 있으니, 1.8과 17 모두 설치해보자.

설치 경로는 아래와 같다.

JAVA 1.8 : https://docs.aws.amazon.com/ko_kr/corretto/latest/corretto-8-ug/amazon-linux-install.html

sudo yum -y update
sudo amazon-linux-extras enable corretto8
sudo yum install java-1.8.0-amazon-corretto-devel

[root@ip-10-0-1-57 ~]# java -version
openjdk version "1.8.0_332"

JAVA 17 : https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/amazon-linux-install.html

sudo yum install java-17-amazon-corretto-devel

[root@ip-10-0-1-57 ~]# java -version
openjdk version "17.0.3" 2022-04-19 LTS

alternatives 명령어를 통해 java version을 선택하여 사용할 수 있다.

[root@ip-10-0-1-57 ~]# alternatives --config java

There are 2 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
   1           /usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64/jre/bin/java
*+ 2           /usr/lib/jvm/java-17-amazon-corretto.x86_64/bin/java

Enter to keep the current selection[+], or type selection number:

Jenkins 설치

이제 Jenkins를 설치해보자

설치 경로는 아래와 같다.

https://www.jenkins.io/doc/tutorials/tutorial-for-installing-jenkinson-AWS/

먼저 패키지 업데이트 작업을 진행한다.

[root@ip-10-0-1-57 ~]# sudo yum -y update

Jenkins repository를 추가한다.

[root@ip-10-0-1-57 ~]# sudo wget -O /etc/yum.repos.d/jenkins.repo \
>     https://pkg.jenkins.io/redhat-stable/jenkins.repo

Jenkins의 public key를 import 해준다.

[root@ip-10-0-1-57 ~]# sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key

[root@ip-10-0-1-57 ~]# sudo yum upgrade

jenkins를 설치한다.

[root@ip-10-0-1-57 ~]# sudo yum install jenkins -y

이제 설치 작업이 완료되었다.

service 상태를 확인하고 start 시켜주자.

[root@ip-10-0-1-57 ~]# systemctl status jenkins
● jenkins.service - Jenkins Continuous Integration Server
   Loaded: loaded (/usr/lib/systemd/system/jenkins.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
   
[root@ip-10-0-1-57 ~]# sudo systemctl enable jenkins
Created symlink from /etc/systemd/system/multi-user.target.wants/jenkins.service to /usr/lib/systemd/system/jenkins.service.

[root@ip-10-0-1-57 ~]# sudo systemctl start jenkins

이렇게 active로 표시되면 서비스가 정상적으로 구동중인 것이다.

이제 Jenkins 웹 콘솔에 접속해보자.

브라우저에서 EC2의 Public IP:8080 형태로 입력하면 된다.

Administrator password는 /var/lib/jenkins/secrets/initialAdminPassword 파일을 확인하면 된다.

[root@ip-10-0-1-57 secrets]# cat /var/lib/jenkins/secrets/initialAdminPassword
40371389a9464b9eb8215ae81ed227c8

Jenkins에서 지원하는 plug-in을 설치하는 과정이며, 실습 진행을 위해 [Install suggested plugins] 옵션을 선택한다.

선택하면 아래와 같이 많이 사용되고 있는 plug-in 설치 과정을 볼 수 있다.

이제 Admin 계정을 생성하면 구축이 완료된다.

현재 URL은 EC2 인스턴스의 Public IP로 설정되어 있으며, [Save and Finish]를 눌러준다.

이것으로 Jenkins에 대한 설치 과정이 완료되었다.