스쿠터를 탄 소녀. 삽화 Freepik, Nomad 로고 하시 코프

Kubernetes는 컨테이너 오케스트레이션의 300파운드 고릴라입니다. 이는 세계 최대 규모의 컨테이너 시스템에서 작동하지만 비용이 많이 듭니다.

많은 지원 시간과 가파른 학습 곡선이 필요한 소규모 팀의 경우 특히 비용이 많이 듭니다. 이는 XNUMX명으로 구성된 우리 팀에게는 너무 많은 오버헤드입니다. 그래서 우리는 대안을 찾기 시작했고 사랑에 빠졌습니다. 유목민.

당신은 무엇을 원하나요

우리 팀은 Go로 작성된 지표에 대한 API 엔드포인트, Prometheus 내보내기, Logstash와 같은 로그 파서 등 다양한 일반적인 성능 모니터링 및 분석 서비스를 지원합니다. 골룸, InfluxDB 또는 Elasticsearch와 같은 데이터베이스도 있습니다. 이러한 각 서비스는 자체 컨테이너에서 실행됩니다. 이 모든 것을 계속 실행하려면 간단한 시스템이 필요합니다.

우리는 컨테이너 오케스트레이션에 대한 요구 사항 목록부터 시작했습니다.

• 많은 시스템에서 일련의 서비스를 실행합니다.
• 실행 중인 서비스 개요.
• 서비스 간 링크.
• 서비스가 중단되면 자동으로 다시 시작됩니다.
• 소규모 팀에 의한 인프라 유지 관리.

또한 다음 사항도 좋지만 필수 추가 사항은 아닙니다.

• 기능에 따라 시스템에 태그를 지정합니다(예: 과도한 I/O 서비스를 위해 빠른 디스크가 있는 시스템에 태그 지정).
• 오케스트레이터와 독립적으로 서비스를 실행하는 기능(예: 개발 중)
• 구성과 비밀을 공유하는 공통 장소입니다.
• 측정항목 및 로그의 끝점입니다.

Kubernetes가 우리에게 적합하지 않은 이유

Kubernetes로 프로토타입을 제작하면서 우리는 우리가 크게 의존하는 점점 더 복잡한 논리 계층을 추가하고 있음을 발견했습니다.

예를 들어 Kubernetes는 다음을 통해 기본 제공 서비스 구성을 지원합니다. 컨피그맵. 특히 여러 구성 파일을 병합하거나 포드에 추가 서비스를 추가할 때 혼란스러울 수 있습니다. 쿠버네티스(또는 지배 이 경우)을 사용하면 외부 구성을 동적으로 구현하여 문제를 분리할 수 있습니다. 그러나 이로 인해 프로젝트와 Kubernetes 간에 긴밀하고 숨겨진 결합이 발생합니다. 하지만 Helm과 ConfigMaps는 추가 옵션이므로 반드시 사용할 필요는 없습니다. 구성을 Docker 이미지에 복사하기만 하면 됩니다. 그러나 이 길을 따라가다가 나중에 후회할 수도 있는 불필요한 추상화를 구축하는 것은 유혹적입니다.

또한 Kubernetes 생태계는 빠르게 발전하고 있습니다. 모범 사례와 최신 도구를 최신 상태로 유지하려면 많은 시간과 에너지가 필요합니다. Kubectl, minikube, kubeadm, helm, Tiller, kops, oc - 목록은 계속해서 이어집니다. 시작할 때 이러한 도구가 모두 필요한 것은 아니지만 무엇이 필요할지 모르므로 모든 것을 알고 있어야 합니다. 이 때문에 학습 곡선이 상당히 가파르다.

Kubernetes를 사용해야 하는 경우

우리 회사에서는 많은 사람들이 Kubernetes를 사용하고 있으며 상당히 만족하고 있습니다. 이러한 인스턴스는 이를 지원하는 리소스를 보유한 Google 또는 Amazon에서 관리합니다.

쿠버네티스와 함께 제공되는 놀라운 기능, 대규모 컨테이너 오케스트레이션을 보다 쉽게 ​​관리할 수 있습니다.

• 상세한 권리 관리.
• 맞춤형 컨트롤러 클러스터에 로직을 추가합니다. 이는 단순히 Kubernetes API와 통신하는 프로그램입니다.
• 자동 확장! Kubernetes는 서비스 측정항목을 사용하여 수동 개입 없이 필요에 따라 서비스를 확장할 수 있습니다.

문제는 이러한 모든 기능이 실제로 필요한지 여부입니다. 추상화에만 의존할 수는 없습니다. 넌 내부에서 무슨 일이 일어나고 있는지 알아내야 할 거야.

우리 팀은 (주 인프라와의 긴밀한 연결로 인해) 대부분의 서비스를 원격으로 제공하므로 자체 Kubernetes 클러스터를 구축하고 싶지 않았습니다. 우리는 단지 서비스를 제공하고 싶었습니다.

배터리는 포함되어 있지 않습니다

Nomad는 필요한 것의 20%를 제공하는 오케스트레이션의 80%입니다. 수행하는 작업은 배포를 관리하는 것뿐입니다. Nomad는 배포를 관리하고 오류가 발생할 경우 컨테이너를 다시 시작합니다. 그게 전부입니다.

Nomad의 핵심은 그것이 하는 일입니다. 최소한의: 세분화된 권한 관리가 없거나 확장된 네트워크 정책, 이것은 특별히 설계되었습니다. 이러한 구성 요소는 외부에서 제공되거나 전혀 제공되지 않습니다.

Nomad는 사용 편의성과 유용성 사이에서 완벽한 절충안을 찾은 것 같습니다. 소규모의 독립적인 서비스에 적합합니다. 더 많은 제어가 필요하면 직접 키우거나 다른 접근 방식을 사용해야 합니다. 유목민은 막 오케스트레이터.

Nomad의 가장 좋은 점은 쉽다는 것입니다. 대체하다. 해당 기능은 서비스를 관리하는 다른 시스템에 쉽게 통합되므로 공급업체와의 연결은 사실상 없습니다. 클러스터의 모든 머신에서 일반 바이너리처럼 실행됩니다. 그게 전부입니다!

느슨하게 결합된 구성요소로 구성된 노마드 생태계

Nomad의 진정한 강점은 생태계입니다. 다음과 같은 다른 제품(완전히 선택 사항)과 매우 잘 통합됩니다. 영사 (키-값 저장소) 또는 둥근 천장 (비밀 처리). Nomad 파일에는 다음 서비스에서 데이터를 추출하기 위한 섹션이 있습니다.

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

여기서 우리는 핵심을 읽었습니다. service/geo-api/log-verbosity Consul에서 작업 중에 환경 변수에 노출합니다. LOG_LEVEL. 열쇠도 제시해 드립니다 secret/geo-api-key Vault에서 API_KEY. 간단하지만 강력합니다!

단순성으로 인해 Nomad는 API를 통해 다른 서비스로 쉽게 확장할 수 있습니다. 예를 들어 작업에 대한 태그가 지원됩니다. 우리는 측정항목으로 모든 서비스에 태그를 지정합니다. trv-metrics. 이런 방식으로 Prometheus는 Consul을 통해 이러한 서비스를 쉽게 찾고 엔드포인트를 주기적으로 확인할 수 있습니다. /metrics 새로운 데이터를 위해. 예를 들어 로그의 경우 다음을 사용하여 동일한 작업을 수행할 수 있습니다. 로키.

확장성의 다른 많은 예가 있습니다:

• 후크를 사용하여 Jenkins 작업을 실행하면 Consul은 서비스 구성이 변경될 때 Nomad 작업의 재배포를 모니터링합니다.
• Ceph는 Nomad에 분산 파일 시스템을 추가합니다.
• 파비오 로드 밸런싱을 위해.

이 모든 것이 허용됩니다 인프라를 유기적으로 발전시키다 판매자와 특별한 연관 없이 말이죠.

공정한 경고

어떤 시스템도 완벽하지 않습니다. 최신 기능을 프로덕션에 즉시 도입하는 것은 권장하지 않습니다. 물론 버그와 누락된 기능이 있지만 Kubernetes에도 동일하게 적용됩니다.

Kubernetes에 비해 Nomad 커뮤니티는 그다지 크지 않습니다. Kubernetes에는 이미 약 75개의 커밋과 000명의 기여자가 있고 Nomad에는 약 2000개의 커밋과 14명의 기여자가 있습니다. Nomad는 Kubernetes의 속도를 따라잡는 데 어려움을 겪겠지만 아마도 그럴 필요는 없을 것입니다! 이는 더욱 전문화된 시스템이며 커뮤니티가 작을수록 Kubernetes에 비해 끌어오기 요청이 주목되고 수락될 가능성이 더 높다는 것을 의미합니다.

개요

결론: 다른 사람들이 모두 사용한다고 해서 Kubernetes를 사용하지 마세요. 요구 사항을 주의 깊게 평가하고 어떤 도구가 더 유용한지 확인하세요.

대규모 인프라에 수많은 동종 서비스를 배포하려는 경우 Kubernetes가 좋은 선택입니다. 복잡성과 운영 비용이 추가된다는 점만 유의하세요. 다음과 같은 관리형 Kubernetes 환경을 사용하면 일부 비용을 피할 수 있습니다. 구글 쿠버네티스 엔진 또는 아마존 EKS.

유지 관리가 쉽고 확장이 가능한 신뢰할 수 있는 오케스트레이터를 찾고 있다면 Nomad를 사용해 보는 것은 어떨까요? 이것이 당신을 얼마나 멀리 데려갈지 놀랄 수도 있습니다.

Kubernetes를 자동차에 비유한다면 Nomad는 스쿠터에 해당합니다. 때로는 한 가지가 필요하고 때로는 다른 것이 필요합니다. 둘 다 존재할 권리가 있습니다.

출처 : habr.com