社内 Kubernetes 実験環境をRancher 1.6から 2.0にアップデートして復活させた話

  • このエントリーをはてなブックマークに追加

Kubernetesをイメージする画像

※画像引用「https://rancher.com/

「SEROKU フリーランス(以下、SEROKU)」の中の人をやっている kouki です。
SEROKUを支える技術〜社内 Kubernetes 編〜 でも言及しましたが、社内では自分たちでサーバマシンを用意し、Kubernetes 環境を構築しています。

今回、その実験環境が壊れてしまったので、Rancher 2.0 にアップデートして復活させたお話をさせていただこうと思います。

Rancher とは

まず、社内 Kubernetes 実験環境は Rancher というソフトウェアを用いて構築しています。

Your Enterprise Kubernetes Platform | Rancher Labs

OSS で公開されており、比較的簡単に Kubernetes クラスタを構築できるソフトウェアです。
オンプレミスで構築できるだけでなく、 GCE や AWS ESK、Azure Container Service など、様々なクラウドプロバイダにも対応しています。

また、Rancher 1.6 の段階では、Kubernetes 以外にも Cattle, Mesos, docker swarm などの様々なコンテナ分散システムに対応していました。ですが、2017年9月頃、 Rancher 2.0 が発表され、Kubernetes 前提のシステムに舵を切っています。

弊社では、2017年12月頃から利用を始めたため、安定版である Rancher 1.6 を採用しました。

Rancher OS とは

Rancher OS とは、Rancher を開発している同社が公開している Rancher に特化した Operating System です。
動作速度と軽量さが特徴ですが、一番の特徴としては、すべてのコマンドやシステムがコンテナで動作する前提で組まれているところだと思います。

OS の機能を担当する system-docker と、それ以外の用途で利用される docker といった形でコンテナの実行環境が分離されており、ポータビリティに優れた設計になっています。

※Overview of RancherOS から引用

社内 Kubernetes 実験環境では Rancher OS と Rancher を組み合わせて、Kubernetes クラスタを構築しています。

なぜ壊れたのか

半年ほど安定して運用していたのですが、今年の6月末あたりにミスで大量にコンテナ(数百程度)を作成してしまい、
Node(Kubernetes クラスタに属しているサーバ)に負荷がかかり、Rancher システム自体の動作が不安定になる事象が発生しました。

最初は大量に作成されたコンテナを削除していくことで収束していくだろう、と目論んでいたのですが、負荷も相まって Kubernetes の設定などを保持している etcd のデータに不整合が発生し、クラスタの状態を正しく復元することができなくなっていました。

リカバリをするために etcd が持っている内部データのバイナリを見てみると、設定が保存されているようでしたが、そのデータから頑張って復元処理をするよりも、Rancher 2.0 GA がアナウンスされていたため、社内ノウハウの刷新も含め、そちらを採用する選択をしました。

幸いにも Kubernetes にデプロイしている各種設定は別のレポジトリにバックアップを取っていて、コンテナのボリュームは NFS ストレージ上に残っていたため、新しいクラスタ上にも復元することは可能でした。

2.0 にアップデートして嬉しかったこと

Kubernetes クラスタ前提のシステムになったため、Rancher 独自の用語が少なくなっており、Kubernetes への理解があればシンプルに扱えるようになりました。

また、以下のような点にメリットを感じました。

  1. Cattle が排除され、対応するクラスタが Kubernetes 前提になったため、動作するコンテナがシンプルになった
    • 1.6 ではクラスタを組むためのシステム用途的なコンテナが多く動作していました。それが 2.0 からは比較的少ないコンテナでクラスタが組めるようになったため、本来サービスに割り当てたいリソースを使えるようになりました。
  2. Node 同士のネットワークを組む際に Flannel, Canal, Calicoが選択可能になった
    • Calico を利用することでセキュリティポリシーも設定できるようになるため、柔軟なアクセスコントロールを書けることができるようになったのは非常に便利でした
  3. Kubernetes 前提の WebUI になっている
    • Kubernetes に対応を絞ったことにより、 Kubernetes の namespace 一覧や Volume 一覧などを手軽に WebUI から確認できるようになりました

Rancher 2.0 の不満点

不満というほどではないのですが、下記のような点が 1.6 と比較して気になりました

  1. 1.6 ではサポートされていた LDAP 認証が v2.0.4 段階ではまだリリースされていない
  2. 1.6 ではあった Infrastructure という Pod 一覧が見ることができる管理画面が 2.0 にはない
    • 上記の画像のように Node 毎の Pod が見られる画面があり、Pod の開始、停止などをリアルタイムに確認できる画面が 1.6 にはありましたが、2.0 では今のところ採用されていません。
    • kubectl コマンドなどを利用して、Pod の状態は確認できますが、個人的には格好良い画面だと思っていたので少々残念でした

2.0 で行ったトラブルシューティング

構築する際にスムーズに行かなかった点があり、数件トラブルシューティングを行いました。

  1. グローバル IP とプライベート IP 2つの足(NIC)を持つサーバを Kubernetes クラスタのネットワークに所属させることができない (Calico ネットワークが確立されない)
  2. 一度クラスタに所属させた Node をクラスタから外し、再度クラスタに所属させようとすると、etcd のデータ同期が上手く同期されない

こちらは解決方法とトラブルシューティングの過程も含めて、また別の記事として公開したいと思います。

最後に

Kubernetes クラスタが壊れるという経験はあまりできないことで、今回は貴重な経験ができたと思います。トラブルが発生しても、「ただでは起きない精神」というのは大切にしていきたいです。

また、再度最初から Kubernetes クラスタを構築し直したことで、古い設定を刷新していくこともできましたし、Kubernetes の yaml 設定が残っていれば復元可能である、という Kubernetes 自体の強力さも痛感しました。

Rancher 2.0 もバージョンが v2.0.4 とリリースされてから間もないですが、開発が活発にされているため、今後も期待できるソフトウェアだと思います。

 

SEROKU新規フリーランスエンジニア・プログラマ登録促進バナー

SEROKU新規フリーランスエンジニア・プログラマ登録促進バナー

 

kouki
profile:強面のインフラエンジニア。夜の街が似合うらしい。

SNSでもご購読できます。