kubernetesのnode運用の具体例

kubernetesのインフラ運用の楽な点は、dockerコンテナとサーバーを切り分けて運用できる点です。

dockerのイメージが完成していれば、サーバーのクラスタを指定して起動するだけです。

ハードを交換する場合にも、OSレベルの環境バックアップ・構築はDockerで完結しているため、新しいクラスタを用意してコンテナを起動それば良いので、非常に手早く対応できます。

Google Kubernetes EngineのNode Pool

Googleのkubernetesホスティングサービス”Kubernetes Engine”(GKE)は、Node Poolという機能を提供しています。

これはnode（仮想マシン）のグループを作成する機能で、１つのクラスタの中で複数の実行環境を管理するものです。

Google Cloudの多彩なサイズのマシンタイプ（n1-standard, n1-hignmem, …）から処理能力の異なるプールを作成できます。

たとえばDBMSはCPU/メモリ性能の高いプール、Webフロントは比較的低スペックでマシン数の多いプール、というように特性に合わせたハードにコンテナをアサインできます。

Node Poolの利用手順

ノードプール作成

まず、gcloudコマンドでコンテナ実行環境となるNode Poolを作成します。なお、Google CloudのWebコンソールなどで、クラスタ（例ではcluster1）はあらかじめ作成しておく必要があります。

$ gcloud container node-pools create standard-pool --cluster=cluster1 --machine-type=n1-standard-1 --disk-size=100 --num-nodes=2 --zone=asia-east1-a

上の例では、poolの名称はstandard-poolです。オプションは、クラスタ名、マシンタイプ、各マシンのディスクサイズ（単位：GB）、実マシン数、データセンターのゾーンをそれぞれ指定しています。

動作状況は、kubectl get nodesを実行した際のノード名称に含まれているpool名で確認できます。

なお、GKEのnodeに使用するマシンタイプはn1-standard-1以上をおすすめします。

f1-microやg1-smallは共用サーバーであるためか、内部のネットワークが不通になったり、不定期にコンテナが一斉に異常終了する現象がそれなりに頻発します。

とくにkubernetes v1.2までの環境では、インフラのAPI応答品質が低い場合、仮想マシンじたいの動作が安定していても低品質なノードと見なして復旧処理が走る仕様になっているため不安定になりがちです。

実際に運用してみたところ、g1-small x 3台よりも、n1-standard-1 x 1台構成の方が安定動作しました。

プール指定でコンテナ起動

作成したNode Poolへのコンテナ割り当ては、kuberunetesのnodeSelector機能を利用して、コンテナ起動時にReplication Controllerの設定ファイルに記載します。

spec:
    containers:
      (略：コンテナ設定)
    nodeSelector:
      cloud.google.com/gke-nodepool: standard-pool

このnodeSelectorの2行の設定のみで、コンテナ起動時にプールが検索されます。

cloud.google.com/gke-nodepoolというラベルはgcloud container node-pools createした際に自動で割り当てられています。

あとは一般的な手順通り、kubectl create -f replication_controller_setting.ymlのように起動するだけです。

動作状況は、kubectl describe pod some_podを実行した際に”Node”欄の名称に含まれているpool名で確認できます。

ノードプールの削除

不要になったnode poolはdeleteコマンドで削除できます。

$ gcloud container node-pools delete standard-pool

※ なお、Kubernetesのノードプールとは別にCompute Engine(サーバーインフラ)のレイヤで仮想マシンが意図したとおりに削除されているか、という点も確認した方が良さそうです。インスタンスグループで仮想マシンのサービスレベルが設定されていたため、VMが削除されずに課金が継続されていた例に遭遇しました。VMが稼働し続けていることに関するアラートはないため、注意していないと気づきにくいケースといえます。