안녕하세요 여러분! 제 이름은 파벨 아갈레츠키입니다. 저는 Lamoda 배송 시스템을 개발하는 팀에서 팀장으로 일하고 있습니다. 2018년에 저는 HighLoad++ 컨퍼런스에서 연설을 했고, 오늘은 제 보고서의 녹취록을 발표하고 싶습니다.

제 주제는 다양한 환경에 시스템과 서비스를 배포한 우리 회사의 경험에 관한 것입니다. 모든 시스템을 일반 가상 서버에 배포했던 선사 시대부터 시작하여 Nomad에서 Kubernetes 배포로 점진적으로 전환되었습니다. 왜 그렇게 했는지, 그 과정에서 어떤 문제가 있었는지 말씀드리겠습니다.

VM에 애플리케이션 배포

3년 전 회사의 모든 시스템과 서비스가 일반 가상 서버에 배포되었다는 사실부터 시작해 보겠습니다. 기술적으로는 젠킨스를 사용하여 자동 조립 도구를 사용하여 시스템의 모든 코드를 저장하고 조립하는 방식으로 구성되었습니다. Ansible을 사용하여 버전 제어 시스템에서 가상 서버로 출시되었습니다. 또한 우리 회사의 각 시스템은 최소 2개의 서버에 배포되었습니다. 그 중 하나는 헤드에, 다른 하나는 테일에 배치되었습니다. 이 두 시스템은 모든 설정, 전원, 구성 등이 완전히 동일했습니다. 이들 사이의 유일한 차이점은 Head가 사용자 트래픽을 수신하는 반면 Tail은 사용자 트래픽을 수신하지 않는다는 것입니다.

그것은 무엇을 위해 행해졌습니까?

우리는 애플리케이션의 새로운 릴리스를 배포할 때 원활한 롤아웃, 즉 사용자에게 눈에 띄는 결과가 발생하지 않도록 하고 싶었습니다. 이는 Ansible을 사용하여 다음 컴파일된 릴리스가 최종 출시되었기 때문에 달성되었습니다. 그곳에서 배포에 참여한 사람들은 모든 것이 정상인지 확인하고 확인할 수 있었습니다. 모든 지표, 섹션 및 애플리케이션이 작동하고 있었습니다. 필요한 스크립트가 시작됩니다. 모든 것이 괜찮다고 확신한 후에야 트래픽이 전환되었습니다. 이전에 tail이었던 서버로 이동하기 시작했습니다. 그리고 이전에 헤드였던 항목은 사용자 트래픽 없이 그대로 유지되었으며 이전 버전의 애플리케이션이 여전히 남아 있습니다.

그래서 사용자에게는 원활했습니다. 스위칭은 즉각적이기 때문에 단순히 밸런서를 스위칭하는 것이기 때문입니다. 간단히 밸런서를 다시 전환하면 이전 버전으로 매우 쉽게 롤백할 수 있습니다. 또한 사용자 트래픽을 수신하기 전에도 애플리케이션이 생산 가능하다는 것을 확인할 수 있어 매우 편리했습니다.

이 모든 것에서 우리는 어떤 이점을 보았습니까?

1. 우선은 충분해요 그냥 작동합니다. 대부분의 사람들이 일반 가상 서버에 배포한 적이 있기 때문에 이러한 배포 체계가 어떻게 작동하는지 모두가 이해합니다.
2. 이것으로 충분하다 확실하게, 배포 기술이 간단하기 때문에 수천 개의 회사에서 테스트를 거쳤습니다. 수백만 대의 서버가 이러한 방식으로 배포됩니다. 무언가를 깨는 것은 어렵습니다.
3. 그리고 마침내 우리는 얻을 수 있었습니다 원자적 배포. 이전 버전과 새 버전 사이를 전환하는 눈에 띄는 단계 없이 사용자에게 동시에 발생하는 배포입니다.

그러나 우리는 이 모든 것에서 몇 가지 단점도 발견했습니다.

1. 프로덕션 환경, 개발 환경 외에도 다른 환경이 있습니다. 예를 들어 QA 및 사전 제작이 있습니다. 그 당시 우리는 많은 서버와 약 60개의 서비스를 보유하고 있었습니다. 이런 이유로 필요했습니다. 각 서비스에 대해 최신 버전을 유지합니다. 가상 기기. 또한 라이브러리를 업데이트하거나 새 종속성을 설치하려면 모든 환경에서 이 작업을 수행해야 합니다. 또한 애플리케이션의 다음 새 버전을 배포할 시간과 devops가 필요한 환경 설정을 수행하는 시간을 동기화해야 했습니다. 이 경우 모든 환경에서 우리의 환경이 한꺼번에 다소 달라지는 상황에 빠지기 쉽습니다. 예를 들어, QA 환경에는 일부 버전의 라이브러리가 있고 프로덕션 환경에는 다른 버전이 있어 문제가 발생할 수 있습니다.
2. 종속성을 업데이트하는 데 어려움이 있음 너의 어플리케이션. 그것은 당신에게 달려 있는 것이 아니라 다른 팀에 달려 있습니다. 즉, 서버를 유지 관리하는 DevOps 팀에서. 당신은 그들에게 적절한 작업과 당신이 하고 싶은 일에 대한 설명을 제공해야 합니다.
3. 그 당시 우리는 또한 우리가 가지고 있던 크고 큰 단일체를 별도의 작은 서비스로 나누고 싶었습니다. 그 이유는 서비스가 점점 더 많아질 것이라는 점을 이해했기 때문입니다. 당시 우리는 이미 100개 이상의 서비스를 보유하고 있었고, 새로운 서비스마다 별도의 새로운 가상 머신을 생성해야 했으며, 이를 유지 관리하고 배포해야 했습니다. 또한 자동차 한 대가 아니라 최소한 두 대가 필요합니다. 여기에 QA 환경이 추가되었습니다. 이로 인해 문제가 발생하고 새로운 시스템을 구축하고 실행하기가 더 어려워집니다. 복잡하고 비용이 많이 들고 시간이 오래 걸리는 프로세스.

따라서 우리는 일반 가상 머신 배포에서 Docker 컨테이너에 애플리케이션 배포로 이동하는 것이 더 편리할 것이라고 결정했습니다. Docker가 있으면 컨테이너만 키울 수는 없으므로 클러스터에서 애플리케이션을 실행할 수 있는 시스템이 필요합니다. 일반적으로 들어 올려지는 컨테이너 수를 추적하여 자동으로 들어 올려지기를 원합니다. 이러한 이유로 우리는 제어 시스템을 선택해야 했습니다.

우리는 어느 것을 택할 수 있는지 오랫동안 생각했습니다. 사실 그 당시 일반 가상 서버의 이 배포 스택은 최신 버전의 운영 체제가 없었기 때문에 다소 구식이었습니다. 어느 시점에는 지원하기가 그리 편리하지 않은 FreeBSD도 있었습니다. 우리는 가능한 한 빨리 Docker로 마이그레이션해야 한다는 것을 이해했습니다. 우리 데브옵스는 다양한 솔루션에 대한 기존 경험을 살펴보고 Nomad와 같은 시스템을 선택했습니다.

노마드로 전환

Nomad는 HashiCorp의 제품입니다. 그들은 또한 다른 솔루션으로도 알려져 있습니다:

"영사" 서비스 검색을 위한 도구입니다.

"테라폼" - 소위 코드형 인프라라고 불리는 구성을 통해 서버를 구성할 수 있는 서버 관리 시스템입니다.

"방랑자" 특정 구성 파일을 통해 로컬 또는 클라우드에 가상 머신을 배포할 수 있습니다.

당시 Nomad는 전체 인프라를 변경하지 않고도 빠르게 전환할 수 있는 상당히 간단한 솔루션처럼 보였습니다. 게다가 배우기도 매우 쉽습니다. 이것이 바로 우리가 컨테이너의 여과 시스템으로 이를 선택한 이유입니다.

Nomad에 시스템을 배포하려면 무엇이 필요합니까?

1. 우선 당신에게 필요한 것은 도커 이미지 너의 어플리케이션. 이를 빌드하고 docker 이미지 저장소에 배치해야 합니다. 우리의 경우 이것은 다양한 유형의 다양한 아티팩트를 푸시할 수 있는 시스템인 아티팩트입니다. 아카이브, 도커 이미지, Composer PHP 패키지, NPM 패키지 등을 저장할 수 있습니다.
2. 또한 필요 구성 파일, 이는 Nomad에게 무엇을, 어디에, 어느 정도 배포하려는지 알려줄 것입니다.

Nomad에 대해 이야기할 때 Nomad는 정보 파일 형식으로 HCL 언어를 사용합니다. HashiCorp 구성 언어. 이는 Nomad 용어로 서비스를 설명할 수 있는 Yaml의 상위 집합입니다.

이를 통해 배포할 컨테이너 수, 배포 중에 어떤 이미지에서 다양한 매개변수를 전달할지 말할 수 있습니다. 따라서 이 파일을 Nomad에 제공하면 Nomad는 이에 따라 컨테이너를 프로덕션으로 시작합니다.

우리의 경우, 단순히 각 서비스에 대해 완전히 동일한 HCL 파일을 작성하는 것은 그리 편리하지 않다는 것을 깨달았습니다. 서비스가 많고 때로는 이를 업데이트하고 싶기 때문입니다. 하나의 서비스가 하나의 인스턴스가 아닌 다양한 인스턴스에 배포되는 경우가 있습니다. 예를 들어, 프로덕션 환경에 있는 시스템 중 하나에는 프로덕션 인스턴스가 100개가 넘습니다. 동일한 이미지에서 실행되지만 구성 설정과 구성 파일이 다릅니다.

따라서 우리는 배포할 모든 구성 파일을 하나의 공통 저장소에 저장하는 것이 편리하다고 결정했습니다. 이런 방식으로 시스템을 볼 수 있었습니다. 유지 관리가 쉬웠고 우리가 어떤 시스템을 보유하고 있는지 확인할 수 있었습니다. 필요한 경우 무언가를 업데이트하거나 변경하는 것도 쉽습니다. 새 시스템을 추가하는 것도 어렵지 않습니다. 새 디렉터리 내에 구성 파일을 생성하기만 하면 됩니다. 그 안에는 서비스에 대한 설명이 포함된 service.hcl과 프로덕션에 배포되는 바로 이 서비스를 구성할 수 있는 일부 env 파일이 있습니다.

그러나 일부 시스템은 하나의 복사본이 아닌 동시에 여러 복사본으로 프로덕션 환경에 배포됩니다. 따라서 우리는 구성을 순수한 형식이 아닌 템플릿 형식으로 저장하는 것이 편리하다고 결정했습니다. 그리고 우리는 선택했다 진자 2. 이 형식에서는 서비스 자체의 구성과 서비스에 필요한 env 파일을 모두 저장합니다.

또한 모든 프로젝트에 공통적인 배포 스크립트를 저장소에 배치했습니다. 이를 통해 서비스를 프로덕션, 원하는 환경, 원하는 대상으로 시작하고 배포할 수 있습니다. HCL 구성을 템플릿으로 전환한 경우 이전에는 일반 Nomad 구성이었던 HCL 파일이 이 경우 약간 다르게 보이기 시작했습니다.

즉, 일부 구성 위치 변수를 env 파일이나 다른 소스에서 가져온 삽입된 변수로 대체했습니다. 또한 HCL 파일을 동적으로 수집할 수 있는 기회도 얻었습니다. 즉, 일반적인 변수 삽입뿐만 아니라 사용할 수도 있습니다. jinja는 루프와 조건을 지원하므로 애플리케이션을 배포하는 위치에 따라 변경되는 구성 파일을 생성할 수도 있습니다.

예를 들어 사전 프로덕션 및 프로덕션에 서비스를 배포하려고 합니다. 사전 프로덕션에서 cron 스크립트를 실행하고 싶지 않고 서비스가 작동하는지 확인하기 위해 별도의 도메인에서 서비스를 보고 싶다고 가정해 보겠습니다. 서비스를 배포하는 모든 사람에게 프로세스는 매우 간단하고 투명해 보입니다. 여러분이 해야 할 일은 배포.sh 파일을 실행하고 배포하려는 서비스와 대상을 지정하는 것뿐입니다. 예를 들어 특정 시스템을 러시아, 벨로루시 또는 카자흐스탄에 배포하려고 합니다. 이렇게 하려면 매개변수 중 하나를 변경하기만 하면 올바른 구성 파일을 갖게 됩니다.

Nomad 서비스가 이미 클러스터에 배포된 경우 다음과 같습니다.

첫째, 모든 사용자 트래픽을 수신할 일종의 외부 밸런서가 필요합니다. Consul과 함께 작동하여 특정 도메인 이름에 해당하는 특정 서비스가 있는 위치, 노드, IP 주소를 알아냅니다. Consul의 서비스는 Nomad 자체에서 제공됩니다. 같은 회사의 제품이다 보니 서로 연관성이 꽤 깊습니다. Nomad는 즉시 사용 가능한 모든 서비스를 Consul 내부에 등록할 수 있다고 말할 수 있습니다.

프런트 엔드 로드 밸런서는 트래픽을 보낼 서비스를 알고 나면 해당 트래픽을 애플리케이션과 일치하는 적절한 컨테이너 또는 여러 컨테이너로 전달합니다. 당연히 안전에 대해서도 생각할 필요가 있습니다. 모든 서비스가 컨테이너의 동일한 가상 머신에서 실행되더라도 일반적으로 특정 서비스에서 다른 서비스로의 무료 액세스를 방지해야 합니다. 우리는 세분화를 통해 이를 달성했습니다. 각 서비스는 라우팅 규칙과 다른 시스템 및 서비스에 대한 액세스를 허용/거부하는 규칙이 규정된 자체 가상 네트워크에서 시작되었습니다. 이 클러스터 내부와 외부 모두에 위치할 수 있습니다. 예를 들어, 서비스가 특정 데이터베이스에 연결되는 것을 방지하려는 경우 네트워크 수준 분할을 통해 이를 수행할 수 있습니다. 즉, 실수로 테스트 환경에서 프로덕션 데이터베이스로 실수로 연결할 수 없습니다.

전환으로 인해 인적 자원 측면에서 비용이 얼마나 들었나요?

회사 전체를 Nomad로 전환하는 데는 약 5~6개월이 걸렸습니다. 우리는 서비스별로 진행했지만 상당히 빠른 속도로 진행했습니다. 각 팀은 서비스를 위한 자체 컨테이너를 만들어야 했습니다.

우리는 각 팀이 독립적으로 시스템의 도커 이미지를 책임지는 접근 방식을 채택했습니다. DevOps는 배포에 필요한 일반적인 인프라, 즉 클러스터 자체에 대한 지원, CI 시스템에 대한 지원 등을 제공합니다. 그리고 당시 우리는 60개 이상의 시스템을 Nomad로 이전했는데, 이는 약 2개의 컨테이너에 해당합니다.

Devops는 배포 및 서버와 관련된 모든 것의 일반적인 인프라를 담당합니다. 그리고 각 개발 팀은 특정 컨테이너에 일반적으로 필요한 것이 무엇인지 알고 있는 팀이기 때문에 특정 시스템에 대한 컨테이너 구현을 담당합니다.

노마드를 포기한 이유

Nomad, docker 등을 사용하여 배포로 전환함으로써 어떤 이점을 얻었습니까?

1. 우리 동등한 조건을 제공 모든 환경에 적합합니다. 개발, QA 환경, 사전 프로덕션, 프로덕션에서는 동일한 종속성과 동일한 컨테이너 이미지가 사용됩니다. 따라서 실제로 프로덕션 환경에서 결과가 이전에 로컬 또는 테스트 환경에서 테스트한 내용과 다를 가능성은 거의 없습니다.
2. 우리는 또한 그것이 충분하다는 것을 발견했습니다 새로운 서비스를 추가하기 쉽다. 배포 관점에서 볼 때 모든 새 시스템은 매우 간단하게 시작됩니다. 구성을 저장하는 저장소로 이동하여 시스템에 대한 다른 구성을 추가하면 모든 설정이 완료됩니다. DevOps의 추가 노력 없이 시스템을 프로덕션에 배포할 수 있습니다.
3. 모든 구성 파일 하나의 공통 저장소에 검토중인 것으로 밝혀졌습니다. 가상 서버를 사용하여 시스템을 배포할 당시에는 구성이 동일한 저장소에 있는 Ansible을 사용했습니다. 그러나 대부분의 개발자에게는 이 작업이 조금 더 어려웠습니다. 여기서 서비스 배포를 위해 추가해야 하는 구성 및 코드의 양이 훨씬 작아졌습니다. 게다가 개발자가 이를 수정하거나 변경하는 것도 매우 쉽습니다. 예를 들어 Nomad의 새 버전으로 전환하는 경우 동일한 위치에 있는 모든 운영 파일을 가져와 대량 업데이트할 수 있습니다.

그러나 우리는 또한 몇 가지 단점에 직면했습니다:

우리는 원활한 배포를 달성할 수 없었습니다. 노마드의 경우. 다양한 조건에서 컨테이너를 출시하면 실행 중인 것으로 판명될 수 있으며 Nomad는 이를 트래픽을 수신할 준비가 된 컨테이너로 인식했습니다. 이는 내부 애플리케이션이 시작되기도 전에 발생했습니다. 이러한 이유로 아직 트래픽을 받아들일 준비가 되지 않은 컨테이너로 트래픽이 이동하기 시작했기 때문에 시스템에서는 짧은 시간 동안 500개의 오류가 발생하기 시작했습니다.

우리는 몇몇을 만났습니다. 습지에 의해. 가장 심각한 버그는 시스템과 컨테이너가 많은 경우 Nomad가 대규모 클러스터를 잘 처리하지 못한다는 것입니다. Nomad 클러스터에 포함된 서버 중 하나를 유지 관리를 위해 꺼내려고 할 때 클러스터가 별로 좋지 않아 무너질 가능성이 상당히 높습니다. 예를 들어, 일부 컨테이너는 떨어지지만 올라가지 않을 수 있습니다. 모든 프로덕션 시스템이 Nomad가 관리하는 클러스터에 있는 경우 나중에 비용이 많이 듭니다.

그래서 우리는 다음에 어디로 가야할지 생각해보기로 결정했습니다. 그 시점에서 우리는 우리가 달성하고자 하는 것이 무엇인지 훨씬 더 잘 알게 되었습니다. 즉, 우리는 신뢰성, Nomad가 제공하는 것보다 조금 더 많은 기능, 더 성숙하고 안정적인 시스템을 원합니다.

이러한 점에서 우리는 클러스터 출시를 위한 가장 인기 있는 플랫폼으로 Kubernetes를 선택했습니다. 특히 컨테이너의 크기와 개수가 충분히 컸다는 점을 고려하면 더욱 그렇습니다. 그런 목적으로 볼 때 쿠버네티스가 가장 적합한 시스템인 것 같았습니다.

쿠버네티스로 전환

Kubernetes의 기본 개념과 Nomad와의 차이점에 대해 조금 말씀 드리겠습니다.

우선 쿠버네티스의 가장 기본적인 개념은 포드(Pod) 개념이다. 작은 무리 항상 함께 실행되는 하나 이상의 컨테이너 그룹입니다. 그리고 항상 하나의 가상 머신에서만 작동하는 것처럼 작동합니다. 서로 다른 포트에서 IP 127.0.0.1을 통해 서로 액세스할 수 있습니다.

nginx와 php-fpm(클래식 구성표)으로 구성된 PHP 애플리케이션이 있다고 가정해 보겠습니다. 아마도 nginx와 php-fpm 컨테이너를 항상 함께 유지하고 싶을 것입니다. Kubernetes를 사용하면 이를 하나의 공통 포드로 설명하여 이를 달성할 수 있습니다. 이것이 바로 우리가 Nomad에서는 얻을 수 없었던 것입니다.

두 번째 컨셉은 전개. 사실 포드 자체는 일시적인 것이며 시작되고 사라집니다. 이전 컨테이너를 모두 종료한 후 새 버전을 한 번에 시작하시겠습니까, 아니면 점진적으로 출시하시겠습니까?이것이 배포 개념이 담당하는 프로세스입니다. 포드를 배포하는 방법, 수량, 업데이트 방법에 대해 설명합니다.

세 번째 컨셉은 서비스. 귀하의 서비스는 실제로 일부 트래픽을 수신한 다음 이를 귀하의 서비스에 해당하는 하나 이상의 Pod로 전달하는 시스템입니다. 즉, 이러한 이름을 가진 해당 서비스로 들어오는 모든 트래픽이 이러한 특정 포드로 전송되어야 한다고 말할 수 있습니다. 동시에 트래픽 균형도 제공합니다. 즉, 애플리케이션의 두 개의 포드를 시작할 수 있으며 모든 수신 트래픽은 이 서비스와 관련된 포드 간에 균등하게 균형을 이룹니다.

그리고 네 번째 기본 개념은 입구. 이는 Kubernetes 클러스터에서 실행되는 서비스입니다. 모든 요청을 인계받는 외부 로드 밸런서 역할을 합니다. Ingress는 Kubernetes API를 사용하여 이러한 요청을 어디로 보내야 하는지 결정할 수 있습니다. 게다가 그는 이 일을 매우 유연하게 해낸다. 이 호스트 등에 대한 모든 요청과 그러한 URL이 이 서비스로 전송된다고 말할 수 있습니다. 그리고 이 호스트와 다른 URL로 들어오는 요청은 다른 서비스로 전송됩니다.

애플리케이션을 개발하는 사람의 관점에서 볼 때 가장 멋진 점은 모든 것을 스스로 관리할 수 있다는 것입니다. Ingress 구성을 설정하면 이러한 API로 들어오는 모든 트래픽을 예를 들어 Go로 작성된 별도의 컨테이너로 보낼 수 있습니다. 그러나 동일한 도메인이지만 다른 URL로 오는 이 트래픽은 논리가 많지만 속도가 그리 빠르지 않은 PHP로 작성된 컨테이너로 전송되어야 합니다.

이 모든 개념을 노마드와 비교해 보면 처음 세 가지 개념이 모두 합쳐져 서비스라고 할 수 있습니다. 그리고 Nomad 자체에는 마지막 개념이 없습니다. 우리는 외부 밸런서를 그대로 사용했습니다. haproxy, nginx, nginx+ 등이 될 수 있습니다. 큐브의 경우에는 이 추가 개념을 별도로 소개할 필요가 없습니다. 하지만 내부적으로 Ingress를 살펴보면 nginx, haproxy 또는 traefik 중 하나이지만 일종의 Kubernetes에 내장되어 있습니다.

제가 설명한 모든 개념은 실제로 Kubernetes 클러스터 내에 존재하는 리소스입니다. 큐브에서 이를 설명하기 위해 Nomad의 경우 HCL 파일보다 읽기 쉽고 친숙한 yaml 형식이 사용됩니다. 그러나 구조적으로는 Pod와 같은 경우에도 동일한 내용을 설명합니다. 그들은 말합니다-저는 그러한 이미지와 함께 그러한 포드를 그러한 수량으로 배포하고 싶습니다.

또한 배포, 서비스, Ingress 등 개별 리소스를 각각 직접 생성하고 싶지 않다는 것을 깨달았습니다. 대신 배포 중에 Kubernetes 측면에서 각 시스템을 설명하여 필요한 모든 리소스 종속성을 올바른 순서로 수동으로 다시 생성할 필요가 없도록 하고 싶었습니다. 이를 가능하게 하는 시스템으로 Helm이 선택되었습니다.

Helm의 기본 개념

투구는 패키지 관리자 쿠버네티스용. 프로그래밍 언어의 패키지 관리자가 작동하는 방식과 매우 유사합니다. 예를 들어 nginx 배포, php-fpm 배포, Ingress 구성, configmaps(시스템에 env 및 기타 매개변수를 설정할 수 있는 엔터티)로 구성된 서비스를 다음과 같은 형식으로 저장할 수 있습니다. 차트라고 부른다. 동시에 헬름 Kubernetes 위에서 실행. 즉, 이것은 일종의 시스템이 아니라 큐브 내부에서 시작되는 또 다른 서비스입니다. 콘솔 명령을 통해 API를 통해 상호 작용합니다. Helm의 편리함과 아름다움은 Helm이 손상되거나 클러스터에서 제거하더라도 Helm은 본질적으로 시스템을 시작하는 역할만 하기 때문에 서비스가 사라지지 않는다는 것입니다. 그러면 Kubernetes 자체가 서비스 성능과 상태를 담당합니다.

우리는 또한 그것을 깨달았습니다. 템플릿화이전에 구성에 jinja를 도입하여 스스로 수행해야 했던 작업은 helm의 주요 기능 중 하나입니다. 시스템에 대해 생성한 모든 구성은 템플릿 형태로 helm에 저장됩니다. jinja와 약간 유사하지만 실제로는 Kubernetes와 같이 helm이 작성되는 Go 언어의 템플릿을 사용합니다.

Helm은 우리를 위해 몇 가지 개념을 더 추가합니다.

거래차트 - 귀하의 서비스에 대한 설명입니다. 다른 패키지 관리자에서는 이를 패키지, 번들 또는 이와 유사한 것으로 부릅니다. 여기서는 차트라고 합니다.

마케팅은: 템플릿에서 구성을 빌드하는 데 사용하려는 변수입니다.

해제. helm을 사용하여 배포된 서비스가 릴리스의 증분 버전을 받을 때마다. Helm은 이전 릴리스, 그 이전 릴리스 등의 서비스 구성을 기억합니다. 따라서 롤백이 필요한 경우 helm callback 명령을 실행하여 이전 릴리스 버전을 가리키면 됩니다. 롤백 시 저장소의 해당 구성을 사용할 수 없더라도 helm은 여전히 ​​그 구성을 기억하고 시스템을 이전 릴리스의 상태로 롤백합니다.

helm을 사용하는 경우 Kubernetes의 일반 구성도 변수, 함수를 사용하고 조건문을 적용할 수 있는 템플릿으로 전환됩니다. 이렇게 하면 환경에 따라 서비스 구성을 수집할 수 있습니다.

실제로 우리는 Nomad에서 했던 것과는 조금 다르게 일을 하기로 결정했습니다. Nomad에서 서비스를 배포하는 데 필요한 배포 구성과 n-변수가 모두 하나의 저장소에 저장되어 있는 경우 여기서는 이를 두 개의 별도 저장소로 나누기로 결정했습니다. "배포" 저장소는 배포에 필요한 n-변수만 저장하고 "헬름" 저장소는 구성 또는 차트를 저장합니다.

이것이 우리에게 무엇을 주었나요?

구성 파일 자체에는 실제로 민감한 데이터를 저장하지 않는다는 사실에도 불구하고. 예를 들어 데이터베이스에 대한 비밀번호입니다. Kubernetes에는 비밀로 저장되지만, 그럼에도 불구하고 모든 사람에게 액세스 권한을 부여하고 싶지 않은 특정 사항이 여전히 있습니다. 따라서 "배포" 저장소에 대한 액세스가 더 제한되며 "helm" 저장소에는 서비스에 대한 설명만 포함됩니다. 그렇기 때문에 더 많은 사람들이 안전하게 접근할 수 있습니다.

프로덕션 환경뿐만 아니라 다른 환경도 있으므로 이러한 분리 덕분에 헬름 차트를 재사용하여 프로덕션뿐만 아니라 QA 환경에도 서비스를 배포할 수 있습니다. 다음을 사용하여 로컬로 배포하는 경우에도 미니쿠베 - 이는 Kubernetes를 로컬에서 실행하기 위한 것입니다.

각 저장소 내부에는 각 서비스에 대해 별도의 디렉터리로 구분을 두었습니다. 즉, 각 디렉토리 내부에는 해당 차트와 관련된 템플릿이 있으며 시스템을 실행하기 위해 배포해야 하는 리소스를 설명합니다. "배포" 저장소에는 환경만 남겨두었습니다. 이 경우, helm 자체가 기본적으로 템플릿을 제공하기 때문에 jinja를 사용한 템플릿을 사용하지 않았습니다. 이것이 주요 기능 중 하나입니다.

helm을 사용하여 배포 시작을 단순화하고 표준화하는 배포 스크립트인 배포.sh를 남겼습니다. 따라서 배포를 원하는 사람이라면 누구나 배포 인터페이스가 Nomad를 통해 배포할 때와 똑같아 보입니다. 동일한 배포.sh, 서비스 이름, 배포하려는 위치. 이로 인해 Helm이 내부적으로 시작됩니다. 그런 다음 템플릿에서 구성을 수집하고 필요한 값 파일을 여기에 삽입한 다음 배포하여 Kubernetes에 실행합니다.

조사 결과

Kubernetes 서비스는 Nomad보다 더 복잡한 것으로 보입니다.

여기서 나가는 트래픽이 Ingress로 들어옵니다. 이는 모든 요청을 인계받아 요청 데이터에 해당하는 서비스로 보내는 전면 컨트롤러일 뿐입니다. Helm의 애플리케이션 설명에 포함된 구성과 개발자가 직접 설정한 구성을 기반으로 이를 결정합니다. 서비스는 해당 포드, 즉 특정 컨테이너에 요청을 보내 이 서비스에 속한 모든 컨테이너 간에 수신 트래픽의 균형을 조정합니다. 그리고 물론 우리는 네트워크 수준의 보안에서 벗어나서는 안 된다는 점을 잊어서는 안 됩니다. 따라서 세분화는 태그 지정을 기반으로 하는 Kubernetes 클러스터에서 작동합니다. 모든 서비스에는 클러스터 내부 또는 외부의 특정 외부/내부 리소스에 대한 서비스의 액세스 권한이 연결된 특정 태그가 있습니다.

전환을 진행하면서 우리는 Kubernetes가 이전에 사용했던 Nomad의 모든 기능을 갖추고 있고 새로운 기능도 많이 추가했다는 것을 확인했습니다. 플러그인을 통해 확장할 수 있으며 실제로는 사용자 정의 리소스 유형을 통해 확장할 수 있습니다. 즉, Kubernetes와 함께 제공되는 기능을 바로 사용할 수 있을 뿐만 아니라 리소스를 읽을 수 있는 고유한 리소스와 서비스를 만들 수 있는 기회가 있습니다. 이는 Kubernetes를 다시 설치하거나 수정하지 않고도 시스템을 확장할 수 있는 추가 옵션을 제공합니다.

이러한 사용의 예로는 Kubernetes 클러스터 내에서 실행되는 Prometheus가 있습니다. 특정 서비스에서 메트릭 수집을 시작하려면 서비스 설명에 서비스 모니터라는 리소스 유형을 추가해야 합니다. Prometheus는 Kubernetes에서 시작될 때 사용자 정의 리소스 유형을 읽을 수 있다는 사실로 인해 자동으로 새 시스템에서 지표 수집을 시작합니다. 꽤 편리합니다.

Kubernetes에 대한 첫 번째 배포는 2018년 3000월이었습니다. 그리고 이 기간 동안 우리는 그것에 대해 어떤 문제도 경험하지 않았습니다. 큰 버그 없이 아주 안정적으로 작동합니다. 게다가 더 확장할 수도 있습니다. 오늘날 우리는 충분한 기능을 보유하고 있으며 Kubernetes의 개발 속도를 정말 좋아합니다. 현재 Kubernetes에는 XNUMX개가 넘는 컨테이너가 있습니다. 클러스터는 여러 노드를 차지합니다. 동시에 서비스가 가능하고 안정적이며 제어가 용이합니다.

출처 : habr.com