Kubernetes

1. 배경 해당 글은 서비스 메쉬에 대해 조사하며 Linkerd의 블로그를 읽고 서비스 메쉬에 대해 이해하기 좋은 거 같아 해당 글을 번역하고 추가로 조사하며 글을 작성하였습니다. 그렇기 때문에 Linkerd를 기준으로 서비스 메쉬를 설명합니다. 현재 많은 기업에서 서비스 메쉬를 도입하고 적용하려고 하지만, 이에 대한 많은 사례가 없어 어려움을 겪고 있습니다. 하지만 서비스 메쉬(Linkerd)의 전체 아키텍처를 크게 보면 간단합니다. 서비스 메쉬의 역할을 단순히 말하면 각 서비스에 사이드카 패턴을 사용해 프록시를 추가하여 서비스 간 통신 하도록 하고, 이러한 기능에 중점을 둡니다.(Proxy, Reverse Proxy의 역할) 이러한 영역을 Data Plane이라 하며, 데이터 플레인이 잘 동작하도록 ..

1. 배경 쿠버네티스 파드는 한 개 이상의 컨테이너로 이루어져 있습니다. 메인 컨테이너 기동 전에 초기 설정을 도와주는 init-container, 로그/메트릭 수집 등 보조 역할을 하는 사이드카 컨테이너 등 한 개의 파드에 여러 개의 컨테이너가 있습니다. 이러한 여러 컨테이너는 서로 localhost로 통신이 가능합니다. 도커로 컨테이너를 여러 개 생성할 경우에는 localhost로 통신이 불가한데, 파드 내부에서는 어떻게 이러한 동작이 가능한지 확인합니다. 2. Pod 생성 및 확인 한 개의 파드에 두개의 노드 서버 컨테이너를 다른 포트를 설정해 생성합니다. apiVersion: v1 kind: Pod metadata: name: multiple-web spec: containers: - image:..

1. 배경 쿠버네티스를 운영하다 보면 PV,PVC 등의 퍼시스턴트 볼륨을 관리하는 일이 필수적으로 발생합니다. 일반 hostPath, EmptyDir 등의 볼륨은 기본적으로 사용할 수 있지만, 볼륨의 한계는 명확합니다. 데이터의 지속성, 컨테이너 간의 데이터 공유, 백업의 한계 등, 하지만 퍼시스턴트 볼륨을 사용하게 되면 하나의 쿠버네티스 리소스로 관리되어 라이프사이클을 갖게 되며, 동적 프로비저닝, 외부 스토리지 사용 등의 볼륨의 한계를 넘어 사용할 수 있어 대부분의 운영 단계에서 권장되어 사용됩니다. 이러한 퍼시스턴트 볼륨을 관리하면서 외부 스토리지를 사용하여(예를 들어 Weka Storage,NFS,AWS EBS 등) Persistent Volume를 만들고 관리하기 위해서는 CSI Driver(c..

1. 배경 이전 글을 통해 Github action과 ArgoCD를 통해 Spring Cloud 기반의 MSA 애플리케이션의 CI/CD를 구축하였습니다. 하지만 해당 구조는 실제 환경에서 사용하게 부족한 부분이 많습니다. 개발계/운영계가 나누어져 있지 않다. Image의 버전 관리가 되어 있지 않다. 배포 방법에 대한 고려가 되어 있지 않다(Rolling,Blue/Green 등) 롤백 기능이 존재하지 않는다. 이러한 문제점을 해결하여 실제 프로젝트에 적용할 수 있도록 구조를 변경하며, 테스트한 내용을 기록합니다. 2. 환경 분리 우선 개발계/운영계는 각각 다른 쿠버네티스 클러스터입니다. 두 개의 클러스터를 한 개의 파이프 라인을 통해 관리하다 보니 다양한 변수를 고려해야 돼서 초기 구축에 공수가 많이 들..

1. 배경 쿠버네티스는 클러스터에 대한 대부분의 정보를 저장하기 위해 키-값 저장소인 ETCD를 사용합니다. ETCD에 문제가 발생하면 클러스터 전체에 장애가 발생할 수 있고, 데이터 유실에 따라 리소스가 변경될 수 있습니다. 그렇기 때문에 클러스터를 안전하게 운영하기 위해서 ETCD의 백업은 필수입니다. 이전에도 대규모 클러스터를 운영하면서, 원인이 파악되지 않는 클러스터 이상이 발생하였을 때도, ETCD백업이 구성되어 있어, 빠른 시간에 복구를 함으로써 이에 대한 중요함을 느낀 적이 있습니다. 이를 위하여 백업과 복구하는 방법에 대해 정리합니다. 테스트를 진행하는 환경은 Ubuntu 서버에 클러스터가 구성되어있는 멀티 마스터 구조입니다. 또한 ETCD는 파드로 설치되어 데몬으로 설치되어있는 환경과는 ..

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..