[Google Cloud Platform] GKEとSpinnaker |

Blog

2016.11.7

[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ヘルスチェック

構成

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とほとんど変わりません。ただコンテナのステータスやワークロードなんかも見れるので便利ですね。以前まではなかったように思いますが、最近変わった気がします。

次に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を構成しているマイクロサービス

deck

ユーザインターフェース

echo

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

rosco

vmのイメージを作成

front50

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

clouddriver

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

rush

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

orca

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

gate

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

igor

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

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

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

それでは、今回の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を以下のように変更しました。

  kubernetes:
    enabled: true (←kubernetesの使用の有無)
    primaryCredentials:
      name: my-kubernetes-account (←spinnaker上で使用するアカウント名：任意)
      dockerRegistryAccount: ${providers.dockerRegistry.primaryCredentials.name} (←以下のdockerRegistry:で使用するアカウント名)

  dockerRegistry:
    enabled: true (←Docker Registryの使用の有無)
    primaryCredentials:
      name: my-docker-registry　(←spinnaker上で使用するアカウント名：任意)
      address: https://index.docker.io (←使用するdocker registryのaddress)
      repository: library/nginx (←使用するrepositry)

kubernetes:

enabled: true (←kubernetesの使用の有無)

primaryCredentials:

name: my-kubernetes-account (←spinnaker上で使用するアカウント名：任意)

dockerRegistryAccount: ${providers.dockerRegistry.primaryCredentials.name} (←以下のdockerRegistry:で使用するアカウント名)

dockerRegistry:

enabled: true (←Docker Registryの使用の有無)

primaryCredentials:

name: my-docker-registry　(←spinnaker上で使用するアカウント名：任意)

address: https://index.docker.io (←使用するdocker registryのaddress)

repository: library/nginx (←使用するrepositry)

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

kubernetes:
  enabled: true
  accounts:
    - name: ${providers.kubernetes.primaryCredentials.name}
      dockerRegistries:
        - accountName: ${providers.kubernetes.primaryCredentials.dockerRegistryAccount}

dockerRegistry:
  enabled: true
  accounts:
    - name: my-docker-registry
      address: https://index.docker.io
      repositories:
       - library/nginx

kubernetes:

enabled: true

accounts:

- name: ${providers.kubernetes.primaryCredentials.name}

dockerRegistries:

- accountName: ${providers.kubernetes.primaryCredentials.dockerRegistryAccount}

dockerRegistry:

enabled: true

accounts:

- name: my-docker-registry

address: https://index.docker.io

repositories:

- library/nginx

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

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

 gcloud compute ssh {Spinnakerが実行されているインスタンス名} --ssh-flag="-L 8084:localhost:8084" --ssh-flag="-L 9000:localhost:9000" --ssh-flag="-L 8087:localhost:8087"

1	gcloud compute ssh {Spinnakerが実行されているインスタンス名} --ssh-flag="-L 8084:localhost:8084" --ssh-flag="-L 9000:localhost:9000" --ssh-flag="-L 8087:localhost:8087"

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

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

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

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

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

 su - spinnaker
 gcloud container clusters get-credentials {Kubernetesが動いているGKEクラスタ} --zone {GKEクラスタがデプロイされたゾーン} --project {プロジェクト名}
 gcloud config set container/use_client_certificate true

su - spinnaker

gcloud container clusters get-credentials {Kubernetesが動いているGKEクラスタ} --zone {GKEクラスタがデプロイされたゾーン} --project {プロジェクト名}

gcloud config set container/use_client_certificate true

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

今回はここまでです。

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

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

Author

yeongjae