네른

고가용성을 보장하는 서버 환경이 필요해졌다. 그래서 가장 먼저 적용하기로 한게 서버 이중화. 그 중에서 앞쪽에서 유저의 요청이 들어왔을 때, 이를 분산하는 방법에 대해 조사했다. 서버 이중화란, 말 그대로 서버를 이중으로 구성하는 것. 보통 고가용성을 달성하기 위해 서버를 여러대 설치하는 경우가 많은데, 각 서버의 용도에 따라 이름이 나뉜다. 크게 Active-Standby(Passive) 와 Active-Active 형태로 나뉘게 된다! Active-Passive - 실제 요청을 받아 처리하는 Active 서버와, Active 서버에 장애가 발생할 때 대신 받아 요청을 처리하는 Passive 서버로 나뉨. - 즉, 평소에는 Passive 서버는 별다른 요청 처리를 수행하지 않음. 모든 요청은 Activ..

앞선 글대로 Kubernetes를 설치하면, 말 그대로 kube cluster만 구성된 상태가 된다. 여기에 먼저 설정한 것들이 위에 적힌 것들이다. - rook ceph : kubernetes 환경 위에 가상 스토리지인 ceph를 배포하여 사용하게 해주는 도구. - chartmuseum : 프라이빗 차트 레포. helm chart를 사용할 때, 프라이빗 레포가 필요하다면 설치. - ingress controller : ingress rule을 적용하기 위해 필요한 controller - OCI registry : docker 환경을 이용한 프라이빗 레지스트리. 사용하는 환경이 프라이빗 레포에 레지스트리가 필요하고 helm chart로 관리를 하고자 하였기때문에 chartmuseum, OCI regist..

앞에서 대시보드 구성을 먼저 쓰게된거같은데, 실제로는 클러스터 구성 후에 진행했던 내용이긴 하다. 어쩌다보니 베어메탈 위에 직접 kubernetes 클러스터를 구성하게 되었었다. 기존 클라우드를 이용해 구성했을때에 비해 그렇게 어려웠던 부분은 없었던거같지만 추억보정이 들어가있을 수 있으므로 한번 정리해보기로 했다. 쿠버네티스 클러스터를 구성하는 건 기본적으로 Installing kubeadm | Kubernetes Installing kubeadm This page shows how to install the kubeadm toolbox. For information on how to create a cluster with kubeadm once you have performed this installa..

쿠버네티스는 각 Pod별로 작동에 필요한 리소스를 지정하는 옵션이 있다. 지정하는 리소스는 대표적으로 CPU와 Memory가 있으며, 각각 request, limit 이라는 두 값을 입력해 주어야 한다. - 이 때 CPU의 리소스 단위는 상수(1.0) 혹은 m으로 표현되며 공식문서에 따르면, : 1.0 == 1개의 CPU 코어 : 100m == 0.1 == 100 밀리코어 라고 한다. - 메모리의 리소스 단위는 주로 M, G, T, P와 같은 단위를 쓰며 바이트 단위를 의미한다. : 128M == 128 메가바이트 : 혹은 2의 거듭제곱을 사용하는 방식인 128Mi 등이 있다. Request VS Limit Request와 Limit의 차이는 단순하다. Request는 컨테이너가 생성될 때 노드에 요청하..

보통 yaml 파일을 새로 적용하려면 kubectl create -f 명령어를 사용하게 된다. 이와 별개로, 호스트나 파드의 상태를 한눈에 보고싶을 때 설치하게되는게 dashboard이다. dashboard에서 직접 yaml파일의 내용을 업로드해서 만들 수 도 있고, 파드나 노드의 상태를 보기에도 좋다. 로그를 볼 수도 있고, container shell에 접근할 수도 있다. kubectl이 익숙하지 않으면 잠시 써도 나쁘지 않을 것 같다. kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml 대시보드를 배포하는 명령어는 위와 같다. 공식적으로 제공되는 yaml과 이미..

종종, Pod를 생성하고 나서 내부의 앱이 권한문제로 인해 정상적으로 동작하지 않을 때가 있다. 그럴 때 주로 사용한 방법이 Pod의 SecurityContext를 수정하는 것. SecurityContext란 Pod/Container의 권한을 수정하는 데 사용되는 기능으로, 프로세스의 사용자/그룹을 수정하거나 보안정책, 권한 등을 설정하게 된다. 대표적인 몇가지만 간단히 나열하자면, - hostPID/IPC : 해당 리소스가 node의 PID와 IPC를 사용할 수 있게되어 직접 통신이 가능해진다 - hostNetwork : 해당 리소스가 node의 network interface에 접근할 수 있게된다 - runAsUser: 해당 리소스의 사용자 ID(UID)를 지정한다. 디폴트 값이 0 이기에, 특정 U..

보편적으로 account라 하면, 해당 서비스에 접근하기 위한 유저의 계정을 생각한다. 그러나 kubernetes에서 account라 하면, 보편적으로는! service account를 의미한다고 보면 된다. 물론 일반적인 user account도 있지만, kubernetes는 그러한 유저 정보를 별도로 저장하지 않는다. - 단지 외부 서비스에 의한 인증(Oauth 등)을 제공만 할뿐, 별도로 저장해서 가지고있지 않다는 뜻. 그러면 service account란 뭘까. - 단순하게 말해서 kube에 접근하고자 하는 시스템의 계정이다. - 즉, kubernetes의 API를 이용해 kube를 수정하거나 조회하려면, 해당 시스템은 적절한 servica account를 가지고 있어야 한다는 것. - 생성은 복..

로그 로테이션. 말 그대로 로그를 회전시키는 것. 로그 파일의 크기가 너무 커지는 것을 방지하기 위해, 로그 파일을 분산/갱신 하는 과정을 의미한다. Spring과같은 다양한 애플리케이션들은 기본적으로 로그 로테이션 방법을 내부적으로 지니고 있다. 그런데 만약 없다면?? 예를들어 database들 그런 것들을 위해 사용되는거이 리눅스의 기본 패키지 중 하나인 logrotate이다. logrotate는 cron을 기반으로 돌아간다고 생각하면 되는데, 당연하게도 주기적으로 로그를 갱신해야되므로 필요하다. 간단하게 구조를 보면 cron의 동작을 기술하는 부분 중, cron.daily 폴더 내부를 보면 logrotate파일이 있는 것을 볼 수 있다. 그리고, 해당 파일의 내부에는 /etc/logrotate.d ..

약간 번외 느낌인데, Elasticsearch를 사용하다가 쌓인 데이터를 어떻게 처리할까? 에 대해 고민하다가 찾아봤다. 디스크가 터질 것 같았기 때문. ILM(Index Lifecycle Management)인데, 말그대로 elasticsearch index들의 수명을 어떻게 처리할지이다. 주로 Hot, warm, cold, delete 페이즈를 지정해서 일정 기간이 지나도록 접근이 없거나 접근 횟수가 낮으면 중요도를 점점 낮추다가 삭제하는 방식. - 기본적으로 hot-warm-cold 방식을 기반으로 동작 - 자주 접근되는 인덱스는 hot, 일정 기간 이상 접근되지 않으면 warm -> cold 순으로 내려감 - cold 상태에서도 일정 기간 이상 접근되지 않으면(데이터 조회나 추가가 없으면) del..

지난번에 작성한 Fluentd 내용을 토대로, 실제 EFK 스택을 kube에 올릴 때 사용한 yaml을 정리하고자 한다. 해당 yaml들은 helm chart를 기반으로 작성되어있어 일부 변수가 포함되어있다. 실제로는 해당 부분을 직접 채워넣어 사용해도 되니까 우선은 helm chart 내용을 토대로 정리한다! 우선, 각 애플리케이션별 구성은 크게 다음과 같다. Fluentd - Deployment (HTTP 로그 수집용 / Side-car 형태의 로그 수집용) - ConfigMap - Service (HTTP 로그 수집용 Pod를 위한 서비스) - Ingress Elasticsearch - Deployment - Service - Ingress Kibana - Deployment - Service - ..