이 이야기는 프로덕션 환경, 특히 Kubernetes에서 컨테이너를 사용하는 방법에 관한 것입니다. 이 기사는 컨테이너에서 지표와 로그를 수집하고 이미지를 구축하는 데 중점을 두고 있습니다.

우리는 온라인 거래 서비스와 B2B 및 B2C용 핀테크 제품을 개발하는 핀테크 기업 Exness 출신입니다. 우리의 R&D에는 다양한 팀이 있으며, 개발 부서에는 100명 이상의 직원이 있습니다.

우리는 개발자가 코드를 수집하고 실행할 수 있는 플랫폼을 담당하는 팀을 대표합니다. 특히, 우리는 애플리케이션에서 지표, 로그 및 이벤트를 수집, 저장 및 보고하는 일을 담당합니다. 우리는 현재 프로덕션 환경에서 약 50개의 Docker 컨테이너를 운영하고, XNUMXTB 빅 데이터 스토리지를 유지 관리하며, Kubernetes, Rancher 및 다양한 퍼블릭 클라우드 공급자 등 인프라를 기반으로 구축된 아키텍처 솔루션을 제공합니다. 

우리의 동기

무엇이 불타고 있나요? 아무도 대답할 수 없습니다. 난로는 어디에 있나요? 이해하기 어렵습니다. 언제 불이 붙었나요? 알아낼 수는 있지만 당장은 아닙니다. 

왜 일부 컨테이너는 서 있고 다른 컨테이너는 떨어졌습니까? 어떤 컨테이너가 책임이 있습니까? 결국 컨테이너의 외부는 동일하지만 내부에는 각각 고유한 Neo가 있습니다.

우리 개발자들은 유능한 사람들입니다. 그들은 회사에 이익을 가져다주는 좋은 서비스를 만듭니다. 그러나 애플리케이션이 포함된 컨테이너가 잘못된 경우 오류가 발생합니다. 한 컨테이너는 CPU를 너무 많이 소비하고, 다른 컨테이너는 네트워크를 소비하고, 세 번째 컨테이너는 I/O 작업을 소비하고, 네 번째 컨테이너는 소켓으로 무엇을 하는지 완전히 불분명합니다. 모든 것이 무너지고 배는 가라앉는다. 

자치령 대표

내부에서 무슨 일이 일어나고 있는지 이해하기 위해 에이전트를 컨테이너에 직접 배치하기로 결정했습니다.

이들 물질은 용기가 서로 깨지지 않는 상태로 유지되도록 하는 제지 프로그램입니다. 에이전트는 표준화되어 있으므로 컨테이너 서비스에 대한 표준화된 접근 방식이 가능합니다. 

우리의 경우 에이전트는 태그가 지정되고 제한되는 표준 형식으로 로그를 제공해야 합니다. 또한 비즈니스 애플리케이션 관점에서 확장 가능한 표준화된 지표를 제공해야 합니다.

에이전트는 또한 다양한 이미지(Debian, Alpine, Centos 등)를 지원하는 다양한 오케스트레이션 시스템에서 작동할 수 있는 운영 및 유지 관리용 유틸리티를 의미합니다.

마지막으로 에이전트는 Docker 파일이 포함된 간단한 CI/CD를 지원해야 합니다. 그렇지 않으면 컨테이너가 "비뚤어진" 레일을 따라 배송되기 시작하기 때문에 선박이 무너질 것입니다.

빌드 프로세스 및 대상 이미지 장치

모든 것을 표준화하고 관리 가능하게 유지하려면 일종의 표준 빌드 프로세스를 따라야 합니다. 따라서 우리는 컨테이너별로 컨테이너를 수집하기로 결정했습니다. 이것이 재귀입니다.

여기서 컨테이너는 실선으로 표시됩니다. 동시에 그들은 "인생이 산딸기처럼 보이지 않도록"배포 키트를 넣기로 결정했습니다. 왜 그렇게 되었는지 아래에서 설명하겠습니다.
 
그 결과는 특정 배포 버전과 특정 스크립트 버전을 참조하는 버전별 컨테이너인 빌드 도구입니다.

어떻게 사용하나요? 컨테이너가 포함된 Docker Hub가 있습니다. 외부 종속성을 제거하기 위해 시스템 내부에 이를 미러링합니다. 결과는 노란색으로 표시된 컨테이너입니다. 필요한 모든 배포판과 스크립트를 컨테이너에 설치하기 위한 템플릿을 만듭니다. 그런 다음 바로 사용할 수 있는 이미지를 조립합니다. 개발자는 코드와 자신의 특별한 종속성을 여기에 넣습니다. 

이 접근 방식의 좋은 점은 무엇입니까? 

• 첫째, 빌드 도구(빌드 컨테이너, 스크립트 및 배포 버전)의 전체 버전 제어입니다. 
• 둘째, 표준화를 달성했습니다. 동일한 방식으로 템플릿, 중간 및 즉시 사용 가능한 이미지를 생성합니다. 
• 셋째, 컨테이너는 이식성을 제공합니다. 오늘은 Gitlab을 사용하고 내일은 TeamCity 또는 Jenkins로 전환하여 동일한 방식으로 컨테이너를 실행할 수 있습니다. 
• 넷째, 의존성을 최소화합니다. 배포 키트를 컨테이너에 넣은 것은 우연이 아닙니다. 이렇게 하면 매번 인터넷에서 배포 키트를 다운로드하지 않아도 되기 때문입니다. 
• 다섯째, 빌드 속도가 향상되었습니다. 이미지의 로컬 복사본이 있으면 로컬 이미지가 있으므로 다운로드에 시간을 낭비하지 않아도 됩니다. 

즉, 우리는 제어되고 유연한 조립 프로세스를 달성했습니다. 우리는 동일한 도구를 사용하여 완전히 버전화된 컨테이너를 구축합니다. 

빌드 절차의 작동 방식

하나의 명령으로 어셈블리가 시작되고 프로세스가 이미지에서 실행됩니다(빨간색으로 강조 표시됨). 개발자는 Docker 파일(노란색으로 강조 표시됨)을 가지고 있으며 이를 렌더링하여 변수를 값으로 바꿉니다. 그리고 그 과정에서 머리글과 바닥글을 추가합니다. 이것이 에이전트입니다. 

헤더는 해당 이미지의 분포를 추가합니다. 바닥글은 내부에 서비스를 설치하고, 워크로드 시작, 로깅 및 기타 에이전트를 구성하고, 진입점을 대체하는 등의 작업을 수행합니다. 

우리는 슈퍼바이저를 설치할 것인지 오랫동안 고민했습니다. 결국 우리는 그가 필요하다고 결정했습니다. 우리는 S6를 선택했습니다. 감독자는 컨테이너 관리 기능을 제공합니다. 기본 프로세스가 충돌하는 경우 컨테이너에 연결할 수 있도록 하고 컨테이너를 다시 만들지 않고도 수동 관리를 제공합니다. 로그와 지표는 컨테이너 내부에서 실행되는 프로세스입니다. 또한 어떻게든 통제해야 하며, 감독자의 도움을 받아 이를 수행합니다. 마지막으로 S6는 하우스키핑, 신호 처리 및 기타 작업을 처리합니다.

서로 다른 오케스트레이션 시스템을 사용하기 때문에 컨테이너를 구축하고 실행한 후에는 컨테이너가 어떤 환경에 있는지 이해하고 상황에 따라 행동해야 합니다. 예를 들어:
이를 통해 하나의 이미지를 구축하고 이를 다양한 오케스트레이션 시스템에서 실행할 수 있으며, 이 오케스트레이션 시스템의 세부 사항을 고려하여 실행됩니다.

 

동일한 컨테이너에 대해 Docker와 Kubernetes에서는 서로 다른 프로세스 트리를 얻습니다.

페이로드는 S6의 감독하에 실행됩니다. 수집기와 이벤트에 주의하세요. 이들은 로그와 측정항목을 담당하는 에이전트입니다. Kubernetes에는 없지만 Docker에는 있습니다. 왜? 

포드(이하 쿠버네티스 포드)의 사양을 살펴보면 이벤트 컨테이너가 포드에서 실행되는 것을 볼 수 있는데, 포드에는 메트릭과 로그를 수집하는 기능을 수행하는 별도의 컬렉터 컨테이너가 있다. Kubernetes의 기능을 사용하여 단일 프로세스 및/또는 네트워크 공간의 하나의 포드에서 컨테이너를 실행할 수 있습니다. 실제로 에이전트를 소개하고 일부 기능을 수행합니다. 그리고 동일한 컨테이너가 Docker에서 시작되면 출력과 동일한 기능을 모두 받게 됩니다. 즉, 에이전트가 내부적으로 시작되므로 로그와 메트릭을 전달할 수 있습니다. 

측정항목 및 로그

지표와 로그를 전달하는 것은 복잡한 작업입니다. 그녀의 결정에는 몇 가지 측면이 있습니다.
인프라는 로그 대량 전달이 아닌 페이로드 실행을 위해 생성됩니다. 즉, 이 프로세스는 최소한의 컨테이너 리소스 요구 사항으로 수행되어야 합니다. 우리는 개발자를 돕기 위해 노력하고 있습니다. "Docker Hub 컨테이너를 구입하여 실행하면 로그를 전달할 수 있습니다." 

두 번째 측면은 로그의 양을 제한하는 것입니다. 여러 컨테이너에서 로그 볼륨의 급증이 발생하면(애플리케이션이 루프로 스택 추적을 출력함) CPU, 통신 채널, 로그 처리 시스템의 부하가 증가하고 이는 호스트의 운영에 영향을 미칩니다. 전체 및 기타 컨테이너가 호스트에 있는 경우 때로는 이로 인해 호스트가 "떨어지게" 됩니다. 

세 번째 측면은 기본적으로 가능한 한 많은 메트릭 수집 방법을 지원해야 한다는 것입니다. 파일 읽기 및 Prometheus 엔드포인트 폴링부터 애플리케이션별 프로토콜 사용까지.

마지막 측면은 자원 소비를 최소화하는 것입니다.

우리는 Telegraf라는 오픈 소스 Go 솔루션을 선택했습니다. 140가지 이상의 입력 채널(입력 플러그인)과 30가지 이상의 출력 채널(출력 플러그인)을 지원하는 범용 커넥터입니다. 우리는 그것을 마무리했으며 이제 Kubernetes를 예로 들어 어떻게 사용하는지 알려 드리겠습니다. 

개발자가 워크로드를 배포하고 Kubernetes가 포드 생성 요청을 받았다고 가정해 보겠습니다. 이 시점에서 각 Pod마다 Collector라는 컨테이너가 자동으로 생성됩니다(우리는 mutation webhook을 사용합니다). 수집가는 우리의 대리인입니다. 처음에 이 컨테이너는 Prometheus 및 로그 수집 시스템과 작동하도록 자체 구성됩니다.

• 이를 위해 Pod 주석을 사용하고 해당 콘텐츠에 따라 Prometheus 엔드포인트를 생성합니다. 
• 포드 사양 및 특정 컨테이너 설정에 따라 로그 전달 방법을 결정합니다.

우리는 Docker API를 통해 로그를 수집합니다. 개발자는 로그를 stdout 또는 stderr에 넣기만 하면 Collector가 이를 정렬합니다. 호스트 과부하 가능성을 방지하기 위해 로그는 약간의 지연을 거쳐 청크로 수집됩니다. 

지표는 컨테이너의 워크로드 인스턴스(프로세스) 전체에서 수집됩니다. 네임스페이스, 언더 등 모든 항목에 태그가 지정되고 Prometheus 형식으로 변환되어 수집이 가능해집니다(로그 제외). 또한 로그, 지표, 이벤트를 Kafka 등에 전송합니다.

• 로그는 Graylog(시각적 분석용)에서 사용할 수 있습니다.
• 로그, 지표, 이벤트는 장기 보관을 위해 Clickhouse로 전송됩니다.

AWS에서는 모든 것이 정확히 동일하게 작동합니다. 단지 Graylog를 Kafka로 Cloudwatch로 대체합니다. 로그를 거기로 보내면 모든 것이 매우 편리해졌습니다. 어떤 클러스터와 컨테이너에 속하는지 즉시 알 수 있습니다. Google Stackdriver도 마찬가지입니다. 즉, 우리 계획은 Kafka를 사용하여 온프레미스 및 클라우드 모두에서 작동합니다. 

포드가 포함된 Kubernetes가 없으면 구성은 조금 더 복잡하지만 동일한 원칙에 따라 작동합니다.

동일한 프로세스가 컨테이너 내부에서 실행되며 S6을 사용하여 조정됩니다. 동일한 프로세스가 모두 동일한 컨테이너 내에서 실행됩니다.

그 결과,

우리는 로그와 지표를 수집하고 전달하기 위한 옵션을 포함하여 이미지 구축 및 실행을 위한 완벽한 솔루션을 만들었습니다.

• 우리는 이미지 조합에 대한 표준화된 접근 방식을 개발했으며 이를 기반으로 CI 템플릿을 개발했습니다.
• 데이터 수집 에이전트는 Telegraf 확장입니다. 우리는 프로덕션 환경에서 이를 잘 테스트했습니다.
• 우리는 Pod에 에이전트가 포함된 컨테이너를 구현하기 위해 Mutation Webhook를 사용합니다. 
• Kubernetes/Rancher 생태계에 통합되었습니다.
• 다양한 오케스트레이션 시스템에서 동일한 컨테이너를 실행하고 기대하는 결과를 얻을 수 있습니다.
• 완전히 동적인 컨테이너 관리 구성을 만들었습니다. 

공저자: 일리아 프루드니코프

출처 : habr.com