これはKubernetes Advent Calendar 2014の18日目の記事です。

k8sカレンダーに書くネタは何にしようかと考えていて、最近ちょくちょく作ってたbigquery-fluentd-docker-sample（nginxのログをFluentdでBigQueryに流すサンプルのDockerコンテナ）をGoogle Container Engine (GKE)で動かしてみよう！動くだろDockerだし！と思った。しかし結果から言うと、現状のGKEではコレ動かない...orz

じゃあGKEじゃなくて素のk8sなら行けるかな？と思ってk8s環境を用意しようとしたら、これもいろいろハマって時間切れになってしまった。結局、当初の目標を達成できなかったのだけど、postmortemとして書いておこう。

GKEからBQ、何が問題か

FluentdからBQへ流すには定番のfluent-plugin-bigqueryを使うのだけど、GKEの場合はGCEからBQへの接続となるので、秘密鍵を置く必要はない。その代わりに、td-agent.confには以下のように書いておく。

<match nginx.access>
  type bigquery
  auth_method compute_engine

  project "#{ENV['GCP_PROJECT']}"
  dataset bq_test
  tables access_log

  time_format %s
  time_field time
  fetch_schema true
  field_integer time
</match>

こんなふうにauth_method compute_engineと書いておくと、プラグインがGCEのMetadata Serverから最新のアクセストークンを取得してくれるので、秘密鍵がいらない仕組み。GCPは認証が統合化されてて便利だね。

...のはずだけど、この仕組みを使うにはGCEのインスタンス作成時のオプションでOAuth2のスコープを指定しておく必要がある。こんなふうに：

$ gcloud compute instances create "bq-test" \
--zone "us-central1-a"  \
--machine-type "n1-standard-1"  \
--network "default" \
--maintenance-policy "MIGRATE"  \
--scopes storage-ro bigquery \
--image container-vm-v20140929 \
--image-project google-containers

ここで--scopes storage-ro bigqueryと指定している部分、これによってBQ接続権限を持つアクセストークンをMetadata Serverから取得可能になる。

現在のGKEではOAuth2スコープ指定ができない

で、GKEのクラスタ設定でこのスコープを指定するところってどこ？と探したけど、

うーん、GKEのUIにはないね。じゃあCLIではどうかな？

あれ、それっぽいオプションないね。

k8sエキスパートのYさんに相談してみたら、「そうなんですよねー、スコープ指定できないんですよ」とのお返事。結局、GKEでは未対応ということが判明...orz GKEのissueとして上がってたので、これは困りますとコメントしといた。

4/19追記

GKEでのスコープ指定、対応しました。詳しくはコメントをご覧ください。

k8sなら行けるかも

秘密鍵方式に変更すれば動くかもだけど、なんだかスマートでないので、GKEでのBQ接続は断念。

一方で、素のk8sならGCEインスタンス作成時のscopeオプション指定できそうだ。

MINION_SCOPES=("storage-ro" "compute-rw")

そこで、作戦変更してk8s環境を用意することにした...が、

GCEインスタンスでkube-up.shを動かそうとしたら、GCS認証まわりでエラー
Mac上のboot2dockerでkube-up.shを動かそうとしたら、なぜかsegmentation faultで落ちる

などなどの事象でハマってしまった。最終的に、手元のUbuntuにk8sを入れて、kube-up.shが正しく動作し、nginxサンプルが動いたところで時間切れとなってしまった。

というわけで、GKE、まだAlpha版なので暖かく見守ってあげてください。

Disclaimer この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり､私の雇用者には関係はありません｡