LakeScript

Blog 이사갔습니다!!!

hosu4549@gmail.com — Sat, 19 Oct 2024 15:30:00 GMT

블로그 이전했습니다!

https://lakescript.net/ 에서 만나욥!

이사가는 이유는 유지보수를 하기 어렵다.. 그때그때마다 빌드해서 올리기도 귀찮다.. 등등 다양한 이유로 이전을 하기로 했습니다.

그리고 사실 여러 플랫폼을 고민했지만 티스토리를 선택한 이유는 커스텀 가능하고, 쉽게 글 쓸 수 있어서 선택하게 됐습니다요!

최근 프로젝트를 진행하면서 이 블로그를 보시는 분도 계셨기 때문에 없애진 않을 에정입니다.

하지만 포스팅을 새롭게 하진 않을 예정이니 새로운 블로그로 와주세요 :)

CKA, CKAD 취득 후기

hosu4549@gmail.com — Fri, 23 Feb 2024 08:20:00 GMT

들어가며

사내에서 Kubernetes를 도입하기 위해 공부하던 찰나 쿠버네티스 관련 자격증이 있다는 것을 알게 되었습니다. 하지만 당시에 자격증 취득을 위한 공부보단 하루 빨리 실무에 적용하기 급급했던터라 수박겉핥기 식으로 공부를 했었습니다. 그렇게 오직 이론보단 실무를 위하여 Kubernetes를 도입하여 운영했었고, 어느정도 시간이 지남에 따라 안정화가 되어 자격증을 공부를 하기 시작했습니다. (시기로 보자면 23년 11월부터 준비를 했네요.) 23년 12월에 2번의 시험을 본 후 연달아 불합격했고 24년 1월에 한 번 더 결제를 하여 2번을 보아 합격했습니다!(총 4번을 보았네요…) 그리고 바로 2주 뒤 45% 설날 세일때 이때다 싶어 CKAD까지 1번의 불합격에 이어 결국 합격을 했습니다..! (저만큼 불합격 받은 사람 없을 겁니다… 🤣🤣) 눈물겨운 시도끝에 포기하지 않는 마음으로 2024년에 계획했던 첫 목표를 이룰 수 있었습니다!

시험을 많이 보면서 노하우도 생겼고, 문제 유형도 많이 알게 되었고 무엇보다 시험 환경에 익숙해졌습니다. 이런 저의 경험을 후기로 남겨 봅니다. (많은 분들에게 도움이 되었으면 좋겠습니다!)

CKA

첫 번째 시험

첫 번째 시험은 Udemy의 강의만 수강하고 덤프도 풀어보지 않은채 ‘어차피 한번 더 기회있으니까 한번 봐 보자!’ 라는 생각으로 시험을 보았습니다.

결과 (처참한 결과…)

66%가 커트라인인데 저는 49%였습니다. 하하… 이 결과를 보고 충격을 먹기도 했지만 왠지 모를 자신감도 있었습니다.. (~~dump도 풀어보지 않고 봤는데 49점이라고?!~~)

두 번째 시험

두번째 시험은 Udemy의 CKA 강의에 수록되어있는 Mock Exam과 killer.sh를 어느정도 풀어본 후 도전했습니다. 이때 떨어지면 진짜 $395가 공중분해 되는 것이라… 어느 정도 마음의 부담감을 느끼며 준비를 하였고 시험을 보았습니다.

결과

이때까지도 대체 무엇이 틀렸는지 문제 자체는 알려 주지 않고 틀린 유형에 대해서만 알려 주어 난감했습니다. 하지만 2번의 기회가 없어진 터라 새로 자격증 응시를 구매해야 했고, 무엇보다 어떤 것이 틀렸는지 감을 잡을 수 없어 이성미 강사님의 따배씨 를 수강하였습니다.

세 번째 시험

$395(한화로 53만원)의 가격을 자랑하는 CKA를 어떠한 할인도 없이 응시하기엔 부담이 되서 할인하는 타이밍을 기다렸습니다. 그러던 중 24년 연초 세일로 25% 세일 쿠폰을 뿌려 바로 구매했고, 시험 날짜까지 바로 예약했습니다. 이때부터는 강의도 다시 들었고, Mock Exam도 완벽하게 외울 정도로 준비를 하였습니다. 그 후 killer.sh 도 풀어 보았는데, 난이도가 정말 어려워 하나의 session만 풀고 초기화 하고를 반복해서 풀어 보았고 해당 문제들의 오답 정리 수준으로 준비를 했었습니다.

결과 (역시나 탈락..)

이번 탈락으로 보니 공통적으로 제가 틀렸던 카테고리가 있었습니다.

Service & Networking
Cluster Architecture, Installation & Configuratoin
Storage
TroubleShooting

이 점을 지독하게 파고 들었고, 이때부터 Killer.sh 도 완벽하게 풀어보기로 했습니다. killer.sh 가 정말 도움이 많이 되었는데, 특히 2번의 session 에서 첫 번째 session은 시간 제한 없이 풀어 보았고 어느 정도 감을 잡은 후에 2번째 session은 시간 제한을 염두에 두고 풀어 보았습니다. 이때 느낀 건, 이 문제에서 원하는 것이 무엇인가를 명확히 인지하느냐가 문제를 푸는 데에 있어 크게 작용한다는 것이었습니다.

네 번째 시험

틀린 문제에 해당하는 문제 유형을 강의 노트에서 따로 정리해서 유형을 파악했고, killer.sh도 체계적으로 풀어 보았습니다.

2시간 동안 25문제 중 23문제 정도 풀어 본 것 같네요. 시간이 지난 후 score 확인 창에서 101점이라는 점수를 받고나서야 마음이 안심되었고 바로 다음날 시험을 보았습니다. (이때 시험 환경에 완벽히 적응하였습니다. 그래서 실제 시험을 볼 때 시간도 여유로웠고 무엇보다 긴장이 덜했습니다!!)

결과

90%의 정답률로 합격!

CKAD

첫번째 시험

(CKAD 후기 (Certified Kubernetes Application Developer) - 라온클)

CKAD는 CKA의 연장선이라고 들어서 별도로 공부하지 않았습니다. 시험에 출제된다는 커리큘럼을 보니 Job, CronJob, 배포 방식등 CKA에 해당 하지 않은 내용들은 시험을 보면서 직접 Doc에서 검색하여 풀었습니다. 왠지 모를 자신이 있었고 killer.sh 를 풀었을 때도 60점이라는 스코어가 나왔어서 더욱 자신이 있었습니다…

결과

하지만 정말 아쉽게도 66%를 맞아야 합격인데, 65%를 받아 1% 차이로 탈락했습니다. (후우….) 멘탈이 정말 많이 흔들렸고 “그냥 올해 후반기에 시험볼까” 싶었지만 시험에 대한 내용들을 잊을까 바로 1주일 후 시험 날짜를 예약해서 틀렸던 항목들, 풀면서 고민했던 부분들을 주로 공부하고 다시 응시하였습니다.

두번째 시험

killer.sh를 정말 열심히 풀었고, 스스로 시간 제한을 두고 풀었을 때 120점중 100점을 받았습니다. 또, 후기 글을 많이 찾아보고 첫번째 시험때 나왔었던 내용들을 복기해서 오답노트 식으로 만들어 숙지하고 시험을 봤습니다.

결과

86점의 득점으로 시험을 통과했습니다.. 길고 긴, 멀고 먼 시험 여정이 드디어 막을 내렸습니다…!

시험 후기

할인쿠폰

본래는 $395라는 부담이 되는 가격으로 응시를 해야 합니다. 하지만 할인 쿠폰을 자주 뿌리는 편이라 할인된 가격으로 응시하시는 게 더 확실히 이득입니다! 할인 쿠폰은 매일 올라오는 것이 아니라 특별한 시즌에 가끔씩 뿌리기 때문에 주기적으로 devopscube에서 확인하셔야 합니다. linkedIn 페이지도 있으니 팔로우 해놓으면 소식을 제때 받아 보실 수 있습니다. (저는 35%, 45% 쿠폰을 받아 사용했습니다!)

CKA

강의

Udemy - certified kubernetes administrator with practice tests
Youtube - 따배씨 (따라 배우는 CKA)

Dump

Udemy- certified kubernetes administrator with practice tests (Mock Exam)
killer.sh

문제 유형

최대한 기억나는 것만 적어 보면 아래와 같습니다.

notReady 상태인 Node를 ready 상태로 변경 (kubelet restart )
Pod의 log 확인 후 특정 경로에 저장하기 (kubectl logs )
특정 node를 drain 후 uncordon 하기 (kubectl drain , kubectl uncordon )
run 상태인 특정 파드에 sidecar container 생성 하여 로그 저장하기 (volumes mount)
각각 다른 ENV를 가진 multi container pod 생성하기
문제에 정의된 상황에 맞는 network policy 생성하기 (namespace selector, pod selector, ports)
CPU 가장 많이 할당된 Pod 이름 특정 경로에 저장하기 (kubectl top )
ETCD Backup & Restore
kubeadm version 업그레이드 & kubelet, kubectl 업그레이드

CKAD

강의

따로 듣지 않음

Dump

killer.sh

문제 유형

최대한 기억나는 것만 적어 보면 아래와 같습니다.

canary 배포
sidecar container (kubect edit)
netowrk policy를 건들지 않고 network 설정 (kubectl label)
주어진 조건에 따른 cronJob 생성
pod 생성 (kubectl run)
deployment 생성 (kubectl create deploy)
nodePort type의 service 생성 (kubectl expose)
replicas를 늘리고, 이미지를 바꾼 후 다시 undo (kubectl rollout)
service account 생성 (kubectl create serviceaccount generic)
resource 설정 (request, limit)
readinessProbe, livenessProbe 설정
Docker file 핸들링

메일

시험에 떨어지면 하나의 메일이 오게 되고, 합격하게 되면 3개의 메일이 오게 됩니다. (그래서 시험을 보고 24시간이 지난 후 메일이 왔다는 알림이 올 때에 한번만 진동이 느껴지면 불합격임을 인지했고, 2번 이상온다 하면 합격임을 인지하고 결과를 확인했습니다..)

불합격시 메일 제목

Your score for the CKA Exam & How to Claim your Retake

합격시 메일 제목

Your Exam Results for the CKA Exam
'Certified Kubernetes Administrator (CKA)' certificate granted!
Lee! You just earned a badge from The Linux Foundation

Reference

https://lifeoncloud.kr/entry/ckad

쿠버네티스에서 Pod의 생애주기

hosu4549@gmail.com — Wed, 03 Jan 2024 04:50:00 GMT

들어가며

최근에 면접을 본 곳에서 한가지 질문을 받았습니다.

🗣 : "Pod의 LifeCycle에 대하여 설명해주세요."

여태 K8s Cluster나 Control Plane의 구성 요소, Pod가 생성되는 과정에 대해서만 질문을 받았었는데 막상 쿠버네티스에서 가장 작은 컴퓨팅 단위인 Pod에 대해서는 나름 공부하지 못했던 것 같다는 생각이 들게 되었습니다.

그렇기에 이번에 정리를 해보았습니다.

Pod phase (Pod 단계)

Pending

Pod가 쿠버네티스 클러스터에서 생성되는 것에 승인되었지만 Pod에 정의된 하나 이상의 컨테이너가 아직 실행되지 않았음을 뜻하는 상태입니다.
Pod가 Schedule되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함됩니다.

Running

Pod가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다는 상태입니다.
적어도 하나의 컨테이너가 여전히 활성 상태이거나 시작 또는 다시 시작되는 중입니다.

Succeeded

Pod에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것임을 알려주는 상태입니다.

Failed

Pod에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 Pod가 종료되었다는 상태입니다.
즉, 해당 컨테이너가 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었음을 뜻합니다.

Unknown

어떤 이유로 Pod의 상태를 알 수 없으며, Pod 호스트와의 통신 오류로 인해 발생했을 가능성이 높습니다.

Pod의 phase는 Pod 객체의 status 필드 중 하나입니다. 그렇기에 Pod의 phase를 확인하려면 아래와 같이 명령하면 확인할 수 있습니다.

$ kubectl get po my-app -o yaml | grep phase
phase: Running

$ kubectl describe po my-app
Name:         my-app
Namespace:    default
...
Status:       Running
...

$ kubectl get po my-app
NAME    READY   STATUS    RESTARTS   AGE
my-app   1/1     Running   0          40m

Pod Conditions (Pod 조건/상태)

PodScheduled

Pod가 노드에 예약되었는지 여부를 표시합니다.

Initialized

Pod의 초기화 컨테이너가 모두 성공적으로 완료되었음을 표시합니다.

ContainersReady

Pod의 모든 컨테이너는 준비가 되었음을 표시합니다.

Ready

Pod가 클라이언트에게 서비스를 제공할 준비가 되었음을 표시합니다.

위의 조건은 모두 충족되거나 충족되지 않습니다. PodScheduled Initialized은 처음부터 충족되지 않고 실행되지만 곧 충족되고 Pod가 실행되는 동안 유지됩니다. 반면 ContainersReady, Ready 조건은 Pod가 실행되는 동안 여러 번 변경될 수 있습니다.

Pod의 condition을 보려면 kubectl describe 명령어로 확인할 수 있습니다.

$ kubectl describe po my-app | grep Conditions: -A5
Conditions:
  Type              Status
  Initialized       True            # Pod가 초기화 되었다.
  Ready             True            # Pod와 Container가 준비되었다.
  ContainersReady   True            # Pod와 Container가 준비되었다.
  PodScheduled      True            # Pod가 Node에 Schedule되었다.

하지만 kubectl describe 명령은 결과값이 boolean 입니다. false인 이유를 찾으려면 Pod의 manifast를 확인해야 합니다.

$ kubectl get po my-app -o json | jq .status.conditions
[
  {
    "lastProbeTime": null,
    "lastTransitionTime": "2024-01-03T11:42:59Z",
    "status": "True",
    "type": "Initialized"
  },
  ...

Container Status(Container 상태)

Waiting

컨테이너가 시작되기를 기다리고 있음을 나타내는 상태입니다.
reason 및 message 필드에서 컨테이너가 이 상태에 있는 이유에 대해 명시합니다.

Running

컨테이너가 생성되었으며 컨테이너에서 프로세스가 실행 중임을 나타내는 상태입니다.
startAt 필드는 이 컨테이너가 시작된 시간을 나타냅니다.

Terminated

컨테이너에서 실행 중이던 프로세스가 종료되었음을 나타내는 상태입니다.
startAt 및 doneAt 필드는 컨테이너가 시작된 시기와 종료된 시기를 나타냅니다. 기본 프로세스가 종료되는 종료 코드는 exitCode 필드에 있습니다.

Unknown

컨테이너의 상태를 확인할 수 없음을 알려주는 상태입니다.

$ kubectl describe po my-app | grep Containers: -A15
Containers:
  kubia:
    Container ID:   docker://c64944a684d57faacfced0be1af44686...
    Image:          nginx
    Image ID:       docker-pullable://luksa/kubia@sha256:3f28...
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running                                     # 컨테이너의 현재 상태
      Started:      Web, 03 Jan 2023 12:43:03 +0100             # 컨테이너의 시작 시기
    Ready:          True                                        # 컨테이너가 서비스를 제공할 준비가 되었는지 여부
    Restart Count:  0                                           # 컨테이너가 다시 시작된 횟수
    Environment:    <none>
    Mounts:
      ...

CrashLoopBackOff

컨테이너가 시작한 후 실패하였고 Kubernetes가 재시작을 시도하고 있지만 반복적으로 실패하는 상태입니다.

ImagePullBackOff

Kubernetes가 컨테이너 이미지를 가져오려고 시도하고 있지만 실패한 상태입니다.

ErrImagePull

ErrImagePull은 첫 번째 시도에서 실패했을 때 나타나고, ImagePullBackOff는 계속해서 시했지만 실패했음을 나타냅니다.

InvalidImageName

지정된 컨테이너 이미지 이름이 잘못되었거나 존재하지 않아 이미지를 가져올 수 없는 상태입니다.

Pod lifecycle

초기화

Pod가 생성되고, 필요한 리소스 할당 및 스케줄링을 기다립니다. 이때는 Pod가 아직 실행 준비가 완료되지 않았고, 초기화 컨테이너가 아직 실행되지 않았으므로 컨테이너가 아직 준비되지 않았습니다.

Pod phase : pending
Pod condition :PodScheduled: True, Ready: False, Initialized: False,ContainersReady: False
container status: Waiting

실행 준비

Pod가 노드에 스케줄링되고, 컨테이너가 시작됩니다. 이때는 Pod가 노드에 스케줄링되었고, 초기화 컨테이너도 실행되었지만 모든 컨테이너가 아직 준비되지 않았습니다.

Pod phase : running
Pod condition :PodScheduled: True, Ready: False, Initialized: True, ContainersReady: False
container status: running

정상 운영

Pod가 정상적으로 작동하고, 모든 컨테이너가 정상적으로 실행 중입니다. 이때는 Pod가 노드에 스케줄링되었고, 모든 초기화 컨테이너가 성공적으로 시작되었고, 모든 컨테이너가 준비 상태로 서비스 요청을 처리할 준비가 되었습니다.

Pod phase : running
Pod condition : PodScheduled: True, Ready: True, Initialized: True, ContainersReady: True
container status: running

종료

Pod 내의 모든 컨테이너가 작업을 완료하고 종료합니다. 이때는 Pod가 노드에 이미 스케줄링되었고, 초기화 단계도 이미 완료되었지만 Pod가 종료되었으므로 컨테이너가 준비 상태가 아니므로 더 이상 요청을 처리할 수 없습니다.

Pod phase : succeeded, failed
Pod condition : PodScheduled: True, Ready: False, Initialized: True, ContainersReady: False
container status: terminated

오류 상황

컨테이너가 실패하거나 (CrashLoopBackOff), 이미지를 가져오지 못하는 경우 (ImagePullBackOff, ErrImagePull) 등의 오류가 발생하면, Pod는 여전히 Running 상태일 수 있지만, Container Status는 Waiting 상태를 보여줍니다. 이때는 Pod가 노드에 이미 스케줄링되었고, 컨티에너 초기화가 안되거나 되었는데 오류가 있는 컨테이너가 있거나 Pod가 정상적으로 작동하지 않았습니다.

Pod phase : running
Pod condition : PodScheduled: True, Ready: False, Initialized: False, ContainersReady: False
container status: waiting

요약

Pod Phase

Pod의 전체 상태를 나타내는 값.
pending, running, succeeded, failed, unknown이 존재.

Pod Conditions

Pod가 생성되어 실행되는 상태를 나타내는 값.
PodScheduled, Initialized, ContainersReady, Ready 가 존재

Container Status

Pod안에는 Container가 있어, Container마다 State가 있고 Container의 상태를 나타내는 값.
waiting, running, terminated, unknown이 존재

Reference

2023년 회고

hosu4549@gmail.com — Sat, 30 Dec 2023 04:00:00 GMT

들어가며

안녕하세요! 2023년에는 무슨 일을 했었고, 개인적으로 어떤 변화가 있었는지, 목표했던 것을 이루었는지 회고를 한번 해보려고 합니다.

평소 개인적으로 회고를 하는 타입이어서 개인 회고는 따로 진행했는데요. 좀 다른 성격인 업무적, 커리어적 회고는 블로그를 통해 진행해보려고 합니다. (업무보단 커리어에 대한 고민이 주를 이루네요)

내가 무엇을 했지?

업무적으로 무엇을 했지?

Kubernetes를 활용한 컨테이너 운영 환경의 서버 환경을 운영 서버에 적용

2022년에 개발서버와 스테이징 서버에는 k8s의 컨테이너 운영 환경을 적용해놓고 피드백을 받으며 운영 중이었습니다! 안정성이 충분히 증명되었고, 운영서버에 배포했을 때에 또 다른 이슈가 수집 될 것이고 하루 빨리 배포하여 그것을 수집하여 해결하는 것이 더 낫겠다 라는 판단하에 2023년 1분기에 운영 서버에도 배포하였습니다.

결과는 아주!! 성공적!!! 쿠버네티스의 여러 장점 중 재해 복구 가 너무 좋았습니다ㅜㅜㅜㅜ 기존엔 새벽에 문제 생기면 즉시 서버에 들어가서 다시 excute 시켰는데,, 쿠버네티스를 도입하고 나서는 새벽에 문제가 생겨도 다음날 업무시간에 파악 및 해결 할 수 있으니,,, 후후 (+ 다양한 오픈소스도 너무 좋았습니다!!!)

PLG Stack 구축

기존에 모니터링 시스템으로 AWS OpenSearch를 활용하여 EFK Stack을 구축해놓았었는데, 비용이 상당했습니다.. 그렇기에 하루 빨리 교체가 필요했는데, 개인적으로 Prometheus와 Loki, Grafana를 경험해보고 싶어 해당 Stack으로 구축했습니다. 자세한 내용은 포스팅을 참고해주세요!

VPN 구축

개발팀이 워케이션을 떠나기도 하고, 호주에 계신 개발자분이 계셔서 여러 보안적인 이슈에 의해 VPN을 구축했습니다. 이것도 충분한 시간을 갖고 VPN의 원리부터 하나하나 파고들어야 하지만,, 급하게 구축을 했어야 해서 AWS에서 제공해주는 Workshop 을 기초로 작업을 진행했습니다.

Jenkins에서 Github Action으로 전환

사내에서 다양한 Devops 시스템을 구축해서 사용하다보니 간소화해야 할 이슈가 생겼습니다. (서버 비용 줄이자는 이슈도 있었습니다.) 그래서 여러 CI 파이프라인 솔루션을 찾던 도중 어차피 사내에서 Github을 통해 코드를 관리하고 있으니 같은 페이지에서 바로 확인할 수 있게 github action을 한번 도입해보자라는 마음으로 구축했습니다. 전환하면서 기존에 불필요했던 ci Stage도 수정하고, base imgae도 경량화 하고, 최대한 cache를 활용하여 build 시간을 줄일 수 있게 되었어요. 개발팀이 코드 병함과 리뷰는 github에서, 빌드는 jenkins에서, 배포는 argo에서 각각 다른 브라우저를 사용해야 했는데, 이번 전환으로 github에서 코드에 관해서는 이동없이 한 곳에서 진행하게 되어 매우 편리하다고 해주었습니다 흐흐 ( slack bot도 한 몫!)

개인적으로는 무엇을 했지?

독서 24권!

	읽은 책 목록	성격
1	김미경의 마흔수업	자기계발
2	데미안	인문학
3	이어령의 마지막 수업	자기계발
4	태도의 말들	자기계발
5	말의 품격	자기계발
6	관계에도 연습이 필요합니다	자기계발
7	참 괜찮은 태도	자기계발
8	어떤 생각들은 나의 세계가 된다.	자기계발
9	모두를 움직이는 힘	자기계발
10	챗GPT 거부할 수 없는 미래	IT
11	내 안의 어린 아이에게	에세이
12	테크커리어	IT
13	매니징 쿠버네티스	IT
14	모두의 네트워크	IT
15	IT개발자의 영어필살기	자기계발
16	K 배터리 레볼루션	경제
17	말랑말랑 생각법	자기계발
18	한자줍기	에세이
19	한 권으로 끝내는 네트워크 기초	IT
20	하나님의 열심	종교
21	소프트 스킬	IT
22	자기만의 트랙	자기계발
23	당신을 더 좋은 회사를 다닐 자격이 있다	자기계발
24	그림으로 배우는 AWS 구조	IT

2023년에 계획했던 목표였던 25권을 못채웠네요,, 🥲 그래도 독서를 꾸준히 하자라고 목표를 세운 첫해에 만족스러운 결과라고 생각합니다!!! (무한 긍정,,)

저는 주로 주변에 좋은 사람들에게 제가 읽었던 책중 인상깊고, 선물 받을 사람에게 필요할 만한 책을 선물해주는데요. 올해에 선물을 많이 했었고, 2023년에 읽었던 책 중 올해의 책 Top3를 선정하자면 아래와 같습니다!

이어령의 마지막 수업 (https://product.kyobobook.co.kr/detail/S000001860182)
말랑말랑 생각법 (https://product.kyobobook.co.kr/detail/S000201350451)
자기만의 트랙 (https://product.kyobobook.co.kr/detail/S000200688253)

각각 링크를 걸어두었으니,, 꼭 한번은 읽어보시길,,,!

맥북 Air 구매

드디어!! M2 8코어, GPU 10코어, 512GB, 16GB의 스펙을 가진 개인 노트북을 구매하게 되었습니다 !! 🎉🎉

여러 컨퍼런스와 세미나를 다니면서 수집한 스티커를 붙이면서 재미를 더했어요!!

하지만,, 어느 순간 노트북을 딱 보는데 머리가 너무 아파서 다 떼고 핵심만 붙여놨습니다 하하… (지금은 다 뗏어요!!!!)

세미나, 밋업 15곳 참석

자칭 세미나 쟁이인 저는 올해에도 많은 세미나 및 컨퍼런스, meetup에 참석했는데요. 정말 많은 인사이트와 경험을 얻을 수 있었습니다!!

특히, 7월에 진행했던 Kubernetes Community Day는 실제로 업무적으로 도움이 되는 세션들이 많아서 유익했고, 10월에 진행했던 AWS Industry Day에서는 많은 회사에서 AWS를 사용해서 어떻게 그들만의 고민을 해결했는지에 소중한 경험을 들을 수 있었던 시간이었어요!

그리고 저기에는 기록되어 있지 않지만 2023 느린밤도 너무 좋았습니다! 매년 참석할 예정이에요 흐흐

2024년에는 더 많은 세미나를 참석하면서 트랜드를 쫒고, 제가 얻을 수 없는 귀한 경험을 간접적으로 느껴볼 수 있도록 더더욱 열정을 갖고 동향을 살피도록 하겠습니다!!

링크드인 가입

처음으로 LinkedIn에 가입해서 커리어 적으로 SNS 생활을 했습니다. 정말 다양한 영역에서 영향을 미치는 사람들이 있어 그들의 소식을 접할 수 있었고, 개인적으로 요 근래에 가장 많이 사용하는 APP이 되었습니다. 특히 Devops 그룹에 가입하여 올라오는 꿀팁들을 짧게나마 보는 것도 상당히 도움이 많이 되더라고요! 저의 블로그 포스팅도 업데이트로 올려놓으면 반응도 꾸준히 수집되어 너무 유익했습니다! 특히 이직, 구직활동할 때에 관심 있는 서비스를 하는 회사의 채용공고가 올라오면 링크드인으로 먼저 해당 기업을 살펴보기도 하고, 해당 회사의 속해있는 엔지니어와 개발자들을 보면서 정보를 얻기도 하니 매우 유용합니다!

닌텐도 스위치 구매

평소 게임을 그렇게 좋아하지 않지만,, 과감히 블랙프라이데이 때 구매했습니다!! 어렸을 때 정말 재밌게 했던 포켓몬스터 게임이 떠올라 포켓몬스터 스칼렛도 같이 구매했고 구매한지 2주만에 다 깻네요 ㅎㅎㅎ

가끔 취미로 한두시간씩 할 생각으로 구매했는데, 매우 만족하고 있습니다!! (게임 추천해주세요…..)

주저리주저리

권고사직

2023년에는 2022년의 성과를 토대로 성공적인 연봉협상을 이루어내어 만족스러운 보상에 이어 Devops Engineer로서 전문성을 키우기로 목표했던 해 인데요. 하지만 회사의 재정적인 문제로 인해 더이상 함께 하지 못하게 되었습니다. (이직 준비를 Start,,,)

이직 준비,, 하지만 연이은 불합격

회사에서 이야기를 해주기 전에 이력서를 최신화하면서 시험(?) 삼아 몇 군데를 지원해 보기 시작했었는데요. 운 좋게 서류 통과하고, 과제 전형도 통과하고 면접을 보게 된 곳도 꽤 많았습니다. 하지만 1차 면접에서 대부분 탈락하게 되었는데, 제 능력이 너무나도 부족하다는 것을 새삼 깨닫게 되었습니다. 그래도 꾸준히 2023년에 이직을 하기 위해 면접을 보고 있었는데, 결과는 ALL Failed!

원인은 전문성

회사의 규모상 하나를 구축하기 위해 개념 정리를 탄탄하게 하고 구축하는 것보다 빠른 실행에 의해 피드백을 받고 보다 빨리 구축해야 했습니다. (그래도 어느 정도 개념은 잡고 했습니다!) 그래서 제가 생각했던 계획은 빨리 구축하고, 안정화를 거쳐 고도화를 진행하면서 DEEP 하게 파고들어 가 보자! 였습니다. 이런 생각에 의해 하나의 시스템을 구축할 때 생각보다 얕게, 기능에만 문제없을 정도로만 개념 정리를 하고 구축하게 되었습니다. 그러다 보니 면접에서 제가 구축한 시스템에 대해 꼬리 물기식으로 질문을 이어가게 되면 머릿속으로는 그려지는데 말로 설명하지 못하는 상태가 되었습니다. (제가 생각하는 제 것으로 만든 지식은 남들에게 해당 내용에 대해, 개념에 대해 처음 접하는 사람들도 쉽게 이해할 수 있게 설명하는 것이라고 생각하는데… 이것을 못 하니 제 것이 아니었습니다.)

그래서?

2023년 12월부로 저는 다시 백수로 돌아갑니다. 하지만 이직에 급하게 달려들진 않으려고 합니다. 저에 대해 먼저 탐구를 해보고, 제가 지원해 보고 싶은 회사가 무엇인지 목록화해 보려고 합니다. (이미 완료!) 그다음 전문성을 기르기 위해 제가 구축했던 시스템들에 대해 공부를 하고, 자격증을 공부하면서 1~2월을 보내려고 합니다. 하지만 공백기를 길게 갖진 않고, 꾸준히 지원해 보려고 합니다! (좋은 기회가 있을 수 있으니…ㅎㅎ)

하지만,, 시작이 좋지 않다,,,

자격증 취득을 목표로 하고 12월에 공부를 제대로 시작하고 12월 28일에 CKA 시험을 보게 되었습니다! 사실 14일에도 시험을 응시했었는데, 예약한 스터디룸의 문제로 인해 시험을 못 보게 되었습니다.. 억울하지만 다시 멘탈을 붙잡고 28일에 응시를 하고 보게 되었는데 결과는 탈락이었습니다. ㅜㅜ (제 점수 : 57 / 통과 점수 :66)

(,,, 내 $395,,,, 또 사야한다니,,,) )

2023년 정리

한 마디로 “최악의 해” 였습니다.

회사의 권고사직, 자격증 불합격, 2023년에는 이직 실패.. 최고의 스타트로 시작했던 해를 최악의 결과로 마무리 짓게 되었습니다 😢

하지만, 늘 그렇듯 시련은 저를 더 단단하게 만들어 준다는 것을 믿어 의심치 않기에!!! 저는 잘 될것임을 믿기에!!

2024년는 기똥찬 한 해가 될 것을 기대해 봅니다!

그래서 2024년엔 뭐 할건데?

자격증 따보자!

2024년엔 개인적으로 전문성을 더하기 위해 자격증을 공부하려고 해요!

CKA
AWS Cloud Practitioner
AWS Solutions Architect
Terraform Associate (003)
Linux System Administration(LFCS) : 큰 도전!

취득을 해보면서 계속 추가할 예정입니다!!

독서

2023년보다 더 많이!! 최소 24권 이상 독서를 해보려고 합니다! 기록의 중요성을 알기 때문에 읽은 책은 제때 제때 느낌점과 인상깊었던 부분을 따로 기록하려고 합니다! (좋은 책이 있다면 언제든 추천해주세요!!)

영어 공부

진짜 영어의 중요성을 절실하게 느낀 2023년이었습니다...

운동

2024년엔 운동을 좀 꾸준히 해보려고 합니다… 제발….

일단 이직이 최우선!

내년 계획을 세우기 위해서는 아무래도 이직을 진행한 후에 주어진 업무에 맞게 계획을 해야하니, 이직한 후에 계획하려고 합니다. 11월, 12월의 시간을 투자하여 나는 어떤 사람인가?, 어떤 커리어를 쌓고 싶은가?, 그래서 내가 어떤 회사를 원하는가? 에 대해 정리를 해보았습니다. 그러니 조급하게 이직을 하려고 하지 않고 최선을 다해서 원하는 회사에 이직을 하려고 합니다! 조만간 좋은 소식으로 돌아오겠습니다!

KUBERNETES에서 POD가 생성되고 업데이트 되는 과정

hosu4549@gmail.com — Wed, 13 Sep 2023 01:00:00 GMT

들어가며

kubectl 명령을 통해 pod를 생성하거나 수정할 때에 무슨 과정이 일어나는지에 대해 포스팅 해보았습니다. kubernetes를 사용 및 관리한다면 알아야 할 정말 기초적인 일련의 과정이지만 막상 kubernetes cluster object들이 무슨 일을 하는지 모를 수 있으니 이번 기회에 개념을 확! 잡고 갑니다!

💡 개념적인 내용은 공식 문서와 ChatGPT를 참고하여 작성하였습니다.

Overview

kubectl apply 명령어가 적용되는 순서

client → kube-apiserver
kube-apiserver → etcd
kube-apiserver → kube-controller-manager
kube-apiserver → kube-scheduler
kube-apiserver → kubelet → Container Runtime
kube-apiserver → etcd

1) client → kube-apiserver

kubectl 클라이언트는 deployment.yaml 파일에 정의된 resource를 생성하거나 수정하기 위해 kube-apiserver에 요청을 보냅니다.

kube-apiserver

Kubernetes Cluster의 모든 컴포넌트와 사용자가 상호 작용할 수 있도록 중앙 집중식 API를 제공하며, 특히 Kuberentes Cluster의 게이트키퍼(클러스터 내부 또는 외부의 모든 API 요청을 처리하고, 해당 요청이 유효하고 권한이 있는지 확인) 역할을 합니다.

주요 기능

RESTful API 제공 : RESTful API를 통해 클라이언트와 통신합니다. 이 API를 통해 Resource를 생성, 읽기, 수정, 삭제(CRUD)할 수 있습니다.
인증: client가 실행한 명령에 의해 cluster내에 접근하기 전에 토큰, 인증서, 기본 인증 등 다양한 방법으로 누구인지 확인합니다.
인가 : 인증된 client가 특정 resource에 대한 작업을 수행할 권한이 있는지 Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC) 등을 통해 수행됩니다.
데이터 유효성 검사: 들어오는 요청이 유효한 형식과 데이터를 가지고 있는지 검사합니다.
API 요청 라우팅: 들어오는 API 요청을 적절한 서비스나 컴포넌트로 라우팅합니다.
API Aggregation: 여러 API 버전과 추가적인 API server를 하나의 API Endpoint로 묶을 수 있습니다.
상태 저장: kube-apiserver는 일반적으로 etcd와 같은 분산 데이터 스토어에 클러스터 상태를 저장합니다.

2) kube-apiserver → ETCD

유효성 검사가 통과되면, kube-apiserver는 etcd 데이터베이스에 리소스의 상태를 저장합니다.

ETCD

etcd는 분산 key-value저장소로, 데이터를 저장하고 고가용성을 제공하며 주로 분산 시스템의 설정 정보, 상태 정보, 메타데이터 등을 저장하는 데 사용됩니다.

주요 특징

고가용성: etcd cluster는 여러 node노드로 구성되며, 일부 node가 실패해도 계속 작동합니다.
일관성: etcd는 Raft 합의 알고리즘을 사용하여 분산 node 간에 데이터의 일관성을 유지합니다.
분산 시스템: etcd는 분산 시스템을 통해 네트워크 파티션, 장애 복구 등 복잡한 문제를 해결합니다.
트랜잭션 지원: 여러 연산을 하나의 트랜잭션으로 묶을 수 있습니다.
보안: etcd는 TLS를 통해 데이터를 암호화하고, 인증서를 통해 클라이언트와 서버 간의 신뢰성을 확보합니다.
key-value 모델: 간단한 key-value 데이터 모델을 사용하여 데이터를 저장하고 검색합니다.

Kubernetes에서의 역할

etcd는 kubernetes cluster의 모든 상태 정보를 저장합니다.

즉, kube-apiserver는 etcd와 통신하여 이러한 정보를 읽고 쓰며, 다른 Kubernetes 컴포넌트들은 kube-apiserver를 통해 이 정보에 접근합니다. 이렇게 해서 Kubernetes cluster의 모든 컴포넌트가 일관된 상태 정보를 가질 수 있습니다.

3) kube-apiserver → kube-controller-manager

kube-apiserver는 리소스의 상태가 변경되었음을 kube-controller-manager에 알려주게 됩니다.

kube-controller-manager

kube-controller-manager는 Kubernetes cluster에서 여러 개의 컨트롤러를 실행하는 컴포넌트입니다. 이 컴포넌트는 클러스터의 전반적인 상태를 관리하고, 필요한 작업을 자동으로 수행하며, kube-apiserver와 통신하여 cluster의 상태를 읽고 업데이트합니다.

주요 기능

상태 관리 : 클러스터의 다양한 resource 상태를 지속적으로 체크하고, 필요한 경우 조정합니다.
자동화 : node가 어떠한 이유로 pod를 유지할 수 없게된다면 자동으로 해당 node에서 실행되던 pod를 다른 node로 옮기는 등의 작업을 자동으로 수행합니다.
스케일링 : pod의 수를 자동으로 늘리거나 줄일 수 있습니다.
롤아웃과 롤백: 새로운 버전의 애플리케이션을 안전하게 배포하고, 문제가 발생하면 이전 버전으로 롤백할 수 있습니다.

주요 컨트롤러

Node Controller: node의 상태를 모니터링하고, node가 다운되면 이를 감지하여 적잘한 조치를 취합니다.
Replication Controller: 지정된 수의 Pod의 Replicas가 항상 유지되고 있는지 확인합니다.
Deployment Controller: 사용자가 선언한 상태를 기반으로 Pod와 ReplicaSets을 관리합니다.
StatefulSet Controller: 상태를 유지하는 Pod의 배포와 스케일링을 관리합니다.
DaemonSet Controller: 모든 (또는 일부) node에서 deamonsets의 복제본이 실행되도록 관리합니다.
Job Controller: 배치 작업을 실행합니다.
Horizontal Pod Autoscaler: CPU 사용량 등의 metric을 기반으로 pod의 수를 자동으로 조절합니다.
Persistent Volume Controller: storage 요구사항에 따라 persistent volume을 생성하고 관리합니다.

4) kube-apiserver → kube-scheduler

새로 생성된 pod는 초기에는 Pending 상태입니다. 이 pod를 적절한 node에 배포하기 위해 kube-scheduler 가 동작합니다. (kube-scheduler 가 pod를 직접 배포를 하는 것이 아니라 pod가 배포될만한 적절한 node를 찾는 작업을 합니다.)

kube-scheduler

kube-scheduler는 Kubernetes Cluster에서 여러 가지 metric과 규칙, 정책등을 고려하여 Pod의 scheduling (어떤 Pod를 어떤 Node에 배치할 것인지를 결정하는 과정) 을 담당하는 컴포넌트입니다.

작동 원리

파악: kube-apiserver를 통해 새로 생성되거나 아직 할당되지 않은 Pod를 감지합니다.
선택: 감지된 Pod에 대해 여러 가지 scheduling 알고리즘과 정책을 적용하여 가장 적합한 worker node를 선택합니다.
할당: 선택된 node에 pod를 할당하고, 이 정보를 kube-apiserver에 정보를 전달합니다.

고려하는 요인

리소스 요구사항: CPU, Memory, Storage 등의 resources가 충분한지
노드 제약사항: node-selector, node-affinity, Taints, Tolerations 등이 설정되어있는지
데이터 지역성: 데이터를 가까운 곳에서 처리할 수 있도록 node를 선택
로드 밸런싱: 모든 node에서 균등하게 resources를 사용할 수 있도록 node를 선택
사용자 정의 정책: 사용자가 정의한 scheduling 정책 또는 알고리즘을 적용

5) kube-apiserver → kubelet

Woker Node에서 kubelet과 함께 동작하는 Container Runtime이 Pod를 생성하고 실행합니다.

Kubelet

kubelet은 Kubernetes Cluster의 각 Worker Node에서 실행되는 Agent입니다. 이 Agent는 Node에서 Container의 실행, 중지, 업데이트 등을 관리하며, Node의 상태를 모니터링합니다. kubelet은 앞의 작업을 수행하고 kube-apiserver와 통신하여 상태 정보를 전달합니다.

주요 기능

파드 수명 주기 관리 : kube-apiserver로부터 Pod의 명세(spec)를 받아와 해당 Node에서 Pod와 그 안의 Container를 실행합니다.
노드 상태 모니터링: Node의 CPU, Memory, 디스크 사용량 등을 moniroting하고 이 정보를 kube-apiserver 전달합니다.
리소스 격리: kubelet은 cgroups, namespaces 등의 리눅스 커널 기능을 활용하여 Pod와 Container의 Resource를 격리합니다.
로그 및 메트릭 수집: 설정에 따라 Container의 Log를 수집하고, Metric을 추출하여 필요한 경우 외부 시스템에 전달합니다.
자동 복구: 설정에 따라 Container나 Pod가 실패하면 자동으로 복구 작업을 수행합니다.
컨테이너 런타임 인터페이스(CRI) 지원: 다양한 Container Runtime(Docker, containerd, CRI-O 등)과 통신할 수 있습니다.

작동 방식

API 서버로부터 파드 정보 가져오기: kubelet은 kube-apiserver와 통신하여 해당 노드에 스케줄링된 파드의 목록과 상태 정보를 가져옵니다.
원하는 상태와 현재 상태 비교: kubelet은 가져온 파드의 원하는 상태(Desired State)와 노드의 현재 상태(Current State)를 비교합니다.
컨테이너 런타임에 명령 내리기: 원하는 상태와 현재 상태가 일치하지 않으면, kubelet은 Container Rumtime 에게 필요한 작업을 수행하도록 명령을 내립니다.
상태 업데이트: 작업이 완료되면, kubelet은 파드의 상태를 업데이트하고 이 정보를 다시 API 서버에 보고합니다.
로그 및 메트릭스 모니터링: kubelet은 또한 Container의 Log와 Metric 를 수집하여 필요한 경우 중앙 로깅 및 모니터링 시스템에 전달할 수 있습니다.

Container Runtime

Container를 실행, 중지, 관리하는 역할을 하는 소프트웨어 컴포넌트로써 kubelet과 통신하여 Worker Node에서 Container의 생명주기를 관리합니다.

주요 Container Runtime

Docker : 가장 널리 사용되는 Container Runtime 중 하나이며 사용하기 쉬운 CLI와 API를 제공하고 다양한 플랫폼에서 지원됩니다.

containerd : Docker사에서 개발한 오픈소스로써 현재는 독립적인 프로젝트이며, OCI(Open Container Initiative) 표준을 따르고 Docker 엔진 위에서도 작동합니다.

CRI-O : CRI(Container Runtime Interface)가 구현된 Kubernetes를 위한 경량의 Container Runtime입니다.

역할

이미지 관리: Container 이미지를 다운로드하고 저장합니다.
컨테이너 실행: Container 를 시작, 중지, 재시작 등의 작업을 수행합니다.
로깅과 모니터링: Container의 Log를 수집하고, resources 사용량을 모니터링합니다.
보안: 하나의 Container가 다른 Container나 호스트 시스템에 영향을 주지 않도록 격리합니다.
네트워킹: Container 간의 통신과 외부와의 통신을 관리합니다.

6) kube-apiserver → ETCD

Pod의 상태가 변경되면 이 정보는 다시 kube-apiserver를 통해 etcd에 업데이트됩니다.

kube-prometheus-stack으로 모니터링 시스템 구축하기

hosu4549@gmail.com — Sun, 27 Aug 2023 06:40:00 GMT

들어가며

사내에서 EFK-Stack(ElasticSearch+Fluent-bit+Kibana)를 이용하여 모니터링 시스템을 구축했었습니다. 하지만 AWS Opensearch를 이용하다보니 비용적인 문제와 비교적 활용도가 낮았던 fluent-bit(응답이 길면 Probe가 자꾸 문제가 발생), metirc 데이터 필요, 쿠버네티스에 맞지 않은 설정들등 다양한 이슈로 모니터링 시스템을 바꿔야 하는 요구 사항이 생겼습니다. 그러던 중 쿠버네티스 모니터링 시스템계의 또 하나의 터줏대감인 Prometheus, Loki, Grafana를 이용하여 새롭게 모니터링 시스템을 구축하였습니다.

💡 개념적인 내용은 공식 문서와 ChatGPT를 참고하여 작성하였습니다.

Overview

Prometheus

Prometheus란?

Prometheus는 SoundCloud에서 처음 개발된 오픈 소스 시스템 모니터링 및 알림 툴킷입니다. 2012년에 시작된 이후로 많은 회사와 조직이 Prometheus를 채택하였고, 매우 활발한 개발자와 사용자 커뮤니티를 가지고 있습니다.

Prometheus는 2016년 Kubernetes 에 이어 두 번째 프로젝트로 Cloud Native Computing Foundation에 합류했으며, 서비스 운영을 위해 모니터링 시스템을 구축할 때 가장 널리 사용되는 툴 중 하나입니다.

특징

다차원 데이터 모델: 메트릭 이름과 키/값 쌍으로 시계열 데이터를 식별합니다.
PromQL: 이러한 차원성을 활용할 수 있는 유연한 쿼리 언어입니다.
분산 저장에 의존하지 않음: 단일 서버 노드가 자립적으로 작동합니다.
HTTP를 통한 풀 모델: 시계열 데이터 수집이 HTTP를 통해 이루어집니다.
서비스 발견 또는 정적 구성을 통한 타겟 발견: 다양한 그래핑 및 대시보드 지원 모드가 있습니다.

위처럼 여러 특징이 있지만 주요 특징은 2가지로 요약됩니다.

Pull-Based Monitoring

기존의 Push-Based Monitoring 방식 대신에 Pull-Based Monitoring을 사용합니다. 대상 서버에 설치된 Exporter가 메트릭 정보를 수집하고, 이 데이터는 수집 서버가 주기적으로 가져가는 구조입니다.

즉, 클라이언트에서 서버로 데이터를 보내는 것(PUSH)가 아닌 서버가 클라이언트의 데이터를 수집(Pull) 방식입니다. 이러한 방식은 기존의 에이전트(agent) 방식보다 더 유연하고 관리하기 쉽습니다.

시계열 데이터베이스(TSDB)

관계형 데이터베이스(RDB) 대신 메트릭 이름과 key-value 쌍으로 식별되는 시계열 데이터 모델을 사용합니다. 이를 통해 대량의 정보를 빠르게 검색할 수 있습니다.

Architecture

Exporter

host서버에 설치되어 메트릭 데이터를 수집하는 역할을 합니다.
Prometheus 서버가 접근하여 데이터를 가져올 수 있는 HTTP 엔드포인트를 제공하여 다양한 데이터를 수집합니다.

Prometheus Server

Prometheus Server는 메트릭 데이터를 스크랩하고 저장합니다.
메트릭 데이터 수집 주기를 설정하여 지정된 시간마다 대상 서버에 있는 Exporter로부터 데이터를 수집합니다.
수집한 데이터를 저장하고 PromQL(프로메테우스 쿼리 언어)를 사용하여 데이터를 쿼리하고 필터링할 수 있습니다.

Grafana

Grafana는 데이터 시각화 도구로, Prometheus가 수집한 메트릭 데이터를 그래프나 대시보드 형태로 시각화하여 표현할 수 있습니다.
Prometheus Server에서 직접 제공하는 웹 뷰보다 더 다양한 시각화 기능을 제공하며, Grafana를 통해 데이터를 더 직관적으로 이해할 수 있습니다.

Alertmanager

Prometheus가 수집한 메트릭 데이터를 기반으로 경고를 생성하고 규칙을 만들어 관리합니다.

이렇듯 Prometheus로 metric 데이터를 수집하려고 했지만 Docker형태나 pod 형태로 배포하기엔 따로 작업을 해야해서 다른 방안이 없나하고 찾아보던 중 Prometheus, Grafana, Alertmanager 등을 함께 묶어 kubernetes 환경에 맞게 Helm 차트 형태로 설치할 수 있는 kube-prometheus-stack을 발견했습니다..!

kube-prometheus-stack

Kube-Prometheus-Stack이란?

kube-prometheus-stack은 kubernetes cluster에 맞게 구성된 오픈 소스 프로젝트입니다. Prometheus를 기반으로 하며, 쿠버네티스 클러스터의 다양한 컴포넌트들의 메트릭 데이터를 수집하고 이를 시계열 데이터로 생성하여 모니터링 및 경고 기능을 제공합니다.

즉, 쿠버네티스 클러스터만 있다면 간단하게 helm chart로 설치가 가능합니다!

github : https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

Architecture

Prometheus Operator

쿠버네티스 내에서 Prometheus 서버와 관련된 리소스들을 관리하기 위한 컨트롤러입니다.
Prometheus와 관련된 설정, 서비스 디스커버리, 룰 및 대시보드를 관리할 수 있습니다.

Prometheus Server

고가용성을 제공하는 Prometheus 서버입니다.
메트릭 데이터를 스크랩하고 저장합니다.

Alertmanager

Prometheus가 수집한 메트릭 데이터를 기반으로 경고를 생성하고 관리하는 역할을 합니다.

Prometheus node-exporter

node-exporter는 Host의 metric을 수집하는 역할을 합니다.
CPU, 메모리, 디스크 사용량 등의 데이터를 수집하여 Prometheus로 전달합니다.

Prometheus Adapter for Kubernetes Metrics APIs

쿠버네티스의 메트릭 API와 연동하여 클러스터 내부의 리소스 메트릭 데이터를 수집하고 Prometheus로 전달합니다.

kube-state-metrics

쿠버네티스 클러스터의 상태 정보를 메트릭으로 수집합니다.
파드, 디플로이먼트, 노드 등의 상태 정보를 모니터링할 수 있습니다.

Grafana

Grafana는 데이터 시각화 및 대시보드 생성 도구로, 수집한 메트릭 데이터를 그래프나 대시보드 형태로 시각화하여 사용자에게 제공합니다.

구성

kube-prometheus-stack을 포함한 대부분의 Helm 배포 패키지는 비슷한 구성으로 이루어져있습니다.

charts

Helm 차트의 종속 차트를 포함하는 위치입니다.
이 패키지의 경우 grafana, kube-state-metrics, prometheus-node-exporter가 존재합니다.

templates

Helm 차트의 템플릿 파일들을 포함합니다.
템플릿은 Kubernetes 리소스의 정의를 작성하는 데 사용되며, 애플리케이션의 배포, 서비스, 구성 등을 관리할 수 있습니다

crds

Custom Resource Definitions(CRDs) 파일을 포함할 수 있는 위치입니다.
Kubernetes API에 사용자 정의 리소스와 그에 대한 스키마를 추가하는 데 사용됩니다.

Chart.yaml

Helm 차트의 메타 정보를 정의합니다.
메타 정보에는 차트의 이름, 버전, 유형, 유지 보수자 정보 등이 포함됩니다.
종속 차트, 애플리케이션의 버전 제약 조건 등을 지정할 수도 있습니다.

values.yaml

Helm 차트의 기본 구성 값을 정의합니다.
애플리케이션의 설정 옵션, 환경 변수, 리소스 크기 등을 설정할 수 있습니다.
values.yaml 파일에 정의된 값은 템플릿 파일 내에서 사용될 수 있으며, 차트를 배포할 때 사용자 지정 값으로 수정하여 배포할 수도 있습니다.

설치하기

create namespace

$ kubectl create namsespace monitoring

먼저 KPS을 설치할 네임스페이스를 생성합니다.

Add Helm repo

# 헬름 차트의 저장소 추가
$ helm repo add prometheus-community https://prometheus-community.github.io/
$ helm repo update

Helm을 통해 prometheus-community repo를 cluster에 받아옵니다.

Pull helm config file

몇가지 커스텀을 해야하기 때문에 config에 대한 값을 수정할 수 있는 manifast file을 다운로드 한 후 압축을 풀어줍니다.

$ helm pull prometheus-community/kube-prometheus-stack
$ tar xvfz kube-prometheus-stack-${version}.tgz #설치된 버전을 작성하시면 됩니다!

service 수정

대시보드 형태로 외부에서 접근할 수 있게 prometheus-grafana만 clusterIP에서 LoadBalancer나 NodePort로 변경합니다. (이 글에선 loadbalancer로 설정하였습니다)

...
grafana:
	enabled: true
	...
	## Passed to grafana subchart and used by servicemonitor below
  ##
  service:
    type: LoadBalancer
    portName: http-web
...

그 후 수정된 values.yaml 파일을 paramater로 주어 helm chart를 배포합니다.

$ helm install prometheus . -n monitoring -f values.yaml

service 확인

kubectl get svc -n mornitoring

배포되어있는 service를 확인해보면 정상적으로 prometheus-grafana의 servive type이 LoadBalancer로 설정되어 배포된 것을 확인할 수 있고, EXTERNAL-IP 에 명시된 외부 IP 주소로 접근하실 수 있습니다.

(후에 AWS Route53와 같은 DNS service를 통해 해당 주소를 routing 해주시면 좋습니다!)

자! metric data 수집과 모니터링 구축은 완료했습니다. 이제 log를 수집해보겠습니다.

Loki-Stack

Loki-stack이란?

Loki-Stack은 Loki 로깅 엔진을 포함하지만, 추가적으로 로그를 수집, 집계, 시각화하기 위한 다른 컴포넌트들도 함께 제공합니다.

Loki: 로그 데이터를 저장하고 쿼리합니다.
Promtail: 로그 데이터를 수집하고 Loki로 전송합니다.
Grafana: 로그 데이터를 시각화합니다.

Loki VS Loki-Stack

	구성 요소	기능 범위	용도	설치 및 관리
loki	로깅 엔진	로그 저장 및 쿼리에 중점	다른 로깅 시스템이나 시각화 도구와 통합	단일 컴포넌트로 더 간단하게 설치 및 관리
loki-stack	로깅 엔진, 로그 수집기, 시각화 도구까지 포함	로그 수집부터 저장, 쿼리, 시각화까지 전체 로깅 파이프라인 제공	독립적인, 통합된 로깅 솔류션을 제공	여러 컴포넌트를 관리해야하므로 설정과 관리 복잡

loki만이 아니라 promtail과 여러 컴포넌트를 쉽게 사용할 수 있는 loki-stack을 선택해서 배포하도록 하겠습니다.

설치

git clone https://github.com/grafana/helm-charts

위의 명령어로 helm chart를 받아옵니다.

cd helm-charts/charts/loki-stack

grafana/helm-chart 레포지토리를 clone하여 받아온 후 loki-stack 디렉토리로 이동합니다.

디렉토리 구조

./                                
├── Chart.yaml                    
├── README.md                     
├── charts                        
│   ├── filebeat-7.17.3.tgz       
│   ├── fluent-bit-2.6.0.tgz      
│   ├── grafana-6.43.5.tgz        
│   ├── logstash-7.17.3.tgz       
│   ├── loki-2.16.0.tgz           
│   ├── prometheus-15.5.4.tgz     
│   └── promtail-6.14.1.tgz       
├── requirements.lock             
├── requirements.yaml             
├── templates                     
│   ├── NOTES.txt                 
│   ├── _helpers.tpl              
│   ├── datasources.yaml          
│   └── tests                     
└── values.yaml

loki-stack 디렉토리에서 values.yaml 파일을 수정하여 원하는 기능을 키고 끄고 추가로 설정할 수 있습니다.

...
loki:
  enabled: true
...
promtail:
  enabled: true
...
grafana:
  enabled: false
...

저희가 사용할 서비스는 loki와 promtail 인데 기본값이 enabled:true 이기 때문에 수정하지 않고 배포합니다.

$ helm install loki-stack . --namespace monitoring

배포시 오류

helm install loki-stack . --namespace monitoring                                │
Error: INSTALLATION FAILED: An error occurred while checking for chart dependencies. You may need to run `helm dependency build` to fetc│
h missing dependencies: found in Chart.yaml, but missing in charts/ directory: loki, promtail, fluent-bit, grafana, prometheus, filebeat│
, logstash

만약 설치시 위와 같이 문제가 생긴다면 helm dependency build 을 통해 의존성을 설치하신 후 진행하시면 됩니다.

확인

kubectl get po -n monitoring

조금 후 해당 namespace의 pod 목록을 출력해보면 아래와 같이 Running이 되고 있습니다!설치가 완료되었습니다…!

promtail에서 로그가 수집안되는 이슈

위의 사진처럼 promtail에서 log를 수집할 때에 error level의 로그 수집 오류 내용이 발생할 수 있습니다. 해당 이슈의 원인은 비교적 설치 시간이 짧은 promtail이 loki보다 먼저 설치되어 발생한 이슈인데, promtail Pod를 재시작해주면 해결됩니다!

Retention

기본적으로 table_manager.retention_deletes_enabled또는 compactor.retention_enable플래그가 설정되지 않은 경우 Loki로 전송된 로그는 영원히 유지됩니다.

table_manager 통한 보존은 객체 저장소 TTL 기능을 사용하며 boltdb-shipper store와 chunk/index store 에서 작동합니다. 그러나 Compactor을 통한 로그 보관은 boltdb-shipper store 에서만 지원됩니다.

boltdb-shipper

Grafana Loki에서 사용되는 index 및 chunk 데이터를 저장하는 데 사용되는 저장소 엔진 중 하나입니다.

특징

인덱스와 로그 청크 모두를 객체 저장소(예: Amazon S3, Google Cloud Storage 등)에 저장합니다.
객체 저장소만을 사용하기 때문에, 일반적으로 비용이 더 저렴합니다.
수평 확장이 가능하며, 큰 규모의 로그 데이터를 처리할 수 있습니다.
Loki의 Compactor 컴포넌트와 함께 사용할 때 더 세밀한 데이터 보존 정책을 설정할 수 있습니다.
인덱스 데이터를 로컬에 캐싱할 수 있어, 쿼리 성능이 향상될 수 있습니다.

table_manager

Loki 데이터베이스의 핵심 구성 요소로서 로그 데이터의 저장, 유지 관리, 압축 및 정리를 관리하며 데이터베이스의 성능과 공간 효율성을 유지하는 역할을 합니다.

특징

로그 데이터를 시간별로 테이블에 저장하는 형태로 데이터를 구성하며, 이를 통해 검색 성능을 최적화합니다.
설정된 로그 보존 기간 내에 있는 데이터만을 유지하고, 설정보다 오래된 데이터는 자동으로 삭제합니다.
인덱스 관리
데이터를 정리하고 필요한 경우 압축하여 저장 공간을 효율적으로 관리합니다.
설정된 보존 기간이 지난 로그 데이터를 정기적으로 삭제하여 데이터베이스의 용량을 유지합니다.

설정하기

...
loki:
	...
	config:
    table_manager:
      retention_deletes_enabled: true
      retention_period: 24h
...

Compactor

특징

boltdb-shipper 저장소에서만 지원됩니다.
단일 인스턴스(싱글톤)로 실행하는 것이 권장됩니다.
Compactor가 재시작되면 이전에 중단된 지점에서 계속 작업을 수행합니다.
설정된 compaction_interval마다 압축과 보존을 적용하기 위해 루프를 실행합니다.

Compactor의 알고리즘은 다음과 같습니다

- 각 테이블을 단일 인덱스 파일로 압축합니다.
- 전체 인덱스를 순회하여 제거해야 할 청크를 식별하고 표시합니다.
- 표시된 청크를 인덱스에서 제거하고 디스크에 있는 파일에 참조를 저장합니다.
- 새로 수정된 인덱스 파일을 업로드합니다.

보존 알고리즘은 인덱스에 적용되며, 청크는 즉시 삭제되지 않고 추후에 비동기적으로 삭제됩니다.
설정된 retention_delete_delay가 만료된 후에만 표시된 청크가 삭제됩니다.
Compactor를 사용하여 보존을 적용할 때는 table_manager가 필요하지 않습니다.

설정하기

...
	loki:
	...
		config:
	    compactor:
	      shared_store: s3 // store가 설정되어 있어야 함
	      retention_delete_delay: 72h
	      retention_enabled: true
...

table_manager VS Compactor

table_manager는 데이터의 논리적 구조와 스키마를 관리하고 구성하며, Compactor는 저장된 데이터의 물리적인 관리와 최적화를 담당합니다.

결과

위의 사진을 보시면 lokiindex 형식으로 log index가 쌓이고 있습니다. 해당 데이터들은 설정된 Retention 값에 따라 gz file로 압축하여 AWS S3에 전송한 후 pod내에선 삭제합니다.

실제로 Retention을 24h로 설정한 Loki pod 내부입니다. 총 4일이 지나 lokiindex 디렉토리가 4개가 생성되어있는데, 가장 최근의 값인 lokiindex19597에만 log data들이 저장되어 있고 lokiindex19594의 디렉토리는 비어져있습니다.

마치며

이렇게 PLG (Prometheus, Loki, Grafana)를 이용하여 모니터링 시스템을 구축해보았습니다! 개인적으로 EFK (Elasticsearch, Fluent-bit, Kibana)보다 가볍지만 강력하다고 생각이 들어요! 다음엔 Grafana Dashboard 설정에 대해 공부해보고 포스팅 해보도록 하겠습니다!

Reference

Prometheus - Monitoring system & time series database

[Helm] kube-prometheus-stack 모니터링 시스템 구축하기 (Grafana, exporter, monitoring)

Retention | Grafana Loki documentation

좌충우돌 AWS EKS Nodegroup 전환기

hosu4549@gmail.com — Tue, 15 Aug 2023 04:00:00 GMT

개요

현재 AWS EKS를 이용하여 K8s 를 구축하고 운영하고 있습니다. 하지만 최근들어 신규 서비스도 런칭하고, 배포해야 할 Pod 수도 늘어나고, 여러 가지 devops 관련 pod를 구축하고 싶어 프로젝트로 일정을 수립하고 진행하고 있던 와중 Pod가 정상적으로 생성되지 않는 현상이 발생했습니다..!

찾아보니 EKS Workernode로 사용중인 EC2 Instance 의 Memory 의 용량이 부족하여 Pod를 띄울 수 없었습니다.

적절한 EC2 Instance Type을 찾아보자!

제가 처음 고려했던 Type은 현재쓰고 있는 다음 크기의 EC2 였습니다.

As-Is : t3.xlarge
To-Be : t3.2xlarge

타입 비교

	vCPU*	메모리(GiB)	네트워크 성능(Gbps)***	최대 Pod수	시간당 요금	한달 요금
t3.xlarge	4	16	최대 5	58	0.208 USD	200,524.46원
t3.2xlarge	8	32	최대 5	58	0.416USD	401,048.92원

하지만,, 회사 입장에서 비용이 과하다는 피드백이 돌아왔고 눈물을 머금고 다른 type을 찾기 시작했습니다.

같은 CPU, Memory를 호스팅 해주는 것을 중점으로 찾다가 t4g type을 찾게 되었습니다..!

타입 비교

	vCPU*	메모리(GiB)	최대 Pod수	시간당 요금	한달 요금
t3.xlarge	4	16	58	0.208 USD	200,524.46원
t3.2xlarge	8	32	58	0.416USD	401,048.92원
t4g.2xlarge	8	32	58	0.3328USD	320,833.85원

하지만..!

그렇게 t4g type으로 결정하고 AWS EKS에서 새로운 node group을 생성하는 도중 AMI 이미지가 다른 것을 확인하게 되었습니다. t3는 AL2_x86_64 인 반면 t4g는 AL2_ARM_64였습니다.

별 문제 없겠거니.. 싶었지만 그래도 조사를 해보았고 gpt는 아래와 같은 답변을 주었습니다.

t3 vs t4g

[GPT]

T3 모델

T3 인스턴스 패밀리는 "burstable" 워크로드를 위해 최적화되었습니다. 이는 CPU 사용률이 낮고 가끔 높은 CPU 활동이 필요한 경우에 해당합니다.

예를 들어, 워크로드가 일반적으로 낮은 CPU 부하를 가지며 가끔 특정 시점에서 높은 CPU 부하를 겪는 경우, T3 인스턴스 패밀리는 이러한 워크로드에 적합하며 비용 효율적일 수 있습니다.

T3a 인스턴스와 달리, T3 인스턴스는 Skylake 프로세서를 사용합니다.

→ 가변적인 CPU 사용량을 가진 워크로드에 유용하

T4g 모델

T4g 인스턴스 패밀리는 ARM 기반의 AWS Graviton2 프로세서를 사용하여 동작합니다.

T4g 인스턴스는 가격 대비 성능을 개선하도록 설계되었습니다.

ARM 프로세서의 사용으로 인해 T4g 인스턴스는 일부 워크로드에서 좋은 성능을 발휘할 수 있습니다.

→ ARM 기반 프로세서를 사용하여 특정 워크로드에서 성능을 향상

AL2_ARM_64 (ARM 64비트 아키텍처):
- AL2_ARM_64는 ARM 64비트 아키텍처를 기반으로 동작하는 Amazon Linux 2 인스턴스 유형입니다.
- ARM 아키텍처는 저전력 및 효율적인 프로세서 아키텍처로, 모바일 및 임베디드 시스템에서 주로 사용됩니다.
- AL2_ARM_64 인스턴스 유형은 ARM 프로세서를 사용하여 실행되며, 컴퓨팅 및 메모리 요구 사항을 처리하는 데 최적화되어 있습니다[1].

AL2_x86_64 (x86 64비트 아키텍처):
- AL2_x86_64는 x86 64비트 아키텍처를 기반으로 동작하는 Amazon Linux 2 인스턴스 유형입니다.
- x86 아키텍처는 주류 컴퓨터 시스템에서 많이 사용되며, Intel 및 AMD 프로세서를 포함한 다양한 프로세서에서 실행됩니다.
- AL2_x86_64 인스턴스 유형은 x86 64비트 아키텍처를 사용하여 실행되며, 다양한 워크로드 및 응용 프로그램을 처리하는 데 최적화되어 있습니다.

아키텍처가 다르다보니 여러 이슈가 생길 것 같았지만 무슨 문제가 있을까 궁금했습니다. 그래서 일단 해당 node에만 파드를 하나 생성해서 테스트 해보자 생각으로 구성을 이어갔습니다.

해당 node에 label을 주었고, test pod manifast file에 labelSelector를 이용하여 해당 노드에만 Pod가 띄어지게 구성하였고 바로 배포해보았습니다.

하지만 아니나 다를까 Pod가 생성되지 않고 CrashBackOff로 계속 restart가 되고 있었습니다..

띠용?!! exec format error?!

해당 오류는 처음 보는 내용이었고 바로 구글링을 해봤습니다.

x86으로 build된 Docker Image는 arm64/aarch64 아키텍처 서버에서는 띄울 수 없다… 는 내용의 답변이었고 Docker 공식 페이지를 들어가서 확인해보니 특정 옵션을 주어서 Docker Image build를 하면 된다 라는 문서를 확인하게 되었습니다.

하지만 이미 서비스중인 파드들이 많고 이미지 빌드 형식을 바꾸기엔 공수가 많이 드는 작업이었고, 추후 서비스가 더 늘어날 시에 x86 아키텍처의 EC2를 사용할 가능성이 다분하여 다른 대안을 모색하게 되었습니다.

대안

현재 운영중인 모든 서비스가 띄어져 있는 기존 node의 memory를 늘려 더 많은 pod를 띄우려는 것이 목적이었던터라 같은 아키텍처의 EC2 instance가 전제였습니다.

그래서 결국 다른 EC2 instance type을 찾아보게 되었고 t3a를 찾았습니다..!

t3a 모델

[GPT]

T3a 모델

T3a 인스턴스 패밀리는 T3와 유사한 특성을 가지고 있습니다. 하지만 프로세서가 다릅니다. T3a는 AMD EPYC 7000 시리즈 프로세서를 사용합니다.

T3a 모델은 비슷한 워크로드에 대해 T3와 비슷한 성능을 제공하지만, 프로세서에 따른 차이가 있습니다.

타입 정리

To-Be	vCPU*	메모리(GiB)	최대 Pod수	시간당 요금	한달 요금	최종 금액
t3.2xlarge	8	32	58	0.416USD	304.84 USD	401,048.92원
t4g.2xlarge	8	32	58	0.3328 USD	242.94 USD	320,833.85원
t3a.2xlarge	8	32	58	0.3744 USD	273.31 USD	360,941.39원

또 다른 문제..!

t3 모델에서 t3a 모델로 바꾸면서 기존 node에 띄어져 있는 Pod들을 옮기는 drain을 진행했는데, t3a 모델의 노드 그룹 상태가 저하됨 이라고 표시되었습니다.

두둥…!

AWS EC2는 Instance Type별로 가용 영역이 정해져있습니다.

가용 영역: ap-northeast-2a, ap-northeast-2c
- t2, t3a, c4 계열 등
가용 영역: ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d
- t3, c5 계열 등
가용 영역: ap-northeast-2a, ap-northeast-2b, ap-northeast-2c
- t3, c5 계열 등
가용 영역: ap-northeast-2a, ap-northeast-2d
- mac1.metal
가용 영역: ap-northeast-2d
- t3, c5 계열 등
가용 영역: ap-northeast-2c
- t2, t3, c4, c5 계열 등

또 다른 확인 방법으로는 아래의 명령어를 이용하는 것입니다.

$ aws ec2 describe-instance-type-offerings \
    --location-type availability-zone \
    --filters Name=instance-type,Values=**t3a.*** \
    --region ap-northeast-2 --output table

그렇기에 현재 작업한 Type인 t3a는 ap-northeast-2a, ap-northeast-2c 영역에서만 EC2 Instance를 생성할 수 있었지만 nodegroup을 생성할 때 ap-northeast-2b, ap-northeast-2d도 추가를 해놔서 발생한 이슈였습니다!

즉, ap-northeast-2b, ap-northeast-2d 영역을 제외하고 node group을 생성해주시면 해결됩니다..!

마치며

AWS EC2는 type별로 각각의 특성이 있습니다. 이번 작업을 통해 AWS EC2의 type별로 어떤 특성이 있는지 확인할 수 있는 값진 경험이었습니다.😂

이러한 경험을 토대로 현재 운영서버는 문제없이 잘 돌아가고 있습니다 😎😎😎

쿠버네티스 service란?!

hosu4549@gmail.com — Thu, 03 Aug 2023 02:40:00 GMT

들어가며

인터넷을 통해 일반 사용자가 kubernetes의 파드에 접근하는 흐름은 어떻게 될까요? 직접 pod에 접근할까요? 아니면 routing을 통해 특정 경로로 접근할까요? 이러한 것을 도와주는 것이 Kubernetes Service 입니다.

Kubernetes Service란?

kubernetes service는 cluster내에서 컨테이너화된 파드들을 네트워크에 노출하는 가상의 컴포넌트입니다. 이를 통해서 다른 cluster 내부의 객체들과 외부의 애플리케이션 혹은 사용자와 연결되도록 도와줍니다.

kubernetes에서 Pod는 언제든지 다른 노드로 이동하거나 삭제될 수 있으며, 생성될 때마다 새로운 내부 IP를 할당받게 됩니다. 이로 인해 Pod는 외부와 지속적인 통신이 어렵습니다.

kubernetes에서는 service를 통해 Pod가 외부와 통신할 수 있도록 고정적인 IP를 부여하고 애플리케이션을 구동하는 여러 Pod에게 하나의 Network Endpoint를 제공하여 통신을 가능하게 합니다.

Kubernetes Service에는 ClusterIP, NodePort, LoadBalancer, ExternalName과 같은 다양한 유형이 있습니다.

ClusterIP

ClusterIP는 Kubernetes Service의 기본값으로 클러스터 내부에서 여러 파드들 간의 통신을 지원합니다. 클러스터 내에서만 접근 가능할 수 있게 IP를 할당하며 외부에서는 접근할 수 없고 port forwarding 또는 proxy를 통해 접근을 해야 합니다.

NodePort

NodePort는 ClusterIP의 확장한 유형으로, 외부에서도 접근 가능하도록 합니다. Node의 IP 주소와 지정된 포트 번호를 통해 서비스에 접근할 수 있게 해줍니다.

NodePort는 30000-32767 범위 내에서 지정할 수 있으며, 명시적으로 지정하지 않으면 Kubernetes가 자동으로 할당합니다.

단점은 노드가 사라졌을때 자동으로 다른노드를 통해 접근이 불가능합니다. 따라서 자동으로 다른 노드에 접근을 하려면 별도의 Loadbalancer가 필요 합니다

Loadbalancer

LoadBalancer는 Nodeport의 확장한 유형으로 가장 일반적으로 사용되는 서비스 유형입니다.

NodePort타입 앞단에 Cloud 공급업체(AWS, GCP, Azure등) 지원하는 Loadbalancer가 붙어서 살아있는 노드를 체크하여 트래픽을 전달 할 수 있는 장점이 있습니다.

ExternalName

ExternalName은 내부 클러스터에서 외부 서비스에 접근하기 위해 사용되는 서비스 유형입니다.

외부 서비스의 DNS 이름을 클러스터 내부에서 CNAME으로 사용하고자 할 때 유용합니다.

이 서비스 유형은 외부에 직접 연결되지 않으며, 단순히 DNS 이름을 노출시켜 주는 역할을 합니다.

Reference

쿠버네티스 update에 관해

hosu4549@gmail.com — Wed, 19 Jul 2023 06:00:00 GMT

들어가며

얼마전 nginx 기반의 vue 애플리케이션에 대해 평소와 같이 manifast 파일을 만들어서 RollingUpdate하여 배포했는데 502, 504 Error가 빈번히 발생했습니다..!

분명히 Probe 설정을 해두었는데도 발생하였고 terminationGracePeriodSeconds와 lifecycle.prestop을 설정하여 해결했습니다!

해당 내용에 대해 정리할 예정인데, 그보다 먼저 Kubernetes의 Update 방식에 관해 먼저 정리해볼게요!

Kubernetes Pod Update

쿠버네티스는 pod를 다양한 방법으로 Update할 수 있습니다.

과정

클라이언트 요청

Pod 업데이트를 요청하는 클라이언트(kubectl, REST API 호출등) 업데이트 관련 명령을 실행합니다.

kube-apiserver

클라이언트의 요청은 kube-apiserver에 전달되며 인증과 권한, 요청 유효성 검사등 검증 과정을 거치게 됩니다.

검사 등의 과정을 거칩니다. kube-apiserver는 요청을 처리하고 클라이언트에 응답을 반환합니다.

그 후 kube-apiserver는 요청된 업데이트 작업을 수행하기 위해 관련된 리소스(Deployment, ReplicaSet)를 식별합니다.

kube-controller-manager에게 전달

kube-controller-manager는 리소스의 현재 상태를 확인하고 설정되어 있는 업데이트 전략에 따라 작업을 진행합니다.

업데이트 전략 확인

kube-controller-manager는 업데이트를 수행할 리소스의 업데이트 전략(Recreate, Rolling, Canary, Blue/green)을 확인합니다.

Pod update 진행

새로운 버전의 pod 를 생성하거나 기존 버전의 pod를 제거하는 등의 작업을 진행합니다.

kubelet 처리

kubelet은 각 worker node에서 실행되며 pod의 상태를 모니터링하고 실제로 pod를 생성하거나 제거하는 역할을 합니다.

업데이트 완료

업데이트 작업이 완료되면 클러스터의 상태는 새로운 버전의 pod로 업데이트됩니다.

종류

Recreate

Recreate 업데이트 전략은 기존의 모든 Pod를 제거하고 새로운 Pod를 생성하는 방식입니다.

-> 무중단 형태의 업데이트 방식이 아니기 때문에 다운타임이 발생합니다.

RollingUpdate

RollingUpdate 업데이트 전략은 새로운 버전의 Pod를 하나씩 생성하고 기존 버전의 Pod를 제거하는 방식입니다.

업데이트 중에는 기존 버전과 새 버전의 Pod 인스턴스가 함께 실행되며, 점진적으로 업데이트가 진행되기 때문에 가용성이 보장됩니다.

-> 구버전과 신버전이 함께 배포되어있는 순간이 존재하고 기본 방식입니다.

Blue/Green

Blue/Green 업데이트는 새로운 버전의 Pod를 별도의 "Green" 환경에 배포한 후, 트래픽을 기존의 "Blue" 환경에서 Green 환경으로 전환하는 방식입니다.

이 방법은 롤백이 쉽고 빠른 가용성 전환을 제공합니다.

업데이트 중에는 블루와 그린 환경이 병행되며, 트래픽을 그린 환경으로 전환하기 전까지는 사용자에게는 보이지 않습니다.

-> 기존과 같은 수의 pod를 새로 띄어야하기 때문에 리소스가 많이 소모됩니다.

Canary

Canary 업데이트는 일부 트래픽을 새로운 버전의 Pod로 전달하여 새로운 버전의 성능 및 안정성을 검증하는 방식입니다.

트래픽의 일부만 카나리(새로운 버전)로 전송되고, 나머지는 기존 버전으로 유지됩니다. 이를 통해 카나리 환경의 동작을 모니터링하고 문제가 발생하면 롤백할 수 있습니다.

-> 위험감지를 하기 위한 배포 전략으로 성능 모니터링에 유용하다는 장점이 있습니다.

Rolling VS Canary

롤링 업데이트는 새 버전을 점진적으로 배포하고 기존 버전을 제거하는 방식으로, 서비스의 가용성을 유지하며 업데이트를 수행합니다. 반면, 카나리아 업데이트는 일부 트래픽을 새 버전으로 전달하여 신규 기능이나 변경 사항을 검증하고, 문제가 발생할 경우 롤백할 수 있는 가용성과 안정성을 제공합니다.

무중단 배포

pod를 RollingUpdate로 배포할 경우 새로운 pod를 생성하고 기존 pod에 terminated 명령을 내리고 새롭게 띄어진 pod에 service를 연결하고 트래픽을 보내는 일련의 과정이 일어나는데 새로운 pod에 트래픽을 미쳐 보내지 못한다거나 기존의 파드가 늦게 죽는다거나 등 다양한 이유로 무중단 배포가 되지 못하는 현상이 발생합니다.

그럴 때 설정하는 옵션인 terminationGracePeriodSeconds와 lifecyle.preStop에 대해 알아보겠습니다.

terminationGracePeriodSeconds

terminationGracePeriodSeconds란 Kubernetes(Pod)에서 컨테이너의 종료(graceful termination)에 대한 대기 시간을 설정하는 속성입니다.

이 속성은 컨테이너가 종료되기 전에 운영체제에게 대기할 시간을 지정하여 종료 과정에서 진행 중인 연결을 처리하고 리소스 정리 등의 작업을 완료할 수 있도록 합니다.

왜 써야하지?

일반적으로 컨테이너의 종료 시에는 컨테이너가 동작 중인 애플리케이션에 대한 연결이 있을 수 있습니다.

그렇기 때문에 갑작스럽게 컨테이너를 중지하면 이러한 연결이 강제로 끊어질 수 있고, 데이터의 손실이나 비정상적인 동작이 발생할 수 있습니다.

terminationGracePeriodSeconds 속성을 사용하여 컨테이너 종료 시 애플리케이션에 대기 시간을 지정합니다. 설정한 시간 동안 Kubernetes는 컨테이너에 종료 신호를 보내며, 컨테이너는 종료 프로세스를 시작하고 진행합니다.

예를 들어, terminationGracePeriodSeconds를 30으로 설정하면, 컨테이너는 종료 신호를 받은 후 30초 동안 종료 과정을 수행할 수 있습니다. 만약 해당 기간 내에 컨테이너가 종료되지 않으면 Kubernetes는 강제로 종료시킵니다.

이렇게 terminationGracePeriodSeconds 속성을 설정하여 컨테이너의 graceful termination을 지원하면 애플리케이션의 안정성과 데이터 무결성을 보다 잘 유지할 수 있습니다.

Graceful termination

Graceful termination(정상 종료)은 컨테이너나 애플리케이션을 종료할 때, 현재 처리 중인 작업이나 연결을 완료하고 정리 작업을 수행하는 것을 의미합니다. 이는 애플리케이션의 안정성과 데이터 무결성을 유지하며, 사용자에게 원활한 서비스 경험을 제공합니다.

기본 값은 30초이며 spec 하위에 선언해줍니다.

...
spec:
  containers:
  - image: ***
  ...
    readinessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 30
      periodSeconds: 30
  terminationGracePeriodSeconds: 60 <<
  ...

lifecycle.preStop

컨테이너가 종료되기 전(pre-stop)에 실행할 작업을 정의하는 속성입니다 예를 들어, 컨테이너 내에서 정리 작업이나 연결 종료, 상태 저장 등의 작업을 수행해야 할 수 있습니다. lifecycle.preStop은 이러한 종료 전 작업을 정의하고 실행할 수 있도록 도와줍니다.

lifecycle.preStop을 사용하면 컨테이너가 종료되기 전에 필요한 작업을 수행할 수 있습니다. 종료 전 작업을 수행함으로써 데이터의 일관성을 유지하거나 리소스를 안전하게 정리할 수 있습니다. 이는 graceful termination을 통해 애플리케이션의 안정성과 사용자 경험을 향상시키는 데 도움을 줍니다.

작동 방식

lifecycle.preStop 설정
- 컨테이너의 스펙 내에서 lifecycle.preStop 속성을 정의합니다. 이 속성은 컨테이너의 lifecycle 속성 중 하나로 설정되며, 실행할 명령을 포함하는 컨테이너 생명주기 후크(hook)를 지정합니다.
PreStop 후크 실행
- 컨테이너가 종료되기 전에 Kubernetes는 lifecycle.preStop에 지정된 명령을 실행합니다. 이 명령은 컨테이너가 안전하게 종료되기 전에 실행되는 스크립트 또는 명령어일 수 있습니다. 예를 들어, 연결을 종료하거나 현재 진행 중인 작업을 완료하는 등의 작업을 수행할 수 있습니다.
대기 시간
- lifecycle.preStop 명령이 실행되고 난 후에도 컨테이너는 정해진 대기 시간(terminationGracePeriodSeconds) 동안 대기합니다. 이 시간 동안 컨테이너는 여전히 요청을 처리하거나 작업을 완료할 수 있습니다.

...
spec:
  containers:
  - image: ***
    lifecycle:  <<
      preStop:
        exec:
          command:
          - /bin/sh
          - -c
          - sleep 40
  ...
    readinessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 30
      periodSeconds: 30
  terminationGracePeriodSeconds: 60
...

lifecycle.preStop으로 인해 컨테이너가 종료되기 전에 sleep 40 명령을 실행하여 40초 동안 대기합니다. 그후 terminationGracePeriodSeconds가 60으로 설정되어있어 컨테이너가 종료되기 전에 60초 동안 대기할 수 있도록 설정한 것입니다. 이 기간 동안 컨테이너는 새로운 버전으로 트래픽을 전달 받을 수 있습니다.

즉, 기존의 파드를 60초동안 대기하며 트래픽을 받습니다. 바로 끊는 것이 아니라 40초동안 대기하고 새로운 파드로 트래픽을 전달합니다.

쿠버네티스는 Node에 Resource가 부족할 때 어떤 순서로 pod를 없앨까?!

hosu4549@gmail.com — Thu, 13 Jul 2023 01:30:00 GMT

들어가며

kubernetes는 node의 리소스에 따라 Pods의 배치 전략도 달라지고, 제한이 됩니다. 이번 게시글에서는 Node의 리소스가 꽉 찼을 때 리소스를 확보하기 위해 어떤 우선 순위에 의해 Pods를 삭제하는지에 대해 알아보겠습니다.

우선 순위

Kubernetes에서 Node의 리소스가 가득 찼을 때 Pod를 삭제하는 순서를 정하는 것은 kube-scheduler에 의해 정해집니다.

QoS 클래스

Kubernetes에서 QoS(Quality of Service)는 Pod의 리소스 요구 사항을 기반으로 Pod를 세 가지 클래스로 분류하는 개념입니다. 해당 클래스는 관리자가 직접 부여하는 것이 아니라 해당 조건이 충족되면 자동으로 부여됩니다. 즉, QoS 클래스는 Pod가 얼마나 신속하게 할당된 리소스를 사용할 수 있는지와 관련이 있는데 세가지로 분류됩니다.

Guaranteed (보장)

리소스 요구 사항을 완벽하게 충족하는 Pod 입니다.
Pod 는 CPU 와 Memory 에 대한 정확한 요구 사항을 지정합니다.
Pod 가 필요한 리소스를 모두 사용할 수 있으며, 다른 Pod 가 리소스를 사용하지 못하도록 합니다.
다른 클래스의 Pod 보다 우선 순위가 높습니다.
이 클래스의 Pod 는 리소스 부족 상황에서도 최우선으로 유지됩니다.

요구 조건

파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 한다.

파드 내 모든 컨테이너의 메모리 상한이 메모리 요청량과 일치해야 한다.

파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 한다.

파드 내 모든 컨테이너의 CPU 상한이 CPU 요청량과 일치해야 한다.

...
spec:
  containers:
  - name: myapp
    image: nginx
    resources: // resource의 limit(cpu,memory)와 request(cpu, memory)가 명시되어있다.
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
...

위의 명세로 파드를 생성한 후 상세 정보를 보게 되면 아래와 같이 status 가 부여된 것을 확인할 수 있습니다.

...
spec:
  containers:
  - name: myapp
    image: nginx
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    
...
status:
  qosClass: Guaranteed
...

Burstable (가변)

일부 리소스를 보장하면서도 추가 리소스를 요청할 수 있는 Pod입니다.
Pod 는 최소한의 리소스 요구 사항을 지정하며, 필요한 경우 추가 리소스를 동적으로 요청할 수 있습니다.
다른 클래스의 Pod보다 우선 순위가 낮습니다.
** Burstable Pod 는 리소스 부족 상황에서 Guaranteed Pod 보다 우선 삭제될 수 있습니다.**
요구 조건
- 파드 내에서 최소한 하나의 컨테이너가 메모리 또는 CPU 요청량/상한을 가집니다.

...
spec:
  containers:
  - name: myapp
    image: nginx
    resources: // resource의 limit.memory와 request.memory만 명시되어있다.
      limits:
        memory: 200Mi
      requests:
        memory: 200Mi
...

위의 명세로 파드를 생성한 후 상세 정보를 보게 되면 아래와 같이 status 가 부여된 것을 확인할 수 있습니다.

...
spec:
  containers:
  - name: myapp
    image: nginx
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
...
status:
  qosClass: Burstable
...

BestEffort (최선의 노력)

리소스 요구 사항이 없거나 매우 낮은 Pod 입니다.
Pod 는 최소한의 리소스를 요청하지 않으며, 리소스를 다른 Pod 와 공유합니다.
다른 클래스의 Pod 보다 우선 순위가 가장 낮습니다.
리소스 부족 상황에서 가장 먼저 삭제될 수 있습니다.
요구 조건
- 파드의 컨테이너에 메모리 또는 CPU의 상한이나 요청량이 없어야 합니다.

...
spec:
  containers:
  - name: myapp
    image: nginx
...

위의 명세로 파드를 생성한 후 상세 정보를 보게 되면 아래와 같이 status 가 부여된 것을 확인할 수 있습니다.

...
spec:
  containers:
  - name: myapp
    image: nginx
    resources: {}       // 비어있음.
...
status:
  qosClass: BestEffort
...

정리

우선순위 클래스에 따라 BestEffort Pod 가 가장 먼저 삭제됩니다.
그 다음으로는 우선순위가 낮은 Burstable Pod 가 삭제됩니다.
Guaranteed Pod 는 리소스가 부족한 상황에서도 최우선으로 유지되며, 가장 마지막에 삭제됩니다.

Reference

https://kubernetes.io/ko/docs/tasks/configure-pod-container/quality-service-pod/

쿠버네티스는 pod를 어떻게 삭제할까??

hosu4549@gmail.com — Wed, 12 Jul 2023 01:00:00 GMT

들어가며

kuberentes 에서 pod 를 어떻게 kill 하는지, 어떻게 delete하는지에 대해 알아보려고 합니다. 상당히 많은 회사에서 물어보는 질문으로 미리 알고갔으면 어땟을까? 하는 생각이 들지만... 늦었더라도 지금이라도 정리하고 넘어가려고 합니다!

순서

사용자 또는 관리자가 아래의 명령으로 Pod 를 삭제 요청합니다.

$ kubectl delete pod <pod-name>

Kubernetes Control Plane 내의 api-server 는 Pod 삭제 요청을 받고, 해당 요청을 클러스터 내의 모든 Control Plane 구성 요소에게 전달합니다.

Control Plane

컨트롤 플레인은 Kubernetes 시스템의 논리적인 부분으로, 클러스터의 마스터 노드에 실행되는 여러 컴포넌트들의 조합입니다.

kube-apiserver

Kubernetes 클러스터의 모든 작업은 API 서버를 통해 수행됩니다. kube-apiserver는 클러스터 내의 모든 리소스 및 작업에 대한 인터페이스를 제공하며, 클라이언트와의 상호 작용을 관리합니다.

etcd

etcd는 Kubernetes 클러스터의 상태 정보를 저장하는 고가용성 분산 key-value 저장소입니다. etcd는 컨트롤 플레인 컴포넌트들 간의 통신과 클러스터의 상태를 유지하는 데 사용됩니다.

kube-scheduler

kube-scheduler는 새로 생성된 Pod에 대해 적합한 노드를 선택하여 배치하는 역할을 합니다. 리소스 요구 사항, 제약 조건, 애플리케이션의 가용성 등을 고려하여 최적의 노드를 선택합니다.

kube-controller-manager

kube-controller-manager는 다양한 컨트롤러를 실행하고 관리합니다. 예를 들면 ReplicaSet, Deployment, StatefulSet, Service와 같은 오브젝트들을 감시하고 클러스터의 상태를 원하는 상태로 유지합니다.

cloud-controller-manager

cloud-controller-manager는 클라우드 제공 업체의 기능과 통합된 컨트롤러를 실행합니다. 클라우드 특정 작업(예: 로드 밸런서 프로비저닝, 스토리지 관리 등)을 처리하는 역할을 합니다.

Kubernetes ControlPlane 내의 kube-controller-manager 는 Pod 가 ReplicaSet 또는 Deployment 와 같은 객체의 소유 Pod 인지 확인합니다.

만약 Pod 가 ReplicaSet 또는 Deployment 에 속한 경우, kube-controller-manager 는 해당 컨트롤러가 관리하는 ReplicaSet 또는 Deployment 에서 Pod 의 개수를 조정합니다. 그로인해 일반적으로 Pod 를 삭제하면 새로운 Pod 를 생성하여 설정된 개수를 유지하도록 합니다.

Pod 를 삭제하기 위해 kube-api-server 는 해당 노드의 kubelet 에게 Pod 삭제 요청을 전달합니다.

kubelet 은 Pod 를 삭제하기 전에 Pod 내의 컨테이너에 SIGTERM 시그널을 보내고, 일정 시간(기본적으로 30초) 동안 대기합니다. 컨테이너는 이 시그널을 받고 종료 준비를 시작합니다.

만약 일정 시간 내에 컨테이너가 종료되지 않으면 kubelet 은 SIGKILL 시그널을 보내어 강제로 컨테이너를 종료시킵니다.

Pod 의 모든 컨테이너가 종료되면 kubelet 은 Pod 를 완전히 삭제하고, 상태 업데이트를 kube-api-server 로 보냅니다.

kube-api-server 는 Pod 삭제 완료를 확인하고, 상태를 업데이트한 후 요청한 클라이언트에 응답합니다.

kubernetes Pod의 상태를 진단하는 Probes

hosu4549@gmail.com — Sat, 01 Jul 2023 06:40:00 GMT

들어가며

처음 kubenetes로 container 운영 환경을 구성하였을 때, 애플리케이션 컨테이너가 생성되지도 않았는데 kube-scheduelr가 scheduling을 하고, ingress에선 해당 파드로 트래픽을 보내는데 아직 생성되지 않아 500 ERROR 발생하기도 하고.. pod가 unhealth 상태인데 kubenetes에선 그 상태를 감지하지 못해 계속 트래픽을 분산하기도 하고.. 아주 곤욕스러웠습니다. 그러던 중 kubernetes에서도 health check를 할 수 있는 Probe가 존재한다는 것을 알게되었고 바로 도입하였습니다.

나아가 kubernetes pod probe는 오픈소스인 botkube를 통해 효율을 극대화 할 수 있습니다. 이번 포스팅에서는 kubernetes의 probe에 대해 다뤄보고 추후에 botkube에 대해 포스팅하도록 할게요!

Probe란?

kubenetes는 kubelet을 통해 pod의 상태를 파악하는 Probe(조사) 기능을 제공합니다.
컨테이너의 상태를 파악하고 라이프 사이클을 제어하는 health-check기능을 수행합니다.
진단을 수행하기 위해서, kubelet은 컨테이너 안에서 코드를 실행하거나, 또는 네트워크 요청을 전송합니다.

종류

ReadnessProbe(준비성 조사)

컨테이너가 요청(트래픽)을 처리할 준비가 되었는지 여부를 나타냅니다.
준비성 프로브가 실패한다면 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP 주소를 제거합니다.

[동작 원리]
- 문제가 발생한 컨테이너는 일시적으로 어떠한 요청도 처리하지 않는 상태가 된다.
- 해당 probe가 성공하게 되면 Pod는 해당 Pod의 Service가 생성되는 시점에 
kube-proxy 에 의해 iptable에 등록되면서 서비스 백엔드에 등록된다.
- 서비스 백엔드에 등록된 pod들은 `chain rule` 에 의해 
해당 서비스로 들어온 트래픽을 분배하고 이를 처리하게 된다.

→ 서비스 백엔드에서 제외되면 해당 pod는 어떠한 요청도 처리하지 않는 상태가 된다.

LivenessProbe(활성 조사)

컨테이너가 동작 중인지 여부를 나타냅니다.
활성프로브에 실패한다면 kubelet은 컨테이너를 죽이고 해당 컨테이너는 재시작 정책의 대상이 됩니다.

StartupProbe(시작 조사)

컨테이너 내의 애플리케이션이 시작 되었는지를 나타냅니다.
스타트업 프로브가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 활성화 되지 않습니다.
스타트업 프로브가 실패하면 kubelet이 컨테이너를 죽이고 컨테이너는 재시작 정책에 따라 처리됩니다.

옵션

health-check

ExecAction

컨테이너에서 지정된 명령어를 실행
명령어를 실행한 후, exit code 가 0이면 성공, 이외의 값은 실패로 분류

TCPSocketAction

지정된 포트로 TCP 소켓 연결을 시도
연결이 정상적으로 이루어지는 경우 성공, 연결에 실패한 경우 실패로 분류

HttpGetAction

지정된 포트와 주소로 HTTP GET 요청을 전송
응답 상태가 200~400 구간에 속하는 경우 성공, 이외에는 실패로 분류

health-check parameter

initialDelaySeconds

기본 옵션
시작하기전에 기다리는 시간을 설정
기본 값 : 0초

periodSeconds

추가 설정 옵션
검사 빈도를 결정
기본 값 : 10초

timeoutSeconds

기본 옵션
얼마나 기다려야 하는지를 결정
기본 값 : 1초

successThreshold

추가 옵션
시도가 실행한 후 성공한 것으로 간주할 최소 연속 성공 횟수를 지정
기본 값 : 1회

failureThreshod

추가 옵션
시도가 실행한 후 실패한 것으로 간주할 최소 연속 실패 횟수를 지정
기본 값 : 3회

example

failureThreshold: 1
initialDelaySeconds: 3
periodSeconds: 3
successThreshold: 1
timeoutSeconds: 3
terminationGracePeriodSeconds: 5

최초 3초 기다리고 (timeoutSeconds : 3)

3초 후에 첫 헬스 체크를 하고 (initialDelaySeconds : 3)

3초 마다 체크하며 (periodSeconds : 3)

수행 실패가 1번 이상이면 실패로 판단한다. (failureThreshold : 1)

failureThreshold: 10
initialDelaySeconds: 3
periodSeconds: 5
successThreshold: 5
timeoutSeconds: 1

최초 1초 기다리고 (timeoutSeconds : 3)

3초 후에 첫 헬스 체크를 하고 (initialDelaySeconds : 3)

5초마다 헬스 체크를 하며 (periodSeconds : 5)

수행 실패가 10번 이상이면 실패로 판단한다. (failureThreshold : 1)

참고

Managing Kubernetes - 03.아키텍처

hosu4549@gmail.com — Sat, 10 Jun 2023 07:00:00 GMT

3. 아키텍처

쿠버네티스는 분산 시스템을 쉽게 배포하고 관리할 수 있도록 고안되었는데, 쿠버네티스는 그 자체로도 관리가 필요한 분산 시스템이다.

개념

시스템이 꽤 복잡해 보일 수 있지만 사실은 비교적 적은 수의 몇몇 개념을 토대로 하고 이 개념들이 전체적으로 반복된다.

선언적 구성(Declarative Configuration)

사용자가 결과를 생성하기 위해 원하는 상태를 선언하는 선언적 구성(declarative configuration)은 쿠버네티스 개발의 주요 동력 중 하나이다.

선언은 실제로 구조화된 YAML 또는 JSON 문서의 형태로 이루어진다.

시스템에 일련의 명령보다 더 많은 것을 제공하며 ‘원하는 상태’를 선언하여 개발자가 원하는 상태를 이해하고 사용자 상호작용과 관계없이 능동적인 조치를 할 수 있다.

즉, 자동으로 자가 수정과 복구가 가능하다. (이는 개발자에게 매우 중요한 기능인데 한밤중에 시스템이 개발자를 깨우지 않고도 스스로 복구가 가능)

조정 또는 컨트롤러

조정

자가 복구나 자가 수정을 수행하기 위해 쿠버네티스는 많은 독립 조정(Independent Reconciliation) 또는 제어 루프(Control Loops)를 기반으로 구성

단일 상태 기반 접근 방식(단일 시스템 설계)
시스템이 모든 프로세스의 상태를 인식하고 모든 것을 조화롭게 발전시키기 위해 완전한 관점 사용
시스템 작동이 중앙 집중화되어 이해하기 쉬움.
안정적이지 않다.
예기치 않은 일이 발생하면 전체 시스템이 다운될 수 있음
분산형 컨트롤러 기반 접근 방식
많은 수의 컨트롤러로 구성되어 각 컨트롤러는 자체 독립 조정 루프를 수행
- 독립적인 조정 루프
  1. 원하는 상태를 얻는다.
  2. 관찰한다.
  3. 관찰 결과와 원하는 상태 사이의 차이점을 찾는다.
  4. 관찰 결과와 원하는 상태가 일치하도록 조치를 취한다.
각 컨트롤러는 다른 나머지 부분과는 완전히 무관
작은 문제에 집중하고 해결하면 전체 시스템을 훨씬 더 안정적으로 만듬.
시스템의 작동 방식에 대한 설명을 찾을 수 있는 단일 위치가 없으므로 시스템의 전반적인 동작을 이해하기 어려움.

쿠버네티스 컨트롤러

쿠버네티스 API 서버에 대한 선언문으로 원하는 상태를 관찰

[동작 원리]
# 사용자는 "웹 서버의 레플리카 4개가 필요합니다." 라고 선언
1) 쿠버네티스 복제 컨트롤러는 원하는 상태를 받아들이고 현재 상태를 관찰.
2) 컨트롤러는 현재 상태와 원하는 상태 사이의 차이점을 찾음.
3) 원하는 상태와 일치하도록 컨테이너를 생성/삭제 작업 수행.

암시적 또는 동적 그룹화

어떤 것을 한 집합으로 묶을 때에는 두 가지 접근법이 존재.

명시적/정적 그룹화
- 모든 그룹이 구체적인 목록으로 정의(ex. 내 팀원은 alice, bob, ted입니다.)
- 목록은 그룹의 멤버 이름을 명시적으로 호출하며 목록은 정적이다.
- 목록 자체가 변경되지 않으면 멤버 자격이 변경되지 않는다.
- 그룹에 누가 있는지 알기 위해서는 그저 목록을 읽기만 하면 된다.
- 유연성이 부족하여 동적으로 변화하는 것에 대응 하기 어렵다.
암시적/동적 그룹화
- 멤버 목록 대신 그룹을 ‘우리 팀원은 오렌지색의 옷을 입고 있는 사람들입니다’ 와 같은 문구로 정의
- 그룹의 정의에는 일일이 이름이 적힌 멤버가 없다.
- 존재하는 사람들에 대한 그룹을 정의
- 복잡성을 초래할 수 있지만, 훨씬 더 유연하고 안정적이며 정적 목록을 지속해서 조정하지 않고도 변화에 대응 할 수 있다.
- 쿠버네티스에서는 레이블, 레이블 쿼리 또는 레이블 셀렉터로 수행된다.

구조

유닉스 철학

첫 번째 원칙은 쿠버네티스가 일반적인 유닉스 철학인 ‘각자 일을 잘 수행하는’ 작은 조각, 즉 모듈화를 기반으로 한다.

쿠버네티스는 단일 바이너리에서 다양한 기능을 모두 구현하는 단일 애플리케이션이 아니다.

쿠버네티스라는 전체 시스템을 구현하기 위해 서로 모르는 다른 애플리케이션의 모음이다.

다수의 상이한 기능을 함께 그룹화하는 바이너리가 있을지라도 그 기능들은 해당 바이너리 내에서 거의 독립적으로 유지된다.

구성 요소 간의 긴밀한 결합 때문이 아니라 쿠버네티스를 쉽게 배포하고 관리할 수 있도록 컴파일 된다.

→ 이 모듈 방식의 장점은 쿠버네티스가 유연하다는 것.

시스템의 큰 부분을 교체할 때도 다른 부분을 고려하거나 신경 쓰지 않고 그 부분만 교체할 수 있다.
시스템을 배포하고 모니터링하고 이애하기 위해서 여러 가지 툴에 정보와 구성을 통합해야하기 때문에 복잡하다.

API 기반 상호작용

쿠버네티스의 두 번째 구조 설계 원칙은 구성 요소 간의 모든 상호작용이 중앙 집중식 API로 이루어진다는 것이다.

→ 구성 요소가 사용하는 API가 다른 모든 클러스터 사용자가 사용하는 API와 완전 동일

시스템의 어느 부분도 다른 어떤 부분보다 특권을 갖지 않고 상호간에 직접 접근할 수 없다.
API서버를 제외하고는 내부에 대한 접근 권한이 전혀 없다.
- 모든 구성 요소를 대체 구현하여 교체할 수 있으며 핵심 구성요소를 재구성하지 않고도 새로운 기능을 추가할 수 있다.

구성 요소

쿠버네티스는 다수 장비를 하나의 단위로 그룹화하여 API로 사용할 수 있는 시스템

쿠버네티스 구현 시에는 실제로 장비 집합을 워커 노드와 헤드 노드라는 두 그룹으로 나눈다.

쿠버네티스 인프라를 구성하는 대부분의 구성 요소는 헤드, 제어, 플랜 노드에서 실행된다.

클러스터에는 일반적으로 노드 수가 1개, 3개, 5개로 제한되어 있다.

이 노드에서는 etcd나 API 서버와 같은 쿠버네티스를 구성하는 요소를 실행한다.

노드의 수는 홀수인데 쿼럼에 대해 Raft/Paxos 알고리즘을 사용하여 쿼럼을 공유 상태로 유지

클러스터의 실제 작업은 워커 노드에서 수행된다.

쿠버네티스의 구성 요소가 생성되면 쿠버네티스 클러스터에 스케줄된다.

헤드 노드의 구성 요소

헤드 노드는 쿠버네티스 클러스터의 두뇌이다.

쿠버네티스 API 기능을 구현하는 핵심 구성 요소들이 모아져 있다.

etcd

쿠버네티스 클러스터의 핵심
쿠버네티스 클러스터의 모든 오브젝트가 유지되는 키/값 저장소를 만든다.
분산된 합의 알고리즘인 Raft를 구현하여 스토리지 서버 중 하나에 장애가 발생하더라도 etcd에 저장된 데이터를 유지하고, etcd 서버가 정상 상태가 되어 다시 클러스터에 추가할 때 데이터를 복구할 수 있도록 충분한 복제가 이루어진다.
etcd 서버는 쿠버네티스가 많이 사용하는 두 가지 중요한 기능을 제공한다.
1. 낙관적인 동시성
  - etcd에 저장된 모든 값에는 해당 리소스 버전이 있다.
  - 키/값 쌍이 etcd 서버에 기록되면 특정 리소스 버전을 조건으로 지정할 수 있다.
  - etcd를 사용하면 모든 동시성 시스템에서 제일 중요한 비교 후 교환(CAS, Compare and swap)을 구현
  - 비교 후 교환을 사용하면 사용자가 값을 읽고 시스템의 다른 구성 요소가 값을 업데이트하지 못했다는 것을 알게 되어 업데이트 할 수 있게 된다.
  → 시스템이 비관적인 잠금장치가 없어도 etcd의 데이터를 조작하는 다중 스레드를 안전하게 가질 수 있게 하여 서버의 처리량을 크게 줄일 수 있다.
2. 워치(Watch) 프로토콜 구현
  - 워치의 장점은 클라이언트가 전체 값 디렉터리에 대한 키/값 저장소의 변경 사항을 효율적으로 감시할 수 있다는 것
  - 워치를 사용하면 클라이언트가 지속적으로 etcd 서버에 폴링하지 않아도 변경 사항을 효율적으로 기다리고 이에 대응할 수 있다.

API 서버

etcd가 쿠버네티스 클러스터의 핵심이긴 하지만 쿠버네티스 클러스터에 직접 접근할 수 있는 서버는 실제로 API서버 하나 뿐이다.

API 서버는 쿠버네티스 클러스터의 허브로서 클라이언트와 etcd에 저장된 API 오브젝트 사이의 모든 상호작용을 중개한다.

→ 결과적으로 다양한 구성 요소 모두에 대한 중앙 집중 지점이 된다.

스케줄러

파드가 실행될 위치를 찾는 것이 바로 쿠버네티스 스케줄러의 역할

→ 스케줄러는 API 서버에서 스케줄 되지 않은 파드를 검색한 다음, 이들을 실행할 최적의 노드를 결정

컨트롤러 관리자

etcd, API 서버, 스케줄러가 작동한 후에는 성공적으로 파드를 만들고 노드에 스케줄된 것을 볼 수 있지만 예상대로 ReplicaSets, Deployment, Service는 작동하지 않는다.

→ 필요한 모든 조정 제어 루프가 현재 실행중이지 않기 때문이다.

루프를 실행하는 것은 컨트롤러 관리자의 역할

모든 노드의 구성 요소

쿠블렛(kubelet)

쿠버네티스 클러스터의 일부인 모든 시스템의 노드 데몬이다.
사용 가능한 CPU, 디스크, 노드의 메모리를 큰 쿠버네티스 클러스터에 연결하는 다리이다.
API 서버와 통신하여 노드에서 실행되어야 하는 컨테이너를 찾는다.
다른 조정 제어 루프가 컨테이너의 현재 상태를 볼 수 있다.
실행될 것으로 예상되는 컨테이너의 상태를 확인하고 다시 시작하는 일을 담당한다.

→ 쿠블렛이 실행한 컨테이너가 죽거나 상태 점검에 실패하면 쿠블렛은 컨테이너를 다시 시작하고 상태와 재시작 정보를 다시 API 서버에 전달한다.

kube-proxy

모든 컴퓨터에서 실행되는 다른 구성 요소
쿠버네티스 Service 로드 밸런서 네트워킹 모델 구현을 담당

[동작 원리]
1. 쿠버네티스 클러스터의 모든 서비스에 대한 엔드 포인트 오브젝트를 항상 감시한다.
2. 노드의 네트워크를 프로그래밍하여 Service의 가상 IP 주소에 대한 네트워크 요청이 실제로 
	 Service를 구현하는 엔드포인트로 라우팅되도록 설정한다.

쿠버네티스의 모든 Service는 가상 IP 주소를 가지며 kube-proxy는 로컬 로드밸런서를 정의하고 구현하는 데몬이다.

→ 클러스터 내의 어떤 곳이든 파드에서 파드로 트래픽을 라우팅하게 된다.

스케줄된 구성 요소

쿠버 DNS

스케줄된 구성 요소 중 첫 번째는 쿠버 DNS 서버이다.
쿠버네티스 Service가 생성되면 가상 IP 주소를 얻지만 해당 IP 주소는 DNS 서버에 프로그램이되어 쉽게 검색할 수 있다.
쿠버 DNS 컨테이너는 쿠버네티스 Service 오브젝트에 대해 네임 서비스를 구현한다.
쿠버 DNS Service 자체는 쿠버네티스 Service로 표현되므로 kube-proxy가 제공하는 동일한 라우팅이 DNS 트래픽을 쿠버 DNS 컨테이너로 라우팅된다.

→ 쿠버 DNS 서비스에 정적 가상 IP 주소가 부여된다.

→ API 서버가 생성한 모든 컨테이너에 DNS 서버를 프로그래밍할 수 있음을 의미하며 쿠버네티스 서비스에 대한 이름 지정 및 서비스 검색이 가능해짐을 의미한다.

힙스터

쿠버네티스 클러스터에서 실행되는 모든 컨테이너에서 CPU, 네트워크, 디스크 사용량과 같은 메트릭을 수집한다.
이러한 메트릭은 인플럭스DB(InfluxDB)와 같은 모니터링 시스템으로 푸시되어 클러스터의 애플리케이션 상태에 대한 경고 및 일반 모니터링을 수행한다.
쿠버네티스 클러스터 내에서 파드의 자동 스케일링을 구현하는데 이러한 메트릭을 사용한다.

→ 힙스터는 특정 기준을 수집하고 집계하여 자동 측정기가 구현한 조정 루프를 가동하는 구성 요소.
metric-server와 metric API로 대체되었다.

마치며

쿠버네티스는 API 서버를 실행하는 컨트롤 플랜 노드와 API 백업 스토어를 구성하는 etcd클러스터를 포함해 완전한 쿠버네티스 API를 구현하는 다양한 구성 요소를 가진 복잡한 분산 시스템
스케줄러는 API 서버와 상호작용하여 컨테이너를 특정 워커 노드로 스케줄링하고, 컨트롤러 관리자는 클러스터가 올바르게 작동하도록 대부분의 제어 루프를 작동
클러스터가 제대로 작동하면 클러스터 DNS 서비스, 쿠버네티스 서비스 로드 밸런서 인프라 구조, 컨테이너 모니터링 등을 비롯하여 클러스터 자체에서 실행되는 수많은 구성 요소가 작동

Reference

https://techdozo.dev/kubernetes-architecture/

Managing Kubernetes - 02.쿠버네티스 살펴보기

hosu4549@gmail.com — Sat, 06 May 2023 06:00:00 GMT

쿠버네티스 살펴보기

쿠버네티스 API를 기반으로 애플리케이션을 작성, 배포, 관리하는 것은 그 자체로 아주 복잡한 주제입니다.

컨테이너

컨테이너는 도커가 등장하며 대중화되었으며 개발자가 애플리케이션을 패키지화하고 배포하는 방식에 혁명을 일으켰습니다.

쿠버네티스는 컨테이너 오케스트레이터 이기 때문에 쿠버네티스를 제대로 이해하기 위해서는 일단 컨테이너가 무엇을 의미하는지 정확히 이해하는 것이 중요합니다.

컨테이너는 아래의 개념을 포함합니다.

컨테이너 이미지
실행중인 프로세스 또는 프로세스를 격리하는 일련의 운영체제 개념

컨테이너 이미지

애플리케이션 런타임을 포함하는데, 이는 바이너리, 라이브러리, 컨테이너를 실행하는 데 필요한 기타 데이터로 구성합니다.
개발자는 자신의 컴퓨터에서 애플리케이션을 컨테이너 이미지로 패키지화합니다.
다른 사용자의 컴퓨터나 데이터 센터 서버와 같은 다른 환경에서 이미지를 배포하고 실행할 때, 자신의 컴퓨터에서와 동일하게 컨테이너가 작동합니다.

💡 다양한 환경에서의 이식성과 일관된 실행은 컨테이너 이미지가 추구하는 주요 가치입니다.

컨테이너 이미지가 실행될 때 운영체제의 네임스페이스를 사용하여 실행합니다.
이러한 네임스페이스는 프로세스를 포함하고 있으며, 이 프로세스는 시스템에서 실행 중인 다른 작업의 프로세스나 이와 관련된 것과 격리합니다.
각 컨테이너에는 고유한 자체 네트워크 및 프로세스 식별자(PID) 네임스페이스 존재합니다.
또한 제어그룹(cgroup)을 사용하면 메모리나 CPU와 같은 리소스 사용 격리합니다.

💡 격리에 관해 이야기 할때는 CPU, 메모리, 파일과 같은 자원과 관련이 있다는 것이 중요합니다.

이 모든 작업을 수행하기 위해 컨테이너형 애플리케이션을 빌드하고 배포하는 데 도움이 되는 여러 툴이 존재합니다.

컨테이너 이미지 빌더

오픈 컨테이너 이니셔티브 (OCI) 표준으로 이미지 형식이 표준화

OCI (Open Container Initative)

-> 이 표준으로 클라우드 API, CI/CD 또는 새로운 대체 툴과 라이브러리로 제공되는 다른 이미지 빌더를 개발

표준 동작(standard operation)

표준 컨테이너 도구들을 이용하여 컨테이너의 생성, 시작, 정지

표준 파일 시스템 도구를 이용해서 컨테이너의 스냅샷과 복사

표준 네트워크 도구들을 이용해서 컨테이너의 업로드와 다운로드

내용 중립성(content-agnostic)

표준 컨티에너는 컨테이너가 담고 있는 애플리케이션의 종류에 상관 없이 표준 동작들이 동일하게 동작

인프라 중립성 (Infrastructure agnostic)

표준 컨테이너는 OCI 지원 인프라라면 종류에 상관없이 컨테이너 실행이 가능

자동화를 위한 설계 (designed for Automation)

표준 컨테이너는 컨테이너 내용과 인프라 종류에 상관없이 동일한 표준 동작을 지원하기 때문에 자동화가 용이

산업 수준의 배포 (Industrygrade delivery)

표준 컨테이너는 기업 규모에 상관 없이 산업 수준의 배포가 가능

이미지 레지스트리

컨테이너 이미지를 만든 후에는 해당 이미지를 사용자의 컴퓨터에서 다른 사용자, 클라우드, 개인 데이터 센터에 배포하는 방법이 필요
이미지 레지스트리는 이미지를 업로드하고 관리하기 위한 API
이미지가 빌드되면 이미지 레지스트리로 푸시
모든 레지스트리는 이미지를 푸시할 수 있는 권한이 있어야 하지만 일부 레지스트리는 공개되어 있으므로, 이미지를 푸시하면 전세계 누구나 이미지를 가져오거나 실행
모든 공개 클라우드에는 사용할 수 있는 서비스 레지스트리가 있으며, 자체 사용자 환경에서 다운로드해서 실행할 수 있는 오픈 소스 레지스트리 서버 존재

컨테이너 오케스트레이션

애플리케이션을 컨테이너 이미지로 패키징하고 레지스트리로 푸시한 다음에는 해당 컨테이너를 사용하여 애플리케이션을 배포해야 한다.
레지스트리 어딘가에 컨테이너 이미지를 저장한 후 동작하는 애플리케이션을 만들려면 컨테이너 이미지를 실행해야 한다.
쿠버네티스의 역할은 CPU, 메모리, 디스크와 같은 컴퓨팅 리소스 그룹을 가져와서 개발자가 컨테이너를 배포하는 데 사용할 수 있도록 컨테이너 지향 API로 변환하는 것.

# ‘컨테이너 이미지를 실행하고 올바르게 운영하려면 코어 3개와 메모리 10GB가 필요합니다.’
1. 쿠버네티스 시스템은 일련의 리소스를 검토
2. 해당 컨테이너 이미지가 실행될 수 있는 좋은 위치를 검토
3. 해당 컴퓨터 위치에서 컨테이너가 실행되도록 스케줄
→ 개발자는 자신의 컨테이너 이미지가 실행되는 것을 확인할 수 있지만 컨테이너가 구체적으로 어디에서 실행되는지 관심을 둘 필요가 없다.

오케스트레이션 시스템은 컨테이너를 서버에 스케줄 하는 것 이상의 의미
쿠버네티스 오케스트레이터는 문제가 발생했을 때 컨테이너를 복구하는 방법이 내장 → 컨테이너 내부의 프로세스가 충돌하면 쿠버네티스가 다시 시작
사용자 정의 상태 검사(health check)를 정의하면 쿠버네티스는 애플리케이션이 교착 상태에 있어서 다시 시작해야 하는지 정상 검사(liveness check), 로드 밸런싱 조정 서비스 준비 상태 검사(Readness check) 를 해야 하는지 확인
로드밸런싱(부하분산)과 관련하여 쿠버네티스는 다양한 레플리카(복제본)간 트래픽의 로드밸런싱 방법을 정의하는 API 오브젝트 제공 또한 쿠버네티스는 제로 다운타임 롤아웃을 수행하고 설정, 퍼시스턴트 볼륨, 시크릿등을 관리하는 오브젝트를 가지고 있습니다.

쿠버네티스 API

쿠버네티스 API는 HTTP 및 JSON 기반의 RESTful API이며 API 서버가 제공되며 모든 구성 요소는 API를 이용해 통신

기본 오브젝트 : 파드, 레플리카셋, 서비스

파드(Pod)

쿠버네티스 클러스터 스케줄링에서 가장 작은 원자
파드를 원자라고 하는 것은 모든 컨테이너가 클러스터에서 동일한 시스템을 차지하도록 보장한다는 의미합니다.
파드는 하나 이상의 실행중인 컨테이너로 구성합니다.
프로세스와 프로세스 간 통신 네임스페이스를 공유하고 있어서, 공유 메모리나 시그널링 같은 툴을 사용하여 다른 컨테이너에서 파드의 여러 프로세스를 제어합니다.
이러한 밀접한 그룹화는 메인 컨테이너와 백그라운드에서 데이터를 로딩하는 컨테이너 처럼 파드가 컨테이너 사이의 공생관계를 이상적으로 적합하다는 것을 의미합니다.
만약 컨테이너 이미지를 별도로 유지하면 일반적인 경우에 서로 다른 팀 간 컨테이너 이미지를 소유하거나 재사용할 때 빠르게 사용할 수 있습니다.
반면 컨테이너 이미지를 런타임에 파드 안에서 함께 그룹화하면 조화롭게 사용합니다.
파드는 스케일링과 복제의 단위
파드는 애플리케이션이 계속해서 실행 상태에 있도록 도와줍니다.
컨테이너의 프로세스가 충돌하면 쿠버네티스는 자동으로 프로세스를 다시 시작합니다.

레플리카셋(ReplicaSet)

컨테이너 오케스트레이션을 사용하는 주된 이유는 복제된 시스템을 안정적으로 더 쉽게 구축하기 위함
주어진 파드 정의에서 시스템에 여러 개의 복제본이 존재함을 보장

서비스(Service)

Service는 TCP나 UDP 로드 밸런싱 서비스를 나타낸다.
모든 서비스는 TCP 또는 UDP에 상관없이 아래의 세가지를 갖고 있다.
자체 IP 주소
쿠버네티스 클러스터 DNS 항목
Service를 구현하는 파드로 트래픽을 프록시하는 로드밸런싱 규칙
Service가 생성되면 고정 IP가 할당됩니다.
이 IP는 가상 주소여서 네트워크에 있는 인터페이스과 일치하지는 않습니다.
대신 할당된 IP주소는 로드 밸런싱될 IP주소로 네트워크 패브릭에 프로그램이 됩니다.
패킷이 해당 IP로 전송되면 Service를 구현하는 파드 집합으로 로드밸런스 됩니다.
로그밸런싱은 라운드 로빈이나 소스 및 대상 ip 주소 튜플에 기반해 결정하는 방식으로 수행합니다.

라운드 로빈 스케줄링 (Round Robin Scheduling)

시분한 시스템을 위해 설계된 선점형 스케줄링 프로세스들 사이에 우선 순위를 두지 않고, 순서대로 시간 단위로 CPU를 할당하는 방식

고정 IP가 주어지면, DNS 이름이 쿠버네티스 클러스터의 DNS 서버에 프로그래밍합니다.
이 DNS 주소는 쿠버네티스 Service 오브젝트의 이름과 동일한 의미의 이름을 제공하며, 클러스터의 다른 컨테이너가 Service 로드밸런서의 IP 주소를 검색할 수 있게 해줍니다.
Service의 로드 밸런싱은 쿠버네티스 클러스터의 네트워크 패브릭에 프로그래밍 되어 Service IP 주소와 통신하려고 시도하는 컨테이너가 해당 파드에 올바르게 로드밸런싱합니다.
이 네트워크 패브릭 프로그래밍은 동적이므로 ReplicaSet의 장애나 확장으로 파드들이 오갈 때 로드밸런서는 클러스터의 현재 상태와 일치하도록 끊임없이 다시 프로그래밍합니다.
즉, 클라이언트는 Service를 구현하는 파드에 대한 Service IP 주소 연결을 신뢰할 수 있음을 의미합니다.

스토리지: 퍼시스턴트 볼륨, 컨피그맵, 시크릿

쿠버네티스에서 처음 소개된 스토리지 개념이 볼륨이다.
실제로 파드 API 의 일부
볼륨은 다양한 유형에서 선택할 수 있으며 NFS, iSCSI, gitRepo, 클라우드 스토리지 기반 볼륨등 10가지가 넘는 유형의 볼륨을 생성
파드에 볼륨을 추가할 때 실행 중인 각 컨테이너의 임의의 위치에 볼륨을 연결
실행중인 컨테이너가 볼륨 내의 스토리지에 접근
다른 컨테이너들은 이 볼륨을 다른 위치로 연결하거나 무시

ConfigMap 오브젝트

구성 파일의 모음
파드에 ConfigMap 기반의 볼륨을 추가하면 ConfigMap의 파일이 실행중인 컨테이너의 지정된 디렉토리에 나타냅니다.

Secret

쿠버네티스는 데이터베이스 암호 및 인증서와 같은 보안 데이터에 시크릿 구성 유형을 사용합니다.
볼륨으로 파드에 부착할 수 있으며 사용중인 컨테이너에 연결할 수 있습니다.

persistentVolumes(퍼시스턴티 볼륨)과 persistenetVolumesClaims(퍼시스턴트 볼륨 클레임)

구체적 제공자를 지정하지 않고 일반적인 스토리지를 요청하는 경우에는 파드 정의가 필요합니다.
파드에 직접 볼륨을 결합하는 대신 PersistentVolume이 별도의 오브젝트로 생성합니다.
PersistentVolumesClaims이 오브젝트를 특정 파드에 할당하고 이 요청으로 파드에 최종 연결합니다.

클러스터 구성 오브젝트 : 네임스페이스, 레이블, 어노테이션

네임스페이스

클러스터 구성을 위한 첫 번째 오브젝트는 Namespace입니다.
쿠버네티스 API 오브젝트를 위한 폴더
Namespace는 역할 기반 접근 제어(RBAC:Role-Based Access Control) 규칙의 범위를 제공합니다.
폴더와 마찬가지로 Namespace를 삭제하면 그 안에 잇는 모든 오브젝트도 삭제합니다.
모든 쿠버네티스 클러스터에는 default라는 이름의 기본 제공 Namespace가 있으며, 보통 쿠버네티스를 설치할 때는 클러스터 운영 컨테이너가 생성되는 곳인 kube-system이라는 Namespace도 같이 생성합니다.

💡 쿠버네티스 오브젝트는 네임스페이스에 배치할 수 있는지에 따라 네임스페이스 오브젝트와 비네임스페이스 오브젝트로 나눈다. 가장 일반적인 쿠버네티스API 오브젝트는 네임스페이스 오브젝트이다. 그러나 전체 클러스터에 적용되는 일부 오브젝트는 네임스페이스 오브젝트가 아니다.

쿠버네티스 오브젝트를 구성하는 것 외에도 namespace는 service용으로 작성된 DNS 이름과 컨테이너에 제공되는 DNS 검색 경로에도 배치됩니다.
즉, 서로 다른 Namespace의 서로 다른 Service가 서로 다른 정규화된 도메인 이름(FQDNs : Fully Qualified Domain Names)를 갖게 된다는 뜻입니다.
또한 각 컨테이너의 DNS 검색 셩로에는 Namespace가 포함되어 있습니다.

# foo namesapce의 frontend 컨테이너에 대한 DNS 조회 
frontend.svc.foo.cluster.internal 
# bar namespace의 frontend 컨테이너에 대한 DNS 조회 
frontend.sve.bar.cluster.internal

레이블과 레이블 쿼리

쿠버네티스 API의 모든 오브젝트는 연관된 임의의 레이블 집합을 가질 수 있습니다.
레이블은 오브젝트를 식별하는 데 도움이 되는 문자열 키/값 쌍

ex ) “role” : “frontend”

레이블 쿼리

레이블을 사용하여 API의 오브젝트를 조회하고 필터링합니다.

레이블 셀렉터

쿠버네티스 API의 많은 오브젝트는 자신에게 적용되는 오브젝트 집합을 식별하는 방법합니다.

ex) 노드 셀렉터 : 파드를 실행할 수 있는 노드 집합을 식별 / 파드 셀렉터 : service에서 로드 밸런스를 조정해야 하는 파드 집합을 식별

어노테이션

API 오브젝트에 할당할 모든 메타데이터 값이 정보를 식별하는 용도는 아닙니다.
일부 정보는 단순히 오브젝트 자체에 대한 어노테이션(주석)
오브젝트 옆에 표시할 아이콘이나, 오브젝트가 시스템에 의해 해석되는 방식을 변경하는 수정자 같은 것이 포함합니다.

고급 오브젝트 : 디플로이먼트, 인그레스, 스테이트풀셋

디플로이먼트(Deployment)

ReplicaSets은 동일한 컨테이너 이미지의 여러 레플리카를 실행하는 기본 요소이지만 애플리케이션은 정적 오브젝트가 아닙니다.
새 코드를 Service에 적용하는 작업은 부하를 안정적으로 처리하기 위해 복제하는 것만큼이나 중요합니다.
Deployment 오브젝트는 한 버전에서 다른 버전으로 안전한 롤아웃을 나타햅니다.
여러 개의 ReplicaSets에 대한 포인터를 보유할 수 있으며 한 ReplicaSet에서 다른 ReplicaSet으로 빠르고 안전한 이동(migration)을 제어할 수 있습니다.

[동작 이해]
# rs-v1이라는 ReplicaSet의 레플리카 3개에 배포된 애플리케이션
1) Deployment에 새 이미지 (v2)를 롤아웃하도록 요청
2) Deployment는 단일 레플리카를 사용하여 새 ReplicaSet(rs-v2) 작성 
3) Deployment는 이 레플리카가 정상적으로 유지될때 까지 기다림
4) 잘 유지되면 Deployment는 rs-v1의 레플리카 수를 2로 줄임
5) 그런 다음 rs-v2의 레플리카 수도 2개로 늘리고 v2의 두 번째 레플리카가 정상저긍로 유지될 때 까지 기다림
6) 위의 프로세스를 v1 replica가 더는 없고 v2 replica가 3개가 될 때까지 반복

💡 실제로 대부분의 최신 클러스터에서는 사용자가 Deployment 오브젝트를 단독으로 사용하고 ReplicaSets을 관리하지 않는다.

HTTP 로드 밸런싱과 인그레스

사용자가 컨테이너와 쿠버네티스를 사용하여 배포하는 대부분의 애플리케이션은 HTTP 웹 기반 애플리케이션이기 때문에 HTTP를 이해하는 로드밸런서를 제공
Ingress(인그레스, 수신) API가 쿠버네티스에 추가합니다.
- 경로 및 호스트 기반 HTTP 로드 밸런서와 라우터를 나타냅니다.
- 오브젝트를 만들 때 Ingress 오브젝트는 서비스와 마찬가지로 가상IP주소를 받지만, 서비스 IP주소와 파드 집합 간의 일대인 관계 대신 Ingress가 HTTP 요청 내용을 사용하여 이를 다른 Service로 라우팅합니다.
- 호스트나 경로, 혹은 둘 다 설정 가능합니다.

[동작 이해]
# foo와 bar라는 두 개의 쿠버네티스 Service가 존재
# 각자 고유한 IP주소가 있지만 실제로 동일한 호스트의 일부로 인터넷에 노출하려고 한다.
1) foo.company.com, bar.company.com Ingress 오브젝트를 만들고 IP 주소를 각 DNS 이름과 연결
2) Ingress 오브젝트에서 호스트 이름 두 개를 각각의 쿠버네티스 Service에 매핑
3) foo.company.com에 대한 요청이 수신될 때 클러스터의 foo Service로 라우팅 (bar도 마찬가지)
4) 호스트 외에 경로로 설정이 가능하여 company.com/bar를 bar Service로 라우팅 가능

💡 쿠버네티스는 Ingress 오브젝트를 저장하지만 생성할 때는 아무 일도 일어나지 않는다. 대신 클러스터에서 인그레스 컨트롤러를 실행하여 Ingress 오브젝트를 만들 때 적절한 작업을 수행해야 합니다.

스테이트풀셋(StatefulSet)

각 레플리카는 다른 레플리카와 구별되는 고유한 ID가 없습니다.
ReplicaSets과 마찬가지로 StatefulSets은 쿠버네티스 클러스터에서 실행되는 동일한 컨테이너 이미지의 여러 인스턴스를 만들지만, 각 컨테이너의 이름에 따라 컨테이너를 만들고 삭제합니다.
ReplicaSet에서 복제된 각 파드는 임의의 해시(ex. frontend-13au2)와 관련된 이름으로 생성되며 순서를 지정하지 않습니다.
StatefulSet의 경우, 각 레플리카는 단조롭게 증가하는 색인(ex. frontend—0,frontend-1 등)으로 생성됩니다.
StatefulSets은 레플리카 1이 생성되기 전에 레플리카 0이 생성되어 정상적이 될 것이라고 보장합니다.

배치 워크로드 : 잡과 크론잡

잡(Job)

행해야 할 작업 집합
ReplicaSets와 StatefulSets와 마찬가지로 컨테이너 이미지를 실행하여 작업을 실행하는 파드를 생성합니다.
ReplicaSets와 StatefulSets과 달리 Job에 의해 생성된 파드는 작업을 완료하고 종료합니다.

크론잡(CronJob)

Job에 일정을 추가하여 Job 오브젝트 위에 구축합니다.
생성하려는 Job 오브젝트의 정의와 해당 Job을 언제 생성해야 하는지 스케줄 포함합니다.

클러스터 에이전트와 유틸리티 : 데몬셋

쿠버테니트스는 DaemonSet API로 사용자가 클러스터에 에이전트를 설치할 수 있게 합니다.
DaemonSet이 생성되면 쿠버네티스는 이 파트가 클러스터의 각 노드에서 실행중인지 확인합니다. -> 나중에 새로운 노드가 추가되면 쿠버네티스는 해당 노드에도 파드를 만들게 됩니다.
기본적으로 쿠버네티스는 클러스터의 모든 노드에 파드를 배치하지만 DaemonSet은 노드 셀렉터 레이블 쿼리도 제공할 수 있으며, DaemonSet의 파드를 해당 레이블 쿼리와 일치하는 노드에만 배치합니다.

kubelet이란?

hosu4549@gmail.com — Wed, 03 May 2023 06:40:00 GMT

각 Node에는 ControlPlane과 통신하는 kubelet이 있습니다. kubelet은 각 노드에서 실행되는 기본 Node Agent입니다.

즉, 쿠블릿(kubelet)은 노드에서 컨테이너가 동작하도록 관리해 주는 핵심 요소입니다. 각 노드에서 파드를 생성하고 정상적으로 동작하는지 관리하는 역할을 담당하고 있으며, 실제로 우리가 쿠버네티스의 워크로드를 관리하기 위해 내려지는 명령은 kubelet을 통해 수행된다고 볼 수 있습니다.

작동 방식

쿠버네티스 파드를 관리하기 위해 YAML 파일을 작성합니다.
kubectl 명령어를 통해 해당 명령을 쿠버네티스 클러스터에 적용합니다.
이때 YAML의 명령이 kube-apiserver로 전송된 후 kubelet으로 전달됩니다.
kubelet은 이 YAML을 통해 전달된 파드를 생성 혹은 변경하고, 이후 이 YAML에 명시된 컨테이너가 정상적으로 실행되고 있는지 확인합니다.

기능

kublet은 컨테이너가 포드에서 실행되게 합니다. 컨트롤 플레인에서 노드에 작업을 요청하는 경우 kubelet이 이 작업을 실행합니다.
api-server와 통신하며, PodSpecs라는 설정을 받아서 그 조건에 맞게 컨테이너를 실행하고 컨테이너가 정상정으로 실행되고 있는지 상태 체크를 진행합니다.
선언된 상태와 일치하지 않는 Pod가 있는지 확인하고, 어떤 Node에 Pod을 배치하면 좋을지 결정합니다.
어디에 배치할 지는 Scheduler가 결정하지만 실제로 Container Runtime(Docker등)에 배치를 명령하는 것은 kubelet입니다.

Reference

Managing Kubernetes - 01.쿠버네티스란?

hosu4549@gmail.com — Wed, 26 Apr 2023 06:00:00 GMT

쿠버네티스란

쿠버네티스는 컨테이너화된 애플리케이션을 배포하기 위한 오픈 소스 오케스트레이터(orchestrator)입니다.

쿠버네티스는 애플리케이션 지향 API로 구글이 컨테이너에 확장 가능하고 안정적인 시스템을 배포해온 10년의 경험을 토대로 개발하여 배포되었습니다.

쿠버네티스 클러스터

클러스터는 쿠버네티스가 최종 사용자에게 줄 수 있는 전체 컴퓨팅 리소스를 제공하기 위해 함께 작동하는 여러 시스템이며 모두 단일 API로 제어되며 해당 API의 사용자가 사용할 수 있는 시스템 모음입니다.

쿠버네티스 클러스터는 간단한 선언 구문을 사용하여 애플리케이션을 정의하고 배포할 수 있게 해주는 오케스트레이션 API를 제공
오류가 있는 경우 애플리케이션을 복구하는 수많은 온라인 자가 재해 복구 알고리즘을 자체척으로 제공
쿠버네티스 API는 소프트웨어 무중단 업데이트를 더욱더 쉽게 수행 할 수 있게 배포
서비스의 여러 레플리카 간에 트래픽을 쉽게 분산할 수 있는 서비스 로드밸러서 개념을 제공

클러스터 작동 방식

기초 이해 없이 쿠버네티스만큼 복잡한 소프트웨어를 관리하는 것은 배기관이 엔진과 어떻게 관련되어 있는지도 모른 채 자동차를 수리하려는 것과 같습니다.

클러스터 조정, 보안, 적용

클러스터의 요소가 결합된 방법과 개발자가 애플리케이션을 빌드하고 배포할 때 쿠버네티스 API를 사용하는 방법을 아는 것이 중요합니다.

클러스터와 클러스터의 사용량에는 주기가 있다. 클러스터의 수명 변화에 모두 대응하려면 명령줄 플래그, 배포 옵션, API 구성 등으로 쿠버네티스를 구성하는 방법을 이해해야 합니다.

클러스터는 애플리케이션을 배포하는 대상이기만은 아니다. 애플리케이션의 보안상 취약점을 공격하기 위한 매개체가 될 수도 있습니다.

문제에 대응하기

문제가 발생하였을 때 가장 중요한 것은 사용자를 통해서 문제를 알아내기보다는 자동화와 알림으로 신속하게 문제를 알아내고 가능한 한 빨리 시스템을 복구해 응답하도록 조치하는 것 입니다.

적합한 메트릭을 올바르게 설정
- 컨테이너에는 그 자체로 CPU, 메모리, 네트워크, 디스크 사용과 같은 기본 메트릭을 관찰할 수 있는 도구가 오픈 소스로 많이 존재한다. ex) 프로메테우스 오픈 소스 프로젝트
시스템의 문제에 대응하고 복구
- 쿠버네티스는 시스템과 결합하지 않은 모듈 방식으로 최소한의 상태만 시스템에 구축되어 있습니다.
- 일반적으로 언제든지 시스템에 부하가 걸리거나 오작동 할 수 있는 구성 요소를 다시 시작하는 것이 안전함을 의미합니다. (모듈성, 멱등성)

💡 어떤 일이 발생했는지 알려주는 모니터링, 무언가가 고장 났을 때 알려주는 알림, 어떻게 수리해야 하는지 알려주는 시나리오뿐만 아니라 성공적인 클러스터의 관리를 위해서는 재해 대응 및 복구 절차를 개발하고 실행해야 합니다.

새로운 기능과 사용자 정의 기능으로 시스템 확장하기

쿠버네티스 오픈 소스 프로젝트의 가장 중요한 강점은 쿠버네티스 클러스터의 사용법을 구축/확장/개선하는 라이브러리, 툴, 플랫폼의 폭발적인 성장에 있습니다.

쿠버네티스 생태계에 있는 모든 툴을 사용하면 관리 중인 쿠버네티스 클러스터를 개선, 확장, 향상할 수 있습니다. 그러나 이러한 툴을 사용하면 클러스터가 불안정해지고 보안이 취약해지며 오류가 발생하기 쉬워집니다.

쿠버네티스 클러스터를 운영하기 위해서는 이러한 툴, 플랫폼, 프로젝트를 클러스터에 추가하는 방법과 시기를 잘 이해해야 합니다.

클러스터 운영자는 다른 솔루션을 권장하거나, 특정 프로젝트가 클러스터에 적합한지 아니면 최종 사용자에 대해 동일한 목표를 달성하는 더 나은 방법이 있는지를 알려주는 편지자나 조언자의 역할도 해야 합니다.

마치며

쿠버네티스 클러스터 운영은 일련의 컴퓨터에 일부 소프트웨어를 설치하는 것 이상의 일 입니다.
성공적인 관리를 위해서는 쿠버네티스를 어떻게 조합할지 확실히 이해하고, 쿠버네티스를 사용하는 개발자가 클러스터를 다루는 방법을 정확하게 알아야 합니다.
사용패턴이 바뀌면 그에 따라 클러스터를 유지, 관리, 조정, 개선하는 방법을 이해해야 합니다.
작동중인 클러스터에서 나오는 정보를 모니터링 하는 방법, 클러스터의 상태가 좋지 않을 때를 알려주는 알림, 대시보드를 개발하는 방법, 다시 상태를 좋게 만드는 방법을 알아야 합니다.

🔍 AWS OpenSearch를 활용해 EFK Stack 구축하기

hosu4549@gmail.com — Fri, 21 Apr 2023 05:30:00 GMT

Overview

들어가며

Kubernetes는 생성된 Pod들에 대하여 Stateless하게 관리되어야하는 것이 기본 관리 원칙이다.

그렇기에 STDOUT/STDERR등 SYSOUT의 형태로 쌓이는 로그들을 노드내에 저장하는 방식이 아닌 중앙 집중식 로깅 시스템을 구축해야 한다.

Pod로부터 수신된 로그를 Fluent-bit를 통해 AWS Kinesis로 전송하고, 수신된 로그 데이터를 AWS OpenSearch의 ElasticSearch가 받게 되고 Kibana를 통해 시각화하게 된다.

What Is EFK Stack?

ELF Stack

ELK Stack은 ElasticSearch + Logstash + Kibana의 로그 분석 프로세스를 지칭한다.

하지만 이 중 Logstash보다 fluent-bit이 쿠버네티스 환경에서 최적화 되어있는 시스템 구축 시 많이 사용되기 때문에 Fluent-bit를 선택하였다.

EFK Stack

Fluent-bit : 로그를 수집해서 Elasticsearch로 전달
Elasticsearch : Fluentd로부터 받은 데이터를 검색 및 분석하여 저장
Kibana : Elasticsearch의 빠른 검색능력을 통해 데이터 시각화

사내 EFK Stack

k8s내 파드들의 로그를 수집하는 fluent-bit가 노드별로 DaemonSet에 존재하고 fluent-bit에서 AWS Kinesis Datafirehose를 통해 AWS OpenSearch의 ElasticSearch로 전송하며 Kibana를 통해 시각화 하게 구성하였다.

Set a EFK Stack

Install Fluent-bit

## create k8s namespace
kubectl create ns logging

먼저 loggging 전용 namespace를 생성한다.

## helm repo add
helm repo add fluent https://fluent.github.io/helm-charts

그 후 helm을 통해 fluent chart를 다운로드한다.

## helm install
helm upgrade --install fluent-bit fluent/fluent-bit -n logging

k8s cluster에 해당 helm repo를 logging namespace에 설치합니다.

Result

Set AWS Kinesis Data Firehose

AWS Kinesis Data Firehose를 생성하기 전 AWS Opensearch Domain과 백업용 AWS S3 Buckect을 생성해야 한다.

왼쪽 상단에 전송스트림 생성을 클릭한다.

소스 및 대상을 선택한다.

소스 : Direct PUT
대상 : Amazon OpenSearch Service

미리 생성해둔 AWS OpenSearch Domain을 설정하고 특히, index 이름을 설정한다. 해당 index 이름과 같은 fluent-bit로 부터 수집된 pod들의 로그가 수집된다.

미리 생성해둔 백업용 AWS S3 Bucket을 설정한다. 해당 AWS S3 Bucket에는 설정해놓은 버퍼와 파일 형태로 log들이 수집된다.

Set Fluent-bit Configmap

apiVersion: v1
data:
  fluent-bit.conf: |
    [SERVICE]
        Parsers_File      parsers.conf
        HTTP_Server       On
        HTTP_Listen       0.0.0.0
        HTTP_Port         2020

    [INPUT]
        Name              tail
        Path              /var/log/containers/front-end-app-*.log
        DB                /var/log/flb_kube.db
        Mem_Buf_Limit     10MB
        Refresh_Interval  10
        Tag               front-end
        Parser            docker
    [FILTER]
        Name              record_modifier
        Match             front-end
        Whitelist_key     log
    [OUTPUT]
        Name              kinesis_firehose
        Match             front-end
        region            ap-northeast-2
        delivery_stream   kinesis-app
...

kind: ConfigMap
metadata:
  creationTimestamp: "2022-05-30T05:43:33Z"
  labels:
    k8s-app: fluent-bit
  name: fluent-bit
  namespace: logging

위의 내용중 [INPUT] , [FILTER], [OUTPUT] 에 내용을 수정한다.

INPUT : 로그를 수집할 app log path를 작성한다.
FILTER : 해당 INPUT 의 Type을 작성한다.
OUTPUT : 수집된 로그들을 어느 곳으로 전송할지 설정합니다. (여기서는 AWS Kinesis delivery_stram을 작성한다.)

Result

이제 AWS Kinesis로 접속하여 해당 DataFirehose에서 모니터링 탭에서 확인해보면 위의 사진 처럼 성공 그래프가 찍히는걸 볼 수 있다.

Finish

위의 과정을 모두 마쳤으면 AWS OpenSearch Domain으로 접속하여 kibana를 보자.

Index patterns 설정을 먼저 하고 kibana의 Discover 메뉴에 접속하면 정상적으로 로그가 쌓이는 것을 확인할 수 있다.

Reference

https://nsxbaas.blog/2022/09/27/visualising-antrea-ids-logs/

⬆️ AWS EC2 Storage 용량 늘리기(scale-up)

hosu4549@gmail.com — Thu, 20 Apr 2023 06:30:00 GMT

들어가며

k8s를 운영하다보면 어느날 갑자기 resource 에 대한 부족으로 인해 문제가 생길 수 있다.

그럴때 AWS Console에 접속하여 해당 EC2 Instance의 storage 용량을 증가시켜 해결할 수 있다.

WorkFlow

인스턴스에 접속한다.

아래의 명령어로 해당 노드의 파티션을 확인한다.

$ sudo lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1       259:0    0  30G  0 disk /data
nvme0n1       259:1    0  16G  0 disk
└─nvme0n1p1   259:2    0   8G  0 part /
└─nvme0n1p128 259:3    0   1M  0 part

growpart 명령을 사용하여 확장할 파티션을 지정한다.
```
$ sudo growpart /dev/nvme0n1 1
```

lsblk 명령어를 사용하여 파티션이 확장되었는지 확인한다.

$ sudo lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1       259:0    0  30G  0 disk /data
nvme0n1       259:1    0  50G  0 disk
└─nvme0n1p1   259:2    0  16G  0 part /
└─nvme0n1p128 259:3    0   1M  0 part

df -hT 명령어를 사용하여 현재 스토리지 가용 현황을 확인한다.

$ df -hT
Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  xfs   8.0G  1.6G  6.5G  20% /
/dev/nvme1n1    xfs   8.0G   33M  8.0G   1% /data
...

xfs_growfs 명령어를 사용하여 파티션 탑재를 진행합니다.
```
$ sudo xfs_growfs -d /
```

df -hT 명령어를 통해 변경된 스토리지 가용 현황을 확인합니다.

$ df -hT
Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p1  xfs   8.0G  1.6G  6.5G  20% /
/dev/nvme1n1    xfs   8.0G   33M  48.0G   1% /data
...

Finish

Before

After

( 🚨 스크린샷에는 EC2 Instance type도 변경하여 devtmpts , tmpfs등 다른 filesystem도 증가되어 있다.)

Reference

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html

💬 ArgoCD의 상태를 Slack에 메시지 보내기

hosu4549@gmail.com — Sat, 15 Apr 2023 12:00:00 GMT

들어가며

사내에서 배포 자동화로 ArgoCD를 사용하고 있는데, 여러 개발자가 Sync를 맞추는 작업을 할때에 동시에 작업을 수행할 수도 있는 우려가 있었습니다.

그래서 누군가 Sync를 맞추는 작업을 할때나 완료되었을때, 실패하였을때, 파드가 죽었을 때 슬랙을 통해 알림을 보내는 설정을 하였습니다.

How To Setting

Slack

먼저 Slack에서 새로운 앱을 만듭니다.

Create an App > From scratch 버튼을 눌러 애플리케이션을 만들 수 있습니다.

생성한 후 왼쪽 메뉴의 OAuth & Permissions 메뉴에 접근합니다.

Scopes > Bot Token Scopes에서 chat:writ 기능을 활성화합니다.

그 후 상단으로 이동하여 Install To Workspace 을 진행합니다.

그러면 위와 같이 Bot User OAuth Token 이 발급되게 됩니다.

그 후 슬랙에서 해당 앱을 추가해줍니다.

ArgoCD

[ ] 으로 되어있는 칸은 직접 입력해야하는 값입니다.

$ kubectl apply -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/manifests/install.yaml -n [argoCD namespace]
$ kubectl apply -f https://raw.githubusercontent.com/argoproj-labs/argocd-notifications/release-1.0/catalog/install.yaml -n [argoCD namespace]

위의 명령어를 실행 시켜 ArgoCD Notification의 manifests 파일과 catalog 파일을 적용합니다.

argocd-notifications-secret

apiVersion: v1 
kind: Secret 
metadata: 
  name: argocd-notifications-secret 
stringData:
  slack-token: [Bot User OAuth Token]

argocd-nofitications-cm

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: $slack-token

$ kubectl edit cm argocd-notifications-cm -n ${argocd_namespace}

위의 명령어 실행 후

apiVersion: v1
  kind: ConfigMap
  metadata:
    name: argocd-notifications-cm
    namespace: argocd
  data:
    service.slack: |
      token: [Bot User OAuth Token]<- 이 부분 작성

argocd-notification check

ArgoCD Configmap에서 notificatoin이 설정되어있는지 체크하기 위해 ArgoCD가 배포되어있는 namespace로 이동하여 아래의 명령어를 입력합니다.

$ kubectl edit cm

위의 이미지처럼 argocd-notifications-cm 가 등록되어있다면 잘 설정되어 있는 것입니다!

그 후 ArgoCD가 특정한 액션을 할 시에 알림을 받기 위해 아래의 명령어를 입력해줍니다.

$ kubectl patch app [app name] -n [argoCD Namespace] -p '{"metadata": {"annotations": {"notifications.argoproj.io/subscribe.on-sync-succeeded.slack":"[slack chanel name"}}}' --type merge

ArgoCD Notification List

Sync가 성공했을 때 알림

notifications.argoproj.io/subscribe.on-sync-succeeded.slack

Sync가 실패했을 때 알림

notifications.argoproj.io/subscribe.on-sync-failed.slack

Sync가 진행중일 때 알림

notifications.argoproj.io/subscribe.on-sync-running.slack

Sync 상태가 Unknown일 때 알림

notifications.argoproj.io/subscribe.on-sync-status-unknown.slack

Health가 Degrade 되었을 때 알림

notifications.argoproj.io/subscribe.on-health-degraded.slack

Deploy 되었을 때 알림

notifications.argoproj.io/subscribe.on-deployed.slack

Finish

위의 설정을 모두 완료하면 정상적으로 Slack 채널을 통해 noti가 오는 것을 확인하실 수 있습니다!

💡 fluent-bit를 활용한 Metric Data 수집하기

hosu4549@gmail.com — Thu, 24 Nov 2022 07:10:00 GMT

들어가며

kubernetes를 상용으로 운영하기 전 CPU나 system에 대한 Metrics Data를 수집하고 시각화하여 원활한 운영을 해야할 필요가 있었습니다.

현재 EFK Stack으로 logging system을 구축해놓았었는데, 그 중 fluent-bit를 활용하여 metrics data를 수집하는 방법에 대해 다뤄보려고 합니다.

CPU Metric

fluent-bit의 input plugin중 cpu는 기본적으로 프로세스 혹은 전체 시스템의 CPU 사용량을 측정합니다.

설정된 시간에 대해 백분율 단위로 수집되며 현재 이 plugin은 linux에서만 사용하실 수 있습니다.

key

cpu_p

이 값은 사용자 및 커널 공간에 소요된 사간 대비 전체 시스템의 CPU 사용량을 요약해서 보여줍니다. ( CPU 코어 수를 고려합니다. )

user_p

이 값은 사용자 모드에서 CPU 사용량을 의미합니다.( CPU 코어 수를 고려합니다. )

system_p

커널 모드에서 CPU 사용량, 간단히 말해서 커널에 의한 CPU 사용량을 의미합니다.( CPU 코어 수를 고려합니다. )

CPU.core

위에 설명한 key외에도 CPU core별로 데이터가 수집됩니다. core는 0에서 N까지 나열됩니다.

cpuN.p_cpu

core N개의 CPU 사용량을 나타냅니다.

cpuN.p_user

core N개의 사용자 모드에서 사용된 총 CPU 사용량을 나타냅니다.

cpuN.p_system

N번째 core와 관련된 시스템 또는 커널 모드에서 사용된 총 CPU입니다.

Proceeding

INPUT

[INPUT]
    Name              cpu
    Tag               my_cpu

먼저 cpu plugin을 작성해줍니다. Tag에는 다른 데이터들도 수집될 수 있으니, 특수한 이름을 작성합니다. (여기선 my_cpu)

OUTPUT

[OUTPUT]
    Name              kinesis_firehose
    Match             my_cpu
    region            [az]
    delivery_stream   [kinesis_firehose_name]

먼저 AWS Kinesis에서 firehose를 생성해두었습니다. 그 후 해당 전송스트림을 delivery_stream에 작성해줍니다.

그러면 설정은 모두 완료되었습니다.

config map을 삭제해주신 후 해당 fluent-bit config map file을 적용해주시면 모든 작업이 완료가 됩니다.

Result

그 후 elastic search에 접속하여 index 설정 한 후 kibana의 discover에서 위와 같이 수집된 metrics data를 확인해볼 수 있습니다.

Reference

https://docs.fluentbit.io/manual/v/1.5/pipeline/inputs/cpu-metrics

📁 AWS EFS를 사용하여 POD Storage 구성하기

hosu4549@gmail.com — Sun, 13 Nov 2022 07:30:00 GMT

들어가며

사내에서 POD를 생성할 때에 EFK Stack으로 구성하기전, POD별로 log를 저장해야할 이슈가 있었습니다. (물론 파드는 stateless하게 관리되어야하지만 어떤 이유 때문에 Stateful하게 관리가 되었었습니다 ㅎㅎ,,,)

그래서 Deployment나 Replicaset으로 POD를 띄우는 것이 아닌 Statefule로 POD를 띄우게 되었었는데, 그때 공유 스토리지 볼륨이 필요하였었습니다. 여러 자료를 찾던 중 AWS에서 제공되는 서비스인 EBS(Elastic Block Store)와 EFS(Elastic File System) 사이에 고민을 하였었고, 결국 여러 가용영역을 지원하는 EFS를 선택하게 되었습니다.

Volum

kubernetes에는 데이터를 저장하는 Storage 즉, Volume을 제공합니다. Container 단위가 아니라 Pod 단위이기 때문에 Pod에 속해 있는 여러개의 컨테이너가 공유해서 사용할 수 있습니다.

여러 볼륨의 종류가 있지만 해당 포스트에서는 PersistentVolume에 대해서 다룰려고 합니다.

PersistentVolume

PV

PV(PersistenetVolume)이란 Kubernetes에서 관리되는 저장소로 Pod와는 다른 수명 주기로 관리됩니다. Pod가 재실행 되더라도, PV의 데이터는 정책에 따라 유지/삭제가 됩니다.

PVC

PVC(Persistent Volume Claim)는 PV를 추상화하여 개발자가 손쉽게 PV를 사용 가능하게 만들어주는 기능입니다. 개발자는 사용에 필요한 Volume의 크기, Volume의 정책을 선택하고 요청만 하면 됩니다. 운영자는 개발자의 요청에 맞게 PV 를 생성하게 되고, PVC는 해당 PV를 가져가게 됩니다. 또한, PVC는 Namespace Object이기 때문에 Namespace에 depedency가 걸리게 됩니다.

AWS EFS

AWS EFS(Amazon Elastic File System)은 AWSAmazon Web Service에서 제공하는 매니지드 NFS 서버입니다. NFS는 여러 서버에서 동시에 같은 파일을 공유할 때 편리하게 사용할 수 있지만, 관리가 어렵다는 단점이 있습니다. 아마존 EFS를 사용하면 좀 더 쉽게 NFS로 서버들 간에 파일을 공유할 수 있습니다. Kubernetes와 같은 분산 환경에서도 같은 용도의 서버들 간에 공유 스토리지로 EFS를 사용할 수 있습니다.

설정하기

Create a AWS EFS

AWS console에 접속하여 AWS EFS 서비스에서 파일 시스템을 하나 생성합니다.

Create a AWS EFS AccessPoint

POD별로 쌓는 데이터를 다 다르게 설정해야하니 Access Point를 설정합니다.

저는 총 5가지의 Application이 있으며 각각 데이터를 따로 수집해야하기 때문에 AccessPoint를 5개 생성해두었습니다.

AccessPoint Mount

그 후 헤딩 파일 시스템과 연동할 서버에 접속하여 폴더를 생성 한 후 Access Point 를 mount 합니다.

sudo mount -t efs -o tls,accesspoint=${ACCESSPOINT_ID} ${EFS_ID}:/ /${PATH}

Install AWS-CSI-Driver

먼저 AWS-CSI-Driver를 설치합니다.

helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
helm repo update
helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \
    --namespace kube-system \
    --set image.repository=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/eks/aws-efs-csi-driver \
    --set controller.serviceAccount.create=false \
    --set controller.serviceAccount.name=efs-csi-controller-sa

POD 생성하기

${} 부분은 직접 작성 해야하는 부분입니다.

storageClass

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ${STORAGECLASS_NAME}
provisioner: efs.csi.aws.com

위의 형식으로 yaml파일을 작성 한 후 적용합니다.

result

PersistentVolume

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv-app
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ${STORAGECLASS_NAME}
  csi:
    driver: efs.csi.aws.com
    volumeHandle: ${ACCESSPOINT_ID}
---
...

metadate에 해당 PV의 이름을 작성해주시고, spec.storageClassName에 StorageClass의 이름을 작성합니다. 그 후 spec.csi에 설정해두었던 AWS EFS Access Point에 대한 내용을 작성합니다.

result

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-pv-app
  namespaces: ${APP_NAMESPACE}
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ${STORAGECLASS_NAME}
  resources:
    requests:
      storage: 5Gi
---
...

PVC는 생성해둔 PV와 매핑이 되어야합니다. 그렇기 때문에 이름을 같게 설정해두어야 자동으로 매핑되어 생성됩니다.

result

POD

...
    spec:
      affinity:
        nodeAffinity:
 ...
        kubernetes.io/os: linux
      volumes:
      - name: data-path
        persistentVolumeClaim:
          claimName: efs-pv-app
---
...

spec.containers.volumeMounts.claimName에 위에서 생성해두었던 pvc 명을 적어줍니다.

결과

그 후 mount 했던 디렉토리로 이동하여 데이터들이 잘 쌓여있나 확인합니다.

Reference

🧵 AWS Console 에서 보여주는 메시지 AWS cli에서 Decode 하기 !

hosu4549@gmail.com — Tue, 02 Aug 2022 03:30:00 GMT

들어가며

보통 AWS를 사용하다보면 AWS Management Console에서 GUI식으로 제공되는 화면에서 Control하는 경우가 많습니다.

특히, 권한과 같은 부분은 이해하기 쉽게 목록화되어있으니 Management Console을 주로 사용하는 편입니다.

AWS Management Console에서 작업을 하던 중에 Error가 발생하게 되면 암호화되어 Message가 노출이 되는데, AWS cli에서 Decode하는 방법에 대해 포스팅 해보겠습니다.

무엇이 문제인가..

현재 사내에서 계정별로 권한을 부여하고 있습니다. 특정 계정에게 특정 Security Group의 AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, RevokeSecurityGroupEgress, AuthorizeSecurityGroupEgress, ModifySecurityGroupRules, UpdateSecurityGroupRuleDescriptionsIngress, UpdateSecurityGroupRuleDescriptionsEgress 권한을 부여하고 특히 ModifySecurityGroupRules 권한에는 자유롭게 수정가능하도록 security-group-rule을 전부 열어주는 작업이었습니다.

Encoding Message

위의 권한을 정상적으로 세팅한 후 계정을 전달하였는데, 아래의 메새지가 왔습니다.

내용은 특정 보안그룹에서 보안그룹규칙의 수정하였는데 Error Message가 보여진다는 것이었습니다. 하지만 암호화되어 보여졌기 때문에 어떤 문제인지 알 수 없었습니다,,(후우)

무엇이 문제냐 알려달라..

암호화된 메시지만 보고는 아무것도 알 수 없었습니다. 어떤 권한을 부여할때 문제가 생겼는지는 제목에 적혀있어 알았지만, 어디서 부여할때 문제가 생긴건지는 알 수 없었습니다.

Decoding Message

$ aws sts decode-authorization-message --encoded-message [message]

위의 명령어를 입력하시면 암호화된 Error Message가 정상적으로 Decoding되어 보여집니다.

위의 저 이슈 문제는 ModifySecurityGroupRules의 권한을 모든 security-group-rule에서 적용되지 못하게 해서 보안그룹의 보안 그룹 규칙을 수정할때 발생했던 문제였습니다 ㅎㅎ,,

🗿 PS의 기본

hosu4549@gmail.com — Thu, 28 Jul 2022 03:10:00 GMT

들어가며

서버를 운영/관리를 하다보면 Process에 대해 긴밀히 알아야합니다. 서버의 어플리케이션에 문제가 생겼을 경우 빠르게 Process의 상태를 확인하고 프로세스에 대해 Kill을 하든 어떤 행동을 취해야 원활한 서버 운영이 가능합니다.

오늘은 이러한 프로세스들의 상태를 확인하는 명령어 중 대표적인 명령어인 PS에 대해 포스팅 해보겠습니다.

PS?

PS는 Process Status의 약자입니다. 즉, 프로세스의 상태를 확인할 수 있는 명령어입니다.

PS를 이용하면 현재 실행중인 프로세스 목록과 상태를 알 수 있습니다.

사용 방법

$ ps [Option]

옵션 없이 사용할 경우 ps는 현재 셸에서 실행 중인 최소 두 개의 프로세스, 셸 자체 및 명령이 호출되었을 때 셸에서 실행되는 프로세스에 대해 네 개의 정보 열을 출력합니다.

즉, 현재 실행되고 있는 process의 목록과 상태를 출력합니다.

Options

시스템에 동작중인 모든 프로세스를 소유자 정보와 함께 출력

$ ps aux

시스템에 동작하는 모든 프로세스 출력

$ ps -ef

$ ps -ef | more

한 페이지씩 화면에 출력되도록 하는 옵션

grep

$ ps -ef | grep tomcat

동작중인 전체 프로세스 중에 [특정] 이름의 프로세스 출력

PID가 []인 프로세스의 이름 출력

$ ps -p [] -o comm=

프로세스의 상태 (STAT)

R : Running or Runnable

Process가 정상적으로 동작하고 있는 상태

S : Interruptible sleep

event를 완료하기 위해 기다리는 상태
Process가 사용자 혹은 다른 Process로 부터 Input을 받기 위해 대기하고 있는 상태

W : Waiting

sleep state에서 input을 입력받아 Running 가능한 상태이지만 아직 CPU에게 선택받지 못해 기다리고 있는 상태

S : Stopped

일반적으로 알고 있는 Process가 멈춘 상태
CPU에게 할당을 받아도 실행되지 않으며, 실행하기 위해서는 state를 변경하는 signal을 입력

Z : Zombie Process

좀비 프로세스 상태 (실질적으로 shutdown인데 목록에 노출되는 process)

Reference

🏗️ Jenkins를 이용한 SSH 통신을 통해 AWS EC2 서버 배포 파이프라인 구성하기

hosu4549@gmail.com — Fri, 15 Jul 2022 07:30:00 GMT

들어가며

여러 배포 프로세스 중 Jenkins로 Build 된 결과물을 SSH 연결을 통해 직접 서버에 접근하여 배포하는 프로세스에 대해 작성해보았습니다.

보안상 이슈로 인해 권장하는 배포 프로세스는 아니지만, 여러 배포 방식 중 이런 방식도 있다 라는 점을 알아주시면 될 것 같습니다.

Process

먼저 Process는 위와 같습니다.

개발 완료된 코드를 git을 통해 저장소에 push 합니다.
gitlab은 push event를 trigger 하며, push 명령이 감지되면 jenkins에 webhook을 전송합니다.
jenkins는 gitlab으로 부터 webhook을 수신하게되면 build를 하게됩니다. 이때 설정해놓은 build process에 따라 build가 진행됩니다.
build가 완료되면 SSH 통신을 하여 AWS EC2로 생성된 server에 결과물을 전송합니다.

Jenkins build Pipeline Setting

build setting

Gitlab Webhook Setting

먼저 webhook으로 연동될 gitlab repository 설정을 합니다.

Credentials가 Jenkins에 설정되어 있어야 gitlab에서 Webhook 전송을 할때에 인증이 되니 꼭 먼저 설정해주세요 !

Gitlab Repository를 설정하였다면 그 다음 매개변수를 설정합니다.

Jenkins의 build 매개변수는 특정 Parameter가 전달되었을때 실행되는 조건을 의미 합니다.

gitlab repository에서 develop으로 push된 commit을 webhook으로 발송할때에 Jenkins에서 감지하기 위해 branch : develop 으로 설정합니다. 즉, Jenkins에서는 develop branch에 관한 webhook만 감지한다는 의미입니다.

빌드 유발 이벤트를 설정합니다.

해당 설정은 Gitlab에서 Webhook으로 이벤트를 전송할때에 어떻게 허용할건지에 대한 설정입니다.

맨 하단에 보시면 Secret token 생성 칸이 있는데, 해당 값을 gitlab webhook 설정화면에서 secret token 입력칸에 넣어주시면 됩니다.

그 후 Gitlab Repository의 Webhook 메뉴로 이동하여 URL에는 Jenkins Project URL을 입력하고, Scret Token에는 위에서 생성된 Secret Token값을 넣어줍니다.

자! 이러면 Jenkins와 Gitlab의 Wehook 연동이 완료되었습니다.

이제 Gitlab reposiory에서 특정 branch(여기선 develop)에 git push 이벤트가 발생하면 Jenkins에 Webhook을 발송하여 빌드가 시작됩니다.

jenkins build

이 부분은 build 설정 단계입니다.

해당 프로젝트는 node.js기반의 Vue.js 프로젝트이기 때문에 Jenkins 에서 node.js를 설치한 후 스크립트로 build를 진행해야합니다.

Jenkins Market Place에서 Node.js를 설치해주신 후 해당 Jenkins 프로젝트에서 Provide 설정을 합니다.

그 후 Build 탭에서 Script를 작성합니다.

npm install yarn -g
yarn cache clean
yarn install
yarn build:test

그 후 chmod 명령어를 통해 해당 direcoty의 권한을 수정합니다. directory의 권한을 수정해주셔야 SSH 통신을 통해 AWS EC2 서버로 build된 결과물을 옮길 수 있습니다.

node.js 기반의 Vue.js 프로젝트를 build 한 후 결과물인 dist 디렉토리를 생성하는 것까지 완료되었습니다.

SSH setting

이제는 SSH Plugin을 이용하여 AWS EC2에 접속한 후 해당 디렉토리를 옮겨보도록 하겠습니다.

먼저 해당 AWS EC2의 서버에 접속을 한 후 ssh-keygen 명령어를 통해 rsa key를 생성해줍니다.

생성된 rsa-key는 위의 화면에서 보여지는 것 처럼 ~/.ssh 경로에서 확인 하실 수 있습니다.

$ vim id_rsa.pub

id_rsa.pub 파일을 편집하여 생성된 ssh-key값을 확인합니다.

그 후 Jenkins로 돌아와 SSH Server 설정을 합니다.

Hostname : AWS EC2의 IP주소를 입력합니다.
Username : AWS EC2의 User를 입력합니다. (여기선 Ubuntu)
Remote Directory : 접속하였을때의 첫 경로를 입력합니다. use Password Authenticaton, or use a different Key 체크 박스를 선택 한 후 Key 입력칸에 위에서 생성해놓은 ssh-rsa 값을 입력합니다.

이렇게 해주시면 Jenkins SSH Publish 설정이 완료되었습니다!! 🎉🎉

이제 Jenkins에서 build가 완료되면 SSH 통신으로 AWS EC2 서버에 접속 한 후 설정해놓은 경로에 build 결과물을 전송하게됩니다 !

Deploy

모든 설정을 마친 후 한번 develop branch에 PUSH를 해보았습니다.

정상적으로 build가 완료가 된 후 SSH 통신을 통해 file을 전송한 log를 통해 확인해보실 수 있습니다! 😎😎

마치며

사실 보안상의 이슈로 인해 Jenkins에서 SSH Publish 사용을 권장하지 않습니다,,ㅎㅎ

하지만 이렇게 구성해보고 자료를 정리해보는 이유는 "이러한 배포 방식도 있었다."라는 것을 경험해보고 싶었습니다. 😺😺

🌐 AWS VPC이란?

hosu4549@gmail.com — Wed, 13 Jul 2022 08:10:00 GMT

들어가며

사내에서 staging server를 구축하기 위해 AWS EKS를 활용하여 cluster를 생성하는 도중 노드 그룹 생성에서 VPC 이슈에 부딪히고 말았습니다... 😢

한번 개념정리를 확실히 해놓기 위해 여러 블로그 및 게시글을 보게 되었는데, 이번 기회에 한번 정리를 해보려고 합니다 !

VPN (Virtual Private Network)

VPN은 한국어로 가설사설망 이라고 합니다. 보안상의 이유로 네트워크를 분리하고 싶다면 기존 인터넷 선 공사도 다시해야하고, 건물의 내부선을 다시 뜯어내면서 공사를 해야하기에 가상의 망인 VPN을 사용하게 됩니다.

인터넷 프라이버시를 지키기 위한 도구로 널리 사용되기 전에는 멀리 떨어진 네트워크 환경을 하나의 안전한 네트워크로 만드는 역할을 하였습니다.

우리가 현재 사용하고 있는 인터넷은 서버의 ip주소에 네트워크 패킷을 주고 받으며 통신을 하고 있습니다. 만약, google.com에 접속한다면 먼저 DNS 서버를 통해 ip주소를 받아오며 패킷을 보내게 됩니다.

주소창에 입력된 주소가 http일 경우 평문(plain text)로 그 내용을 그대로 주고 받고, https 일 경우 암호화된 데이터로 주고 받기 때문에 중간에서 누군가 그 내용을 알 수 없습니다.

VPN은 인터넷에 사용되는 모든 네트워크 패킷을 암호화해서 믿을 수 있는 VPN 서버에 보내고, 그 서버가 나를 대신하여 인터넷에 접속하고 그 결과를 돌려주게 됩니다. 내 컴퓨터와 VPN서버 사이에는 안전하게 암호화 되어 그 내용을 준간에서 볼 수 없기 때문에 인터넷이 안전하다고 볼 수 있습니다. 모든 트래픽을 암호화해서 보내기 때문에 설령 내가 접속하려는 웹사이트가 https를 지원하지 않아도 안전하게 접속이 가능합니다.

Amazon VPC (Virtual Private Cloud)

사용자가 정의하는 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경

Amazon VPC는 인터넷에 엑세스 할 수 있는 웹 서버를 위해 public subnet, 인터넷 엑세스가 없는 private subnet에 데이터 베이스나 애플리케이션 서버 같은 시스템을 배치하고 보안 그룹 및 네트워크 엑세스 제어 목록을 포함한 다중 보안 계층을 사용하여 각 subnet에서 Amazon EC2 인스턴스의 엑세스를 제어할 수 잇습니다.

VPC를 적용하면 위의 그림과 같이 VPC별로 네트워크를 구성할 수 있고 각각의 VPC에 따라 다르게 네트워크 설정을 할 수 있습니다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 동작하게 됩니다.

Region

AWS의 물리적 서버가 위치하고 있는 국가 단위의 위치

Availiability Zone

Region내의 물리적 서버의 지역 단위의 위치

Subnet

Pulic Subnet

외부가 개방되어 있어 인터넷 연결이 가능한 서브넷으로써 인터넷 게이트 웨이로 향하는 라우팅이 잇는 라우팅 테이블과 연결되어 있는 서브넷

Private Subnet

외부에서 직접적으로 접근이 불가능한 네트워크 영역으로 서브넷이 인터넷 게이트웨이에 등록되어있지 않으므로 해당 서브넷에 위치한 리소스들은 외부와의 연결이 불가능

보안에 엄격하게 다뤄야하는 리소스들을 안전하게 관리하기 위해 사용

CIDR

1993년에 도입되기 시작한 최신의 IP 주소 할당 방법으로 IP Adress 그웁을 관리하며 기존의 IP Adress Class보다 유연하게 동작

Routing Table

서브넷 또는 게이트 웨이의 네트워크 트래픽이 전송되는 위치를 결정하는데 사용되는 라우팅이라는 규칙의 집합으로 구성

VPC는 생산량이 제한된 라우팅 테이블을 사용하여 네트워크 트래픽이 전달되는 위치를 제어합니다. VPC의 각 서브넷을 라우팅 테이블에 연결하여 서브넷에 대한 라우팅을 제어합니다.

서브넷을 특정 라우팅 테이블과 연결할 수 있으며 여러 서브넷을 동일한 라우팅 테이블에 연결 할 수 있습니다. (하지만 서브넷은 한 번에 하나의 라우팅 테이블에만 연결 할 수 있습니다.)

또한 라우팅 테이블을 인터넷 게이트웨이 / 가상 프라이빗 게이트웨이 와 연결하여 VPC로 들어오는 인바운스 트래픽에 대한 라우팅 규칙을 정할 수 있습니다.

VPC Peering

물리적으로 의존하지 않는 두 VPC간의 트래픽을 라우팅 할 수 있도록 하기 위한 두 VPC 사이의 네트워킹 연결입니다.

동일한 계정, 동일한 네트워크, 다른 Region의 VPC간의 연결을 할 수 있습니다.

NAT GateWay

외부 접속이 안되는 private subnet의 인스턴스가 외부의 서비스에 연결 할 수 있도록 도와주는 서비스입니다.

private subnet 의 인스턴스를 인터넷 또는 다양한 AWS 서비스에 연결하여 통신 할 수 있습니다. 예를들어 프라이빗 서브넷의 인스턴스가 외부 결제 시스템을 사용해야하는 경우 혹은 다른 AWS 서비스에 데이터를 전달해야하는 경우 NAT GateWay를 public subnet에 두어 통신을 할 수 있습니다.

AWS PrivateLink

데이터를 인터넷에 노출하지 않고 VPC와 AWS 또는 on-premise에서 호스팅되는 서비스 간에 private 연결을 설정

VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT Device, VPN 연결, AWS Direct Connect 하지 않고 VPC를 비공개적으로 연결 할 수 있습니다.

마무리

이번 게시글에는 AWS VPC에 대한 개념을 정리해봤습니다. 다음 포스팅에는 VPC 구축을 직접 해보고 정리해본 결과를 공유해드리고자 합니다. 😎

Reference

https://docs.veilduck.app/knowledge/vpn

https://medium.com/harrythegreat/aws-%EA%B0%80%EC%9E%A5%EC%89%BD%EA%B2%8C-vpc-%EA%B0%9C%EB%85%90%EC%9E%A1%EA%B8%B0-71eef95a7098

https://dontbesatisfied.tistory.com/13

🖥 나만의 Terminal 설정하기 !

hosu4549@gmail.com — Tue, 24 Aug 2021 07:30:00 GMT

들어가며

개발을 하다보면 terminal에서 많은 시간을 보내게 됩니다.

그렇기 때문에 보여지는 것도 이쁘게 ! 나만의 스타일로 커스텀 할 수 있게 되면 좋겠죠? 🤡

Overview

Pre-setting

✅ zsh 설치

✅ Oh my ZSH 설치

✅ iterm2 설치

POWERLEVEL10K 설치

저희가 사용할 terminal theme는 POWERLEVEL10K 입니다.

해당 테마의 자세한 설명은 POWERLEVEL10K를 참고해주세요 !

install

$ git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ~/powerlevel10k

먼저 위의 repo를 로컬로 받아옵니다.

그 후 root 경로의 `~/.zshrc'를 열어 편집을 해줍니다.

...
ZSH_THEME="powerlevel10k/powerlevel10k"
...

config

$ p10k configure

위의 명령어로 기본 config를 설정해주시면 완료입니다 😎

custom

기본 설정 외에 사용자 각자의 성향 / 기호에 맞게 custom 설정을 하고 싶다면, ~/.p10k.sh를 수정해주시면 됩니다.

위의 사진 처럼 왼쪽 prompt의 user 왼쪽에 emoji를 보여주고 싶다라고 하면 위의 shell을 수정해주시면 됩니다.

$ vim ~/.p10k.sh

그 후 POWERLEVEL9K_LEFT_PROMPT_ELEMENTS를 찾아 갑니다.

prompt란? 컴퓨터가 입력을 받아드릴 준비가 되었다는 상태를 알려주는 창입니다. POWERLEVEL10K에서는 LEFT, RIGHT를 나눌 수 있는데 이 부분을 직접 custom 할 수 있습니다.

저 부분 밑에 아래의 코드를 적어주세요.

$ typeset -g POWERLEVEL9K_USER_ICON="👻"

emoji는 원하시는 emoji를 넣어주시면 됩니다.

그 후 해당 shell을 적용시키면 정상적으로 적용된 것을 확인하실 수 있습니다.

이와 같이 직접 원하는 custom을 적용시킬 수 있는데, 해당 내용은 POWERLEVEL10K 과 POWERLEVEL9K 를 참고해주시면 됩니다 !

Status bar Setting

제 터미널 환경을 보시면 여러 상태들을 보여주는 상태창이 터미널 하단에 설정되어있습니다.

iterm2 > Profiles > Session > Status bar enabled

원하시는 status를 확인할 수 있게 Active Components 부분으로 드래그 해주신 후 재실행해주시면 정상적으로 status bar가 적용된 것을 확인하실 수 있습니다 !

👾 git 완벽 정복 - git branch

hosu4549@gmail.com — Mon, 17 May 2021 12:30:00 GMT

들어가며

이번 포스팅에는 git의 핵심이라고 볼 수 있는 최대 장점인 branch에 대해 정리해보려고 합니다.

여러 사람이 같이 개발을 할 때에 코드를 통째로 복사하고 나서 원래의 코드와 상관없이 독릭적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 branch이고 모든 버전 관리 시트템은 branch를 지원합니다.

git의 branch는 매우 가벼워서 다른 버전 관리 시스템과는 다르게 git은 branch를 쉽게 만들어 작업하고 나중에 merge하는 방법을 권장합니다.

branch는 무엇인가?

Git이 branch를 다루는 과정을 이해하려면 우선 git이 데이터를 어떻게 저장하는지 알아야합니다.

git은 데이터를 변경사항(diff)로 기록하지 않고 일련의 스냅샷으로 기록합니다.

commit하면 git은 현 staging area에 있는 데이터의 스탭샷에 대한 pointer, author, message와 같은 메타 데이터, 이전 커밋에 대한 포인터등을 포함하는 커밋 개체(commit object)를 저장합니다.

git commmit으로 커밋하면 먼저 root directory와 각 하위 directory의 tree 개체를 체크섬과 함께 저장소에 저장합니다.

그 다음에 커밋 개체를 만들고 메타데이터와 루트 디렉토리 트리 개체를 가리키는 포인터 정보를 커밋 개체에 넣어 저장합니다.

이 작업을 마치고 나면 git 저장소에는 각 파일에 대한 Blob 파일, 파일과 디렉터리 구조가 들어있는 트리 개체 하나, 메타 데이터와 루트 트리를 가리키는 포인터가 담긴 커밋 개체 하나가 생성됩니다.

위의 이미지를 보면 각 스냅샷은 이전의 commit의 스냅샷을 가리키는 포인터가 저장되어 있는 것을 확인할 수 있습니다.

새 브랜치 생성하기

$ git branch testing

브랜치를 새로 만들면 지금 작업하고 있던 마지막 커밋을 가리킵니다.

그렇다면 현재 작업중인 브랜치가 무엇인지 git은 어떻게 파악할까요 ?

다른 버전관리 시스템과는 달리 git은 HEAD라는 특수한 포인터가 있습니다. 이 포인터는 지금 작업하는 로컬 브랜치를 가리킵니다.

즉, git branch 명령어는 브랜치를 생성만 할 뿐이지 작업하는 브랜치를 바꾸진 않습니다.

$ git checkout testing

위의 명령어를 실행하면 HEAD는 testing 브랜치를 가리킵니다.

커밋을 새로 해보겠습니다!

$ vim test.rb
$ git add test.rb
$ git commit -m 'made a change'

새로 커밋해서 testing 브랜치는 앞으로 이동했습니다. 하지만 master 브랜치는 여전히 이전 커밋을 가리킵니다.

$ git checkout master

위의 명령어는 master 브랜치가 가리키는 commit을 HEAD가 가리키게 하고 working directory의 파일도 그 시점으로 되돌려 놓았습니다.

앞으로 commit을 하게되면 다른 브랜치의 작업들과 별개로 진행되기 때문에 testing 브랜치에서 작업하고 있었다면 add로 stage에 올려놓고 commit을 하고 다른 브랜치로 이동하여 다른 일을 진행 할 수도 있습니다.

branch와 merge의 기초

보통 브랜치와 merge는 아래와 같이 진행합니다.

새로운 이슈를 처리할 새 branch를 만든다.
새로 만든 branch에서 작업을 진행한다.

하지만 이와는 별개로 중요한 문제가 생겨서 그것을 해결하는 hotfit를 먼저 만들어야합니다.

새로운 이슈를 처리하기 이전의 운영 브랜치로 이동한다.
hotfix 브랜치를 하나 생성한다.
수정한 hotfix 를 운영 브랜치로 merge 한다.
다시 작업하던 브랜치로 이동하여 일을 진행한다.

branch의 기초

이렇게 진행되고 있는 프로젝트에서 issue-53번을 처리한다고 가정해봅시다.

그럼 이 이슈를 처리할 브랜치를 하나 만듭니다. 브랜치를 만들면서 checkout까지 함께하기 위해선 -b 옵션을 사용합니다!

$ git checkout -b issue_53

이렇게 HEAD까지 생성된 브랜치인 issue-53으로 이동했으면 이슈를 처리해보겠습니다.

$ vim index.html
$ git add index.html
$ git commit -m '[add] issue 53'

index.html 파일을 추가하고 commit을 하면해당 브랜치가 앞으로 나아갑니다.

하지만 이렇게 쉽게 브랜치를 이동하고 사용하려면 주의해야할 점이 있습니다.

아직 커밋하지 않은 파일이 checkout 할 브랜치와 충돌나면 브랜치를 변경할 수 없습니다. 즉, 브랜치를 변경할 떄는 working directory를 정리하는 것이 좋습니다.

master 브랜치로 이동해서 issue_53 브랜치를 Merge 해보겠습니다.

$ git checkout master
$ git merge issue_53

Merge 메시지에서 fast-forward가 보일 것입니다.

이 단어의 의미는 A브랜치에서 B브랜치로 merge할 때 b브랜치가 a브랜치 이후의 commit을 가리키고 있으면 그저 A브랜치가 B브랜치와 동일한 커밋을 가리키도록 이동시킨다라는 뜻입니다.

이렇게 하면 각 브랜치간의 영향을 끼치지 않는다는 것을 이해하셔야합니다.

예를 들어 issue_53 브랜치에서 작업을 하던 중 master 브랜치에 오류가 생겨 hotfix 브랜치를 master에서 만들어서 작업 후 master에 merge 하게 되어도 issue_53 브랜치에는 영향이 없다는 것입니다.

그 대신 git merge master 명령으로 master 브랜치를 issue_53 브랜치에 merge하면 issue_53 브랜치에 hotfix가 적용됩니다.

👾 git 완벽 정복 - remote 저장소

hosu4549@gmail.com — Sun, 09 May 2021 10:00:00 GMT

들어가며

다른 사람들과 git을 사용해서 성공적인 협업을 하려면 remote 저장소를 관리할 줄 알아야 합니다.

여기서 말하는 remote 저장소란 인터넷이나 네트워크 어딘가에 있는 저장소를 말합니다. 어떤 저장소는 읽기만 가능 할 수 있고, 어떤 저장소는 읽기와 쓰기가 모두 가능 할 수 있습니다.

이번 포스팅에는 이러한 remote 저장소를 관리하는 방법에 대해 공부해보겠습니다!

리모트 저장소

리모트 저장소 확인하기

git remote 명령으로 현재 프로젝트에 등록된 remote 저장소를 확인할 수 있습니다.

저장소를 처음 clone 하면 origin 이라는 remote 저장소가 자동으로 등록되기 때문에 origin이라는 이름을 볼 수 있습니다.

-v 옵션을 주어 이름과 URL을 함께 볼 수 있습니다.

리모트 저장소 추가하기

새 remote 저장소는 쉽게 추가 하실 수 있는데, 아래의 명령어로 가능합니다.

$ git remote add [이름] [url]

이제 URL 대신 lake라는 이름으로 사용할 수 있습니다.

예를 들어 로컬 저장소에는 없는 lake branch를 가져오려면 아래의 명령어를 사용하면 됩니다.

$ git fetch lake

remote 저장소 Pull, Fetch

remote 저장소에서 새로운 branch를 가져오려면 fetch 명령어를 사용하면 됩니다.

이 명령은 local에는 없지만 remote 저장소에 있는 모든 데이터를 가져옵니다.

저장소를 Clone 하면 명령은 자동으로 remote 저장소를 origin 이라는 이름으로 추가됩니다.

그래서 나중에 git fetch origin을 실행하면 Clone한 이후에 수정한 모든 것을 가져옵니다.

git fetch 명령은 리모트 저장소의 데이터를 모두 로컬로 가져오지만, 자동으로 Merge하지는 않습니다. 그래서 로컬에서 작업하던 것은 직접 Merge해야 합니다.

그래서 git pull 명령으로 remote 저장소 branch에서 데이터를 가져올 뿐 아니라 자동으로 local branch와 Merge 시킬 수 있습니다.

정리 하자면,,

git clone 명령은 자동으로 local의 master branch가 remote 저장소의 master branch를 추적하게 합니다.
git pull 명령은 clone한 서버의 데이터를 가져오고 그 데이터를 자동으로 현재 작업하는 코드와 Merge 시킵니다.

remote 저장소에 Push 하기

프로젝트를 공유하고 싶을 때 Upstream 저장소에 Push 할 수 있습니다.

$ git push [remote 이름] [branch 이름]

mater 브랜치를 origin 서버에 push 하려면 아래와 같이 명령어를 사용합니다.

$ git push origin master

위 명령은 clone한 remote 저장소에 쓰기 권한이 있고, clone하고 난 이후 아무도 Upstream 저장소에 Push 하지 않았을 때만 사용할 수 있습니다.

다시 말해, clone 한 사람이 여러 명이고 다른 사람이 push 했을 경우, 충돌이 발생합니다.

그래서 먼저 다른 사람이 작업한 것을 local로 가져와 Merge한 이후에 push 해야합니다.

👾 git 완벽 정복 - commit

hosu4549@gmail.com — Sun, 09 May 2021 09:30:00 GMT

들어가며

이번 포스팅에는 Staged 상태인 파일들을 저장소에 commit 하고 관리해보는 내용을 포스팅하려고합니다 !

Git Commit

변경사항 커밋하기

수정한 것을 커밋하기 위해 Staging Area에 파일을 정리했습니다. Unstaged 상태의 파일은 커밋되지 않는다는 것을 기억해야합니다. Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지 않은 파일은 커밋하지 않습니다. 그 파일은 여전히 Unstaged 상태로 남아 있습니다. 커밋하기전에 git status명령으로 모든 것이Staged 상태인지 확인할 수 있습니다. 그 후 git commit 명령을 통해 커밋합니다.

$ git commit

자동으로 생성되는 커밋 메시지의 첫 라인은 비어 있고 둘째 라인부터 git status 명령의 결과가 채워집니다. 커밋한 내용을 쉽게 기억할 수 있도록 이 메시지를 포함할 수도 있고 메시지를 전부 지우고 새로 작성할 수 있습니다. 내용을 저장하고 편집기를 종료하면 Git은 입력된 내용으로 새 커밋을 하나 완성합니다.

메시지를 직접 인라인으로 첨부하고 싶다면 -m 옵션을 사용하면 됩니다.

$ git commit -m "message"

위와 같이 첫번째 커밋을 작성해보았습니다. commit 명령은 몇 가지 정보를 출력하는데 1) master branch에 커밋을 했고, 2) 체크섬은 2305efd 라는 것을 알려줍니다. 그리고 수정한 파일이 몇개이고 삭제됐거나 추가된 라인이 몇 라인인지 알려줍니다.

Git은 Staging Area에 속한 스냅샷만을 커밋해야한다는 것을 명심해야 합니다. 즉, 수정은 했지만 아직 Staging Area에 넣지 않은 것은 다음에 커밋을 할 수 있습니다.

추가로 커밋할 때마다 프로젝트의 스탭샷을 기록하기 때문에 나중에 스냅샷끼리 비교하거나 예전 스냅샷으로 되돌릴 수 있습니다.

Staging Area 생략하기

Staging Area는 커밋할 파일을 정리한다는 점에서 매우 유용하지만 복잡하고 필요하지 않을때도 있습니다. 그럴 때 아주 쉽게 생략할 수 있는데 git commit -a 명령을 실행하면 됩니다. 그래서 git add를 하는 수고를 덜 수 있습니다.

파일 삭제하기

Git 에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후 커밋해야 합니다. 이 명령은 working directory에 있는 파일도 삭제하기 때문에 실제로 파일도 지워집니다.

커밋하면 파일은 삭제되고 Git은 이 파일을 더이상 추적하지 않습니다. 이미 파일을 수정했거나, 수정한 파일을 추적하고 있다면 -f 옵션을 주어 강제로 삭제할 수도 있습니다.

또, Staging Area에서만 제거하고 working Directory에 있는 파일은 지우지 않고 남겨둘 수도 있습니다. 다시말해서 하드디스크에 있는 파일은 그대로 두고 Git만 추적하지 않게 합니다.

=> .gitignore 파일에 추가하는 것을 빼먹었다거나, 대용량 로그 파일이나 컴파일된 파일인 .a 파일 같은 것을 실수로 추가했을 때 아주 유용합니다.

$ git rm --cached 파일명

파일 이름 변경하기

Git은 파일 이름의 변경이나 파일의 이동을 명시적으로 관리하지 않습니다. 다시 말해서 파일 이름이 변경되었다는 별도의 정보를 저장하지 않습니다.

$ git mv file_from file_to

위의 명령어는 아래의 명령어를 수행한 것과 완전 똑같습니다.

$ mv file_from file_to
$ git rm file_from
$ git add file_to

커밋 히스토리 조회하기

새로 저장소를 만들어서 몇 번 커밋했을 수도 있고, 커밋 히스토리가 있는 저장소를 clone했을 수도 있습니다. 그럴때 조회를 할 수 있는 git log 명령어가 있습니다.

예제

$ git clone https://github.com/schacon/simplegit-progit

위의 프로젝트를 clone해서 받아온 후 git log 명령어를 실행하면 아래와 같이 출력됩니다.

특별한 옵션없이 git log 명령을 실행하면 저장소의 커밋 히스토리를 시간 순으로 보여줍니다. 그리고 각 커밋의 SHA-1 체크섬, 저자 이름, 저자 이메일, 커밋한 날짜, 커밋 메시지를 보여줍니다.

원하는 히스토리를 검색할 수 있도록 git log 명령은 매우 다양한 옵션을 지원합니다.

$ git log -p
$ git log -p -2

-p 옵션은 각 커밋의 diff 결과만을 보여주고 -2 옵션은 최근 2개의 결과만 보여주는 옵션입니다.

직접 diff를 실행한 것과 같은 결과를 출력하기 때문에 동료가 무엇을 커밋했는지 리뷰하고 조회하는데 유용합니다.

또, git log 명령에는 히스토리의 통계를 보여주는 옵션이 있습니다.

$ git log --stat

조회 제한 조건

-n : 최근 n개의 커밋만 조회한다.
--since , --after : 명시한 날짜 이후의 커밋만 검색한다.
--until, --before : 명시한 날짜 이전의 커밋만 검색한다.
--author : 입력한 저자의 커밋만 보여준다.
--committer : 입력한 커미터의 커밋만 보여준다.
--grep : 커밋 메시지 안의 텍스트를 검색한다.
-S: 커밋 변경(추가/삭제)내용 안의 텍스트를 검색한다.

Git 되돌리기

만약 commit 한 내용을 수정하고 싶다면 --amend 옵션을 사용하면 됩니다. 바로 앞의 commit을 수정할 수 있는 옵션입니다.

$ git commit -m "user info update"
$ git add userInfo
$ git commit --amend

여기서 실행한 3개의 명령어는 모두 하나의 commit으로 기록됩니다.

파일 상태를 Unstage로 변경하기

이 방법은 Staged Area와 Working Directory 사이를 제어할 수 있는 방법입니다.

$ git resert HEAD <file> ...

위의 명령어를 사용하면 해당 파일은 staged 상태에서 unstaged 상태로 변경됩니다.

만약 commit 후 해당 파일을 수정해야한다거나, 해당 commit에서 제외해야할때 사용하면 유용한 옵션입니다!

Modified 파일 되돌리기

어떤 파일을 수정했는데, 다시 초기 상태로 되돌리고 싶을 떄 사용하는 옵션입니다.

$ git checkout -- <file>

👾 git 완벽 정복 - git의 기초

hosu4549@gmail.com — Tue, 30 Mar 2021 03:30:00 GMT

들어가며

이번 포스팅에서는 저장소를 만들고 설정하는 방법, 파일을 추적(Track)하거나 추적을 그만 두는 방법에 대해 알아 보겠습니다 !

Git의 기초

Git 저장소 만들기

Git의 저장소를 만드는 방법은 두 가지 입니다.

기존 프로젝트나 디렉토리를 Git 저장소로 만드는 방법
다른 서버에 있는 저장소를 Clone하는 방법

기존 디렉토리를 Git 저장소로 만드는 방법

기존의 프로젝트를 Git으로 관리하고 싶다면, 프로젝트의 디렉토리로 이동해서 아래의 명령어를 실행하면 됩니다.

$ git init

위의 명령어는 .git 이라는 하위 디렉토리를 만들게 됩니다. (하지만 이 명령만드로는 아직 프로젝트의 어떠한 관리도 하지 않습니다 !)

기존 저장소를 Clone 하기

다른 프로젝트에 참여하려하거나(contribute) Git 저장소를 복사하고 싶을 때 git clone 명령어를 사용합니다.

git은 서버에 있는 거의 모든 데이터를 복사하게 됩니다. (프로젝트의 히스토리까지 !)

$ git clone url myName

위와 같이 명령어를 입력하면 해당 프로젝트를 다른 이름으로 clone 할 수 있습니다.

수정하고 저장소에 저장하기

먼저 앞서 git directory에 파일이 쓰여지는 과정을 먼저 알아보겠습니다.

Working Directory의 모든 파일은 크게 Tracked(관리대상)와 Untracked(관리대상이 아님)으로 나눠집니다.

Tracked 파일은 이미 스냅샷에 포함되어있는 파일이며 Unmodified(수정하지 않음)와 Modified(수정함), Staged(커밋으로 저장소에 기록)하는 상태로 나눠집니다. 그리고 나머지는 모두 Untracked 파일입니다.

즉, Untracked 파일은 Working Directory에 있는 파일 중 스냅샷에도, Staging Area`에도 포함되지 않은 파일입니다.

처음 저장소를 Clone하면 모든 파일은 Tracked이면서 Unmodified 상태입니다.

나아가 마지막 커밋 이후 아무것도 수정하지 않은 상태에서 어떤 파일을 수정하게되면 그 파일은 Modified 상태가 됩니다.

실제로 커밋을 하기 위해서는 이 수정한 파일을 Staged 상태로 만들고, Staged 상태인 파일을 커밋합니다.

예제를 통해 공부하기

이제는 파일을 수정하고 파일의 스냅샷을 커밋해보겠습니다~! (실습 !!)

먼저! 빈 디렉토리를 만들어보겠습니다.

$ mkdir git_pratice

이 디렉토리를 git directory로 사용하기 위해 초기화를 해줍니다.

$ git init

파일의 상태 확인하기

Git 초기화를 시켜주고 먼저 상태를 확인해줍니다.

$ git status

위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해줍니다. Tracked나 Modified 상태인 파일이 없다는 의미입니다.

그렇기 때문에 새롭게 파일을 만들고 상태를 확인해보겠습니다.

$ touch pratice_1.md
$ git status

pratice_1.md 파일이 UnTracked files 부분에 속해 있습니다. 즉, Git은 Untracked 파일을 아직 커밋에 넣어지지 않은 파일이라고 보는 것입니다.

파일을 추적하기

Git이 파일을 추적하게 만들기 위해 add 명령어를 실행하고 상태를 확인해보겠습니다.

$ git add pratice_1.md
$ git status

Tracked 상태이면서 커밋에 추가될 Staged 상태라는 것을 확인할 수 있습니다.

Changes to be committed 에 들어 있는 파일은 Staged 상태라는 것을 의미합니다. 커밋하게되면 git add를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남게됩니다.

이 명령을 통해 디렉토리에 있는 파일을 추적하고 관리할 수 있습니다.

Modifed 상태의 파일 Staged 하기

이미 Tracked 상태인 파일을 수정하는 법을 알아보겠습니다.

먼저 pratice_1.md 파일을 수정 후 상태를 확인해보겠습니다!

$ vim ./pratice_1.md
$ git status

Changed not staged for commit 이라는 상태는 수정한 파일이 Tracked 상태이지만 아직 Staged 상태는 아니라는 뜻입니다. Staged상태로 만들고 싶다면 git add 명령을 실행해야 합니다.

add의 의미는 프로젝트에 파일을 추가한다기 보다 다음 커밋에 추가한다고 생각하는게 좋습니다.

add 명령어를 실행하여 Staged 상태로 만들고 상태를 확인해보겠습니다.

$ git add ./pratice_1.md
$ git status

지금 이 시점에서 커밋을 하면 git commit 명령을 실행하는 시점의 버전이 커밋되는 것이 아니라 마지막으로 git add 명령을 실행했을 때의 버전이 커밋됩니다. 즉, git add 명령을 한 후 또 파일을 수정하면 git add 명령을 다시 실행해서 최신 버전을 Staged 상태로 만들어야 합니다!

파일 상태를 짤막하게 확인하기

git status 명령으로 확인할 수 있는 내용이 많기 때문에 조금 더 간단하게 보여주는 옵션이 있습니다.

$ git status -s

아직 추적하지 않은 새 파일 앞에는 ??표시가 붙습니다. Staged 상태로 푸가한 파일 중 새로 생성한 파일 앞에는 A 표시가, 수정한 파일에는 M 표시가 붙습니다.

파일 무시하기

보통 로그파일이나 빌드 시스템이 자동으로 생성한 파일들은 Git이 관리할 필요가 없습니다.

꼭 위와 같은 파일 뿐만아니라 Git으로 관리할 필요가 없다고 생각되는 파일들은 .gitignore 파일을 만들고 그안에 무시할 파일의 패턴을 적습니다.

$ touch .gitignore
$ cat .gitingnore

.gitignore 파일은 아래의 규칙을 따릅니다.

아무것도 없는 라인이나, #으로 시작하는 라인은 무시합니다.
표준 Glob 패턴을 사용합니다.
슬래시 (/)로 시작하면 하위 디렉토리에 적용되지 않습니다.
디렉토리는 슬래시를 끝에 사용하는 것으로 표현합니다.
느낌표로 시작하는 패턴의 파일은 무시하지 않습니다.

# 확장자가 .a인 파일 무시
*.a

# 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
!lib.a

# 현재 디렉토리에 있는 TODO 파일은 무시하고 subdir/TODO처럼 하위 디렉토리에 있는 파일은 무시하지 않음
/TODO

# build/ 디렉토리에 있는 모든 파일은 무시 
build/

# doc/notes.txt 파일은 무시하고 doc/server/arch.txt 파일은 무시하지 않음
doc/*.txt

# doc 디렉토리 아래의 모든 .pdf 파일을 무시
doc/**/*.pdf

Staged 와 Unstaged 상태의 변경 내용을 보기

단순히 파일이 변경됐다는 사실이 아니라 어떤 내용이 변경됐는지 살펴보려면 git status 명령이 아니라 git diff 명령을 사용하면 됩니다. 보통 Staged 파일인 것과 아닌것만 파악해도 되기 때문에 git status으로 충분합니다. 더 자세하게 볼 때는 git diff 명령을 사용하는데 Patch처럼 어떤 라인을 추가했고 삭제했는지가 궁금할 때 사용합니다.

$ git diff

git diff 는 Unstaged 상태인 것들만 보여줍니다. 그렇기 때문에 수정한 파일을 모두 Staging Area에 넣는다면 git diff 명령은 아무것도 보여주지 않습니다.

👾 git 완벽 정복 - git 이란?

hosu4549@gmail.com — Mon, 29 Mar 2021 05:30:00 GMT

들어가며

올해에 개인적으로 목표를 세웠던 것들 중 Git 공부가 있었습니다. 하지만 회사내에서 프로젝트를 진행하면서 주말에도 일을 하는 바람에 따로 공부하는 시간을 갖지 못했죠....

프로젝트가 성공적으로 마무리 되면서 이제 개인 공부를 할 시간이 확보가 되면서 계획했었던 Git 공부를 시작하려고 합니다!

원래 Git을 즐겨 사용했었지만 deep하게 공부하고 싶었고, 특히 git을 누군가에게 설명할 수 있을 정도의 수준으로 끌어올리고 싶어 공부를 하기로 결심하게 되었어요! 🙇🏼‍♂️

이 포스팅은 시리즈로써 작성될 것이며 책 ProGit 을 공부하면서 요약/정리 하는 포스팅입니다!

이 게시글을 보며 도움이 되었으면 좋겠습니다.

버전 관리란?

버전 관리는 무엇이고, 이것을 왜 해야할까 ?

버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템입니다.

버전 관리 시스템을 사용하게 되면 각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌릴 수 있고, 시간에 따라 수정 내용을 비교해보며, 누가 문제를 일으켰는지도 추적이 가능합니다. 또, 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구 할 수 있습니다.

Git의 기초

스냅샷

Git의 핵심은 데이터를 다루는 방법입니다. Git은 데이터를 파일 시스템 스냅샷으로 취급하고 아주 작습니다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 취급합니다. 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 새로 저장하지 않습니다.

Git은 데이터를 스탭샷의 스트림처럼 취급합니다.

거의 모든 명령을 로컬에서 실행

Git은 거의 모든 명령이 로컬 퐈일과 데이터만 사용하기 때문에 네트워크에 있는 다른 컴퓨터는 필요가 없습니다.

예를 들어, Git은 프로젝트의 히스토리를 조회할 때 서버없이 조회합니다. 어떤 파일의 현재 버전과 한달 전의 상태를 비교해 보고 싶을 때도 Git은 그냥 한달 전의 파일과 지금의 파일을 로컬에서 찾습니다.

즉, 오프라인 상태이거나 VPN으로 연결 할 수 없어도 막힘없이 일할 수 있습니다.

Git의 무결성

Git은 데이터를 저장하기 전에 항상 체크섬을 구하여 그 체크섬으로 데이터를 관리합니다. 그래서 체크섬없이는 어떠한 파일이나 디렉토리로 변경 할 수 없습니다.

Git은 SHA-1 해시를 사용하여 체크섬을 만들고 모든 것을 해시로 식별합니다.

Git은 데이터를 추가

Git으로 무엇을 하든 Git 데이터베이스에 데이터가 추가됩니다. 되돌리거나 데이터를 삭제할 방법이 없습니다. Git도 커밋하지 않으면 변경사항을 잃어버릴 수 있습니다. 하지만 일단 스냅샷을 커밋하고 나면 데이터를 잃어버리기 어렵습니다.

또, Git을 사용하면 프로젝트가 심각하게 망가질 걱정없이 매우 즐겁게 여러 가지 실험을 해볼 수 있습니다!

세 가지 상태

이 부분은 매우 중요하기 때문에 집중해서 읽으셔야 합니다 !

Git은 파일을 Committed, Modified, Staged이렇게 3가지로 상태를 관리합니다.

Committed : 데이터가 로컬 데이터 베이스에 안전하게 저장된 상태
Modified : 수정한 파일을 아직 로컬 데이터 베이스에 커밋하지 않은 상태
Staged : 현재 수정한 파일을 곧 커밋할 것 이라는 상태

Git Directory(Repository) 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말합니다. 이 Git Directory가 Git의 핵심입니다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어집니다.

Working Directory는 프로젝트의 특정 버전을 checkout한 것입니다.

Staging Area는 Git directory에 있습니다. 단순한 파일이고 곧 커밋할 파일에 대한 내용을 저장합니다.

Git으로 하는 일은 기본적으로 아래와 같습니다.

Working Directory에서 파일을 수정 한다.
Staging Area에 있는 파일을 Stage해서 커밋할 스냅샷을 만든다.
Staging Area에 있는 파일들을 커밋해서 Git 디렉터리에 영구적인 스냅샷으로 저장합니다.

Git Directory에 있는 파일들은 Committed 상태입니다. 파일을 수정하고 Staging Area에 추가했다면 Staged입니다. 그리고 Checkout하고 수정했지만, 아직 Staging Area에 추가하지 않았다면 Modified입니다.

Git 최초 설정

Git을 처음 설치하고 나면 Git의 사용 환경을 적절하게 설정해주셔야 합니다. 한 번만 설치하면 되며 설정한 내용은 Git이 업그레이드해도 유지가 됩니다.

git config

/etc/gitconfig : 시스템의 모든 사용자와 모든 저장소에 적용되는 설정입니다. git config --system 옵션으로 이 파일을 읽고 쓸 수 있습니다.
~/.gitconfig, ~/.config/git/config : 특정 사용자에게만 적용되는 설정입니다. git config --global 옵션으로 이 파일을 읽고 쓸 수 있습니다.
.git/cnofig : Git Directory(Repository)에 있고 특정 저장소(혹은 현재 작업중인 프로젝트)에만 적용됩니다.

위의 설정은 3->2->1 순으로 우선시 됩니다.

사용자 정보

Git을 설치하고 나서 가장 먼저 해야하는 것은 사용자 이름과 이메일 주소를 설정하는 것입니다.

$ git config --global user.name "l2h"
$ git config --global user_email hosu4549@gmail.com

--global 옵션으로 설정하는 것은 딱 한번만 해주시면 됩니다! 즉, 해당 시스템에서 해당 사용자가 사용할 때에는 이 정보를 사용합니다. 만약 프로젝트마다 다른 이름과 다른 이메일 주소를 사용하고 싶으면 --global 옵션을 빼고 명령을 실행하면 됩니다.

설정 확인

git config --list 명령을 실행하면 설정한 모든 내용을 보여줍니다.

$ git config --list

cron 과 properties를 이용한 Java Scheduler

hosu4549@gmail.com — Tue, 26 Jan 2021 07:30:00 GMT

들어가며

회사에서 주기적으로 AWS 비밀번호 변경 프로그램을 만들라는,, 업무 아닌 업무가 떨어져서 한번 찾아보면서 개발 해본 내용입니다 ! 많이 부족한 내용일 수도 있으니 피드백 언제든지 환영합니다!

java scheduler

특정 시간에 일괄적으로 처리를 해야하는 부분을 코드로 만들어 처리하는 Job입니다.

예를 들어, 기본적으로 서비스 내에서 생성되는 필요없는 log데이터를 정해진 시간에 일괄로 삭제한다던가 매일 오전 10시에 사용들에게 알림 문자나 메일을 보내야할때 사용하는 것이 이러한 스케줄러입니다.

오늘은 scheduler 구현했던 경험에 대해 포스팅을 하겠습니다.

@Scheduler

scheduler를 구현하려면 @scheduler라는 어노테이션을 이용해야합니다. ~~( 이 어노테이션 설정은 여기서 따로 설명하지 않겠습니다! )~~

@Component
public class PasswordScheduler {
    @Scheduled(cron = "*/2 * * * * ? ") // 2분 마다 실행
    public void SchedulerMain(){    
        Date today = new Date();
        System.out.println("스캐쥴링 !" + today);
    }
}

결과

위의 결과를 확인해보면 2초마다 scheduler 가 반복되어 실행되는 것을 확인 하실 수 있습니다.

cron

이제 schduler라는게 무엇인지 알게 되었는데 어노테이션의 cron="*/2 * * * * *" 이건 뭐지? 라는 생각을 하실 겁니다.

cron 이란?

cron이란 원래 윈도우에서 예약된 작업과 같이 리눅스 시스템에서 예약 작업을 실행하기 위한 프로그램입니다.

cron 표현식

cron 표현식은 공백 (" ")으로 구분되는 문자열입니다.

항목값	필수값 여부	허용 범위	허용 특수 문자	비고
초	Y	0~59	* , -	일부 표현식에서 사용되는 필드
분	Y	0~59	* , -
시	Y	0~23	* , -
일	Y	1~31	* , - ? L W	? L W 는 일부 표현식에서만 사용됨
월	Y	1~12 / JAN ~ DEC	* , -
요일	Y	0~6 / MON~SUN	* , - ? L #	? L # 는 일부 표현식에서만 사용됨
년	N	1970~2099	* , -	standard / default 표현식에는 사용되지 않음

* : 와일드 카드로 모든 값을 의미
? : 설정값 없음을 의미
- : 범위 지정

cron 표현식 예제

cron식	설명
/1 * * * ?	1초마다
30 0/10 * * * ?	30초 뒤부터 10분마다
0 0 10 * * ?	매일 10시마다
0 30 10 * * ?	매일 10시 30분마다
0 * 10 * * ?	매일 10:00부터 10:59까지 매분마다
0 0-30 10 * * ?	매일 10:00부터 10:30까지 매분마다

Property

Property란?

기본적으로 property는 어떤 값을 나타냅니다. 소스내에서 사용가능한 parameter 들을 저장하기 위한 파일이며 key, value 형태로 저장되어 있습니다.

property 를 왜 사용하냐면 JAVA는 파일을 실행하기 위해선 class를 생성 후 java Bean을 생성한 후 해당 값을 찾아오게 됩니다. 하지만 코딩을 하다보면 매번 코드를 돌렸다 멈췄다 하기에 번거롭습니다. 특히 서버에 관련된 setting 이라면 더더욱 그렇지요.

그럴때 config 설정을 property에 정의해놓고 해당 class에서 property에서 값을 가져오게 한다면 설정이 바뀌어 수정을 한다해도 property에서 해당 값만 수정하면 되어 서버를 멈출 필요도 없습니다.

Property 설정

먼저 config 파일을 만들 폴더를 생성해줍니다.

폴더를 생성하고 config.xml 파일을 생성했다면 property를 작성해줍니다!

<properties>
    <comment></comment>
	<entry key="message"> property로 설정한 문구 ! </entry>
</properties>

그 후 root-context.xml 파일에서 해당 config 파일을 읽을 수 있게 경로를 명시해줍니다.

<util:properties id="config" location="classpath:/scheduler/config.xml"/>

Property 적용

@Component
public class PasswordScheduler {

	@Value("#{config['message']}")
	private static String config_message;

    @Scheduled(cron = "*/2 * * * * ? ") // 2분 마다 실행
    public void SchedulerMain(){    
        Date today = new Date();
        System.out.println("스캐쥴링 !" + today + config_message);
    }
}

결과

이제 cron 표현식으로 특별한 날짜 및 시간을 정해서 해당 class에 scheduler 어노테이션으로 명시를 해주시면 설정해 놓은 날짜에 자동으로 실행되는 scheduler를 구현하실 수 있습니다.

Reference

Redux.js 완벽 정복

hosu4549@gmail.com — Sun, 17 Jan 2021 07:00:00 GMT

Flux?

Redux를 좀 더 쉽게 이해하기 위해 Flux 패턴을 이해해야 합니다.

먼저 React.js는 MVC 패턴에서 View 에 집중해있습니다.

하나의 controller에서 데이터를 model에 전달하고 view단으로 화면을 구성하는것이 일반적인 MVC패턴입니다.

하지만 만약 이러한 방식에서 View가 많아진다면 어떡할까요?

Model과 View가 추가될 때 마다 복잡도가 증가하고, 프로젝트 규모가 기하급수적으로 늘어나게 되며 논리적인 관계 또한 파악하기 힘들어집니다.

이러한 단점을 보완해줄 수 있는 패턴이 Flux 입니다.

Flux 패턴에서 store는 개념이 등장하는데 이 store는 해당 어플리케이션의 모든 데이터 변화를 담고 있는 개념이라고 생각하시면 됩니다.

action이 발생 했을 때, dispatcher는 store에서 갖고 있는 데이터 들을 어떻게 수정할 것인지 결정합니다.

이 후 store가 변경되면 store 내부의 데이터도 바뀌므로 view가 갱신되게 됩니다.

위의 내용을 간단히 정리하자면, dispatcher가 action으로 인한 데이터 변경 로직을 결정하면 store에 변경된 데이터가 쌓여 view가 바뀌게 됩니다.

React와 React + Redux의 차이

React.js는 React component 자신이 개별적으로 상태관리를 합니다.
React.js + Redux는 데이터들을 한 곳(store)에서 상태 관리를 하고, React component(view)는 그걸 보여주기만 하는 용도로 쓰입니다.

Redux에서 중요한 개념

Action
Reducer
Store

Action

Action에서는 state 변화과 있을법한 상황들을 미리 정의합니다.

Reducer

Reducer에서는 Action이 일어났을 때 어떻게 state를 바꿔줄지에 대한 로직을 담습니다.

Action의 결과가 Reducer로 전달되고 Redux가 state를 해당 결과로 값을 수정합니다.

Store

변경된 state들은 store에 담기게 됩니다. 이 때, store 내부의 상태 변화에 따라 view도 함께 변화해야하기 때문에 store와 view를 연결해줄 필요가 있습니다.

간단 예제 - class형 component

최상위 React Component에 store를 만듭니다.

import { createStore } from 'redux';

...

store = createStore(reducer);

Provider로 전체 앱을 한 번 감싸줍니다.

import { Provider } from 'react-redux';

...

<Provider store = {store}>
	<App />
</Provider>,
document.getElementById('root');

Component와 store를 연결합니다.

const Profile = (props) => {
  const { profile, updateProfile, thunkGetProfile } = props;

  // 첫번째 아이디 수정 
  const updateId = () => {
    updateProfile({
      id: 'test',
    });
  };

  // 두번째 아이디 수정
  const updateId2 = () => {
    updateProfile({
      id: 'test2',
    });
  };
  
  return (
    <div>
      <h1>useState, useEffect Example</h1>
      Profile! <br />
      ID: {profile.id} <br/>
      ButtonClick Count is: {counter} <br />
      <button onClick={updateId}>Update profile</button>
      <button onClick={updateId2}>Update profile</button>
    </div>
  );
};

const mapStateToProps = (state: AppState) => ({
  profile: state.profile,
});

export default connect(
  mapStateToProps,
  { getProfile, updateProfile, thunkGetProfile }
)(Profile);

class 형 component에서는 위와 같이 mapStateToProps를 이용해서 props내 state를 정의하고 connect를 이용해서 props를 바인딩하는 방식으로 구현합니다.

Redux + Hooks

const Profile = (props) => {
	const dispatch = useDispatch();
	const profile = useSelector((store) =>  store.example.profile);

  // 첫번째 아이디 수정 
	const updateId = () => {
			dispatch(updateExampleProfile({ id : "test"}));
	};

  // 두번째 아이디 수정
	const updateId2 = () => {
		dispatch(updateEampleProdile({ id : "test2"}));
	};

	return (
		<div>
      <h1>useState, useEffect Example</h1>
      Profile! <br />
      ID: {profile.id} <br/>
      ButtonClick Count is: {counter} <br />
      <button onClick={updateId}>Update profile</button>
      <button onClick={updateId2}>Update profile</button>
    </div>
	);
};

export default Profile;

실제로 props내에 function들을 이용해서 component를 wrapping하여 props에 연결해주는 방식이 아닌, hooks를 통해 더 직관적으로 접근이 가능해졌습니다.

useSelector의 경우 mapStateToProps와 유사한 기능을 하며, store의 state의 데이터를 할당할 수 있도록 하는 함수입니다.

해당 selector의 경우는 연결된 action이 dispatch 될 때마다 selector에 접근하여 값을 수정하게 됩니다.

여기서 profile 객체는 연결된 store의 example이라는 state의 profile을 할당하도록 되어 있고, 실제 하단의 updateId와 updateId2 에서 dispatch되는 action에 따라 해당 profile에 관련된 state가 변경되도록 설정되어 있습니다.

이를 통해 profile이라는 객체는 store에서 반환되는 값을 통해 update가 가능합니다.

useDispatch 는 redux store에 설정된 action에 대한 dispatch를 연결하는 hook으로써, 실제 updateExampleProfile이라는 action을 연결할 수 있도록 선언해줍니다.

DB란 ?

hosu4549@gmail.com — Mon, 11 Jan 2021 05:30:00 GMT

들어가며

2021년의 목표 중 하나가 기초를 튼튼히 다지자 이기 때문에 그에 맞춰 DataBase의 기본부터 공부하려고 합니다. 그 첫 번째로 DB란 무엇인가?에 대해 포스팅을 시작합니다~!

( 참고한 책은 쉽게 배우는 MySQl입니다. )

데이터 베이스는 특별한 기업의 응용 시스템에서 사용하기 위해서 저장된 데이터의 집합

DBMS는 사용자에게 데이터베이스를 생성하고 유지할 수 있게 해주는 프로그램의 집합

데이터 베이스 개요

데이터 베이스의 네 가지 만족 조건

통합된 데이터 (Integrated data)
- 데이터 베이스는 동일한 데이터가 중복되어 있지 않다는 것을 의미
- 최소한의 중복 또는 통제된 중복을 허용
저장 데이터 (Stored Data)
- 컴퓨터가 접근 가능한 자기테이프나 디스크와 같은 저장 매체에 저장된 데이터
운영 데이터 (Operational Data)
- 어떤 한 조직의 고유 기능을 수행하기 위해 반드시 필요한 데이터
- 조직의 존재 목적이나 기능을 수행하는 데 없어서는 안 될 데이터의 집합
공용 데이터 (Shared Data)
- 어느 한 조직의 여러 응용 프로그램들이 공동으로 소유하고 유지하며, 이용하는 데이터

데이터 베이스의 특성

실시간 접근성 (Real-time accessibility)
- 데이터베이스 내의 데이터들은 데이터 상호간에 연결되어 있지 않으면 이를 참조할 수 없기 때문에 상호 밀접한 관계로 연결.
- 데이터베이스를 구축하여 놓고 이를 효율적으로 사용하기 위해서는 실시간 처리가 가능하도록 하여 어떠한 질의에 대해서도 몇 초안에 즉각적인 응답이 이루어짐.
계속적인 변화 (Continuous evolution)
- 데이터 베이스는 항상 급변하는 데이터를 반영하기 때문에 계속적으로 변화되어야 한다.
동시 공유 (Concurrent sharing)
- 서로 목적이 다른 사용자들이 같은 시간에 같은 데이터에 접근하여 이용할 수 있도록 DBMS는 관리하여 접근
내용에 의한 참조 (Content reference)
- 데이터 참조는 레코드의 주소나 위치에 의해 참조되는 것이 아니라 사용자가 요구하는 데이터의 값에 따라 참조
데이터 베이스는 실제 물체를 구분하는 개체 (Entity)들고 구성되며, 하나의 개체는 한개 이상의 속성 (Attribute)로 구성되고 각 속성은 개체의 특성이나 상태를 나타낸다.
개체 인스턴스(Entity instance) : 개체는 그 개체를 구성해서 기술하고 있는 속성들이 어떤 실제 값을 가지며 구체화 된다.

DBMS

데이터베이스에 저장된 데이터는 직접적으로 접근할 수 없기 때문에 이를 데이터베이스 관리 시스템 (DBMS : DataBase Management System)이라고 한다.

데이터 독립성 : 데이터가 어떻게 저장되고 어디에 저장되는지 알 필요가 없다.
데이터 무결성 : 데이터베이스의 데이터는 실세계에 적용되는 규칙을 항상 만족해야한다.
데이터 일관성: 두 개의 서로 다른 부분에 있는 데이터베이스 데이터가 서로 모순되지 않아야 한다.

Codd의 관계형 데이터베이스 시스템의 특성

데이터의 논리적 독립성
- 한 속성(칼럼)에 가해진 변경이 동일한 관계(테이블)에 대한 다른 속성(칼럼)에 심각한 영향을 주지 않는다.
참조 무결성과 데이터 무결성
- 무결성 제약 조건을 실행해야 하는 부담을 없앨 수 있다.
비정규 질의
- 사용자는 작업을 실행하는 방법을 명시하지 않고도, 데이터베이스에게 어떤 데이터를 조회할 것인지 명령할 수 있다.

모델의 종류

계층 데이터 모델 (`Hierarchical Data Model`)

(이미지 출처 : 위키백과)

계층 모델은 개체 집합에 대한 속성 관계를 표현하기 위하여 개체를 노드로 표현하고 개체 집합들 사이의 관계를 링크로 연결한 트리(tree) 형태의 자료구조 모델
개체와 개체의 관계를 트리구조로 연결하는 데이터 모델

망 데이터 모델 (`Network Data Model`)

(이미지 출처 : 위키백과)

개체 집합에 대한 속성 관계를 표현하기 위하여 개체를 노드로 표현하고 개체 집합들 사이의 관계를 링크로 연결한 그래프 (graph) 형태의 자료구조 모델

관계 데이터 모델 (`Relational Data Model`)

(이미지 출처 : 위키백과)

개체 집합에 대한 속성관 계ㅒ를 표현하기 위하여 개체를 테이블(table)로 사용하고 개체 집합들 사이의 관계는 공통 속성으로 연결하는 독립된 형태의 데이터 모델
모든 개체들이 다른 개체들과 직접적인 관계없이 독립적으로 존재하는 데이터 모델

객체지향 데이터 모델 (`Object-oriented Data Model`)

객체 지향 프로그래밍 (OOP : Object Oriented Programming)에서 발전된 객체 지향 데이터 모델
객체 지향 프로그램의 핵심 개념인 자료 추상형(ADT), 객체 신원(Identity), 계승(Inheritance)등의 개념이 데이터베이스에 통합 된 것.

객체관계 데이터 모델 (`Object Relational Data Model`)

객체지향 모델의 장점과 관계 모델의 장점을 합쳐 하나의 시스템으로 통합된 모델

관계형 모델과 객체 지향형 데이터베이스

RDBMS의 특징

모델 자체가 간단
여러 연산을 수학적으로 최적화
간단하 질의어로 쉽게 정보 검색

관계형 모델의 용어

관계형 데이터베이스 언어 (`Relational database language`)

테이블 (table) -> 공식적인 명칭은 릴레이션(Relation)
열 (Column)
행 (Row)
무결성 규칙 (Integrity rule)
기본 키 (Primary key)
후보 키 (Candidate Key)
대체 키 (Alternate Key)
참조 키 혹은 외래 키 (Referential Key or Foreign Key)

무결성 규칙

무결성 규칙은 관계형 데이터베이스 관리 시스템에서 강화되었다. 매번 테이블이 갱신되면 RDBMS는 새로운 데이터가 적절한 무결성 규칙을 만족하는지 조사해야 한다.

기본 키 (`Primary Key`)

테이블의 기본 키는 유일한 행을 구별할 수 있도록 사용되는 테이블의 열이다.

테이블에서 두 개의 서로 다른 행은 기본 키 값으로 동일한 값을 가질 수 없고, 테이블에서 모든 행의 기본 키는 항상 하나 이상의 값을 가지고 있어야 하며 NULL 값을 가질 수 없다.

후보 키 (`Candidate Key`)

기본 키를 대체 할 수 있는 하나 이상의 열 또는 열의 조합

유일성 (Uniqueness) : 한 테이블에서 모든 튜플들을 서로 구별할 수 있는 성질
최소성(minimal) : 후보 키를 구성하는 칼럼들 중에서 어느 하나를 제거하면 유일성 기능을 상실하는 성질

대체 키 (`Alternate Key`)

테이블의 기본 키가 아닌 훕보 키를 대체 키라 하는데, 특별한 테이블을 위해 0개 이상의 대체키를 정의할 수 있다.

외래 키 (`Foreign Key`)

외래 키는 테이블과 테이블의 관계를 설정해주는 키

한 테이블에 여러 개의 외래 키가 올 수 있는 반면 관계를 설정해 주는 부모 키는 다른 테이블의 기본 키 여야 한다.

RDBMS 구성 요소

RDBMS 구조의 중요한 두 가지 요소는 소프트웨어인 커널(Kernel)과 데이터 베이스를 관리하는 커널에 의해 이용되는 시스템 레벨의 데이터 구조로 구성되는 데이터 사전(Data Dictionary)이다.

커널 : 자원을 사용자가 사용할 수 있게 관리하는 프로그램

RDBMS 커널

MySQL은 데이터 베이스의 동시 사용자를 위해 주어진 자원의 집합게 대한 접근을 관리하고 통제한다. 또한, 메모리 캐시와 페이징을 관리하며, 자원의 동시 사용에 대한 locking을 통제하며 사용자 요청을 할당한다.

데이터 사전

RDBMS과 다른 데이터베이스나 파일 시스템과 근본의 근본적인 차이점은 데이터를 엑세스하는 방법에 있다.

RDBMS는 더욱 더 추상저깅고 논리적인 형식보다는 물리적 데이터를 참조할 수 있게 하여, 애플리케이션 코드 개발시 용이함과 유연성을 제공한다.

데이터 사전은 데이터 베이스 내에 존재하는 모든 객체에 대한 메타 데이터 (Meta data : 데이터 관리상 필요한 작성자, 목적, 저장장소등 속성에 관한 데이터)를 저장한다.

또한 데이터베이스를 읽어오거나 갱신하는 요청은 데이터 사전 내의 정보를 사용하는 MySQL 커널에 의해 처리된다. 데이터 사전 내의 정보는 객체의 존재를 타당하게 하고, 객체에 대한 접근을 제공하며, 실제 물리적 저장 위치를 가진다.

MySQL이란?

SQL(Structure Query Language)은 관계형 데이터베이스 언어이다.

대화형 사용법 하나의 SQL 문장이 입력되면 즉시 처리되어 그 결과를 화면에서 볼 수 있는 형식
내장형 사용법 SQL 문장은 다른 프로그래밍 언어로 작성된 프로그램 내부에 포함되어 있는 형식

2021년 목표 정리

hosu4549@gmail.com — Sun, 10 Jan 2021 02:30:00 GMT

들어가며

다사다난 했던 2020년이 지나고 드디어 2021년을 맞이했습니다.

20년 2월에 대학을 졸업하고 취업을 준비하면서 코로나를 겪어 심히 불안했었고 운 좋게 스타트업에서 저를 필요로하여 비교적 짧은 취준 시간을 갖고 취업을 하였습니다.

나름 자신이 있었지만 막상 실무를 하다보니 상당한 어려움이 있었네요 ㅎ..

2020년에는 회사에 적응하고 업무에 익숙해지기 위해 시간을 주로 보냈다면, 2021년에는 새로운 공부를 통해 업무 능력을 올리고 스스로 레벨업이 되는 한해로 보내려고 합니다.

1년 전체 계획을 계획하는 것보다 반기 혹은 분기로 나누어서 계획을 세웠습니다. (길게 보고 계획을 세우면 쉽게 지칠것을 예상...)

2021년은 레이크에게 개발 능력 업그레이드를 위한 한 해

2021년 목표

DataBase

처음에 업무를 하면서 가장 많이 부딪혔던 장벽이 SQL 이었습니다.

기본 질의어는 쉽게 구현해서 원하는 data를 뽑아 낼 수 있었지만 명령문의 최적화라든지, UNION등 단계가 있는 SQL은 어려움이 있었습니다.

올해에는 SQL문을 상반기에 공부하여 습득하는 것이 첫번째 목표입니다.

쉽게 배우는 MySQL 완독

Chapter	기간	기타
1장 개요	1월
2장 설치와 사용법	1월
3장 학사관리 예제	1월
4장 학사관리 예제	1월
5장 테이블 생성	1월
6장 SELECT - 기본	1월
7장 SELECT - Caluse	2월
8장 SELECT - FROM	2월
9장 SELECT - WHERE	2월
10장 SELECT - 통계 함수	2월
11장 GROUP BY와 HAVING	2월
12장 SELECT - ORDER BY	2월
13장 SELECT - 명령문 조합	2월
14장 부속 질의어	2월
15장 SELECT - JOIN	2월
16장 테이블 변경	3월
17장 인덱스 사용	3월
18장 view	3월
19장 Transaction 과 Lock	3월
20장 SQL 명령문의 최적화	3월
21장 데이터베이스 설계 지침	3월
22장 MYSQL 유틸리티	3월
23장 Trigger	3월

Pro Git

git에 대해서는 대학생때부터 욕심이 있어서 공부를 꾸준히 해왔었습니다. 회사에서도 git을 쓰기 때문에 앞으로 점차 능숙하게 사용하고 싶어 Pro Git 책을 구매하였고 완독이 목표입니다.

( 사실 최종 git 목표는 회사의 git process에 제가 권한을 받는 것 입니다!!)

하지만 git은 꾸준히 공부할 예정이기 때문에 날짜를 정해두고 공부하진 않을 예정입니다. (시간남을때마다 틈틈히 공부!)

Chapter	기타
1장 시작하기
2장 Git의 기초
3장 Git 브랜치
4장 Git 서버
5장 분산환경에서의 Git
6장 GitHub
7장 Git 도구
8장 Git 맞춤
9장 Git과 여타 버전 관리 시스템
10장 Git의 내부

블로그

원래 블로그는 꾸준히 써오려고 했으나.. 회사 업무와 여러 상황들 때문에 글을 잘 쓰지 못했었습니다..

추가로.. 원래 만들어져있던 git repo가 저의 실수 때문에 날라가버리는 바람에 기존에 작성되어 있던 글 들도 살리지 못했습니다.. 😂 😂 😂

하지만 이를 계기로 2021년에는 주 1회 개발 블로그 포스팅을 하려고 합니다 !!

2021년에는 더 나아질 수 있도록 계획을 세워봤습니다.

이 포스트에 공부가 완료되면 ✅ check를 하는 식으로 계속 업데이트를 하려고 합니다~!

2020년 회고

hosu4549@gmail.com — Mon, 04 Jan 2021 07:30:00 GMT

들어가며

분기별로 요약한 2020년

1분기 : 대학 졸업 후 취업 준비

2분기 : 취업 준비 후 취업

3분기 : 회사 서비스 내용 파악

4분기 : 유지보수 및 프로젝트

위의 이미지가 보이시나요? 저게 바로 수습이 끝난 후 열심히 달려온 제가 개발하면서 경험했던 프레임워크, 라이브러리, 도구(?) 들입니다 허허...

수습이 끝나자마자 여러 프로젝트를 진행했고 성공적으로 완성되기까지 많은 시간과 노력이 들었는데, 결국 그 결과로 제가 개발한 결과물이 회사의 수입을 내는 서비스로 반영이 되는 쾌거를 이루었습니다 !

학교에서 깊게 공부하지 않았던 spring 을 업무의 주된 프레임워크로 사용을 해야 했기 때문에 공부를 시작했고 그 밖에 SQL문, DB relationship, jsp, jqeury 등 익숙하지 않은 프레임워크, 도구들로 개발을 해야해서 많은 시간을 들여 공부하며 개발하였습니다.

기획 부터 DB 설계, process 설계, 실제 개발까지 A 부터 Z까지 멘땅에 헤딩(?) 식으로 진행을 하다보니 느낀점도 많고 이러한 경험으로 정말 많이 성장한 듯 싶어 그 중 하나의 서비스에 관해 이렇게 포스팅을 준비하게 되었습니다. 😎

이번 포스팅은 하나의 서비스가 기획되고 개발 시작되며 테스트를 하는 단계까지의 순서를 바탕으로 작성하겠습니다.

✅ 기획

여담이지만.. 평소 학교에서 프로젝트 하듯이 주어진 틀에서 기획을 하는 것이 아니라 처음으로 프로세스 정리부터 테스트 케이스를 작성하는 기획까지 시작했습니다. 하지만 아 프로젝트가 외부업체와 협업을 하는 부분도 있어서 부담도 많이 되었고 내부 시스템을 다 파악하지 못한채 바로 진행했기 때문에 더 힘들었다고 생각이 드네요.. 😅

( 전체적인 process를 회사 내부 규정에 맞게 중요 정보(데이터) 는 제외하고 올렸습니다. )

어떤 부분에서, 어떤 상태일 때 데이터를 보내고, DB에 저장하며, 어떤 값을 반환하는지에 대해 고민했고 특히, 사용자 권한별 데이터에 초점을 맞추어 process를 정리했습니다.

정말 신기하게 한번 이렇게 뼈대 설계를 잘해놓으면 개발이 비교적 쉽게 되었습니다. 특히, 예외처리 부분에서 빛을 발휘했습니다. ~~(하지만 실제로 운영서버에 올렸을 때 생각지도 못한 부분에서 오류가 나더라구요 😭)~~

기획 의도

제가 오픈한 서비스는 바로 저희 시스템에 전자계약이라는 새로운 기능을 연동하는 것이었습니다. 사실 전자 계약 플랫폼 자체를 만드는 것이 아니라 전자계약 플랫폼을 갖고 있는 외부 업체와 협업해서 진행한 프로젝트였는데 저희 쪽의 계약관리에 연동되게 만든 차세대(?) 계약 기능이었습니다.

여기서 제가 특별히 신경썻던 부분은 외부 업체의 API, SDK를 사용함에 있어 반환값의 형태였습니다. 이 부분에 대해서는 밑에서 더 자세히 설명하겠습니다. 😎

기획 특징

외부 업체와 협업을 하다보니 먼저 외부 업체의 플랫폼에 대해 누구보다 잘 알아야 했습니다.

특히,request로 보내는 어떤 parameter가 필요한지, token은 어떤 값인지, response의 형태는 무엇이며 어떤 데이터들을 보내주는지 빨리 파악하는게 핵심이었습니다.

( 이때 사용했던 tool이 바로 postman 이었습니다. 사실 postman은 웹 개발을 할 때 빼놓을 수 없는 도구인것을 알고 있었지만 이번 만큼 API 통신을 할 때 유용했던게 없던 것 같습니다.... )

위의 process를 보시면 알 수 있듯이 저희 쪽 DB에 저장하는 값을 뽑아야 했고, 저희 DB에서 제공할 수 있는 데이터도 파악을 했어야 했습니다.

또, WebHook이라는 서버 통신을 해야 했는데 이 부분까지 고려해야 했으며 이 부분이 특히 공부를 해야하는 부분이라 시간이 걸린 것 같습니다.. ( interceptor 빌어먹을,,, )

✅ Back-end

Back-end 쪽은 제가 경험이 거의 없었습니다. 입사 포지션도 클라이언트 개발 즉, Front-end 로 들어왔기 때문에 제가 back단을 해볼거라곤 생각도 못했었죠.. 😂😂

하지만 다 해봐야 경험이 쌓이고 전체적인 흐름을 파악할 수 있으니 도전하게 되었습니다.

사실 ❕ spring은 대학생때 인턴하던 시기에 조금 다뤄봐서 controller, service, dao에 대한 이해가 조금은 이루어져 있어서 그나마 다행이었숩니다,,,

Spring

처음 Spring으로 업무를 해야한다고 했을 때 구글링을 많이 했던 것 같습니다. 취업을 위해 최근 공부를 javascript, typescript만 하다보니 JAVA에 대해 까먹기도 했고 자신이 없어서 찾아보고 공부하는 시간을 가졌습니다.

개발 목적

back단에서 데이터의 교환이 이루어지는데 이 때 특히 개인적으로 신경쓰면서 개발했던 부분은 소스의 간소화, 중복코드 방지였습니다.

개발 특징

위에서도 언급했듯이 해당 기능이 종료되면 Webhook이라는 특이한 서버 통신으로 데이터 전달이 이루어지는데 이 데이터를 어떻게 받을 지가 key point 였습니다. 왜냐하면 단순히 받아와서 저장을 하면 문제가 되지 않지만 응답하는 데이터가 다른 두가지의 케이스가 있어 이 부분이 상당히 까다로웠습니다. (회사 규정상 자세히 언급하지 못해 죄송합니다.)

✅ Front-end

제가 입사한 포지션이 front-end 쪽이라 화면 쪽은 자신감이 있었습니다. 처음엔 React.js로 취업을 했지만 회사의 방향은 Vue.js였고 Vue.js를 공부하기 시작했습니다. 하지만 회사의 어드민 페이지와 같은 웹 서비스들은 Jquery로 개발되어있어서 제가 따로 공부하는 것 외엔 도움 얻을 수 없었습니다. 하지만 다행히 회사의 작은 서비스 중 하나가 Vue.js로 구성되어 있어서 그것을 유지보수 하면서 공부도 하고 개발 구조를 습득했습니다.

하지만 처음 front-end 포지션으로 입사했을 때에 화면에 그리는 것을 중점에 두는 것이 아니라 자원의 절약, 데이터를 조금 더 효율적으로 다루는 방법등 개발 소스쪽으로 배우고 싶었습니다. 하지만 백단도 만들면서 화면을 그리다보니 결과론적으로 생각을 하게 되었고 처음에 생각했던 방향과는 다르게 완성만 시키자 라는 결과론적 마인드가 생기게 되었습니다.. 이 부분을 굳이 안써도 되지만 쓴 이유는 2021년에는 리소스 관리에도 관심을 갖고 공부하고 싶어 이렇게 적게되었습니다 !!!

Jquery + Vue

회사에서 프로젝트를 진행하다가 느낀 한가지는 현재 내부에서 개발되어진 jsp + jquery 파일에 vue.js를 얹여야 했습니다. 물론 jsp에 Jquery.js와 Vue.js 모두 js이기 때문에 불가능한것은 아니지만 두개의 라이브러리를 하나의 jsp에 넣는다는 것 자체가 비효율적이었습니다.

(저와 같은 상황에 계신 분들을 위헤 이 부분은 추후에 팁(?)으로 따로 포스팅을 할 예정입니다.)

개발 목적

일단 화면은 사용자가 가장 사용하기 쉽고 쉽게 접근할 수 있어야한다고 생각합니다. 그래서 취업하고 UI/UX 스터디도 참여했었고, 특히 저희 서비스는 사용자가 젊은 층도 될 수 있지만 중년 사용자분들이 대부분이라 더더욱 접근하기 쉽고 사용하기 쉬워야했습니다.

색 선정부터 엘리먼트들의 위치, 효율적인 버튼등 사용자를 위한 화면이 될 수 있게 목적을 두고 개발하였습니다.

또, 협력업체의 API 통신을 하고 받아오는 부분을 처리해야하기 때문에 이 부분도 특히 신경 썻고 API 통신은 axios와 fetch 함수를 사용하여 많이 작업했습니다. (이부분도 추후에 포스팅하기로 하겠습니다.)

간단한 회고 형식이라 보니 개발적인 내용이 아니라 제 경험을 적고 싶었습니다 ㅎㅎ

개발하다가 공부가 필요한 개념은 늘 메모를 해두고 시간이 될 때 공부를 하다보니 작성할 포스팅이 아직 엄청 많네요 !!

읽어주셔서 감사합니다. 태클은 언제든 환영입니다 ~!