Kubernetesは必芁ありたせん







スクヌタヌの女の子。 freepikのむラスト、 HashiCorpによるNomadロゎ



Kubernetesは、コンテナオヌケストレヌション甚の300 kgのゎリラです。 䞖界最倧のコンテナシステムで動䜜したすが、高䟡です。



サポヌトず急な孊習曲線に倚くの時間を費やさなければならない小さなチヌムにずっおは特に高䟡です。 4人のチヌムにずっお、これはオヌバヌヘッドが倧きすぎたす。 だから私たちは代替手段を探し始めたした-そしおノマドに恋をしたした。



䜕が欲しい



私たちのチヌムは、パフォヌマンスを監芖および分析するための倚くの兞型的なサヌビスをサポヌトしおいたすGoで蚘述されたメトリックのAPI゚ンドポむント、Prometheusの゚クスポヌト、LogstashやGollumなどのログパヌサヌ、InfluxDBやElasticsearchなどのデヌタベヌス。 これらの各サヌビスは、独自のコンテナで実行されたす。 このすべおを運甚し続けるには、シンプルなシステムが必芁です。



コンテナオヌケストレヌションの芁件のリストから始めたした。





さらに、次のこずも䟿利ですが、必須ではありたせん。





Kubernetesが私たちに合わない理由



Kubernetesでプロトタむプを䜜成するずき、無条件に䟝存するロゞックのより耇雑なレむダヌを远加し始めたこずに気付きたした。



䟋ずしお、KubernetesはConfigMapsを介しお組み蟌みのサヌビス構成をサポヌトしたす。 特に耇数の構成ファむルをマヌゞしたり、ポッドに远加のサヌビスを远加したりするず、すぐに混乱する可胜性がありたす。 Kubernetesたたはこの堎合はhelm を䜿甚するず、関心を分離するために動的に倖郚構成を実装できたす。 しかし、これにより、プロゞェクトずKubernetesの間の匷固な秘密の぀ながりが生たれたす。 ただし、HelmずConfigMapsは远加オプションであるため、䜿甚する必芁はありたせん。 構成をDockerむメヌゞに単玔にコピヌできたす。 それにもかかわらず、このルヌトに進んで䞍芁な抜象化を構築するこずは魅力的であり、埌で埌悔するこずができたす。



さらに、Kubernetes゚コシステムは急速に成長しおいたす。 ベストプラクティスず最新のツヌルを最新の状態に保぀には、倚くの時間ず゚ネルギヌが必芁です。 Kubectl、minikube、kubeadm、helm、tiller、kops、oc-リストは延々ず続く。 䜜業の開始時には、これらのツヌルのすべおが必芁ずいうわけではありたせんが、必芁なものがわからないため、すべおに泚意する必芁がありたす。 このため、孊習曲線はかなり急です。



Kubernetesを䜿甚する堎合



圓瀟では、倚くがKubernetesを䜿甚しおおり、Kubernetesに非垞に満足しおいたす。 これらのむンスタンスは、十分なサポヌトリ゜ヌスがあるGoogleたたはAmazonによっお管理されたす。



Kubernetesには、管理しやすく倧芏暡なコンテナオヌケストレヌションを実珟する玠晎らしい機胜が備わっおいたす 。





問題は、これらすべおの機胜が本圓に必芁かどうかです。 抜象化だけに頌るこずはできたせん。 ボンネットの䞋で䜕が起こっおいるかを知る必芁がありたす 。



私たちのチヌムはメむンむンフラストラクチャずの密接な接続によりほずんどのサヌビスをリモヌトで提䟛しおいるため、独自のKubernetesクラスタヌを䜜成したくありたせんでした。 サヌビスを提䟛したかっただけです。



電池は含たれおいたせん



Nomadはオヌケストレヌションの20で、必芁なものの80を提䟛したす。 圌がしおいるのは、展開の管理だけです。 ノマドは展開を管理し、゚ラヌが発生した堎合にコンテナを再起動したす...それだけです。



Nomadのポむントは最小限であるずいうこずです。詳现な暩利管理や高床なネットワヌクポリシヌは特別に考案されおいたせん。 これらのコンポヌネントは、提䟛されるかたったく提䟛されたせん。



ノマドは䜿いやすさず実甚性の完璧な劥協案を芋぀けたず思いたす。 小芏暡な独立したサヌビスに適しおいたす。 さらに制埡が必芁な堎合は、自分で調敎するか、別のアプロヌチを䜿甚する必芁がありたす。 ノマドは単なるオヌケストラです。



Nomadの最倧の利点は、亀換が簡単なこずです。 ベンダヌの機胜はサヌビスを管理する他のシステムに簡単に統合できるため、ベンダヌぞの拘束力はほずんどありたせん。 クラスタ内のすべおのマシンで通垞のバむナリのように動䜜したす、それだけです



疎結合コンポヌネントの遊牧生態系



゚コシステムにおけるNomadの真の力。 Consul key-value storageやVault secrets processingなどの他の完党にオプションの補品ず非垞によく統合されたす。 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 }
      
      





ここで、Consulからキヌservice/geo-api/log-verbosity



を読み取り、その過皋で環境倉数LOG_LEVEL



それを衚したす。 たた、Vaultのsecret/geo-api-key



をAPI_KEY



ずしおAPI_KEY



たす。 シンプルだが匷力



Nomadはシンプルであるため、APIを介しお他のサヌビスを介しお簡単に拡匵できたす。 たずえば、タスクのタグがサポヌトされおいたす。 trv-metrics



タグを䜿甚しお、すべおのサヌビスにメトリックをタグ付けしたす。 したがっお、PrometheusはConsulを介しおこれらのサヌビスを簡単に芋぀け、定期的に新しいデヌタの゚ンドポむント/metrics



をチェックしたす。 同じこずが、たずえばLokiを䜿甚しおログに行うこずができたす。



拡匵性には他にも倚くの䟋がありたす。





このすべおにより、ベンダヌに特別なバむンドをするこずなく、むンフラストラクチャを有機的に開発できたす。



正盎な譊告



完璧なシステムはありたせん。 最新の機胜をすぐに運甚環境に導入するこずはお勧めしたせん。 もちろん、バグや欠萜しおいる機胜はありたすが、Kubernetesに぀いおも同じこずが蚀えたす。



Kubernetesず比范しお、Nomadコミュニティはそれほど倧きくありたせん。 Kubernetesにはすでに玄75,000のコミットず2,000の貢献者がいたすが、Nomadには玄14,000のコミットず300の貢献者がいたす。 ノマドは、Kubernetesの速床に぀いおいくのが難しくなりたすが、おそらくこれは必芁ありたせん これはより特化されたシステムであり、コミュニティが小さいずいうこずは、プルリク゚ストがKubernetesよりも泚目されお受け入れられる可胜性が高いこずも意味したす。



たずめ



結論Kubernetesは誰もが䜿甚するずいう理由だけで䜿甚しないでください。 芁件を慎重に評䟡し、どのツヌルがより収益性が高いかを確認しおください。



倧芏暡なむンフラストラクチャに倧量の同皮のサヌビスを展開する予定がある堎合は、Kubernetesが適しおいたす。 远加された耇雑さずメンテナンスコストを芚えおおいおください。 Google Kubernetes EngineやAmazon EKSなどのKubernetes管理環境を䜿甚するず、コストの䞀郚を回避できたす。



サポヌトが簡単で拡匵可胜な信頌できるオヌケストレヌタヌを探しおいるだけなら、Nomadを詊しおみたせんか これがあなたをどこたで導くのか疑問に思うかもしれたせん。



Kubernetesを車ず比范するず、Nomadはスクヌタヌになりたす。 時にはあなたはそれを必芁ずし、時には別のものを必芁ずしたす。 䞡方ずも存圚する暩利がありたす。



All Articles