"How NOT to Start with Kubernetes"
(日本語訳: Kubernetesで始める際に、やってはいけないこと)
KubeCon + CloudNativeCon NA 2021にリモート参加いたしました。
前回のEuropeでは完全なリモート開催でしたが、今回は会場とリモートのハイブリッド開催となり、スピーカーの方も熱気を帯びていたと思います。 CNCFは、OSSのコミュニティの中でも最も活気のコミュニティの一つだと思います。
さて、Kubeconでは、多数のセッションありますが、"How NOT to Start with Kubernetes"(Kubernetesで始めてはいけないこと)というセッションのタイトルに惹かれ聴講いたしました。
Kubernetesを社内に導入する時にやってしまいがちな失敗を教えてくれています。特にKubernetesの導入を考えられる方には有益な情報だと考えます。
スピーカーの Christian Heckelmann さんは、実体験を元に惜しみなく注意事項を共有していただいております。Kubecon NA 2021のセッション動画は、早速、youtubeでも公開されています。ぜひ、動画をご確認いただきながら、こちらのブログでもおさらいしていただければと思います。
Christian Heckelmannさんはオンプレミス上でPoCから始めていますが、クラウドでも十分に役に立つ内容だと思います。
では、Christian Heckelmannさんが体験されたストーリーを紐解いていきましょう。大きく分けてK8sインフラ構築・運用編とコンテナデプロイ・開発編の2つになります。
K8sインフラ構築・運用編
1. 自分だけで始めてしまうこと
少なくとも、K8sは小さなデータセンターを構築しているということをお忘れなく。プラットフォームを作るときに、セキュリティ部門、ストレージ、ネットワーク担当者なども含めるべきだと、仰っています。また、K8sについても同様で知識が少ないのであれば、最初からある程度協力を仰ぐ必要もあるとのこと。
AWSなどのクラウドや仮想環境でもそうですが、非常に少ない労力でソフトウェアでデータセンタが作れる時代になりましたが、理解が不十分でも作れてしまうのも事実ですね。また、PoCなど構築を急ぐあまりに、機能要件を優先してしまい、セキュリティなどの非機能要件は後回しになりがちですね。
特にリスクの高いセキュリティについては、詳しいメンバーにプロジェクトの初めから入ってもらうことも検討した方が良いですね。
2. K8をスクラッチからインストールしてしまうこと
3ノード構成で最初の二週間程稼働していたようなのですが、クラスタのアップグレードをしたところ壊れてしまったとのこと。全てマニュアル操作となると、操作ミスや工数、運用スキルも必要となってきます。マルチクラウドでK8sクラスタを一元管理可能なRancherなどで、極力手間を省きましょう。Rancherは、Web UIで操作も可能ですので、ミスは軽減できますね。
Rancherは、コンテナを管理のプラットフォームを提供するアプリケーションで、Web UIでKubernetesの管理やクラスタのアップグレードも容易にできます。またオンプレミス、マルチクラウド問わず一元的に管理することも可能です。
3. GUIに頼り過ぎてしまうこと
便利の裏返しなのですが、Rancherを導入するとWeb UIで操作が可能ですので、圧倒的に運用に関する学習コストは下がります。しかし、GUIに頼り過ぎてkubectlなどのコマンドを知らないと、トラブルが発生したときに切り分けなどが出来なくなります。
もしかしたら、Rancher自体の問題が発生する場合もあるので、コマンドで実行する訓練もしておいた方が良いですね。
4. 管理の自動化を検討せずに、手動に頼ってしまうこと
管理する際に同じようなkubectlコマンドを何度も実行するのではなく、やはり自動化を検討するべきです。シェルスクリプトを用いたり、プログラミング言語など、自動化する方法はいくつも考えられますね。自動化ツールなどを使ってもよいですね。
5. ドキュメント整備を後回しにしてしまうこと
導入初期からドキュメントも整備しておきましょう。PoC の最中ですと、なかなか、ドキュメント作成のタイミングが難しいですが重要な作業です。
こんなことがあるのではないでしょうか。
- 手順や環境が固まっていない
- ドキュメント作成は地味な作業
- 評価されにくい など
しかし、環境が大きくなるにつれてチームメンバーへの引継ぎ、また未来への自分への引継ぎも含め、非常に大事なことです。
6. RBAC、権限などの考慮を後回しにしてしまうこと
初期の開発用のクラスタで、開発者にクラスタ管理者用のトークンを渡して、多くの人に再利用されていたとのこと。 導入直後は、なかなか、アカウント、RBAC(ロールベースアクセス制御)などは、手が回らなかったり、細かく設定しようとすると時間がかかるため、後回しにされがちですね。しかし、特権ユーザーで全てを実行してしまうと、トークンが漏洩した時のインパクトが大きく、また問題発生時のトレースが難しくなりますので、設定は必須としましょう。
7. 構成管理を検討しないで始めてしまうこと
K8s環境が悪化する前に設定ミスのチェックや変更拒否を行うこと
運用しているときに、うっかり設定を間違えたり、セキュリティ上実施してはいけない変更を加えてしまう可能性はありますね。その変更によって、即座にクラスタ上で不具合が発生すればすぐ気づけますが、知らず知らずのうちにセキュリティが甘くなってしまっていることもあります。そして、データが盗まれてから気づくということも、事態も発生する可能性がありますね。
そんな時に、ポリシーエンジンが有効です。予期しない設定変更を防ぐことで、ガバナンスを効かせることが可能となります。
便利なポリシーエンジンがあります。以下の2つを紹介されていました。
kyverno.io www.openpolicyagent.org
コンテナデプロイ・開発編
1. 間違った動機で始めてしまうこと
確かに、仮想マシンを使うために事前に利用申請することがルールという場合もありますよね。しかし、それを回避したいという理由だけで始めないことです。本質的にそのアプリケーションにはコンテナが向いているのかを検討する必要があります。
2. ローカルの検証環境を持たずに、CICDで何とかしようとしてしまうこと
作成したアプリケーションをテストをするために、わざわざCI/CDのパイプラインを通すのではなく、ローカル環境で実行する
特に作成したアプリケーションをトライ&エラーを繰り返すときには、ローカルの方が圧倒的に早いです。minikubeなどであれば、ノートPCで動作するレベルですので、一旦自分のところで試してから、CI/CDに流す方がよさそうです。
3. deploymentなどで":latest"のラベルを使用してしまうこと
バージョンを指定せずに「:latest」のラベルを利用して、常に最新を求めてしまうと、予期せずに未テストの新規バージョンのイメージがダウンロードされ、結果的に不具合が発生してしまいます。
バージョンを固定し、テストされたバージョンだけを利用することで、トラブルを減らすことができます。
4. ベースイメージを取得するレジストリのセキュリティの考慮不足
セキュリティを考慮すると信頼されたイメージだけが置かれたプライベートレジストリを利用するのがベストです。また、信頼できないサイトからイメージをプルしないようにしましょう。
また、コンテナイメージの脆弱性チェックができるHarborを利用しましょう。
5. キャパシティーの考慮不足
ポッドのリソースを制限しておくこと。コンテナのリソース消費量を確認するためには、まずはローカル環境で動作させ、キャパシティープランニングをしておきましょう。
ローカル環境は、ここでも役に立ちますね。
6. 秘匿情報の保護に対する考慮不足
秘匿情報を含む環境変数などは以下のValutなどの利用を検討しましょう。
HashiCorp社が開発しているOSSで、秘匿情報を管理・保護する為のソフトウェアです。 秘匿情報をセキュアに保存するとともに、秘匿情報へのアクセスコントロールを適切に制御する機能を提供します。
7. パッケージマネージャ(Helm)などを利用せずに始めること
実際、ほとんどのデプロイは同じ内容になります。パッケージマネージャを利用し、テンプレート化しておき、再利用可能にすることで、効率よくデプロイが可能となります。また、パッケージ化しておくと設定間違えなどが発生しにくく、セキュリティーの脆弱性も減らすことができます。
テンプレート化は大事ですね。実績のあるテンプレートを作っておけば、構築だけではなく、テストなどの時間も減らせますね。
結びに
まだまだ、これからKubernetesを導入されることも多いと思いますので、イベントの多数の有益なセッションの中から厳選して、"How NOT to Start with Kubernetes" をピックアップし、紹介させていただきました。ぜひ、ご参考にしていただければと思います。
まだまだ、Kubecon NA 2021に参加したメンバーのブログが続きますので、お楽しみに。
執筆: 伊藤 好宏, 技官