WKSctlは、アドオンを含むKubernetesクラスタをSSH経由で立ち上げて管理するオープンソースプロジェクトだ。Cluster APII(CAPI)のプロバイダで、GitOpsアプローチを使用している。Kubernetesクラスタの設定はYAMLで定義するが、WKSctlは、Gitへのプッシュ毎にアップデートを実行することで、再現性のあるクラスタをオンデマンドで使用可能にする。
CAPIは、クラスタの生成、設定、管理を、デプロイやサービスなど他のKubernetesリソースと同じように宣言的に実行する、Kubernetesのプロジェクトである。現時点では実装として、AWSやVMWare vSphereといったインフラストラクチャプロバイダによるものがある。WKSctlはCAPIの新たな実装で、必要なのはKubernetesをブートストラップするための一連のSSHエンドポイントと資格情報のみである。
InfoQは先日、WeaveworksのAlexis Richardson(CEO)、Mark Ramm(プロダクトディレクタ)、Cornelia Davvis(CTO)、Mark Emeis(エンジニアマネージャ)各氏から、WKSctlについて詳しく聞くことができた。
InfoQ: WKSctlとは何であって、新たなKuberenetsツールを開発した理由は何か、教えてください。
Alexis Richardson:Kubernetesには現在、kopsやkubeadmといったRYO(Roll Your Own)インストーラと、rancherやkind、minikubeなどのパッケージドインストーラがあります。WKSctlは、開発者やデータセンタ、さらにクラウドのために、RYOとパッケージドインストーラを組み合わせた機能を提供するものです。
WKSctlはCAPIのオープンソース実装です。Kubernetesディストリビューションではありません。標準版(upstream)Kubernetesクラスタ用のGitOpsインストーラであり、コントローラなのです。Kubernetesのバイナリや、その他インストールの必要なパーツを格納したリポジトリを(Fluxを使って)サブスクライブして、クラスタの構築と立ち上げを行います。SSHエンドポイントを与えることで、後はWKSctlがすべて実行してくれます。クラスタが立ち上がった後は、Git内にあるクラスタ設定を変更すれば、WKSctlがそれをクラスタに反映します。
全体のメリットとして、Kubernetesのさまざまなディストリビューションを、柔軟性のある方法で操作することが可能になります。必要であれば、同じクラスタを何度でも再現することができます。クラスタはそれ自体、畜牛(cattle)であって、ペット(pet)ではありません。100パーセント廃棄可能であるのが理想的で、クラスタの状態が正しくない場合は通知されるべきだ、と私たちは考えています。
InfoQ: WKSctlの典型的なユースケースは、どのようなものでしょうか？
Richardson:マシンのプロビジョニングを行うことは目的ではありません。ですから、理想的なのは、マシン自体のプロビジョニングにTerraformやvSphere、Salt、Ansible、Chefなどを使用しているユーザです。そういったユーザが、マシンにKubernetesをインストールして立ち上げる手段として、WKSctlを使用することができます。マシンのプロビジョニングを希望しないのであれば、WKSctlの次のステップとしてFirekubeも用意しています。FirekubeはWKSctを使用して、バニラKubernetesをIgnite (Firecracker VM)クラスタにインストールします。
もうひとつのユースケースは、マルチクラウドあるいはハイブリッドクラウドのシナリオのためのもので、私たちが"マスタ・オブ・マスタ"(MoM)パターンと呼んでいる高度なパターンを使用します。このパターンでは、各ターゲット環境でKubernetesマスタ管理クラスタをプロビジョニングするMoMクラスタを用意することで、任意の数のKubernetesクラスタのプロビジョニングが可能になります。
InfoQ: WKSctlはどのように動作するのでしょうか？CLIか、Kubernetesコントローラなのか、あるいはその両方なのですか？
Mark Emeis: 両方です。Kubernetesクラスタの最初のノードをCLIで立ち上げて、WKSctlコントローラをインストールし、その他のマスタノードやワーカノードのインストールを管理します。WKSctl CLIはGitリポジトリをベースとしてクラスタを生成し、そのGitリポジトリをサブスクライブするためにFluxをインストールします — これを私たちは、"GitからKubernetesへの照合ループ(reconcilation loop)"と呼んでいます。最後に、独自のリソースコントローラをインストールして、Gitから受信したコンフィギュレーションに基いたクラスタレベルの変更を適用できるようにするのです。
Cornelia Davis: 照合ループには2つあります。まず、Fluxに照合機能があって、Gitリポジトリのクラスタコンフィギュレーションの変更を監視しています。Gitから変更を取得して、基本的にはそれをetcdにコミットするのが仕事です。2つ目の照合機能はWKSctlコントローラのもので、Kubernetesのレプリケーションコントローラのようにetcdを監視しています。
InfoQ: Kubernetesクラスタのパッチやアップグレードはどうなるのでしょうか？ダウンタイムは発生しますか？
Mark Ramm:WKSctlはCAPIマニフェストの変更に反応します。オペレータがKubernetesのバージョンを変更すると、コントローラがまずマスタノードを、続いてワーカノードをアップデートします。クラスタが実際にアップデートされると、再スケジュールを処理するために、アプリケーションを再構築する必要が発生します。最初は12Factor Appパターンに従うとよいでしょう。
InfoQ: クラスタアーキテクチャをカスタマイズして、etcdは専用のVM、APIコンポーネントは別のサーバ、というように、コンポーネントを分離することは可能ですが？
Ramm:デフォルトでは、3つのマスタとワーカノードを立ち上げます。シンプルにしたかったのです。もっと複雑な構成が希望であれば、有償プロダクトであるWKPの使用を検討してください。ざっと見たところでは、WKSctlを使用しているユーザは、開発とテスト用のクラスタをオンデマンドで立ち上げて、短期的に(それほど大きくない規模で)使用しているようです。大規模なクラスタひとつではなくて、たくさんのクラスタを立ち上げたり、破棄したりしています。企業ユーザの一般的な傾向として、権限やセキュリティ上の理由から、ひとつの大規模なクラスタよりも複数のクラスタを運用しているように思えます。また、大規模なクラスタを構築しなくても、クラスタを水平的にスケールアップすれば、システムを簡単に拡張することができます。
InfoQ: コミュニティ内の採用状況はどのようなものでしょうか？
Ramm:ユーザの中ではDeutshce Telekomが現在、WKSctlの使用開始プロセスにあります。同社は先日、自社の環境でWKSctlが動作する様子をデモした簡単なビデオを公開しました。