분류 전체보기

1. 배경 이전 글을 통해 기본 적인 애플리케이션의 스켈레톤 코드를 작성하고, Spring Cloud on Kubernetes 프레임워크를 사용해서 쿠버네티스에 배포하는 과정까지 진행하였습니다. 이후 실제 로직을 작성하며 개발을 진행하면서 당연하게도 CI/CD 구성에 필요성을 느끼게 되었는데, 테스트 애플리케이션의 경우 MS(MicroService)가 2개이지만 실제 개발되는 애플리케이션의 경우 수많은 마이크로 서비스로 구성되기 때문에 각 모듈을 수동으로 빌드, 배포하는 과정에 시간을 많이 소모하였습니다. 이를 위하여 작업의 효율성을 위해 CI/CD를 구축하며 테스트 한 과정을 기록합니다. 사실 이전에도 작성한 Kubernetes CI/CD 구축 글을 통하여 동일한 구조로 Jenkins-Argo 조합으로..

플랫폼 개발을 진행하며 docker image, package, helm 등의 자료를 공개적인 저장소가 아닌 사내에서 팀원들이 공유할 수 있는 Private Repository가 필요하게 되었습니다. 또한 실제로 사내 보안 때문에 Docker hub로의 접근이 불가능 해 Private Repository에 대부분의 이미지를 저장한 후 다운로드하여 사용하는 구조입니다. 이를 위해 Nexus Repository를 설치하고 테스트하는 과정을 기록합니다. Repository Manager를 사용하는 이유 적은 용량 저장소는 라이브러리를 보관하므로 프로젝트마다 필요한 라이브러리를 버전 관리에 추가할 필요가 없고 라이브러리에 대한 메타데이터만 설정하면 빌드할때 내려받으므로 적은 용량을 차지합니다. 빠른 프로젝트 체..

1. 배경 기존 진행하던 쿠버네티스 프로젝트가 마무리되고, 신규 프로젝트를 맡게 되면서 어떤 언어와 프레임워크를 이용해서 개발을 진행할지 고민을 했습니다. 본인은 Python을 가장 많이 쓰고 익숙하지만, 프로젝트가 완료 됐을 때 내부 회사에서만 사용하는 것이 아닌, 외부에 PaaS(K8S, 컨테이너) 형태로 배포할 수 있기 때문에, 코드를 볼 수 있는 인터프리터 언어라는 점 때문에 배제되었습니다. 그렇기 때문에 컴파일 언어를 사용해야 한다는 점과, 향후 MSA 구조를 도입할 예정이었기 때문에 이를 고려하여 언어 후보를 Golang과 Spring Cloud로 결정하였습니다. 본인은 Kubernets를 주로 해왔고, 계속 하고 싶은 맘이 있었기 때문에 이전부터 Golang에 대해 공부하고 싶은 마음이 있었..

1. 배경 쿠버네티스 클러스터 단위의 작업을 진행하기 위해 운영 중인 애플리케이션을 혹시 모를 이슈를 대비하기 위해서 백업을 필수로 진행합니다. 이러한 백업 툴로 가장 많이 사용하는 게 VMware에서 오픈소스로 개발한 Velero입니다. 실제로 운영 과정에서 업그레이드나 인증서 교체 등 클러스터 영역에서 작업할 때 사전에 백업을 진행하기도 하고, 운영 환경에서 발생한 애플리케이션의 에러를 디버깅하기 위하여 Velero를 통해 백업한 후 테스트 환경으로 동일한 이슈 환경을 만들어서 디버깅을 진행하기도 합니다. 이를 위하여 쿠버네티스에서 백업을 하는 방법을 테스트 한 내용을 기록합니다. Velero를 사용하기 위해서는 Snapshot을 저장하기 위하여 S3가 필요합니다. 테스트 환경에서는 AWS와 Mini..

이 전 글에서 EFK Stack을 구성하여 로그가 정상적으로 수집되는 것을 확인하였지만, 안정적인 운영을 위해 추가로 설정해야 될 작업이 필요합니다. 사실 이러한 부분이 로깅 스택 구축에서 큰 부분을 차지하고 Elastic이 다소 복잡하기 때문에 현재 시스템에 딱 맞는 설정을 한 번에 하기 힘듭니다. 로그를 원하는 형태로 변형하거나, 필터링하고 , ElasticSearch에서 적절한 정책을 설정하여 데이터 사이즈를 조정하는 등의 정책이 필요합니다. 이번 글에서는 container 로그뿐 아니라 추가로 필요한 로그에 대해 설정하는 과정을 기록하고 다음 글에서 elastic 정책적인 부분에 대해 기록하고자 합니다. 1. Log 정제 및 파싱 이전 글에서 구성한 방법은 Fleunt-bit에서 데이터를 전송하여..

1. 배경 쿠버네티스 클러스터를 운영하며 안정적인 관리를 위해 로그 시스템을 구축하기 위해 EFK Stack을 테스트 한 내용을 기록합니다. 멀티 클러스터 환경에서 발생하는 로그를 한 개의 키바나에서 볼 수 있도록 설치합니다. 기본 흐름은 다음과 같습니다. Fluent-bit는 Daemonset으로 생성되어 모든 서버에 생성되어 로그를 전송합니다. Fluentd는 로그를 수집해 적절히 파싱해 ElasticSearch로 보냅니다. ElastciSearch에서 수집한 로그를 Kibana에서 시각화합니다. Fluent-bit 없이 Fluentd만 설치하여 로그를 보낼 수 있지만 규모가 큰 클러스터에서 Fluentd의 작업량이 많아져 부하가 생기기 때문에 로그를 전송하는 역할만하는 Fluent-bit을 따로 설..

1. 배경 쿠버네티스 클러스터를 구성하면서 모니터링 시스템으로 주로 프로메테우스를 구축해서 사용하였습니다. 쿠버네티스 위에서 운영하는 서비스의 경우 안정적인 운영을 위해 HA를 구조로 운영하고 있습니다. 프로메테우스는 메트릭을 발생시키는 익스포터에서부터 Pull 해서 데이터를 가져오고, 수집한 메트릭을 TSDB 구조의 Local Disk에 저장하기 때문에(External DB도 사용은 가능) 프로메테우스가 다운되면 복구되는 시간 동안 메트릭이 누락되게 됩니다. 하지만 프로메테우스에서 이러한 HA 구성을 지원하지 않고 이를 타노스를 통해 구성할 수 있습니다. 또한 멀티 프로메테우스 서버를 통합하여 쿼리 할 수 있는 기능을 제공해서 여러 개의 쿠버네티스 클러스터를 운영하고 있는 상황에서 적합한 서비스라고 생..

1. Overviews Kubernetes에서 CI/CD를 테스트 한 내용을 기록합니다. 기존 작성한 Kubernetes CI/CD 글의 경우 Jenkins만 이용하였지만, 이번 테스트에서는 일반적으로 많이 사용하는 Jenkins-ArgoCD 조합을 사용하여 파이프라인을 구성하고 Docker build를 위해 Kaniko를 이용합니다. 또한 Github에서 webhook을 설정해 push가 발생하였을 때 trigger가 발생해 자동화가 되도록 설정하였습니다. 전체적인 플로우는 다음과 같습니다. 효율적인 관리를 위해 Source Repo 와 Manifest Repo를 나누어서 관리하였지만 일반적인 경우 charts, 나 mainfests 파일을 만들어 동일한 repository에서 사용하기도 합니다. Je..

1. Overview 쿠버네티스에서 Deployment를 생성하면서 안정적인 서비스 유지를 위해 여러 개의 파드로 구성할 때가 있습니다. 이는 보통 Replicas를 2개 이상으로 설정해 파드를 여러 개 생성하여 하나의 파드가 문제가 생겨도 정상적으로 서비스가 동작할 수 있도록 합니다. 하지만 Deployment Spec에서 Replicas 개수만 늘릴 경우 하나의 노드에서 여러 개의 파드가 생성되는 경우가 있습니다. 그럴 경우 생성된 노드가 다운이 될 경우 서비스에 문제가 생깁니다(다른 노드에 바로 배포가 되지만 배포가 되기까지의 시간이 걸리기 때문에 무중단이 불가). 그렇기 때문에 일반적으로 여러 노드에 파드를 분산하여 배포하도록 설정합니다. 이를 위해 파드 스케줄링 방법과 이를 외부에서 접근하기 위..

멀티 클러스터와 많은 서버가 구축되어 있을수록 사용자 접근에 대한 관리가 더욱 어려워집니다. 이에 대하여 효율적인 관리를 위해 Access Management로 Teleport를 사용하기 위해 테스트한 내용을 기록합니다. Teleport는 안정적으로 Infrastructure에 접근하도록 관리해 주는 설루션입니다. Teleport를 이용하여 SSO 인증이나 Two factor 인증을 통해 SSH로 접속하기 위한 Node(서버), Kubernetes Cluster, Database, Web application 등을 관리하며 해당 리소스에 접근할 수 있습니다. 1.Teleport Component Teleport Auth Service: 클러스터 인증기관, 리소스에 접근하기 위해 클라이언트에게 인증서 발급..