Blog

[Google Cloud Platform] GKEとSpinnaker


初めましてアドテク本部の李と申します。

今回は、Google Cloud Platform(GCP)を触ろうということでGoogle Container Engine(GKE) × Spinnakerというお題の基、GKEとSpinnakerの連携周りでどう設定すればいいのかを書こうと思います。

Spinnakerのドキュメントはまだまだ少ないのでこれからKubernetesとSpinnakerを触ってみようかな、もしくはSpinnakerのKubernetes周りの設定などでつまずいている方々の力になれればと思います。

まず、Kubernetesってなんなの??のおさらいです。Kubernetesについてまとめてみました。

 

概要

 

Kubernetesの概要を簡単に箇条書きにしました。

・複数のコンテナをpod単位でグルーピング

 -配備/削除、起動/停止を実行

 -pod作成時に使用するコンテナーイメージやCPU、メモリディスクスペースを指定

 -podの配備先を自動追尾、多重度の設定、スケールアウト

 -kubectlコマンドによりpodのイメージアップデートを自動化

・コンテナに割り当てるストレージの管理、IPアドレスの管理

・コンテナ間のネットワークルーティング管理

・複数のコンテナを利用した負荷分散

 -serviceを使用したリクエストのロードバランシング(内部的な処理)

・コンテナの監視(各種ヘルスチェック)

 -pod異常終了時の再配備

 -Webヘルスチェック

 -コンテナーExecヘルスチェック

 -TCP Socketヘルスチェック

 

構成

c8f7ab67-d952-9b1d-1b13-7a13deaf7473

pod

  ・Dockerコンテナをpodという単位で管理

  ・ストレージやIPアドレス等、複数のコンテナーのリソースをpod単位で共有

api server

  ・kube-apiserver、kube-schedulerで構成

  ・pod、Service、replicationcontrollerに対するRESTでの操作を受け付けてetcdに保存

  ・podのスケジューリングとpodの情報(Podの配置場所、ポート情報)とservice設定を同期

  ・kubecfg/kubectlコマンドにてREST実行

scheduler

  ・各ノードに対しコンテナを割り当て

  ・未スケジュールのPodをMinionに配置

replication controller

  ・podの多重度を設定し継続的に監視し調節

  ・pod数の調節を自動化

controller manager server

  ・コンテナの状態管理やノードの管理

  ・etcdにあるreplicationcontrollerオブジェクトを監視(watch)

  ・replicationを実行

minion

  ・Dockerコンテナ配置ノード

  ・minionの中では、Docker、kubelet、proxyが動作

  ・コンテナ数増加→minionを増加

kubelet

  ・minionをコントロールするエージェント(コンテナ作成/削除やボリュームの割り当て)

  ・master apiサーバから情報を受け取りcontainer manifestに従いコンテナを起動

proxy

  ・コンテナへのネットワークルーティングおよび負荷分散

  ・service設定によるTCP/UDPをPodに転送するためのネットワークプロキシ

service

  ・pod通信のエンドポイントを既定

  ・serviceはdocker空間のIPとポートを保持

  ・podはserviceにアクセスすることでPod間で通信を行う

  ・ロードバランサーの機能により、リクエストをPodに分散

  ・NodePort(外部からのアクセス)

   -ホストPortとリンク(= Docker expose設定)

   -LoadBalancerは外部のLBのIPアドレスを指定し通信を受け取る

kubectl

  API経由でKubenetesを操作するためのクライアントツール

 

ずらずら書きましたが、Kubernetesを使えば、コンテナクラスタが組めて、Dockerコンテナをグルーピングできて…要するにコンテナ環境を上手く管理できるよってことです。

このKubernetesコンテナクラスタを簡単に組めるのがGKEです。(もちろんLinux環境があれば問題なく組めます。) GKEではWeb UIもデフォルトで用意されています。接続方法はGKE → コンテナクラスタの接続から確認してください。

以下がWebUIです。YAMLファイルもしくはJSONファイルでデプロイするコンテナを設定できます。CUIとほとんど変わりません。ただコンテナのステータスやワークロードなんかも見れるので便利ですね。以前まではなかったように思いますが、最近変わった気がします。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-14-%e5%8d%88%e5%be%8c5-51-24

 

次にSpinnakerについてまとめておきます。

概要

Spinnakerの概要について箇条書きでまとめます。

・マルチクラウド対応の継続的デリバリープラットフォーム(Netflix製)

・アプリケーションのデプロイとクラスタの管理

・継続的デリバリーのプロセスを自動化

・デリバリープロセスを表す一連のパイプライン作成(アセットの作成から、デプロイで終了)

・パイプラインは拡張と再利用可能

・パイプラインの実行はコンパイルやJenkins、手動、cron等で開始(パラレルにもシリアルにも実行可)

・ビュー経由でデプロイしたクラスタのリサイズ、削除、停止

・Blue-Greenデプロイメントの切り替えも可能

 

機能

クラスタ管理

・基本構成はサーバグループ

 -複数のインスタンス、ロードバランサやセキュリティグループを含む

 -ソフトウェアが実行されているVMの集合体

・セキュリティグループ

 -IP範囲(CIDR)、TCP/UDP、ポート範囲のセットでアクセス制限

・ロードバランサ

 -サーバグループ内のインスタンス間のプロトコル、ポート範囲でバランシング

 -ヘルスチェック機能

 

デプロイ管理

・パイプラインは構成情報とステージで構成

 -構成情報にはトリガーやパラメータ、通知を含む

 -ステージではコンテキストなオペレーション定義(以下オペレーション)

  -Bake: 特定のregionにデプロイイメージ作成

  -Deploy: イメージのデプロイ

  -Destroy Server Group: サーバグループの削除

  -Disable Server Group: サーバグループの無効化

  -Enable Server Group: サーバグループの有効化

  -Find Image: 既存のクラスタにデプロイするイメージを検索

  -Jenkins: jenkinsジョブを実行

  -Manual Judgment: ユーザが承認するまでパイプラインの実行を待機

  -Modify Scaling Process: サーバーグループのスケーリング処理を一時停止/再開

  -Pipeline: パイプラインの実行

  -Quick Patch Server Group: サーバグループにパッチを適用

  -Resize Server Group: サーバグループをリサイズ

  -Script: 任意のシェルスクリプトを実行

  -Shrink Cluster: クラスタを縮小

  -Wait: 指定された期間待機

・通知

 -パイプラインの開始/完了/失敗に電子メール、 SMSまたはslack等に送信可

 

Spinnakerを構成しているマイクロサービス

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-21-%e5%8d%88%e5%be%8c4-24-45

deck

ユーザインターフェース

echo

通知サービスのメッセージングを制御

rosco

vmのイメージを作成

front50

パイプライン、通知およびアプリケーションのデータストア

clouddriver

・プラットフォームの統合
・プラットフォームの認証情報を管理

rush

汎用スクリプトエンジン、スクリプトの管理

orca

・ワークフローのオーケストレーションを提供
・pipelineとtaskの制御

gate

単一のエンドポイントとして異なるサブシステムのゲートウェイサーバとして動作

igor

jenkins、stash、およびGitHubへのインタフェース(ci連携)

 

Spinnaker…大体こんなところですかね。使いこなせればすごく便利ですよね?かなり多機能です。何といってもパイプライン制御でblue-greenデプロイができるのがいいです。

さらにデプロイもCloud Launcherからワンクリック?デプロイできます。今回はこれでデプロイしました。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-19-%e5%8d%88%e5%be%8c9-10-46

それでは、今回のSpinnakerの設定を見ていきましょう。現在、設定の詳細が書かれたドキュメントがあまり充実していないので、困っておられる方々は以下をベースにしていただけますとよろしいかと思います。

Spinnakerの設定

今回はDocker Hubの公開レポジトリを使用しています。もちろんGoogle Cloud Registry (GCR)も使えます。その際はこちらのGCRを参照していただくといいかもしれません。

Kubernetesを使用するには /opt/spinnaker/config/spinnaker-local.yml/opt/spinnaker/config/clouddriver.ymlの編集が必要です。

以下に設定の変更点を記述します。まずは/opt/spinnaker/config/spinnaker-local.yml です。今回はKubernetesを使用するので、providersセクションのKubernetesとdockerRegistryを以下のように変更しました。

 

/opt/spinnaker/config/clouddriver.ymlは以下のように設定しています。

設定完了後 restart spinnaker を実行します。

さて、SpinnakerのUIに接続してみましょう。SpinnakerのUIに接続するにはポートフォーワードする必要があります。ローカル環境で以下を実行してください。

完了後、 WEBブラウザから http://localhost:9000  でUIに接続ができます。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-19-%e5%8d%88%e5%be%8c9-18-28

ここまででSpinnakerを使用できる環境が揃いました。ここで注意すべきポイントがあります。

マイクロサービス群のログは全て/var/log/spinnaker以下に保存されています。clouddriverログに401 unauthorized errorが表示された場合、Kubernetesが動くGKEクラスタの認証情報が正確ではない、もしくはその情報を保持していない可能性があります。

Spinnaker(または構成するマイクロサービス群)はspinnakerユーザで実行されるため、/home/spinnaker/.kube/configをspinnakerユーザで作成しなければなりません。

その作成方法は以下のとおりです。

完了後、 restart clouddriverを実行してください。ログを確認するとエラーが解消されます。以下のようにApplicationの作成画面でKubernetesとDocker Registryのアカウントが表示されていれば問題ないです。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-19-%e5%8d%88%e5%be%8c8-37-39

今回はここまでです。

Spinnakerは、参画されている企業様を見ても分かる通り、かなり期待できる継続デリバリープラットフォームです。
今後は、GKE × Spinnakerの利用もますます増えてきそうですね。

最後まで読んでいただきありがとうございました。

Author

アバター
yeongjae

関連記事