Draft vs Gitkube vs Helm vs Ksonnet vs Metaparticle vs Skaffold

kubernetesのdeployツール比較

gavin.zhou
Apr 17 · 23 min read

Kubernetes上でアプリを構築したりデプロイしたりするときに役に立つツールの比較

TL;DR


Draft

  • k8sクラスタにコードをデプロイする(自動化されているbuild-push-deploy)

- dockerfileもしくはk8sマニュフェストを書き込むことなくdraft-pack supported languages の中で コードをデプロイする

  • クラスタ上でdraft cli、helm cli、 クラスタ上のtiller、local docker, docker registryが必要

Gitkube

  • k8sクラスタにコードをデプロイする(自動化されているbuild-push-deploy)
  • デプロイするためにgit pushする、自身のローカルマシンとの依存関係はなし
  • クラスタ上のgitkube 、gitリポジトリの中でdockerfileとk8sマニュフェストが必要

Helm

  • k8sクラスタ上でチャート(アプリケーションを設定するk8sのオブジェクトの集合)をデプロイし管理する
  • mysql, mediawikiなどのような多くの共通のアプリケーションのための既成のチャート
  • helm cli、クラスタ上のtiller、ローカルもしくはリポジトリからのチャートの設定が必要

Ksonnet

  • jsonnetにおいてk8sマニュフェストを設定し、k8sクラスタへそれをデプロイする
  • デプロイメント+サービス、redisのような一般的なパターンとスタックのための再利用可能なコンポーネント
  • jsonnetに関する知識やksonnet cliが必要

Metaparticle

  • metaparticle supported languages の中にあるコードを k8s(自動化されているbuild-push- deploy) をデプロイする
  • 慣用的な方法で、dockerfileもしくはk8s yamlを書き込みすることなくコンテナ化を設定し、言語そのものの中のk8sへデプロイする
  • 言語のためのmetaparticleライブラリやlocal dockerが必要

Skaffold

  • k8sクラスタにコードをデプロイする(自動化されているbuild-push-deploy)
  • ソースコードを見て、変化やコンフィギュレーション可能なパイプラインが発生したらbuild-push-deployを引き起こす
  • kaffold cli、dockerfile、 k8sマニュフェスト、skaffold cli、フォルダーの中のskaffold マニュフェスト、local docker, docker registryが必要

Want to know more? Read ahead.

Kubernetesは今ではものすごく有名で、人々はKubernetesクラスタにアプリケーションをデプロイするワークフローやデプロイの他の方法を探しています。 kubectl それ自身はより簡単なフレームワークを求めている人向けのレベルの低いツールのようになっています。Draft, Gitkube, Helm, Ksonnet, Metaparticle や SkaffoldはデベロッパーがKubernetes上でアプリを構築したりデプロイしたりするのに役に立つツールです。

Draft, Gitkube ,Skaffoldがあるおかげで、デベロッパーはアプリケーションの構築のときより簡単に、そしてできる限り早くアプリケーションをKubernetesクラスタの中で走らせることができます。HelmやKsonnetはアプリが一度構築されていて、そして送信する準備ができていると、アプリケーションを設定することで、そのデプロイメントの過程で役に立ってくれます。新しいバージョンのロールアウトや、異なるクラスタにも対応してくれたりします。Metaparticleはここでは、少し質の異なるものになります。というのもMetaparticleは、自分のコードの中―yaml, dockerfileなど(コードそのものの中)に全てを統合しするからです。


それでは、こういう場合は何を使うといいのでしょうか?

今からそれを見ていきましょう。

Contents

  1. Draft
  2. Gitkube
  3. Helm
  4. Ksonnet
  5. Metaparticle
  6. Skaffold

Draft

どのKubernetesクラスタ上へも対応可能なシンプルなアプリ開発&デプロイメント

この名前の通り、DraftはKubernetesクラスタ上で走るアプリ開発をより簡単に行うようにしてくれます。公式コメントでは、DraftはKubernetes上で走るアプリケーション開発のためのツールであって、アプリケーションをデプロイするツールではないとのことです。HelmはDraftドキュメンテーションごとのアプリケーションをデプロイするおすすめの方法です。

Kubernetesクラスタへデベロッパーのマシン上で現在のコードを取得することが目的で、バージョンコントロールに対応する前には、同時にデベロッパーはまだそれをはまだハッキングしています。一度デベロッパーが、Draftを使ったデプロイやDraftを使った変化に満足すれば、コードはバージョンコントロールに対応します。

Kubernetesのためのアプリケーションの書き込みをする時、Draftは純粋にとても早い開発のワークフローのために使われるので、プロダクションのデプロイメントのために使われることを目的とされていません。しかし、Draft はHelmとはとても相性がよいです。というのも、内部で変化をデプロイするためにHelmを使用しているからです。

Architecture

この図から見て分かるように、 draft CLIはキーコンポーネントです。ソースコードから使用されている言語を検出することができます。そしてリポジトリからの適切なパックを使います。そのパックというのは、Dockerfile とHelmチャートの組み合わせで、アプリケーションのための環境を一緒に設定します。パックはリポジトリの中で設定され分配されます。ユーザーは、ローカルシステムの中、もしくはgitリポジトリの中で自分たち自身のパックとリポジトリを設定することができます。

もし、そのスタックに対してのパックがあれば、ソースコードを伴うどのディレクトリもデプロイされます。一旦そのディレクトリが draft create(これはdockerfile, Helm チャート、draft.tomlを追加します)を使ってセットアップすると、 draft up はdocker imageを構築し、それをレジストリーにプッシュし、Helm チャート(提供されるHelmはインストールされます)を使ってアプリをロールアウトします。変化が起きるたびに、そのコマンドを再実行することで、新しいビルドがデプロイされます。

コンテナからのストリームログと同じような自分のローカルシステムへの接続をポートフォワードすることのできる draft connect コマンドが存在します。またそれはデプロイするそれぞれのアプリへドメインネームを提供するためのnginx-ingressと相性がよいです。

From zero to k8s

Draftを使ってpythonアプリをk8sクラスタ上で動かすために必要な順序をご紹介します。

(より詳しいガイドは docsをご覧ください)

必要条件:

  • k8s クラスタ (hence kubectl)
  • helm CLI
  • draft CLI
  • docker
  • イメージを保存するdocker リポジトリ
$ helm init

Use case

  • Kubernetes上で走るアプリの開発
  • コードがバージョンコントロールに対応する前に「インナーループ」の中で使用される
  • Pre-CI: draftを使って一旦開発が終了したら、CI/CDが引き継ぐ
  • プロダクションのデプロイメントの中では使われないようにする

詳細は こちら。


Gitkube

Git pushを使ってKubernetesへDocker imagesを構築しデプロイします。

Gitkubeはgit pushを使ってKubernetes上へDocker imageを構築したりデプロイしたりするときに役に立つツールです。draftと違いgitkubeはCLIを持っておらず、クラスタ上で独占的に走ります。

dockerfileを持つどのソースコードリポジトリもgitkubeを使ってデプロイされることが可能です。一旦gitkubeがインストールされ、クラスタ上でエクスポーズされると、デベロッパーはgitリモートurlを与えてくれるリモートカスタムリソースを生成することができます。デベロッパーはそれから与えられたurlへpushすることができ、dockerが構築したkubectlロールアウトがクラスタ上で発生します。その実際のアプリケーションのマニュフェストはどんなツール(kubectl, helmなど)を使っても生成されます。

そして既存の有名なツール(gitと kubectl)のインストールと利用方法とプラグに注目しましょう。デプロイされるリポジトリについての仮説はありません。アップデートされるデプロイメントを伴い、dockerが構築したコンテキストとdockerfile pathはコンフィギュレーション可能です。gitリモートに対する認証はSSHパブリック・キーがベースになっています。コードの中で何か変化が起きればいつも、gitを使ってpushしたり、取り扱うことでビルドとロールアウトを発生させます。

Architecture

クラスタ上には3つのコンポーネントが存在します。リモートCRDというリモートurl上でpushがなされたときに何が起きるべきかを設定するもの、 gitkubedというものでdocker imagesを構築し、デプロイメントのアップデートをするもの、そしてgitkube-controllerというgitkubedをコンフィギュアするためのCRD上で見ているもの、3つです。

一旦それらのオブジェクトがクラスタ上で生成されたら、デベロッパーはkubectlを使って自分たちのアプリケーションを作ることができます。次のステップはリモートオブジェクトを生成することです。リモートオブジェクトは特定のリモートに対してのgit pushが起きた時に何が起こるべきなのかをgitkubeに伝えます。GitkubeはリモートURLをリモートオブジェクトのステータスフィールドに書き戻します。

From zero to k8s

必要条件:

  • k8s クラスタ (kubectl)
  • git
  • クラスタ上(kubectl create)にインストールされたgitkube

gitkubeのインストールを含むKubernetes上にアプリケーションを取得するために必要な手順を示しています。

$ git clone https://github.com/hasura/gitkube-example$ cd gitkube-example$ kubectl create -f k8s.yaml$ cat ~/.ssh/id_rsa.pub | awk '$0="  - "$0' >> "remote.yaml"$ kubectl create -f remote.yaml$ kubectl get remote example -o json | jq -r '.status.remoteUrl'$ git remote add example [remoteUrl]$ git push example master## edit code## commit and push

Use case

  • docker buildがないgitを使った簡単なデプロイメント
  • Kubernetes上でのアプリケーションのデプロイメント
  • デプロイメントの間, WIP ブランチはすぐに結果を見るために複数回pushされることがある。

詳細はこちら


Helm

HelmはKubernetesのためのパッケージマネージャーです。

そのタグが提案するように、Helmはチャートのフォーム内でKubernetes上のアプリケーションの管理をするツールです。 HelmはKubernetesマニュフェストの作成に関与し、バージョニングします。そのため、ロールバックはデプロイメントだけではなく、全ての種類のオブジェクト全体で実行されます。チャートはデプロイメント、サービス、コンフィグマップなどを持っています。またそれはテンプレートされていて、変数は簡単に変わります。依存関係を持ちながら、複雑なアプリケーションを設定するために使われます。

Helmは主にマニュフェストをデプロイするため、そしてそれらをプロダクション環境において管理するためのツールとして作られています。Draft や Gitkubeと比較すると、Helmはアプリケーションの開発のためのツールではありませんが、デプロイをするためのツールです。幅広い種類のまだ構築されていないチャートがHelmと共に使われる準備をして待っています。

Architecture

このチャートをまず初めに見てください。最初に述べたように、情報のまとまり、チャートはKubernetesアプリケーションのインスタンスを生成するには必要なものです。デプロイメント、サービス、コンフィグマップ、シークレット、イングレスなどを持つこともあります。全てのものはyaml filesとして設定され、それは次々にテンプレートされます。デベロッパーはまた他のチャートに対しての依存状態としての最適なチャートを設定することができるか、もしくは他のチャートの中でチャートをネストすることができます。チャートは、チャートリポジトリの中で一緒に発行されるか、一致します。

Helmは主に2つのコンポーネントを持っています。それはHelm CLIとTiller Serverです。cliはマネージングチャートとリポジトリの中で役に立ち、それらのチャートをデプロイしたり管理したりするためにTillerサーバーと互いに作用します。

Tillerはクラスタ上で走っているコンポーネントです。実際のオブジェクトを生成し管理するためにk8s APIサーバーとトークします。また、Tillerはリリースを構築するためにチャートを表示します。デベロッパーが helm install <chart-name>するとき、そのcliはtiller に チャートの名前と共に接続します。そしてtillerはそのチャートを取得し、テンプレートをコンパイルし、クラスタ上でデプロイします。

Helmはあなたのソースコードを取り扱うことはしません。あなたが自分のイメージを構築するためにCI/CDシステムを使う必要があり、正しいイメージをデプロイするためにHelmを使わなければいけません。

From zero to k8s

必要条件:

  • k8s クラスタ
  • helm CLI

Helmを使ってk8sクラスタ上にWordpressのブログをデプロイするときの例を挙げています。

$ helm init$ helm repo update$ helm install stable/wordpress## make new version$ helm upgrade [release-name] [chart-name]

Use case

  • パッケージング:複雑なアプリケーション (多くのk8s オブジェクト) は一緒にパッケージされる
  • 再利用可能なチャートリポジトリ
  • 多様な環境への簡単なデプロイメント
  • チャートのネスティング―依存関係
  • テンプレート―パラメーターを変更するのは簡単
  • 分配と再利用の可能性
  • ラストワンマイルのデプロイメント:継続的なデリバリ―
  • 既に構築されているイメージをデプロイする
  • 色々なk8sオブジェクトを一緒にアップグレードしたりロールバックしたりする―ライフサイクルマネージメント

より詳しい情報はこちら。.


Ksonnet

CLIは拡張可能なKubernetesコンフィグレーションのためのサポートされたフレームワークです。

KsonnetはKubernetesに対してアプリケーションのコンフィグレーションを設定するまた別の方法です。それはk8sマニュフェストを設定するためにデフォルトのyaml file の代わりにJsonnet, a JSONテンプレート言語を使います。ksonnet CLIは最終的なyamlファイルを表示し、それからそれをクラスタ上に提供します。

もともと再利用可能なコンポーネントを設定するために使われるためにうまれたものですが、それがアプリケーションの構築に使われるようにもなりました。

Architecture

その基本的なビルディングブロックはパーツと呼ばれていて、プロトタイプを生成するためにミックスしたりマッチングしたりします。プロトタイプはアプリケーションとして一緒にグループ分けされるコンポーネントになるパラメーターを伴っています。アプリケーションは多様な環境へデプロイされます。

その基本的なワークフローはks initを使ってアプリケーション ディレクトリーを生成することです。 ks generateを使ってコンポーネントのためのマニュフェストを自動的に生成(もしくは自分で書き込む)したり、 ks apply <env>を使ってこのアプリケーションをクラスタ/環境上にデプロイしたりします。 ks env コマンドを使って異なる環境を管理することも可能です。

端的に言えば、Jsonnet を使ってコンポーネントを集めるように、Ksonnetがアプリケーションを設定したり、管理したりするのに役に立つツールです。それから、異なるKubernetesクラスタ上にそれらをデプロイします。

HelmのようにKsonnetはソースコードを取り扱いません。KsonnetはJsonnetを使ってKubernetesのためにアプリケーションを設定するツールだからです。

From zero to k8s

必要条件:

  • k8s クラスタ
  • ksonnet CLI

こちらにガイドブックの例を提示しています:

$ ks init$ ks generate deployed-service guestbook-ui \     --image gcr.io/heptio-images/ks-guestbook-demo:0.1 \     --type ClusterIP$ ks apply default## make changes$ ks apply default

Use case

  • Jsonnetを使ってコンフィグレーションを書き込む際のフレキシビリティ
  • パッケージング: 複雑なコンフィグレーションがコンポーネントをミックスしたりマッチングしたりするときに構築される
  • 再利用可能なコンポーネントとプロトタイプ ライブラリ:複製を避ける
  • 多様な環境への簡単なデプロイメント
  • ラストワンマイル デプロイメント: CD ステップ

より詳しい情報は こちら.


Metaparticle

コンテナとKubernetesのためのクラウドネイティブな基本的なライブラリ

クラウドネイティブ アプリケーションに対しての基本的なライブラリのように、それ自身をポジショニングすること、Metaparticleのおかげでデベロッパーはプログラミング言語インターフェイス経由してプリミティブを通り、分配されたシステム開発のための実績のあるパターンを簡単に受け入れられるようになります。

Kubernetesへアプリケーションをデプロイしたりコンテナ化したりできるシステムの構築に役に立つ慣用的な言語のインターフェイスを提供してくれます。また複製されたロードバランスのとれたサービスをデプロイするなど他にも色々と役に立ちます。Dockerfile やKubernetesマニュフェストを設定することはないと思います。あなたが使っているプログラミング言語へのイディオムネイティブを通して全てがコントロールされているからです。

例えば、Pythonウェブアプリケーションに対しては、containerize(metaparticleパッケージからインポートされた)と呼ばれるデコレーターを自分のメインの機能に追加します。pythonコードを実行するとき、docker imageが構築され、デコレーターの中で各パラメーターが表示したように自分のkubenetesクラスタ上にデプロイされます。デフォルトのkubectlコンテキストはクラスタに接続するために使われます。そして、環境を変えることは、現在のコンテキストを変更することを意味します。

同じようなプリミティブはNodeJS、Jav、.NETでも利用可能です。より多くの言語へのサポートは現在は準備段階にあります。

Architecture

適応している言語へのmetaparticle ライブラリーは必要なプリミティブを持っていて、docker imageのようにコードを構築するためのバインディングを持っていて、それをレジストリーにpushし、k8s yamlファイルを生成し、それをクラスタ上にデプロイします。

Metaparticle Packageはコンテナ構築のために、それらの言語の慣例なバインディングを持っています。 Metaparticle Syncは異なるマシン上で走っている多様なコンテナ全体的な同期のためのMetaparticleの内部にあるライブラリーです。

JavaScript/NodeJS, Python, Java and .NETは書き込みの時間の間はサポートされています。

From zero to k8s

必要条件:

  • k8s クラスタ
  • サポートされている言語に対するmetaparticleライブラリー
  • docker
  • イメージを保存するためのdocker リポジトリ

k8sクラスタへのデプロイとコードを伴いdockerイメージをバインディングするためのA python の例 (関連しているポーションのみ):

@containerize('docker.io/your-docker-user-goes-here',options={'ports': [8080],'replicas': 4,'runner': 'metaparticle','name': 'my-image','publish': True})def main():Handler = MyHandlerhttpd = SocketServer.TCPServer(("", port), Handler)httpd.serve_forever()

Use case

  • k8s yaml やdockerfileの心配をせずにアプリケーションの開発をすること
  • デベロッパーはもはや多様なツールを習得する必要がなくなり、コンテナやKubernetesのパワーを利用するためのフォーマットも不要です。
  • 簡単に複製やロードバランスのとれたサービスを開発
  • 分配された複製の間のロッキングやマスターエレクションのような同期をコントロールする
  • シェアされたシステムのようなクラウドネイティブパターンを簡単に開発する

より詳しい情報はこちら.


Skaffold

簡単で繰り返し利用できるKubernetes開発

Skaffoldはビルドのワークフロー、Kubernetesへのアプリケーションのデプロイやpushなどを担っています。Gitkubeのように、dockerfileを持つどのディレクトリもSkaffoldと一緒にk8sクラスタへデプロイされます。

Skaffoldはdocker imageをローカルで構築し、それをレジストリーにpushし、 skaffold CLIツールを使ってデプロイメントをロールアウトします。またディレクトリを見て、ディレクトリの中のコードが変化するときはいつも再構築と再デプロイが発生します。またSkaffoldはコンテナからのログをストリームします。

そのdocker imageの構築、push、パイプラインのデプロイはyaml fileを使ったコンフィギュレーション可能なものです。そのためデベロッパーはツールをミックスしたりマッチングしたりできます。例えば:docker build vs google コンテナビルダー、ロールアウトのためのkubectl vs helmなど

Architecture

Skaffold CLIはここで全ての作業をします。何をしなければいけないか設定するskaffold.yamlと呼ばれるファイルを参照します。典型的な例は skaffold dev が走っているディレクトリの中でdockerfileを使ったdocker imageを構築し、そのsha256と共にタグをつけ、イメージをpushし、yaml fileで指定するk8sマニュフェストの中のイメージをセットし、クラスタ上にそのマニュフェストを提供する例です。

ディレクトリの中で全ての変化に対して発生する原因になるループの中で継続的に走ります。デプロイされたコンテナからのログは同じウォッチウィンドウへストリームされます。

SkaffoldはDraftやGitkubeにとてもよく似ていますが、よりフレキシブルです。上に示したもののように異なるbuild-push-deployパイプラインも管理できます。

From zero to k8s

必要条件:

  • k8s クラスタ
  • skaffold CLI
  • docker
  • イメージを保存するためのdocker リポジトリ

ここにhello-worldをプリントするGo アプリケーションの例をデプロイする手順を掲載しておきます。

$ git clone https://github.com/GoogleCloudPlatform/skaffold$ cd examples/getting-started## edit skaffold.yaml to add docker repo$ skaffold dev## open new terminal: edit code

Use case

  • 簡単なデプロイメント
  • 繰り返されるビルド — 継続的な build-deploy ループ
  • Kubernetes上でのアプリケーションの開発
  • CI/CD フローの中でbuild-push-deploy パイプラインを設定する

より詳しい情報はこちら.


もし何か間違っていることがあったり、抜けているところがあればお知らせください。今回、KsyncTelepresenceのようなツールについては説明していません。というのもこれらについてはまた近々記事を書きたいと思っているからです。しかし、もし今回説明したツールのカテゴリーに合う他のツールがあればぜひ教えてください。


Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。

Orangesys

Orangesys Inc.

gavin.zhou

Written by

gavin@orangesys.io

Orangesys

Orangesys

Orangesys Inc.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade