Edited at

GKEを便利にするGCPのサービス

More than 3 years have passed since last update.


Google Container EngineとKubernetes

Google Container Engine (以下GKE) は Kubernetes (以下k8s) というコンテナ管理アプリケーションを載せた基盤を構築するサービスだ。GKEは Google Cloud Platform (以下GCP) の幾つかのサービスを使って構築されているので、GCPの各サービスの恩恵を受けることができる。このエントリでは、GCPの恩恵によってGKEがより便利になる事柄を紹介する。


k8sとは

まずk8sとは何なのか。ここではk8sを使う為に理解すべき事柄を中心に紹介する。


k8sにまつわるよくある勘違い

k8sはDockerコンテナを動かすための基盤ではない。Dockerコンテナは手段でしかなく、k8sの本質はコンテナをスケーラブルに運用するための基盤である。そのために様々な概念や設定がでてくるが、これは本質を実現するために避けて通れない事柄だ。


k8sを構成する概念


k8sを構成する要素



  • Contianer: Dockerなどのコンテナ。


  • Pod: 複数のContainerのホスト。


  • Cluster: 全てのPodを格納する為の基盤。


k8sの要素を操作する為の機能



  • Service: 外部からの通信をロードバランシングをしてそのサービスに関連するPodにリクエストを割り振る。


  • Replication Controller: Podを監視し何かしらの原因でPodが死ぬとPodを立ち上げ、指定した数のPodを維持する。ユーザーが複数のPodの存在を意識する必要はない。



    • Horizontal Pod Autoscaler: Replication Controller に対してPodのオートスケールをする。


    • Rolling Update: Replication Controller の複数のPodを順番に新しいContainerで構成されるPodに入れ替える。




ClusterNodeの関係

まず、NodeとはClusterを構成するGCPインスタンスだ。Clusterは複数のNodeから構成することができるが、ユーザーが複数のNodeの存在を意識する必要はない。


GKEにおけるk8sがもたらしてくれるもの


  • 負荷によって適切にPodを増減することで、1つのアプリケーションを安定して動かしてくれる。

  • 1つのClusterで複数のアプリケーションを動かすことができる。1つのアプリケーションをServiceとして適切にグルーピングしてくれることによって、ユーザーがネットワーキングについて意識する必要はない

  • 1つのClusterで複数のServiceがインフラリソースを共有している状態になる。


k8sのメリット


コストパフォーマンス

複数のアプリケーションが1つのClusterでインフラリソースを共有しつつ動作するので、複数のアプリケーションを運用する場合コストパフォーマンスに優れる。例えば開発用に本番環境と同等の環境が欲しいといった場合にも、インスタンスを立ててデプロイするのではなく既に稼働しているClusterに新たなServiceをデプロイしたらよいので、追加コストがほぼ発生しない。特にマイクロサービスをいくつも運用する場合などはこのメリットが顕著になるだろう。


デプロイに対するフットワーク

新しいServiceを作る、新しいReplication Controllerを作るということが、新たにインスタンスを立てることなく行えるので、新しいアプリケーションのデプロイが楽。また、開発環境やステージング環境も楽に構築できる。


k8sのデメリット


単一アプリケーションだと低コスパ

1つのClusterで1つのアプリケーションを運用することも当然可能だが、ある程度スペックの良いインスタンスが必要なのでコストパフォーマンスが下がる。


GKEを便利にするGCPのサービス

これらの前提を押さえた上でやっと本題。


GCPのオートスケーラ

Google Compute Engine (以下GCE) のインスタンスグループにはオートスケーラ1がある。GKEはCluster生成時にGCEのインスタンスグループを作るので、そのグループに対してオートスケールの設定をすることができる。前述のPodの水平オートスケールと合わせると次のようなシナリオが考えられる。


  1. アクセスが増える


  2. Podに割り当てられたCPUリソース使用量が閾を超える


  3. Podがスケールして増える


  4. Podが増えたことでNodeのCPUリソース使用量が閾を超える


  5. Nodeがスケールして増える

  6. アクセスが減る


  7. PodのCPUリソース使用量が閾以下になる


  8. Podが減る


  9. NodeのCPUリソース使用量が閾以下になった状態でクールダウン期間を経る


  10. Nodeが減る

永久機関感ある。自分は実際にこの構成で運用し始めている。今後問題が生じたらまたエントリにしようと思う。


Google Cloud Monitoring

GKE用のリソースをモニタリングする為のUIが用意されている。各NodePodContainerのリソース使用量がモニタできる。k8s標準のkube-uiではモニタリングできないような細かな情報を得ることができる。


Google Container Registry

Contaienerとして動かすDockerイメージをホストしてくれるプライベートな保管庫だ。差分プッシュをサポートしているのでビルドの度に大きなイメージを転送する必要はない。コマンド1つでイメージのプッシュが完了する。物理的な保存先として Google Cloud Storage を使用している。


最後に

素晴らしいk8sというアプリケーションを、周辺サービスの揃っているGKEで使ってみてはどうだろうか。